Agile Maturity: Diagnose the Next Constraint

Two teams can run the same ceremonies and face opposite constraints.

One waits weeks for a portfolio decision. The other decides quickly but cannot release without a fragile migration. A third ships safely and learns almost nothing because research and product evidence never alter the plan.

A maturity score would compress those systems into a ranking. A useful diagnostic should tell each team what to change next.

Agile maturity is the capability to expose a constraint, adapt the operating system, and verify whether the change improved the flow of value and evidence without exporting harm elsewhere.

This article provides a five-lens diagnostic. It is an editorial synthesis, not a validated maturity model.

Define the system before judging it

Choose one product area, service, or value stream. Name the people who frame, build, release, operate, and learn from its work.

Do not assess a team in isolation when approvals, environments, specialists, or customer access sit elsewhere.

Write the boundary:

Customer or operational outcome
Work entering the system
Decision authority
People and services required
Finish point for delivery
Finish point for learning
Material obligations and risks
Period being inspected

The 2020 Scrum Guide defines Scrum through empiricism and lean thinking, with transparency, inspection, and adaptation.

It is official framework guidance, not evidence that Scrum use produces maturity or that every product should use Sprints.

The Agile Manifesto principles emphasise early and continuous delivery, changing requirements, frequent working software, sustainable development, and regular reflection.

Those principles state values and intentions. They do not supply measures or a comparative maturity scale.

Use them as questions about the operating system, not a compliance checklist.

Inspect one completed and one unfinished item

Abstract discussion invites rehearsed opinions. Choose a consequential item that reached a real user or operator, and one that remains unfinished.

Reconstruct each path:

• signal or request entered;
• problem and outcome were framed;
• authority committed the work;
• evidence and options were developed;
• implementation and review occurred;
• the change became available;
• operating and product evidence matured;
• the next decision was made.

Record waiting, rework, changed assumptions, hand-offs, blocked authority, quality failures, and work that continued after the board called the item done.

This trace prevents the diagnostic from rewarding tidy artefacts over actual movement.

Lens one: flow of delivery

Delivery flow asks how selected work reaches a usable, operable finish point.

The May 2025 Kanban Guide defines work in progress, throughput, work item age, cycle time, and a probabilistic service level expectation.

It is official practitioner guidance. It does not prove that one WIP limit or service expectation will improve a particular product system.

Inspect:

• elapsed time and active time;
• age of unfinished work;
• work in progress at the shared constraint;
• blocked time and its owner;
• rework before and after release;
• batch size at integration and deployment;
• frequency and consequence of urgent arrivals.

Compare like work over time. Do not rank teams whose risk, architecture, product cadence, and work-item definitions differ.

Anti-gaming rule: a smaller ticket is not improved flow if several tickets must regroup before users receive a coherent change.

Sprint Execution covers goal protection, ageing work, WIP, quality, and dependency commitments in detail.

Lens two: flow of product learning

Delivery can finish before learning begins.

Trace discovery separately:

• Which uncertainty controlled the next commitment?
• Which population and context did the evidence represent?
• Did the team compare credible alternatives?
• What evidence could reverse the preferred path?
• When did actual use become observable?
• Which result changed a decision?

Discovery flow may include research, analysis, prototypes, technical investigation, commercial evidence, and operating observation.

Do not measure interview count or experiment count as maturity. More activity can coexist with unchanged decisions.

Anti-gaming rule: a released change is not a learning cycle when eligibility, exposure, value event, or review decision cannot be reconstructed.

Product Discovery helps select evidence according to the decision and consequence rather than applying one discovery method by default.

Lens three: technical confidence

Technical confidence is the system’s demonstrated ability to change safely, detect failure, and recover a trustworthy product state.

DORA’s current five delivery metrics cover change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.

DORA says to apply them at application or service level, retain context, and avoid turning them into targets or comparisons across unlike systems.

Use them as prompts, then inspect the mechanism:

• Are critical checks reliable and fast enough to influence the change?
• Can the team deploy independently at the required boundary?
• Does observability show user-visible failure as well as service health?
• Can exposure stop before harm spreads?
• Does recovery address data, messages, contracts, and user work?
• Does technical debt repeatedly enlarge batches or delay evidence?

Anti-gaming rule: more deployments do not indicate confidence when unplanned recovery work, customer repair, or operator strain grows with them.

Lens four: decision rights and usable disagreement

Many apparent delivery problems are authority queues.

Inspect decisions that waited, reopened, or entered through an urgent path.

For each one, ask:

• Who could make the commitment?
• Who supplied evidence or specialist judgement?
• Which role could stop work on a defined risk?
• Which consequence did the team own after release?
• What new evidence could reopen the choice?
• Did disagreement change the option or only delay it?

An autonomous team does not own every decision. It knows the boundary of its authority and has a reliable route beyond it.

In 1999, Edmondson studied learning and error reporting across 51 work groups at one manufacturing business. The observational results associated psychological safety with learning behaviour.

The study does not establish that a survey score improves product decisions. It supports a narrower inspection: can people surface mistakes, uncertainty, and dissent without the response making future candour less likely?

Product Org Design addresses the wider allocation of decisions, dependencies, and accountability.

Lens five: continuous improvement

A retrospective action is not evidence of improvement.

Choose one repeated constraint and write an improvement hypothesis:

Observed mechanism
Work and population affected
Change to the operating system
Expected signal
Counter-signal or exported cost
Owner
Review window
Decision to retain, revise, or remove

The Scrum Guide gives the Sprint Retrospective the purpose of planning ways to increase quality and effectiveness. It prescribes no format and does not guarantee follow-through.

Inspect whether the team completes improvement work, whether the mechanism changes, and whether old actions expire when they no longer help.

Anti-gaming rule: count neither retrospective actions nor ceremonies. Follow a constraint from observation to intervention and review.

Kaizen is useful here when treated as a disciplined sequence of small tests, not a slogan for asking teams to work harder.

Retrospective Formats shows how to select a format based on the evidence needed from a particular event.

Select one next constraint

After reading the five lenses, do not create a transformation backlog.

Rank candidate constraints through four tests:

1. Consequence: Which customer, operating, or learning outcome does it limit?
2. Frequency: Does it recur across comparable work or reflect one exceptional event?
3. Control: Can this group change it, or must authority move elsewhere?
4. Evidence: What observation distinguishes the mechanism from a plausible alternative?

Choose the constraint that most limits responsible progress and can be tested without creating a larger uncontrolled risk.

A long cycle time may come from excessive WIP, slow evidence, one scarce reviewer, oversized changes, or a natural observation period. Each requires a different intervention.

If the constraint sits between a releasable change and controlled exposure, use Release Management to inspect readiness, audience, stop conditions, and evidence ownership.

Do not prescribe pair programming, another ceremony, a platform, or a reorganisation before the mechanism is visible.

From ceremony score to authority constraint

Consider a fictional B2B team responsible for account permissions. The diagnostic identifies a test, not evidence that the intervention will improve performance.

The team runs Sprints consistently and usually completes its planned tickets. Releases occur monthly because permission changes require a specialist review and a coordinated migration.

The delivery trace shows that implementation is short. Work waits in review, and several changes regroup before the migration window.

The learning trace shows another delay. The team observes support cases after release, but no one compares them with the intended permission outcome before the next plan begins.

Technical confidence is mixed. Automated checks cover common roles, while recovery for an incorrect inherited permission still requires manual data repair.

Decision rights are also unclear. Security advises on risk, yet teams treat that advice as final product approval because the actual risk owner is absent.

The group does not declare itself low maturity.

It selects one constraint: unclear authority causes work to wait and batches to grow before the migration review.

The improvement hypothesis names the product owner for policy scope, the security authority for defined risk, the evidence required from each, and the latest responsible review point.

The team will inspect review wait, batch size, reopened decisions, and any risk displaced by the earlier decision.

If review time falls but unsafe changes reach migration, the intervention has failed. If authority remains unclear, the issue requires escalation beyond team process.

The point is the move from a vague score to one testable change with a visible failure condition.

Review maturity as an adaptive capability

Repeat the diagnostic after enough comparable work has passed through the system.

Ask whether the selected constraint changed, whether another constraint became visible, and whether the intervention moved cost or risk elsewhere.

A mature response can be to add a control, remove a meeting, narrow WIP, redesign an interface, slow exposure, change a decision right, or stop work that no longer deserves capacity.

The practice is not continuous acceleration. It is continuous improvement in the system’s ability to deliver, learn, disagree, recover, and adapt at a responsible pace.

Sources

• Principles behind the Agile Manifesto (original practitioner principles; values and intentions rather than an empirical maturity model or prescribed operating system)
• The Scrum Guide, November 2020 (official framework definition of empiricism, accountabilities, events, and artefacts; Scrum compliance does not establish product effectiveness)
• The Kanban Guide, May 2025 (official practitioner guidance on workflow, WIP, flow measures, and service expectations; local stability and transfer remain unproven)
• DORA: Software delivery performance metrics (official current five-metric model with explicit context and anti-target warnings; it measures delivery performance, not product learning or team maturity)
• Edmondson: Psychological Safety and Learning Behavior in Work Teams (multimethod field study of 51 teams in one manufacturer; observational and not a validated product-team maturity measure)

Read next

• Sprint Execution: Protect the Goal, Manage the Flow
• Product Discovery: Match Evidence to the Decision
• Product Org Design: Build the Decision System, Not the Chart