Is your team not delivering the needed outcome? Do you keep building the wrong thing? Does the solution work but doesn't solve the problem? Maybe your Agile Team lacks analytical thinking. Everyone in your team can apply critical and analytical thinking to create better outcomes and higher value levels for your customers.
2. Our Working Agreement
• It's OK to ask questions
• We want to interact with the content
• It's OK to heckle
• We want to share examples
3. You are an agent of
change
• I will talk about how you enact
change in others
• I am not going to teach you
how to perform analysis
practices
• I am going to share a real
world approach I use with Agile
teams every day
Pssst, you
could get better
Sprint
outcomes if you
spent more time
thinking
4. Warm up exercise
• Which buttons can we push
without crashing the plane?
• Can we push this one?
• What about this one?
5. What is Analytical
Thinking?
• The ability to
1. Identify & define problems
2. extract key information from data
3. develop workable solutions for the
problems identified
4. test and verify the cause of the
problem
5. develop solutions to resolve the
problems identified
6. The ADAPT Approach
A process to create change
Awareness
Desire
Ability
Promotion Transfer
There must be awareness
that the way the team does things
now isn’t as good as it
could be
If there is awareness
is there enough desire
to actually want to
do something about
it
Once awareness &
desire are present
deal with the capabilities of
the people to work in a
new way
When you get the wins, promote
them a lot, get the good stories out
there to help cement and promote
the desire to change
Transfer will occur as stories
are told. Teammates will want
to be part of the change. Help
teammates that want to
change
8. Real world Agile Team Observations
Order taking
a solution
statement
End up not solving
the root cause?
Missed
opportunity to
reuse existing
capability?
You purchased
Sledgehammer to
crack a nut
Start coding
right away
the problem is not
really understood
End up with
bloated buggy
code
Code refactoring
frequency is high
Designing
without initial
requirements
The design is a
guess, expect lots
or redesign later
on
Inability to
integrate with
emerging
requirements
Reduction of trust
from Stakeholders
as the design
doesn't meet
expectations
Not
considering
Business
Rules
Holes in the
solution that
increase risk
profile
Loss or damage
through
unexpected use
Cause your
business to be
fined due to
breach in
compliance
11. Building Desire to change
• Assume we have
created awareness
that there is a lack of
analytical thinking
being practiced in the
team. How do we
build desire to
change?
Team
experiment
Articulate
the change
gains
Show the
art of
possible
Primary
sponsor
endorsement
Team
incentive
reward
Positive
coaching
involvement
12. Old vs. New, what could it look like?
Old Behaviour
• Start with Code right away
New Behaviour
• Team gathers at the whiteboard to
model a system context diagram
that the user story is in scope for
• Order taking of a Solution • Team pushes back in favour of Root
Cause Analysis workshop and a Spike
story to check for existing capabilities
• Not considering business
rules
• At the start of sprint, the whole team
works to define the rules for the top
5 PBI’s before anything else
16. Feature or
User Story
Who?
What?
Why?
Success /
Acceptance
Criteria
When?
Where?
How?
Know your
Stakeholders
Understand
Root Cause
Strategy
Alignment
Understand
Scope
Understand
Need
Understand
constraints
Understand
Structure
Understand
the process
Understand
the behaviour
Understand
its design
Persona
Modelling
Stakeholder
Analysis
Decision
Mapping
Rule Flow
Diagram
Business Rule
Model
5 Whys
Fishbone
Diagram
Purpose Alignment
Model
Impact Mapping
Scope Context
Diagram
Value Proposition
Canvas
Empathy Map
Domain Model
Use Case
Diagram
Flowchart
BPMN 2.0
NFRs
Data Modelling
System Context
Diagram
Prototyping
Metrics Analysis
(AARRR, HEART, Impact)
Documentation
Analysis
UX Modelling
Lotus Blossom
17. Lets check our toolkit is geared up for Analytical
Thinking
• The ability to
1. Identify & define
problems
2. extract key information
from data
3. develop workable
solutions for the
problems identified
4. test and verify the
cause of the problem
5. develop solutions to
resolve the problems
identified
5 Whys
Fishbone
Diagram
Value Proposition
Canvas
Domain Model Data Modelling
Prototyping
Decision
Tree/Table
Use Case
Diagram
Flowchart
Business Rule
Model
NFRs
NFRs
Decision
Tree/Table
Use Case
Diagram
Flowchart
Business Rule
Model
NFRs
Documentation
Analysis
System Context
Diagram
System Context
Diagram
Data Modelling
Persona
Modelling
Flowchart
Analytical Thinking is:
19. The Scope or System
Context Diagram
• Why?
• Provides the team with a Big
Picture view
• Visually conveys the scope of a
product or project
• When?
• Early on in a project
• Review and embellish at the start
of a sprint
• Who?
• The whole team should be
involved
System Context
Diagram
20. The Flowchart
• Why?
• A flowchart show you where things
will occur
• When?
• At the start of sprint or
commencement of a User Story
• Who?
• Whoever is working on the User
Story with you
Flowchart
21. Prototyping
• Why?
• Prototypes allow teams to get aligned
quickly
• A tangible example will quickly allow
feedback from customers
• When?
• May have been done as part of
discovery
• At the start of the Sprint of the User
Story.
• Who?
• The whole team will benefit from the
visualization of what they are building
Prototyping
22. Impact Mapping
• Why?
• Helps avoid jumping to solution mode
• Allows team to bridge the gap between
Business Impacts and Feature Ideas
• When?
• Early on in a Project or Product
• Repeat throughout the development
• Who?
• Whole team, Product Owner and
Stakeholders
Impact Mapping
23. Decision Mapping
• Why?
• So that the solution created
upholds the constraint set by
the Business Rule
• So that operational business
decision making is maintained
• When?
• Foundational rules can be set
early in a Product Dev cycle
• At the start of a Sprint
• Who?
• Whole team will benefit from
understanding the constraints
Decision
Mapping
26. Links and referenced used page 1
(3) Why Agile Needs Analytical Thinking | LinkedIn
Secrets of Successful Agile Analysis: How to Make Your Business Analysis Skills Indispensable (bridging-
the-gap.com)
The Importance of Critical Thinking In An Agile Business Operation - The Daily MBA
Problem Solving, Critical Thinking, and Analytical Reasoning Skiills Sought by Employers - Radford
University
Analytical Thinking and Critical Thinking - The Peak Performance Center
AnalyticalThinking.pdf (csu.edu)
ADAPTing to Agile (mountaingoatsoftware.com)
Chapter 7 Don’t Rush into Coding | Engineering Production-Grade Shiny Apps (engineering-shiny.org)
Desire - The Prosci ADKAR Model
(4) 6 Powerful Ways To Create Desire For A Change Initiative | LinkedIn
27. Links and referenced used page 2
What is the AARRR Pirate Metrics Framework? | Definition and Overview (productplan.com)
Four Frameworks to Help You Define Product Metrics | by Anthony Murphy | Product Coalition
What is a Context Diagram (and How Can You Create One)? - Venngage
Use Case Diagram Tutorial (visual-paradigm.com)
Lotus Blossom Technique Ideation Guide (visual-paradigm.com)
How to Use Value Proposition Canvas: The Definitive Guide (digitalnatives.hu)
Empathy Mapping: The First Step in Design Thinking (nngroup.com)
Guideline: How to Create a Domain Model? in UML Tutorial 14 July 2022 - Learn Guideline: How to Create a
Domain Model? in UML Tutorial (13288) | Wisdom Jobs India
Associations in UML Tutorial 14 July 2022 - Learn Associations in UML Tutorial (13290) | Wisdom Jobs India
5 Whys - Problem-Solving Skills From MindTools.com
What is a Fishbone Diagram? Ishikawa Cause & Effect Diagram | ASQ
28. Links and referenced used page 3
WhitePaperonPurposeBasedAlignmentModel.pdf (alaska.edu)
A Guide to Impact Mapping (With Examples!) (getstream.io)
A Guide to Paper Prototyping (POP) - Create Basic Prototypes on Paper - Marvel Blog (marvelapp.com)
How to Create a Customer Journey Map | Lucidchart
Data Modeling 101 (agiledata.org)
Nonfunctional Requirements - Scaled Agile Framework
Business Process Model & Notation - BPMN Introductory Guide | Signavio
Flowchart Tutorial (with Symbols, Guide and Examples) (visual-paradigm.com)
How to Do a Stakeholder Analysis | Lucidchart Blog
9 Steps to Create a Persona - A Guide with Examples (uxpressia.com)
What is Decision Tree? - Easily Learn Key Points with Examples (edrawsoft.com)
How to Model Business Rules - DZone Agile
Hinweis der Redaktion
Set up a working agreement with the attendees
Are we in the air yet?
Is this a simulator
Are we on the runway
We need to understand the scope of what we are going to change before we change it. What impacts will there be, what might we break, what do we need to be aware of. Jumping in feet first is usually always the wrong thing to do
When building solutions Scrum doesn’t really talk about what you need to do before you build in the Initiation phase of the work, but there is still information and knowledge we need to understand for context and for safety
My brother in law loves to jump into queries and I am always reminded of how dangerous jumping into anything without first checking the surroundings are. How deep is the water, what is under the water. Is the water toxic? I don't need to understand the whole lake, just the details about the bit I am jumping into
There are many definitions of Analytical thinking. This is the one that resonates best with me based on the work I have done and still do on a daily basis. This is almost the core of my current job description!
Defining problems not just order taking solution statements
Data is a collection of facts, while information puts those facts into context. While data is raw and unorganized, information is organized
Create cheap workable solutions to be able to test if the hypothesis regarding the root cause of the problem is right or wrong
Test and verify the cause using process maps, mock ups, prototypes, what ever is the cheapest why to robustly test the hypothesis
Work to develop the final solution that has proven in the previous step to solve the root cause. That might be as simple as Training and Education or it might be complex and expensive, like building a customer app.
AnalyticalThinking.pdf (csu.edu)
Let’s park the concept of Analytical thinking for a moment and talk about a process for creating change in people and teams.
During this presentation we will follow the ADAPT Process as it helps put some structure and process around what we can do to help enact change in our teams
But its also a process I recommend when working with your Agile teams to introduce new ideas and concepts for change
Awareness
Communicate the problem
Use metrics
Provide exposure to new people and experiences to see how it could be different
Focus on 1 or 2 key reasons or benefits for changing
Desire
Communicate that there is a better way
Create a sense of urgency
Build a momentum
Get the team to test drive a new way of operating
Focus on addressing fears
Help team mates to let go
Don't discredit the old way of doing things
Engage all teammates in this new adoption
Ability
Provide coaching and training
Hold individuals accountable
Share info
Set targets
Like any good Analyst we should stop and ask the question. What problem are we trying to solve. Alternatively, if the problem definition is not forthcoming reframe the statement to what outcome would we like to be able to observe? Tell a story about what the world looks like now that the problem, what ever it was, has been resolved.
Straight to Solution Example: Your team has been told what the solution is or worse handed the solution that has been purchased. You discover that it doesn't integrate with your existing infrastructure. You discover that your business already had a solution to the problem and now you are paying double. The worst is that the solution doesn't even solve the problem as it turns out problem is still occurring
Starting with Code Example: The User Story says that users must be able to log in using method X. That’s all you need to know, so its straight to coding to build the tech implementation, packages, the pieces of code. You end up building something carelessly complex instead of relentlessly simple. And next sprint when the user story says Users must be able to log in using method Y, you realize you have to massively refactor your work because you didn't think about how your functionality might need to be modular and encompass other forms of log in, you didn't ask any questions about that last sprint at all, you just went straight to coding.
Chapter 7 Don’t Rush into Coding | Engineering Production-Grade Shiny Apps (engineering-shiny.org)
Designing without requirements example: You start designing for a Car Parking solution without a good level of high level business requirements or Initial User Stories. Your company operates and integrates 3 other car parks, how much different could it be. Just grab the design from the library, rename it and that’s a good start, model it out for the data flows and load balancing, job done. When you are implementing and the Business ask, where are the hand held devices that need to manually operate the Car Park boom arm?
Not considering Business Rules example: Imagine your team is building an automated loan approval solution. You know the basics that the customer needs to have enough disposable income to service the loan. However you didn't dig deeper and discover that this year your financial institution is not approving loans for people with outstanding debts of a certain amount. If this is missed your solution will hand out approvals that will increase the risk profile to the business and potentially hurt their S&P Rating
All of these symptoms and their effects make for very unsatisfied customers
Why Agile Needs Analytical Thinking | LinkedIn
Let’s revisit an article I wrote back in 2016
What is the AARRR Pirate Metrics Framework? | Definition and Overview (productplan.com)
Four Frameworks to Help You Define Product Metrics | by Anthony Murphy | Product Coalition
Impact Mapping: How to focus on outcomes in product management (miro.com)
Once upon a time, there was a land where the whole community lived under one big glass dome. For generations, the families had been born, lived and died under the glass dome. And the story that passed down from generation to generation was if you ever did step outside of the glass dome, you would surely die. So no one had ever dared to step outside the glass dome.
In fact, the community had decided that there was no crime so dastardly that the punishment for anyone who committed that crime would be to banish him outside the dome which would be certain death for him.
No one — but no one — had ever committed that crime. Then one day, to the community’s horror, a man did commit such a crime.
The punishment was swift. The whole community escorted the man to the edge of the glass dome and pushed him out into the world beyond. Then they all pressed their noses to the wall of the glass dome to watch the man die.
At first, the man laid on the ground, face down, shivering in his fear of how death would come to him. His muscles were all clenched up as he braced himself for what would certainly happen.
But nothing happened. After a bit he rolled over and looked around, and seeing nothing threatening, he ventured to sit up and look around. As the people in the glass dome watched intently, the man slowly stood up and looked all around him. And then, to their amazement, the man began to dance softly in the green, green grass — moving this way and that way, trying out his arms and legs that seemed to work perfectly well.
And then he began to jump up and down, and to shout joyously, and to beckon to the people under the glass dome to COME ON OUT AND DANCE WITH ME!! The people were filled with confusion and bewilderment to see this happy dancing man when they had expected to see him die a horrible death. The confusion and stress grew so great within them that they finally had to take action. They got buckets of black paint and large paintbrushes. They started at the bottom of the walls and painted the walls solid black, up as high as they could reach and as high as necessary so they could no longer see the dancing man. They then all breathed a sigh of relief and went back to the way things had been before that day.
And what was the crime the man had committed . . . he was an innovator.
Wallace Ford
