The Agile Fluency Model

Origins

The Agile Fluency Model was developed by James Shore and Diana Larsen in 2012, with significant updates in 2018.1 Their framing was a reaction against the "agile maturity model" pattern — the idea that agile teams pass through linear stages from basic to advanced. Shore and Larsen argued that the metaphor was wrong: different teams in different organizations should make different investments depending on the benefits they wanted.

The Four Zones

The model defines four fluency zones, each describing a different set of capabilities and the value they produce:

Focusing

Teams that have invested in basic agile practices. They focus on business value, share ownership of work, and produce visible progress. Outcomes: business engagement, transparency, focus on what matters. Typical investment: 2–6 months. Value delivered: better focus and morale; modest delivery improvements.

Delivering

Teams that have invested in technical excellence. They deploy frequently, maintain quality, refactor continuously. Outcomes: low defect rate, fast delivery, technical sustainability. Typical investment: 3–24 months past Focusing. Value delivered: reliable delivery, lower defect costs, sustainable pace.

Optimizing

Teams that have invested in product ownership and direct customer engagement. They make product decisions themselves, run experiments, optimize for customer outcomes. Outcomes: higher-value products, faster learning. Typical investment: 1–5 years past Delivering. Value delivered: products that better serve customers; faster market response.

Strengthening

Teams (and organizations) that have invested in organizational learning. They share knowledge across boundaries, contribute to organizational improvement, evolve practices. Outcomes: organization that continuously improves. Typical investment: open-ended. Value delivered: long-term organizational adaptability.

What the Model Argues

The deepest claim of the Agile Fluency Model: each zone requires specific investments — training, tooling, leadership support, cultural change — and those investments should be made deliberately, not as a side effect of "doing agile."

The investments are non-trivial:

  • Focusing requires coaching, time for planning, support for cross-functional teams.
  • Delivering requires technical training, CI/CD infrastructure, test automation, refactoring time.
  • Optimizing requires real customer access, decision authority for teams, experimentation budget.
  • Strengthening requires organizational learning structures, time for cross-team knowledge sharing.

Organizations that skip an investment but expect the corresponding benefit are practicing what Shore calls "imitation agile" — the appearance without the substance.

Not a Linear Progression

The model is explicit that teams don't have to progress through all four zones. Different teams should be in different zones based on the value the organization needs:

  • A team building a stable internal tool might stay at Delivering.
  • A startup-style innovation team should reach Optimizing.
  • A team in a mature organization with cross-team coordination needs may benefit from Strengthening.

The right zone is the one where the team's investment matches the organization's need. Pushing every team to "advanced" agile is itself a misunderstanding.

How the Model Is Used

  • Coaching framework. Coaches use the zones to identify what investment a team most needs next.
  • Leadership conversation tool. The model translates "agile" into specific investments leadership can decide to make or not.
  • Self-assessment. Teams use the model to honestly assess where they are and where they want to be.
  • Diagnostic for stuck teams. A team that "did agile" but isn't getting the benefit usually skipped an investment. The model helps identify which.

The Common Misunderstandings

  • "Strengthening is the goal." No. The right zone depends on context. Strengthening is more valuable for some teams, irrelevant for others.
  • "Levels of maturity." No. The zones are different bundles of investment, not stages of development.
  • "All teams should be at the same zone." No. Different teams have different value goals.
  • "You can get to a zone without investing." No. The whole point is that the benefits require the investments.

Coaching Tips

Diagnose by missing investment.

A team that's not getting the benefit usually skipped an investment. The model points at which.

Pick the zone that fits the team's need.

Some teams should stay at Delivering. Pushing to Optimizing without value justification is overreach.

Translate to leadership investment conversations.

"You can't reach Delivering without CI/CD" is more useful than "we need to do agile better."

Don't make zones a hierarchy.

The model is explicit they aren't. Resist the natural urge to make Strengthening "best."

Use the official self-assessment.

The Agile Fluency Project provides a structured self-assessment. It's more rigorous than ad-hoc judgment.

Pair with portfolio prioritization.

Different teams in different zones is fine. Match the zone to the value the team is being asked to produce.

Summary

The Agile Fluency Model is the most intellectually honest treatment of "agile maturity" in the literature. By replacing the linear-level model with four zones requiring specific investments, it makes the conversation about agile concrete: what benefits does the organization want, what investments are required to get them, and is leadership willing to make those investments? Teams and organizations that engage with the model seriously usually discover their agile dysfunction isn't a method problem — it's an investment problem. That clarity, alone, is worth the framework's existence.

Footnotes
  1. Shore, James and Diana Larsen. "The Agile Fluency Model." Martin Fowler's blog, 2018.
  2. Shore, James. The Art of Agile Development. 2nd Edition, O'Reilly, 2021.
  3. Agile Fluency Project. agilefluency.org — the official framework site.
Back to Scaling Agile