Agile Maturity Assessments

Agile Maturity Assessments
Simple Templates for Scrum and Agile
June 2023 David Hanson

2
Have you tried assessing the maturity of your Agile teams? Have you
developed your own unique approach or adopted an approach found online?
Have you found the assessments valuable and continued them?
This session introduces a very simple, straightforward approach for Agile and
Scrum maturity assessments without the complexity and pitfalls of numerous
more sophisticated approaches.
David has used five different approaches to assess Agile maturity over the
past decade, three developed by Agile coaching staff and two developed by
himself, before adopting this simpler retrospective Agile maturity assessment.
David is currently an Agile coach at Mass General Brigham.
Agile Maturity Assessments
David Hanson
dphanson63@yahoo.com | https://www.linkedin.com/in/david-hanson/ | https://www.slideshare.net/DavidHanson5
David Hanson | ANE 101
01:12

3
Tried five different Agile maturity assessments before
developing this retrospective approach.
First approach was Eliassen’s 36x5 rating matrix with
180 detailed descriptions for each possible rating
which proved too time-consuming.
Second approach shifted the details from rating to
topic (only 36 detailed descriptions). In the end, still
too sophisticated and too discouraging.
Third approach was a simple 36-question yes or no
checklist. Might have worked, but didn’t provide
insights towards improvement.
Fourth approach was State Street’s Agile
maturity stories. Teams could earn Bronze,
Silver, Gold and Platinum badges. Solid but
required serious investment in time and effort.
Fifth approach was a checklist of questions
created by an Agile coaching staff. The least
mature teams evaluated high and the most
mature teams evaluated low.
These experiences have led me to this sixth
approach with a simple retrospective on the
Scrum framework.
My Maturity Assessment Experience
David Hanson | ANE

Who has tried an Agile
maturity assessment?
How did it work out?

Why bother with Agile
maturity assessments?

6
Eliassen’s Maturity Matrix, 2011-13 My Maturity Matrix, 2017
My Original Inspiration
https://info.eliassen.com/agile-maturity-matrix
David Hanson | ANE
Benefits to
the team
Current
Level
Impeded (0) In transition (1) Sustainable (2) Agile (3) Ideal (4) Comments
Being Agile No understanding of the spirit of
Agile
Doing the mechanics 80% of the team can explain the benefits of Agile,
believe in the benefits of Agile, understand the spirit
of Agile. The team is making improvements on a
regular basis
Working in an Agile manner Actively pursuing new ways of working in an Agile
manner
Productivity,
Quality
Morale Blame game, finger pointing, denial,
anger, shouting, backstabbing,
passive aggressive, turn-over and
other behaviors on a regular basis.
Desire to go back to the old ways,
active resistance to change,
scapegoating. There is churn or
people are frequently making
references to quitting or how much
they dislike their work or work
environment.
There are still elements of previous state, but there is
steady progress away from those behaviors,
problems are being actively addressed, and there is a
general feeling that morale is improving
For the most part people are getting along and happy
at work. There is very little if any talk about "going
back" and it is generally believed that things are
either better than before or at least not worse
The team generally believes that their work life is
significantly better than before. They are happy,
engaged, productive, and genuinely enjoy working
together.
Most team members feel like this is one of the best
teams they have ever worked on, they are excited to
come in to work and are looking forward to the next
day when they leave.
Productivity,
Quality
Tuckman
Stage
Forming Storming Norming Have been performing consistently for at least 8
weeks
Have been performing consistently for the past 6
months
Productivity,
Quality
Working
agreement
Non-existent Some defacto team norms that are generally
recognized, but haven't yet been written down and
agreed on by the team.
Written down, agreed on by the team, clearly visible
in a public area such as the team room.
Followed by the team Followed naturally, very short list, highly visible,
exceptions are quickly identified and addressed.
Team size >20 people on team It is recognized that a smaller team size is needed
and there is either a near term plan or the team is
actively being reduced in size.
< 20 people on the team < 10 people on the team 7 +/- 2 people on the team
Productivity,
predictability,
customer
satisfaction,
employee
Dedicated
resources
Most team members are on
multiple teams or working on
multiple projects
Most people are 50% dedicated to the team. Nobody
is less than 30% dedicated to the team.
Most people are 100% dedicated to the team,
nobody is less than 60% dedicated to the team.
Productivity,
employee
satisfaction,
predictability,
customer
Continuity /
Standing
team
Constant churn of people on the
team and/or team was formed for a
single release or a single major
initiative and will be disbanded after
There is an understanding that this is important,
progress is being made, and further steps are being
taken to get to the next stage
50%+ of the team is constant over the past 9 months
and team has made multiple production releases or
worked on multiple major initiatives without being
reformed each time.
More than 70% of the team is constant over the past
9 months and team has made multiple production
releases and worked on multiple major initiatives
without being reformed each time.
More than 90% of the team has been constant over
the past 12 months
Productivity,
predictability,
quality
Cross
functional
A significant portion of what is
needed to get the stories to done
exists outside of the team
Some of the skills necessary to get the stories to
done exists outside of the team
All of the necessary skills for performing the work
exist on the team
exist on the team and there is some cross training of
skills
exist on the team and most of the team is cross
trained on most of those skills
Productivity,
responsiveness
and time to
Collocation Team members have very little
proximity to each other.
Plans are in place to move team members as close to
each other as is currently feasible.
Most team members are accessible to any other
team member within 30 seconds
Most team members sit within hearing distance of
each other
Most team members are sitting in a team area
together.
Employee
satisfaction,
productivity
Self
organization
Most people do not have the ability
to choose what they work on,
estimates are not determined by
the team. Team does not feel like it
can make decisions on its own.
Some members just want to be told
Some of the behaviors from the next stage are being
discussed, encouraged, or tried
Teams are pulling work from the product backlog
themselves, doing their own team-based estimation,
choosing what to work on themselves, and using the
definitions of ready and done to guide interaction
with those outside the team.
The roles and responsibilities of the Scrum Master
are shared by the entire team and the need for a
designated and/or dedicated Scrum Master is
significantly reduced. When some members of the
team are not present, the team is able to adjust and
continue getting stories done.
The team is self organized
Quality,
employee
satisfaction
Sustainable
pace
People are tired, irritable, burnt out,
working overtime on a regular basis.
Current situation is considered
business as usual.
There is a recognition that the current pace is not
sustainable and steps are being taken to improve the
situation.
Consensus is that the team is working at a pace that
is close to sustainable indefinitely, though the
workload is still inconsistent with bursts of heavy
work loads
Consensus is that the team is working at a pace that
is sustainable indefinitely, though there is still
occasional crunch time
Steps are actively taken by the organization and the
team to make sure that the team has a high morale,
works no more than 40 hours per week, takes all
vacation days and is a high performing team
Quality,
productivity,
customer
satisfaction
Multi-team
synchronizati
on
Synchronization with other teams
that are working together toward a
common deliverable is either ad-
hoc or done primarily through up-
front planning and setting iteration
content towards a planned
integration phase
Team synchronizes with other teams using at least
one of the methods in level 4
Team uses as least 2 of the methods from level 4 and
integrates their work with the whole product at least
every 4 weeks
Team uses at least 3 of the methods in level 4 or
equivalent, and there is little or no pre-planning of
iteration content towards a planned integration
phase (integration is continuous)
Team synchronizes with other teams by having
common iteration start/stop dates (or use Kanban),
standup-of-standups (or similar), retro-of-retros (or
similar), and participates in a whole-product review
on a frequent basis.
Productivity,
Quality
Impediments Invisible and/or ignored. Fear of
reprisals. Reluctance to raise
impediments. Impediments that are
raised are not resolved.
Raising impediments is actively encouraged and is
frequently done. Some impediments are resolved.
The team is beginning to see the benefits of this
practice and feel comfortable practicing it.
Raising impediments is becoming routine and there is
a high degree of comfort in doing it. Impediments are
usually resolved. Root cause analysis is sometimes
performed and there is a growing recognition of the
value of raising impediments.
Impediment raising and resolution are a cultural
norm. Individual and team impediments that can be
addressed at those levels are addressed. Root cause
analysis is frequently performed and acted on.
Root cause analysis and resolution is a cultural norm
Predictability,
quality,
productivity,
customer
satisfaction
Shippability No stories shippable in less than
four weeks from ready to done
Shippability is measured and visible Team strives for shippability 60% of story points go from ready to done in less
than four weeks
90% of story points go from ready to done in less
than two weeks
Predictability,
quality,
productivity,
customer
satisfaction
End-to-end
cycle time
A year or more from concept to
ready to release
Can get from concept to ready to release in 6 months Can get from concept to ready to release in 3 months Can get from concept to ready to release in weeks Days from concept to ready to release
Quality,
predictability,
productivity,
customer
satisfaction
Product
vision
Not defined It is written down somewhere or the product owner
or similar person knows what it is
There is a written definition which is accurate and
well known by everyone involved
There is a compelling product vision which can be
clearly articulated by the product owner or similar
person
Simple, clear, compelling, everyone involved can
articulate it well.
Quality,
predictability,
productivity,
employee
satisfaction
Stories follow
INVEST
No knowledge of INVEST Team understands INVEST and is starting to follow
parts of it on some stories.
Following most of INVEST on many stories Following INVEST for most stories Following INVEST for all stories
Quality,
predictability,
productivity,
employee
satisfaction
Definition of
ready
Does not exist There is an understanding of the need for a definition
of ready and/or there is a tacit agreement for the
content of one
There is a fairly good definition of ready which
resulted from the collaboration between multiple
members of the team. Definition of ready includes
existence of acceptance criteria
There is a strong, clear, comprehensive (yet simple)
definition of ready which resulted from the
collaboration of most of the members, agreement
and input from all, and it is publicly posted
In place, comprehensive, periodically reviewed and
updated, strictly followed
Quality,
predictability,
productivity,
customer
satisfaction
Definition of
done
Does not exist There is an understanding of the need for a definition
of done and/or there is a tacit agreement for the
content of one
There is a fairly good definition of done which
resulted from the collaboration between multiple
members of the team
There is a strong, clear, comprehensive (yet simple)
definition of done which resulted from the
collaboration of most of the members, agreement
and input from all, and it is publically posted
In place, comprehensive, periodically reviewed and
updated, strictly followed
Quality,
predictability,
employee
satisfaction,
productivity
Story size Random The team is starting to see the relationship between
small stories and success.
Team has a rule of thumb encouraging small stories Most stories can be done in a week or less Most stories shippable in 1-3 days
Quality,
predictability,
employee
satisfaction,
productivity
Backlog
grooming
Stories are rarely ready to be
worked on prior to the team
starting to work on those stories
It is understood that consistent and frequent
grooming is an important goal and steps are being
taken to get there.
60%+ of the time there are stories ready when
needed
There are usually just enough stories ready There are always more than enough stories ready
Quality,
productivity,
customer
satisfaction
Stories use
vertical slices
No knowledge of vertical slices or
they can't be done due to external
constraints
Using vertical slices for an increasing percentage of
stories
Using vertical slices for 50%+ of stories Using vertical slices for 70%+ of stories Using vertical slices for 90%+ of stories
Employee
satisfaction,
productivity,
quality,
predictability
Work in
progress
Amount of WIP unknown. No
knowledge of one piece flow (e.g.
small batch size)
WIP is tracked and visible. One piece flow is
understood and there is interest in doing it. Most of
the time, members are working on 2 or more stories
at a time.
One piece flow is actively being pursued, WIP limits
are set, most of the time members are working on at
most 2 stories and usually only one. Sometimes,
multiple members are working on the same story.
WIP limits are set and respected. Most of the time
members are only working on one story and
frequently more than one member is working on the
same story.
Only as much work that can be done simultaneously
without increasing the cycle time of any of the work
in progress. Most of the time multiple members are
working on the same story.
Employee
satisfaction,
productivity,
quality,
customer
satisfaction
Standups,
check-ins,
huddles, or
similar.
Not being held Being held regularly and on their way to stage 2. 80% of the team shows up every day, the 3 questions
are covered in less than 20 minutes, real
impediments are raised on a regular basis,
participants stay for the entire meeting, the team
understands that the meeting is for them, not the
Scrum Master, manager, or project manager.
Daily, short, effective. Runs well with or without the
presence of the Scrum Master. Team also does an on-
the-spot analysis of how things are going and takes
corrective action if needed.
Positively adapted to the needs of the team
Employee
satisfaction,
productivity,
quality
Retrospective
s
Not being held Held, but not regularly or not frequently enough Held regularly, well attended, produces action items.
Action items are frequently acted on
Held regularly, well attended, enjoyable, produces
action items that are recorded and generally acted
on
Creatively run, format varied from time to time,
forward looking, often produces breakthrough ideas
that are acted on and produce results
Predictability,
employee
satisfaction,
customer
All work
based on user
stories
Not being followed It is understood that it is important to use user
stories for all work and steps are being taken to get
there.
User stories exist for 50%+ of the work, but still using
other artifacts for some work or translating some
user stories to other artifacts for some work.
User stories exist for 80%+ of work, but still using
other artifacts for some work or translating some
user stories to other artifacts for some work.
All work based on user stories
Predictability,
employee
satisfaction
Estimation Ad-hoc, done by a few people,
based on hours, or entirely task-
based
Done on a regular basis The whole team participates in estimation, real story
points are used. Some members still thinking in
hours. Still a fair amount of focus on tasks.
90+% of the time there is no discussion of hours or
tasks
Consistently done by the whole team thinking in story
points. No discussion of hours or tasks.
Customer
satisfaction,
employee
satisfaction,
responsiveness
and time to
market
Progress
tracking
Not implemented Progress is tracked and known using burnup,
burndown, CFD or similar method and sometimes
iinfluences behavior of the team.
Progress is tracked and frequently influences the
behavior of the team
Progress information usually influences the behavior
of the team
The team proactively uses progress information to
head off potential problems
Customer
satisfaction,
employee
satisfaction,
responsiveness
and time to
market
Reviews Not happening, not happening on a
regular basis, or happening less
often than once in 6 weeks
Happening at least once every six weeks, but some or
all of the following are happening: not reviewing all
stories, ill-prepared to do the review, trying to "sell"
what was done as opposed to finding missed
expectations and encouraging feedback
Happening at least once every four weeks, most
stories are reviewed, team is fairly well prepared,
feedback is encouraged and incorporated into future
stories
Reviews are a cultural norm. Every story is reviewed
and the team is very well prepared. Active feedback
is encouraged, the reviews are well attended and
perceived as valuable to stakeholders.
The team proactively involves stakeholders on a
regular basis and frequently delights stakeholders
during reviews. The team and stakeholders work
closely together and often discover unexpected value
as a result of that interaction.
Customer
satisfaction,
employee
satisfaction
Architecture Primarily done by designated
architects up-front prior to
implementation
Team starting to work with architects and architects
starting to delegate more decisions to the team
50% of architectural decisions made by the team.
50% of architectural decisions made just-in-time
80% of architectural decisions made by the team.
80% of architectural decisions made just-in-time
Primarily done on a just-in-time basis by the team in
consultation with the architecture team.
Quality,
predictability,
productivity
Proximity of
testing to
implementati
on
Long after implementation Within eight weeks Mostly within four weeks Mostly within two weeks and mostly before the next
story is started
For software projects, TDD with UI-based testing
done immediately after story is coded
Quality,
employee
satisfaction
Holistic
testing (sw
projects)
Different kinds of testing (unit,
functional, integration, etc.) all
done without coordination
There is a recognition that holistic testing is a good
thing and steps are being taken to move towards it.
For 50%+ of user stories, the developers and testers
coordinated their testing efforts
For 80%+ of user stories, the developers and testers
coordinated their testing efforts
All testing coordinated ahead of coding and based
around user stories
Quality,
predictability,
productivity,
responsiveness
and time to
market
Test
automation
(sw projects)
Not being used 30%+ code coverage via test automation and plans
are in place to increase this level
50%+ code coverage for all new user stories via test
automation
50%+ code coverage via test automation 90% + code coverage via test automation
Quality,
predictability,
productivity,
responsiveness
and time to
market
Continuous
Integration
(sw projects)
Not implemented Set up, but manually run. Failures not fixed right
away.
Run every hour. Failures fixed fairly quickly. Run every 10 minutes. Drop everything on failures
until fixed.
Run on every check-in.
Quality,
predictability,
productivity,
responsiveness
and time to
market
Unit testing
(sw projects)
Not being used Some coding involves unit testing. There is an
understanding that unit testing produces better code
and reduces overall effort
All new stories involve some amount of unit testing All new stories involve the responsible amount of
unit testing. Unit testing of stories included in the
definition of done.
Hard to imagine a shop that is better at unit testing.
Deep knowledge of the latest unit testing techniques,
using mock objects, etc.
Quality,
predictability,
productivity,
responsiveness
and time to
market
Refactoring
(sw projects)
Not understood and/or not being
done
Some understanding of single responsibility principle
(SRP) and open/closed principle. Some amount of
refactoring done as needed when implementing
stories.
Refactoring around SRP and O/C principle. Doing the
appropriate amount of refactoring with most user
stories
Deep understanding of refactoring. True refactoring
is a cultural norm.
Hard to imagine a shop that is better at refactoring.
Deep knowledge of the latest refactoring techniques.
Refactoring to patterns.
Copyright 2011-2013 Eliassen Group, All Rights Reserved
Agile
Process
Mechanics
Agile
Engineering
Practices
Product
Team
Structure
Team
Dynamics
Team Level Maturity Matrix
Scrum Team A Date 1 60% 2.0 Recommendations: Team B
60% 2.0 highlight strength to reinforce highlight opportunity for improvement
60% 2.0
60% 2.0
60% 2.0
60% 2.0
60% 2.0
Metric Description Evaluation Definition Strength Weakness Evaluation
Being Agile
(Shu, Ha, Ri)
rejecting rules > accepting rules > following rules >
bending rules > being rules; progress through each
phase skipping only first Impeded
rejecting,
impeded or
not started 0% 0
highlight strength or reason for higher
score
highlight weakness or reason for lower
score Impeded
Tuckman
Stages
forming > storming > norming > performing >
outperforming; deforming and reforming possible;
poorly formed team may not progress Transitioning
accepting and
learning 40% 1 Impeded
Self-
organized,
Self-managed
not externally managed; not PO or SM managed; PO
explains what, not how; SM owns blocks, not work;
members pull work, leads do not push work Sustainable
practicing and
refining 70% 2 Impeded
Working
Agreement
defined, known, visible, followed, refined; short,
meaningful; principles over policies; how more than
what; formed by team, monitored by SM Agile
skilled and
adaptive 90% 3 Impeded
Transparent,
Inspect &
Adapt
transparent w/ team, management, business; regularly
inspect & adapt internal & external, what & how;
continuously improving Advanced
innovating and
influential 100% 4 Impeded
Scrum Values
members display commitment, focus, openness,
respect, courage first w/ PO, SM, team and then w/
external resources, management, business NA
not applicable
or not
assessed Impeded
Product
Owner
business-sponsored, empowered, not manager; single,
dedicated, available, colocated; sets priorities, clarifies
requirements, knows domain Impeded
rejecting,
impeded or
not started 0% 0 Transitioning
Scrum Master
IT-sponsored, servant leader, coach & mentor, not
manager; dedicated, active learner, owns process,
resolves blocks, knows Agile, interfaces w/ IT Transitioning
accepting and
learning 40% 1 Transitioning
Development
Team
4 to 9 members, dedicated, stable, cross-functional,
entire vertical, continuously improve, volunteer, cross-
train, blending development-tester roles Sustainable
practicing and
refining 70% 2 Transitioning
Business
Users
early adopters attend reviews, provide feedback,
willingly engaged, value incremental delivery, self
prioritize, may attend planning or grooming Agile
skilled and
adaptive 90% 3 Transitioning
Shared
Resources
kanban methodology, consistently staffed, specialized
skills, support <6 teams, short lead & cycle time, just-in-
time, <10% team effort Advanced
innovating and
influential 100% 4 Transitioning
Management
support self-organization, quality focus, long term
investments, team goals & reviews; coach & mentor;
members report externally NA
not applicable
or not
assessed Transitioning
Product
Vision &
Roadmap
vision known and compelling; roadmap outlined,
followed and refined; quarterly goals; team
understands mission Impeded
rejecting,
impeded or
not started 0% 0 Sustainable
Product
Backlog
couple sprints ready stories; prioritized and evolving;
minimum viable increments; reject or defer noise;
estimate just enough Transitioning
accepting and
learning 40% 1 Sustainable
Sprint Backlog
based on team velocity; defined sprint goal; fixed
during sprint; finished end of sprint; tracks everything;
limit WIP based on story priority Sustainable
practicing and
refining 70% 2 Sustainable
Sprint
Increment
shippable & valuable; promoted at least quarterly, best
sprintly; acceptance & releases externally managed,
mostly automated, or on sprint cadence Agile
skilled and
adaptive 90% 3 Sustainable
User Stories
story: independent, negotiable, valuable, estimable,
small, testable; acceptance: specific, measurable,
achievable, relevant, timebound Advanced
innovating and
influential 100% 4 Sustainable
Definitions of
Ready & Done
ready and done defined, known, visible, concise,
meaningful, followed, honored, refined; formed by
team and monitored by scrum master NA
not applicable
or not
assessed Sustainable
Team Dynamics
Team Structure
Product Backlog
Agile Ceremonies
Agile Processes
Team Dynamics
Team Structure
Product Backlog
Agile Ceremonies
Agile Processes
Engineering Practices
Team
Structure
Team
Dynamics
Product
Backlog
TD
TS
PB
Engineering Practices

7
My Scrum Framework Assessment
• Starts with the Scrum framework
• Adds a simple retrospective
• Uses my original ratings
David Hanson | ANE
01:12

8
3 Roles
Developers
Product Owner
Scrum Master
5 Events
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
3 Artifacts with Commitments
Product Backlog with Product Goal
Sprint Backlog with Sprint Goal
Increment with Definition of Done
Scrum 3-5-3 Framework
David Hanson | Agile Coach
5-7-4….if it was up to me…more later

9
Good – Improve – Ideas Retrospective
David Hanson | ANE

10
Ratings
Evaluation Score Range Characteristics
0-NA: - - not assessed or not applicable
1-Impeded: 0% 0-30% rejecting or impeded
2-Transitioning: 40% 30-55% accepting and learning
3-Sustainable: 70% 55-75% practicing and refining
4-Agile: 90% 75-90% skilled and adaptive
5-Advanced: 100% 90-100% innovative and influential
Trend
↔: steady
↗: improving
↘: worsening
↕: mixed
* NA not included in statistics

Scrum Framework Assessment
Team
2023
Evaluator: Agile Coach, Scrum Master, or Scrum Team
01:12

12
Agile Assessment: Roles
Roles Good Improve Idea Assessment
Scrum Team:
Working Agreement
1-Impeded ↗
Product Owner 2-Transitioning ↔
Team Members 3-Sustainable ↕
Scrum Master 4-Agile ↔
Stakeholders 5-Advanced ↘

13
Agile Assessment: Events
Events Good Improve Idea Assessment
Sprint 1-Impeded ↗
Sprint Planning 2-Transitioning ↕
Sprint Tasking* 2-Transitioning ↔
Daily Scrum 3-Sustainable ↕
Sprint Review 4-Agile ↔
Sprint
Retrospective
4-Agile ↕
Refinement
Activity
5-Advanced ↘
* My term for Sprint Planning Topic 3 (How); too often passed over when planning.

14
Agile Assessment: Artifacts
Artifacts:
Commitment
Good Improve Idea Assessment
Product Backlog:
Product Goal
2-Transitioning ↔
Sprint Backlog:
Sprint Goal
3-Sustainable ↗
Backlog Items:
Definition of Ready
3-Sustainable ↘
Sprint Increment:
Definition of Done
4-Agile ↕

15
Key
Aggregate score*
Team, date: 62.5%, 3.0-Sustainable ↕
Recommended actions:
• Role improvement opportunity
• Event improvement opportunity
• Artifact improvement opportunity
* Average (mean) individual scores to get overall score; take most common trend as average (mode)

Simple Scaled Assessment
Team
2023
01:12

17
Agile Assessment: Scaling
Scaling Good Improve Idea Assessment
Scaled Roles 0-NA ↔
Scaled Events 0-NA ↔
Scaled Artifacts 0-NA ↔
SM Cycle 0-NA ↔
PO Cycle 0-NA ↔
Developer Cycle* 0-NA ↔
This simple scaling is intended to be used with Scrum framework assessment for individual teams. Intent is to assess whether the individual team’s needs for scaling are met.
*Optional developer cycle intended to assess scaled technology, architecture, infrastructure, operations and design components; not included with Scrum @ Scale.

Agile Principles Assessment
Organization
2023
Evaluator: Agile Coach, Scrum Master or Leadership
01:12

19
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and
interactions over process
and tools.
Working software over
comprehensive
documentation.
Customer collaboration
over contract negotiation.
Responding to change
over following a plan.
That is, while there is value in the items [after over], we value the items [before over] more. We follow these principles:
Build projects around motivated
individuals; give them the environment
and support they need, and trust them
to get the job done.
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale.
Business people and developers must
work together daily throughout the
project.
At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts
its behavior accordingly.
Agile processes promote sustainable
development; the sponsors,
developers, and users should be able to
maintain a constant pace indefinitely.
Working software is the primary
measure of progress.
The most efficient and effective method
of conveying information to and within
a development team is face-to-face
conversation.
Welcome changing requirements, even
late in development; Agile processes
harness change for the customer’s
competitive advantage.
The best architectures,
requirements, and designs
emerge from self-organizing
teams.
Simplicity—the art of maximizing
the amount of work not done—
is essential.
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Continuous attention to
technical excellence and good
design enhances agility.
Values
Principles

20
Agile Principles
Customer Focus
Principle Good Improve Idea Assessment
Satisfy customer
through continuous
delivery
4-Agile ↔
Harness change for
competitive
advantage
3-Sustainable ↕
Deliver working
software frequently
2-Transitioning ↘
Business and
developers work
together daily
1-Impeded ↗
Customer leaning principles

21
Agile Principles
Management Focus
Support and trust
motivated individuals
4-Agile ↗
Convey information
face-to-face
3-Sustainable ↕
Working software is
primary progress
2-Transitioning ↘
Promote sustainable
pace indefinitely
1-Impeded ↔
Manager leaning principles

22
Agile Principles
Team Focus
Continuous attention
to excellence and
design
4-Agile ↗
Simplicity,
maximizing work not
done
3-Sustainable ↘
Best emerges from
self-organizing teams
2-Transitioning ↕
Team reflects and
adjusts behavior
1-Impeded ↔
Team leaning principles

23
Key
Aggregate score*
Team, date: 50%, 2.5-Transitioning ↕
Recommended actions
• Customer focused improvement
• Management focused improvement
• Team focused improvement
Agile Mindset is much harder to adopt than Agile practices; however Agile Mindset is much more consequential

Alternative Assessments
Zombie Scrum Survey
Mountain Goat Elements of Agile
Agility Health Radars
Kniberg’s Scrum Checklist
01:12

26
Zombie Scrum Survey Mountain Goat Elements of Agile
Online Assessments
Zombie Scrum Survey is scientific based, aggregates responses for teams, and provides actionable advice. Similarly Mountain Goat’s Elements of Agile will provide a list of actionable advice after responding to 70 questions.
David Hanson | ANE

27
Team Agility Team of Teams Agility
Agility Health Radars
https://agilityhealthradar.com/radars/
David Hanson | ANE
Enterprise Agility Individual Role Agility

28
Bottom Line: 3 items
Core Scrum: 43 items
Recommended: 28 items
Scaling: 3 items
Positive Indicators: 3 items
Total: 80 items
Henrik Kniberg’s
Scrum Checklist
https://scruminc.wpenginepowered.com/wp-content/uploads/2019/05/scrum-checklist.pdf
David Hanson | ANE

29
Scaled Agile Assessment Template
Assumes Scrum @ Scale
David Hanson | ANE
01:12

30
Minimum viable bureaucracy
Lowest decision latency
Structure for “linear” scaling
Scales Agile by scaling Scrum
Less prescriptive, more transformative
Product Owner Cycle led by Executive
Meta Scrum focused on business,
priorities, what
Scrum Master Cycle led by Executive
Action Team focused on technology,
process, how
Scrum @ Scale
David Hanson | ANE

31
Symbol Description
t No Impediments
O Minor Impediments, No Measurable Impact
↗ Some Impediments, Situation Improving
↔ Some Impediments, Situation Stable
↘ Some Impediments, Situation Worsening
X Major Impediments, Team Totally Blocked
Heatmap Key
https://marcrodriguezsanz.medium.com/scrum-scales-scaling-heatmap-34b012bb1496
Component Assessment
Mega: Organizational Refactoring t
PO: Executive Meta Scrum O
PO: Strategic Vision O
PO: Backlog Prioritization O
PO: Backlog Decomposition & Refinement O
PO: Release Planning O
SM: Executive Action Team ↗↔↘
SM: Continuous Improvement ↗↔↘
SM: Impediment Removal ↗↔↘
SM: Cross-team Coordination ↗↔↘
SM: Delivery ↗↔↘
PO/SM: Team Process X
PO/SM: Metrics & Transparency X
PO/SM: Product & Release Feedback X
PO/SM: Product Increment X

32
Scaled Agile Current State Heatmap
Mega Issue, PO Cycle or SM Cycle Component 1st Team 2nd Team 3rd Team Team of Teams
Mega: Organizational Refactoring ↘ tO↗↔↘X tO↗↔↘X ↘
PO: Executive Meta Scrum ↔ tO↗↔↘X tO↗↔↘X ↔
PO: Strategic Vision ↔ tO↗↔↘X tO↗↔↘X ↔
PO: Backlog Prioritization ↔ tO↗↔↘X tO↗↔↘X ↗
PO: Backlog Decomposition & Refinement O tO↗↔↘X tO↗↔↘X O
PO: Release Planning X tO↗↔↘X tO↗↔↘X X
SM: Executive Action Team X tO↗↔↘X tO↗↔↘X X
SM: Continuous Improvement ↘ tO↗↔↘X tO↗↔↘X ↔
SM: Impediment Removal ↘ tO↗↔↘X tO↗↔↘X X
SM: Cross-team Coordination t tO↗↔↘X tO↗↔↘X t
SM: Delivery ↔ tO↗↔↘X tO↗↔↘X ↘
PO/SM: Team Process O tO↗↔↘X tO↗↔↘X O
PO/SM: Metrics & Transparency ↗ tO↗↔↘X tO↗↔↘X ↘
PO/SM: Product & Release Feedback X tO↗↔↘X tO↗↔↘X X
PO/SM: Product Increment X tO↗↔↘X tO↗↔↘X X
Symbol Description
t No Impediments

33
Strategic
Importance
t O ↗ ↔ ↘ X
Highest Metrics &
Transparency
Higher Strategic
Vision
Executive
Action Team
High Executive
Meta Scrum
Organizational
Refactoring
Product
Increment
Moderate Team
Process
Continuous
Improvement
Impediment
Removal
Low Cross-team
Coordination
Backlog
Prioritization
Delivery
Lower Backlog
Decomposition
& Refinement
Product &
Release
Feedback
Lowest Release
Planning
Focus on the top right first
Ideally should be done collectively
Could be repeated at the
individual team level
Viewpoints may differ
Transformation Backlog Prioritization
Symbol Description
t No Impediments

Kanban and XP
simple retrospective approach
easily extended
01:12

Scrum Master Service
Assessment & Goals
01:12

36
Service to… Good Improve Ideas Assessment
Service to… Good Improve Ideas Assessment
Service to Scrum
Team
Service to Product
Owner
Service to
Organization
Service to Self
Scrum Master Service Assessment

37
Objective: what
Key Results:
- how
- how
- how
Outcome: why
Timeline: when
Quarterly Reviews: where
Service to Scrum Team: who Service to Product Owner: who
Objective: what
Key Results:
- how
- how
- how
Outcome: why
Timeline: when
Scrum Master Service Goals
SMART: specific, measurable, achievable, relevant, timebound

38
Objective: what
Key Results:
- how
- how
- how
Outcome: why
Timeline: when
Service to Organization: who Service to Self: who
Objective: what
Key Results:
- how
- how
- how
Outcome: why
Timeline: when
Scrum Master Service Goals
SMART: specific, measurable, achievable, relevant, timebound

39
Early on, my attempts at an Agile maturity matrix
captured my knowledge.
Now, my attempt is to provide a framework for
teams to chart their own course.
Perhaps, a reflection of my evolution from
facilitator to trainer to mentor to coach.
Myself Your thoughts
What was valuable for you here?
What was missing?
What would you like to see next?
Reflection
Please don’t forget to provide your feedback on the session; thank you!
David Hanson | ANE
01:12

40
David Hanson | ANE 101
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
ANE 101 Survey

Appendix:
Sample assessment for my best team from 2017
My original organizational and leadership assessments
Sample Excel radar plot visualization
XP adoption planning game
Kanban maturity assessment template
01:12

Scrum Framework Sample
Assessment
My Best Team
2017
01:12

43
Agile Assessment: Roles
Scrum Team:
Working Agreement
Highest profile project,
collocated
Working agreement and
duration together
Embrace XP practices 3-Sustainable ↗
Product Owner Lean certified, Agile
mindset; makes rounds,
strong vision for product
Reports to IT manager, not
business manager
Move to same floor as
users; change reporting to
support manager
4-Agile ↗
Team Members Do not report to PO or SM;
good cross-functional mix;
coders pair w/ testers
Minimal TDD; afraid to
commit so ask for spikes,
then say done
Swap out developer that
liked to work solo in silo
3-Sustainable ↔
Scrum Master Natural; experience as BA,
QA; quality focused; makes
rounds, gets involved
Influence with
management and clients
Find opportunities to
showcase talent with
management
4-Agile ↗
Stakeholders Engaged, available to PO,
analysts; embrace
incremental delivery
Management discouraged
engagement between
users and team
Invite users to reviews with
full team or invite full team
to reviews with users
3-Sustainable ↕

44
Agile Assessment: Events
Sprint 9 day sprint; every sprint
usable value; Scrumban
3 sprint release cycle; goal
not explicitly stated
Release every sprint 5-Advanced ↔
Sprint Planning Serious, focused, efficient,
repetitive
Goal might be implicit, not
discussed
Propose goal, then engage
team in selection of stories
4-Agile ↔
Sprint Tasking Done on first day Done in pairs or
individually
Include time for tasking in
2nd half of planning
3-Sustainable ↔
Daily Scrum Stood; flagged blocks,
issues on whiteboard; 15m
Could be a bit more
aggressive resolving blocks
SoS 3 times a week and EAT
2 times a week
4-Agile ↔
Sprint Review Demoed every story, every
acceptance no exceptions
2nd higher level review with
users w/o team members
Invite user to team review;
invite team to user review
4-Agile ↕
Sprint
Retrospective
Entire team engaged;
actionable items identified
Retros could be more
varied and more interactive
Assess team happiness 3-Sustainable ↔
Refinement
Activity
Quick, effective, efficient;
everyone spoke up
Overuse of spikes Try actual poker planning
cards
4-Agile ↔

45
Agile Assessment: Artifacts
Artifacts:
Commitment
Product Backlog:
Product Goal
Extensive backlog, well-
ordered, known roadmap
Product vision known but
implied; too much clutter
Embrace story mapping w/
users and team
3-Sustainable ↔
Sprint Backlog:
Sprint Goal
Deliverable value every
sprint; usually all done
Unstated goal Make goal explicit 3-Sustainable ↔
Backlog Items:
Definition of Ready
Extremely disciplined;
MoSCoW acceptance
Too much effort estimating
epics
Defer or reject 50% of
product backlog
4-Agile ↕
Sprint Increment:
Definition of Done
Extremely disciplined; done
was done
Accepted UAT as post
sprint activity
Focus on CI/CD and test
automation
4-Agile ↔

46
Agile Assessment: Scaling
Scaling Good Improve Idea Assessment
Scaled Roles Visionary CPO and CSM;
scaled DBE and architect;
common “house rules”
Reporting relationship not
ideal; collaboration with
data and support teams
Recruit UX lead; distribute
database staff across teams
4-Agile ↕
Scaled Events SoS, MetaScrum; Reverse
Scrum w/ user base; cross-
team knowledge share
Lacked EAT and EMS for
team of team of teams
Training in Scrum at Scale
(2017: not yet available)
5-Advanced ↔
Scaled Artifacts Common backlog &
metrics; custom tooling;
integrated product release
One team gamed metrics,
leading to misdirected
questions
Embrace Agile & DevOps
tool suite; cut backlog
4-Agile ↕
SM Cycle SoS, CoP, delivery, metrics;
Scrumban, shared resource
Kanban, led CI/CD
Lacked true EAT to address
org impediments
Training for management;
streamline status reports
3-Sustainable ↗
PO Cycle Roadmap, decomposition,
release, metrics, feedback
More feedback on usage to
drive priorities
Vision known but not
stated
3-Sustainable ↗

47
Key
Aggregate score
Team, date: 82%, 3.7-Agile ↗, 2017
Recommended actions:
• Role improvement opportunity: embrace XP practices, hire accordingly
• Event improvement opportunity: set goal to release every sprint
• Artifact improvement opportunity: leverage story mapping to engage users and team
• Scaling improvement opportunity: training on, then not yet version 1, Scrum at Scale

49
Organizational Assessment Leadership Assessment
My Original Organizational and Leadership Assessments
Inspired by Eliassen’s organizational maturity matrix and Sally Elatta’s individual role assessment
Leadership Attribute Leadership Description
Overall Assessment 75% 50%
Shared Vision what: compelling, shared, collaborative Sustainable
practicing and
refining 70% Transitioning
accepting and
learning 40% Transitioning
Implementation Strategy how: compelling, shared, collaborative Sustainable
practicing and
refining 70% Sustainable
practicing and
Business Outcome why: compelling, shared, collaborative Transitioning
accepting and
accepting and
learning 40% Impeded
Success Metrics measure value and growth Impeded rejecting or impeded 0% Transitioning
accepting and
Agile Principles embraces Agile values & principles Advanced
innovating and
influential 100% Transitioning
accepting and
Team Design cross-functional, fully-dedicated; scaled Agile skilled and adaptive 90% Sustainable
practicing and
refining 70% Impeded
Clear Priorities ordered, balanced, transparent, known Sustainable
practicing and
practicing and
Acceptance Criteria specific, measurable, achievable, relevant, timed Agile skilled and adaptive 90% Sustainable
practicing and
Enables Focus limit WIP, minimize distractions Agile skilled and adaptive 90% Sustainable
practicing and
Engagement hoping > telling > selling > participating > delegating Agile skilled and adaptive 90% Transitioning
accepting and
Develop People 1-on-1s, feedback, coaching, delegating; scaling Agile skilled and adaptive 90% Transitioning
accepting and
Build Teams high-performing, self-organized, stable Sustainable
practicing and
refining 70% Impeded rejecting or impeded 0% Impeded
Lean Practioner map value stream, eliminate waste, optimize whole Agile skilled and adaptive 90% Sustainable
practicing and
Organizational Obstacles identify, remove; courageous, influential Sustainable
practicing and
accepting and
Customer Focus knows customer, domain, business value Transitioning
accepting and
learning 40% Impeded rejecting or impeded 0% Sustainable
Model Culture demonstrates desired culture Advanced
innovating and
influential 100% Sustainable
practicing and
Change Leader challenges status quo; knows best practices Agile skilled and adaptive 90% Transitioning
accepting and
Servant Leader serves teams and direct reports; shares power Sustainable
practicing and
practicing and
Seeks Feedback eagerly seeks and willingly receives feedback Sustainable
practicing and
practicing and
Coach & Mentor coach for team goal; mentor for individual career Agile skilled and adaptive 90% Transitioning
accepting and
Character
Leader 1 Leader 2 Leader 3
Vision
Execution
Value
Attribute Description Org A Date 1 30% Org A Date 2 60% Org B Date 1 20% Org B Date 2
Culture
ownership culture; collaborative; supports
measured risks & transparency Sustainable
practicing and
practicing and
accepting and
accepting and
learning
Agile Values organization supports Agile values & principles Transitioning
accepting and
learning 40% Sustainable
practicing and
accepting and
rejecting or
impeded
Lean Principles
client focus; continuous improvement; maximize
value; eliminate waste Sustainable
practicing and
refining 70% Agile
skilled and
adaptive 90% Sustainable
practicing and
practicing and
refining
Vision
clear, compelling, shared vision w/
implementation strategy Transitioning
accepting and
accepting and
accepting and
accepting and
learning
Goals
SMART goals in support of vision; limited in
number; assessed quarterly Transitioning
accepting and
learning 40% Agile
skilled and
adaptive 90% Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded
Structure
stable, cross-functional teams supporting
product delivery Transitioning
accepting and
learning 40% Agile
skilled and
adaptive 90% Transitioning
accepting and
practicing and
refining
Funding
funding adjusted quarterly based on metrics;
deliver value quarterly Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded
Projects
limit projects in progress; 1 team no more than 1
project; prioritized queue Transitioning
accepting and
practicing and
accepting and
rejecting or
impeded
Metrics
metrics track value and growth; funding and
rewards based on metrics; visible Transitioning
accepting and
practicing and
rejecting or
impeded 0% Transitioning
accepting and
learning
Rewards
compensation based on team performance and
project delivery Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded 0% Impeded
rejecting or
impeded
Space
physical & virtual space supports team & peer
collaboration; video conference rooms Transitioning
accepting and
practicing and
rejecting or
accepting and
learning
Tools
integrated continuous integration and Agile
collaboration tools widely used Transitioning
accepting and
practicing and
accepting and
accepting and
learning
Infrastructure
infrastructure as code supports proper sub
environments & developer toolsets Impeded
rejecting or
accepting and
rejecting or
accepting and
learning
DevOps
DevOps team & community to support
continuous integration & delivery Transitioning
accepting and
practicing and
rejecting or
accepting and
learning
Learning
knowledge sharing activities and training readily
available and supported Impeded
rejecting or
impeded 0% Agile
skilled and
adaptive 90% Impeded
rejecting or
accepting and
learning
Adoption
genuine adoption widespread; services include
launch, scaling, assessment, CI Transitioning
accepting and
accepting and
rejecting or
impeded 0% Impeded
rejecting or
impeded
Governance
Agile governance for Scrum and Kanban defined,
followed, audited; just enough Transitioning
accepting and
practicing and
accepting and
practicing and
refining
Scaling
Agile scaling approach and support available;
actively implemented Impeded
rejecting or
accepting and
accepting and
practicing and
refining
Communities
various communities of practice where best
practices shared Transitioning
accepting and
learning 40% Agile
skilled and
adaptive 90% Transitioning
accepting and
practicing and
refining
Impediments
organizational obstacles raised and addressed at
multiple levels Impeded
rejecting or
accepting and
accepting and
accepting and
learning
Business
trained in Agile and support activities; sponsor
true product owners Transitioning
accepting and
accepting and
rejecting or
impeded 0% Impeded
rejecting or
impeded
Executive
trained in Agile, set Agile goals, allocate budget,
recognize improvement Impeded
rejecting or
impeded 0% Sustainable
practicing and
rejecting or
impeded 0% Impeded
rejecting or
impeded
Management
trained in Agile, define Agile objectives, remove
obstacles, monitor progress Transitioning
accepting and
accepting and
rejecting or
impeded 0% Impeded
rejecting or
impeded
Team Managers
managers external to Scrum team; actively coach
& mentor Transitioning
accepting and
practicing and
rejecting or
impeded 0% Impeded
rejecting or
impeded
Leadership
organization supports leadership at all levels;
teams trusted to self-organize Impeded
rejecting or
impeded 0% Sustainable
practicing and
accepting and
accepting and
learning
Cultural
Organization
Execution
Process
Management

50
Leverage Excel radar
plots to visualize maturity
for team of teams or for
one team over time
Radar Plot Visualization
Example above from my original template

XP Adoption
Planning Game
01:12

XPAdoption
Stories
52
As an owner, we practice
System Metaphor
to communicate ideas
about code clearly.
As a team, we practice
Planning Game
to schedule the most
important work.
Sustainable Pace
to go home tired, but
not exhausted.
On-siteCustomer
to address user concerns
accurately and directly.
As a pair, we practice
Refactoring
to find the code’s
optimal design.
As a team and a pair,
we practice Test First
to prove that the code
works as it should.
As a pair, we practice
Pair Programming
to spread knowledge,
experience, and ideas.
Continuous Integration
to reduce the impact of
adding new features.
Small Releases
to return the customer’s
investment often.
CollectiveOwnership
to share responsibility
for code and design.
Coding Standards
to communicate ideas
clearly through code.
Simple Design
to produce software
that’s easy to change.
As anAgile team, we adopt
XP Practices
to deliver higher value, at lower
cost, with shorter timelines,
while maintaining quality.

XPAdoption
Planning
Game
53
System Metaphor
Planning Game
Sustainable Pace
Should
On-siteCustomer
1
Estimate
Must
Refactoring
2
Estimate
Must
Test First
5 (split)
Guess
Pair Programming Continuous Integration
Should
Small Releases
2
Known
Less Certain Effort Risk More Certain
Lower
Story
Value
Higher
Could
CollectiveOwnership
1
Known
Coding Standards
Could
Simple Design
3
Guess
Value
XP Practice
Effort
Risk
Must/Should/Could
XP Practice
1/2/3
Known/Estimate/Guess
Q1
Q2
Q3
Q4

Kanban Maturity Assessment
Team
2023
01:12

55
Kanban Assessment: Principles*
Principles Good Improve Idea Assessment
Start Where You
Are
4-Agile ↔
Respect Current
Process and Roles
3-Sustainable ↕
Agree to Change 2-Transitioning ↘
Distribute
Leadership
1-Impeded ↗
*Evaluation on the principles optional

56
Kanban Assessment: Core Practices
Practices Good Improve Idea Assessment
Visualize Work 4-Agile ↘
Limit WIP 3-Sustainable ↕
Manage Flow 2-Transitioning ↗
Primary Focus

57
Kanban Assessment: Extended Practices
Practices Good Improve Idea Assessment
Explicit Process 4-Agile ↔
Improve
Empirically
3-Sustainable ↕
Establish Cadence 2-Transitioning ↘
Regular Feedback 1-Impeded ↗
Secondary Focus

58
Key
0-NA: - - not assessed or not applicable
Trends: ↗ improving; ↔ steady; ↘ worsening; ↕ mixed
Team score: 54.5%, 2.6-Transitioning ↕, May 2023
Actions
Note: individual assessments will vary; the score is less important than noting what’s going well, where can improve, and what actions can be taken.

Scrum Framework
Assessment
Room Exercise
June 2023
Evaluator: 101 Participants

60
Scrum Framework Assessment: Roles
Scrum Team:
Working Agreement
1 2 3 4 5
↔ ↕ ↗ ↘
Product Owner 1 2 3 4 5
↔ ↕ ↗ ↘
Team Members 1 2 3 4 5
↔ ↕ ↗ ↘
Scrum Master 1 2 3 4 5
↔ ↕ ↗ ↘
Stakeholders 1 2 3 4 5
↔ ↕ ↗ ↘
David Hanson | ANE

61
Scrum Framework Assessment: Events
Sprint 1 2 3 4 5
↔ ↕ ↗ ↘
Sprint Planning 1 2 3 4 5
↔ ↕ ↗ ↘
Sprint Tasking 1 2 3 4 5
↔ ↕ ↗ ↘
Daily Scrum 1 2 3 4 5
↔ ↕ ↗ ↘
Sprint Review 1 2 3 4 5
↔ ↕ ↗ ↘
Sprint
Retrospective
1 2 3 4 5
↔ ↕ ↗ ↘
Refinement
Activity
1 2 3 4 5
↔ ↕ ↗ ↘
David Hanson | ANE

62
Scrum Framework Assessment: Artifacts
Artifacts:
Commitment
Product Backlog:
Product Goal
1 2 3 4 5
↔ ↕ ↗ ↘
Sprint Backlog:
Sprint Goal
1 2 3 4 5
↔ ↕ ↗ ↘
Backlog Items:
Definition of Ready
1 2 3 4 5
↔ ↕ ↗ ↘
Sprint Increment:
Definition of Done
1 2 3 4 5
↔ ↕ ↗ ↘
David Hanson | ANE

63
Key
Aggregate score*
Date: average rating and trend
Improvement opportunities
• Role:
• Event:
• Artifact:
* Average (mean) individual scores to get overall score; take most common trend as average (mode)
David Hanson | ANE

Agile Maturity Assessments

More Related Content

What's hot

Similar to Agile Maturity Assessments

More from David Hanson

Recently uploaded

Agile Maturity Assessments

Editor's Notes