The Agile Fluency Model
The Agile Fluency Model (AFM) was first introduced in 2011–2012, by Jim Shore and Diana Larsen. Shore and Larsen recognized a problem back then which still persists today — there are far too many organizations where Agile transformations fail or at the very least do not provide the benefits that were expected when they started on their Agile journey.
What the AFM is not
Shore and Larsen are quick to point out that the AFM is NOT a maturity model. The AFM does have four levels (see below for more about its structure), but unlike maturity models, it is non-prescriptive in the sense that it’s up to an organization to decide where on the AFM would be the best place for them to be.
The AFM is also not a methodology or a framework. A cottage industry has surfaced in the Agile community where there are multiple frameworks and methodologies vying for attention, and in many cases, for an organization’s dollars.
What the AFM is
As the AFM website says
There is no right destination on the pathway to Agile Fluency. Investment at any point along the pathway to Agile Fluency can yield benefits.
As shown in the diagram at the beginning of this post, there are four areas of focus in the AFM. It is important to point out that each of the four areas has benefits, and also that greater investment is needed to get from the top to the bottom of the diagram. One of the reasons why greater investment is needed is that the top two areas focus on changes at the team level, while the bottom two areas focus on changes at the organizational level:
- Focus on Value
- Deliver Value
- Optimize Value
- Optimize for Systems
The Four Areas of the Agile Fluency Model
Note that the explanations of each of the four areas below are excerpted from a longer article by Shore and Larsen about the AFM on Martin Fowler’s website.
Note: In the longer article on Fowler’s website, various places on the model are referenced with terminology such as “one-star teams,” “two-star teams,” ‘three-star teams,” and “four-star teams,” where the top area (Focus on Value) is where a one-star team would be, and the bottom area (Optimize for Systems) is where a four-star team would be. In later articles the association of a particular number of stars with a particular place in the model is deemphasized; structurally the model remains the same.
Focus on Value
Teams with a Focus on Value seek to make sure that they are working on the features that are most likely to benefit their sponsors, customers, or users. The characteristics of such teams include:
- Process. Scrum and/or Kanban are likely to be used by such teams, along with a small subset of the XP technical practices.
- Benefits. The benefits include: Greater visibility into what any given team is working on and the progress they are making; More collaboration among team members, reducing the likelihood for misunderstanding or hand-off delays.
- Measurements. It any given time, it should be reasonably clear how much progress any given team is making toward delivery of the features that stakeholders have requested.
Deliver Value
Teams that Deliver Value not only focus on features with reasonably high business value, they do so in such a way that they can deliver those features early and often. Therefore such teams have reasonably mature technical practices, which include the ability to do Continuous Delivery (CD). The characteristics of such teams include:
- Process. Scrum-XP hybrid, Kanban-XP hybrid, XP, or a variant of XP are the most likely processes on such teams. No matter which process those teams might be following, they will unquestionably be using a large number of the XP practices, if not all of them.
- Benefits. Fast concept-to-delivery cycle times help expose flaws or non-optimal design decisions early; In addition to the obvious benefits associated with a high level of technical quality and frequent delivery, other benefits tend to include higher team morale, and greater predictability in terms of what individual teams can deliver
- Measurements. The most important measurement is the ability to ship new features on a cadence dictated by the market, as opposed to a cadence dictated by internal process or technical constraints. Defect rates also tend to be lower.
Another significant difference with Deliver Value is that the focus shifts to team skills (whereas with Focus on Value, the focus is on team culture). As Shore and Larsen point out,
This is the most skill-intensive fluency level. There are a lot of techniques to learn. Some, such as test-driven development, are of the ‘moments to learn, lifetime to master’ variety… study and practice techniques such as those described by Extreme Programming, Software Craftsmanship, DevOps, and Agile software quality gurus [are necessary]… Collective [code] ownership, pair programming, and working in a common team room are useful ways to help team members bring each other up to speed.
It is also important to consider that when teams try technical approaches that are less familiar to them, or need to pay down technical debt, team productivity tends to decline over the short term, but over the long term the team sees significant productivity gains, not to mention the ability to ship completed software features on demand.
Optimize Value
- Process. Variations on Lean Startup or Lean Software Development are common for teams seeking to Optimize Value, along with the full complement of XP technical practices.
- Benefits. Shorter feedback cycles are typical, and there is a high degree of focus in areas such as RoI and customer satisfaction scores. Trust between a team and its organization also tends to be higher, so there should be fewer communication gaps and hand-offs, and the ability to make course corrections more rapidly.
Another difference with teams that focus on Optimize Value is embedding of additional business domain experts as full-time members of teams, such as Business Analysts, or Subject Matter Experts with particularly deep domain knowledge in one or more areas.
The organizational changes tend to be significant, because managers need to work more collaboratively across the organization, often as part of cross-functional management teams, so that they can focus on removing obstacles that impede rapid delivery of features. Furthermore, teams are truly self-organizing and are empowered to make virtually all decisions that need to be made in terms of what to work on and what technical approach to take.
Optimize for Systems
- Process. Teams focusing on Optimize for Systems are at the “Ri” end of the Shu-Ha-Ri spectrum, meaning that they customize and optimize their practices to fit their particular context on an ongoing basis. Thus they tend to borrow some of the constructs and terminology from the approaches mentioned above, often with significant modifications. In short, they seek to optimize the entire value stream, across the enterprise.
It is a high bar for organizations to operate consistently at this level — as Shore and Larsen point out,
If your team doesn’t understand how its work contributes to the organization’s overall value stream, they aren’t yet fluent at optimizing for whole system success… We’ve most often seen [this level of performance] in single-team startups, where it’s not much different from [Optimize Value]… It seems to be easiest to approach [Optimize for Systems] in organizations where trust is high, communication overhead is low, and business information is widely shared. Smaller organizations can start with a culture that supports an Agile mindset across functions and levels. They support intact teams where the work comes to the team, rather than teams repeatedly reforming to fit the work. Working as intact, ongoing teams enables them to demonstrate high performance and [Optimize for Systems].
Additional References
- Agile Fluency Project, The Agile Fluency Model Explained: A Brief Guide to Success with Agile [video]
- Arlo Belshee, Agile Engineering Fluency — Stages of Practice Map
- Jim Shore, Agile and Predictability
- Kelsey van Haaster, Road-mapping Your Way to Agile Fluency
