The Agile Fluency Model (image source).
I was diving into the new Scrum Guide Expansion Pack and Open Guide to Kanban recently, and it hit me once again: comprehensive guides don’t solve the real adoption barriers.
This got me thinking about the Agile Fluency Model by Diana Larsen and James Shore—and honestly, it captures my discomfort with those new documents better than my earlier review did. The model offers a refreshingly different take on these challenges.
Why I’m Into This Model
What I like about the Agile Fluency Model is its pragmatic, intent-driven approach compared to overly rigid agile frameworks. It emphasizes value outcomes, investments needed, and improvement grounded in context—not some one-size-fits-all dogma.
More importantly, it directly addresses the mindset and habits challenge while acknowledging system constraints that most agile guides simply ignore.
The Four Zones (Plus a Reality Check)
The Agile Fluency Model introduces four zones: Focusing, Delivering, Optimizing, and Strengthening.
Here’s the uncomfortable truth: Many teams will never develop fluency in that fourth zone (Strengthening), and many won’t even hit the third (Optimizing). And that’s perfectly fine. Firstly, it takes more time to develop fluency in those two zones, and secondly, they require structural and cultural changes in the organisation.
The Agile Fluency Model (detailed version).
This isn’t a maturity model—it’s a collection of choices. As the model puts it: Each zone represents a fully-mature choice. Each one brings value.
The Question That Actually Matters
Are we building practices or capabilities?
Many teams focus on adopting practices (events, tools, processes) rather than developing capabilities (problem-solving, adaptation, flow). The Agile Fluency Model works as a developmental roadmap to build those capabilities—not a performance target to rush toward.
Pushing teams toward next fluency zone without organizational support only creates stress and disengagement.
Where This Gets Really Useful
I’m still learning about the model and its practical implications, but here are some ways I’ve found it helpful for teams:
Figuring Out Where You Are
- Honestly assessing team fluency without the judgment
- Identifying “fluency friction“ when team and organization have mismatched expectations
Getting Everyone on the Same Page
- Setting team goals that actually match what you’re capable of (match fluency aspirations)
- Aligning what you want with what’s actually possible (systemic realities)
- Being real about which constraints you can change and which you can’t
Making Actual Progress
- Understanding the psychological toll when teams feel forced to do “perfect agile“ in organizations that don’t support it
- Knowing when to stop pushing for more and just get really good at where you are
- Avoiding cargo-cult agile in culturally diverse contexts
- Finding practical next steps through coaching, experiments, and organizational changes
The Thing That Really Matters
Teams develop fluency, but organizations have to enable it
This is why more comprehensive guides miss the mark. Teams don’t need more theory about advanced practices—they need organizational support to develop the capabilities they’re already trying to build.
My Take
We should approach the Agile Fluency Model with humility and realism—not as another maturity checklist. It’s a diagnostic tool that helps us understand where we are and what investment is needed to get where we want to go.
The best part? It lets you choose the zone that actually makes sense for your organization and people—based on what’s genuinely possible given your context and team mindset—without getting caught up in all the cargo-cult agile expectations.
What’s your experience with the Agile Fluency Model? Have you seen teams struggle with that fluency friction? How do you balance what you want to achieve with what’s actually realistic?