An agile maturity assessment measures how a team actually works against how it believes it works, and it is worth running only if it ends in two or three specific changes. Run it as a diagnostic: look at decision speed, ownership of done and what happens when a sprint plan breaks. A score reported to leadership changes nothing. A named fix to the one structural problem slowing delivery does.
When I worked four days a month as a fractional leader at HuStream, a Canadian video startup, one of the first things I did was a lightweight assessment of how the team operated. The gap between belief and practice was wide. They believed they were iterating fast. In practice they had no definition of done, no regular retrospective, and sprint planning was someone reading the backlog aloud.
The assessment produced no score. It produced three changes that unblocked delivery within six weeks.
I ran a similar diagnostic at Acquia as a fractional product leader, while the company fought on two competitive fronts at once. The product organization knew how to run agile, but decision rights were unclear across three layers of leadership. The teams were moving and the decisions were not.
The fix was to name who owned each class of decision and remove one layer of required approval for scoped work. Velocity improved within a quarter, and not one ceremony changed.
Teams that score well on ceremonies and poorly on decision speed are the most common finding, and no amount of ceremony fixes them.
What I look for first
I look at three things before any framework. How long does it take a decision to become code in production? Who owns the definition of done? What happens when the sprint plan breaks halfway through?
Those three questions expose more than a fifty-item scorecard. Usually the answer points at a product owner who cannot make a tradeoff without escalating. The ceremonies run, and the bottleneck sits one level up.
Agile maturity models worth knowing
Two models cover most of what teams use, and the right one depends on your size and what you are trying to fix.
The five-level maturity scale is the classic. Level 1 is initial: agile vocabulary with inconsistent practice. Level 2 is managed: stand-ups and retros happen, without much understanding of why. Level 3 is defined: a standard process with a steady sprint and release rhythm. Level 4 is measured: cycle time and similar numbers drive decisions. Level 5 is optimizing: the team improves its own process as routine work. It is easy to explain to leadership, but it encourages treating a higher level as the goal in itself.
The Agile Fluency Model, from Diana Larsen and James Shore, describes zones of fluency instead of a ladder: focusing on value, delivering value, optimizing value and optimizing the wider system. Its useful idea is that teams need different end states. A team that ships reliably and works on the right things may never need the last zone, and pushing it there wastes a year.
How to run the assessment
Start with scope. Decide whether you are assessing one team, a department or one part of delivery like the release pipeline. Decide what better looks like for this business: faster delivery, fewer escalations, more time on the right work. Without that, the assessment turns into a survey with no question behind it.
Then gather data three ways. An anonymous survey built on your chosen model gives you a broad baseline and lets people be candid. Interviews with engineers, product owners and managers give you the reasons behind the numbers. Observation gives you what nobody mentions: sit in on planning, stand-ups and retros and watch where decisions stall.
The interviews and observation are where the findings come from. The survey tells you where to look.
Finally, pick one to three changes. Trying to fix everything at once is the other pattern I see constantly, and it ends in nothing changing. Review the findings with the team, agree on the few changes that matter most, and put them in the backlog like any other work.
Turn findings into experiments
Each finding becomes a small, testable change inside the normal sprint. If stories keep producing rework because they are vague, require three clear acceptance criteria before a story counts as ready, for the next two sprints, and check the rework rate. If stand-ups have turned into status reports, run them for a week on blockers only and see whether the team leaves with fewer open questions.
Share the results openly. Transparency is what makes an agile team work, and a team that sees its own findings owns the fix. When the bottleneck is structural rather than procedural, the answer usually sits in how the product team is organized and in who is allowed to decide what.
Common questions about agile assessments
How often should we run one? A full assessment every six to twelve months gives the changes from the last one time to show up. A short quarterly pulse check on the one or two things you are fixing keeps them from drifting.
Can a team assess itself? Yes, and ownership is stronger when it does. Use a neutral facilitator (a Scrum Master, an agile coach, or a volunteer from another team) so that people speak freely and every voice gets heard.
How is it different from a retrospective? A retro looks at one sprint and produces tweaks for the next one. An assessment looks across months at capability, structure and culture, and finds the patterns no single retro can see.
If you want a longer path from here, an agile transformation roadmap is where the assessment findings go next.
Diagnosing a delivery problem?
Agile maturity problems trace back to two or three structural causes. I help product and engineering leaders find them and fix them fast. Let's talk.
