This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.
Choose Your Agility
There’s no point in Agile for the sake of Agile. Instead, ask yourself two questions:
Will Agile help us be more successful?
What will it take to achieve that success?
When you can answer these questions, you’ll know whether Agile is right for you.
What Do Organizations Value?
There’s more to success than revenue. Here’s a partial list:
Improving financial results: profit, revenue growth, shareholder value, cost savings
Achieving organizational goals: strategic objectives, original research, charitable causes
Improving market position: brand projection, competitive differentiation, customer loyalty, attracting new customers
Gaining understanding: strategic information, analytics, customer feedback
Reducing risk: security, regulatory requirements, auditing
Increasing capacity: hiring, retention, morale, skill development, automation
The Agile Fluency Model
In 2014, I partnered with Diana Larsen to analyze why companies see such different results from their Agile teams. We had both worked with Agile teams from the beginning. Over the years, we noticed that they tended to see dramatically different types of results, and those results tended to cluster in different “zones.” We captured these observations in the Agile Fluency Model. A simplified view is shown in the “Agile Fluency Model” figure. [Shore2018b]
Each zone is associated with a set of benefits. To reap those benefits, a team needs fluency in that zone. A team has fluency when they’re able to apply all the skills associated with the zone without conscious effort.
Although the figure shows a straightforward path from one zone to the next, reality is messier. Teams can achieve fluency in any zone, in any order, although the progression in the figure is typical.
The skills needed for fluency are listed in the introductions to Parts II through IV. But fluency isn’t something a team can achieve on its own. Your organization also has to invest in your teams’ fluency. That means more than paying lip service to Agile ideas. It has to make actual, meaningful changes that cost time, money, and political capital.
The results you get from your Agile teams depend on how well your company buys into Agile ideas. When a company fails to achieve the results they want from Agile, it’s usually because they didn’t make the required investments. Often, they don’t even realize what was needed.
Make a conscious choice to invest in agility.
Make a conscious choice to invest in agility. Consider each zone carefully. Each has costs; each has benefits. Choose the ones that have the right cost-benefit trade-offs for your situation.
You probably won’t be able to convince your company to invest in every zone. That’s okay. In contrast to maturity models such as the Capability Maturity Model Integration (CMMI), the fluency model doesn’t show a progression from low skill to high skill. Instead, it shows multiple investment/benefit choices. Although the diagram shows the most common progression, each zone may be chosen independently. Each has value on its own.
Fluency and Maturity
Fluency is an emergent property of the team, not any one individual. Fluency doesn’t mean every team member has every skill associated with the zone. Instead, they need the ability, as a whole team, to bring the right people to bear at the right times.
Each zone has several levels of maturity:
Learning. The team is learning the skills.
Proficient. The team is able to exhibit the skills when it concentrates on them.
Fluent. The team exhibits the skills automatically, without conscious effort, as long as it has a coach as part of the team.
Independently Fluent. The team exhibits the skills automatically without needing a coach or any one team member.
The Focusing zone is about Agile fundamentals: focusing on business results; working as a team; taking ownership. Teams that are fluent in this zone focus development on their team’s core purpose, release their most valuable features first, and change direction in response to changing business needs. They’re constantly Focusing on their organization’s most valuable priority.
For most teams and organizations, this requires a shift in how they think about teams. Pre-Agile organizations make plans in advance, ask teams for estimates, and expect reports about how work is progressing relative to those estimates. Focusing teams revise their plans frequently—at least every month—and demonstrate progress by showing what they’ve completed.
Pre-Agile organizations break their plans into tasks, assign those tasks to individuals on the team, and judge individuals based on how well they complete their tasks. Focusing teams do their own task breakdowns, decide for themselves who will work on each task, and expect to be judged on their ability to create value as a team.
For a team to succeed, your organization will need to support these changes with concrete investments in the form of changes to team structure, management, and work environment. (I’ll go into detail in the next chapter.) It’s a “good news, bad news” situation: the bad news is that, when the rubber meets the road, some organizations won’t be willing to invest. The good news is that, if they refuse, you’ve discovered early on that they’re not really on board with the Agile philosophy. You just saved yourself years of frustration and heartache chasing Cargo Cult Agile.
If you are able to get buy-in, Focusing fluency will take each team about 2–6 months of dedicated effort to achieve. With proper support, they’ll exceed their prior levels of performance within 1–4 months.1 Part II has the practices they’ll need.
1The time frames in this chapter are all ballpark figures based on my experience. Your experience may be different.
Agile teams may change their plans at any time. For most teams, this slowly degrades the quality of their code. They gradually lose their ability to make cost-effective changes. Eventually, they say they need to throw away the software and rewrite—an expensive and wasteful proposition.
Delivering teams prevent this problem through technical excellence. They design their code to respond to frequent changes. They keep code quality high, so they don’t waste time hunting bugs. They refine their production lifecycle so releases are painless and operations are manageable. They’re capable of Delivering reliable, low-defect software whenever it makes the most business sense.
Achieving these results requires a substantial investment in team members’ development skills, as well as structural changes to integrate people with skills such as testing and operations into each team.
If your company makes these investments, Delivering fluency will take each team 3–24 months to develop, and you’ll see improved performance within 2–6 months. The exact amount of time each team needs will depends on the quality of its existing code and how much coaching team members receive. Part III has the practices.
Most companies would be satisfied with Focusing and Delivering fluency. But Agile imagines more. In its full glory, Agile is a world in which teams twirl and dance in response to changing market conditions. They experiment and learn; develop new markets; outmaneuver the competition.
Optimizing teams achieve this level of agility. They understand what their market wants, what your business needs, and how to bridge the two. Or, as in a startup environment, they know what they need to learn and how to go about learning it. They’re constantly Optimizing their product plans to achieve the most value possible.
This requires a shift in organizational structure. Creating optimal plans requires constant attention by people with deep business and product expertise, and that means having product and market experts join development teams full-time. It also means giving those teams full responsibility for their product budgets and plans.
These structural changes require high-level permission in the organization. It can be difficult to obtain. Teams typically need to spend at least a year building trust via Delivering fluency before they get permission for these investments. Once that happens, Optimizing fluency takes another 3–9 months to develop, although you’ll see improvements within 1–3 months. But even then, Optimizing is a never-ending process of experimentation, learning, and discovery. Part IV describes how to begin.
There’s one final zone in the Agile Fluency Model. It’s largely speculative: a possible future for Agile. It’s also only appropriate for organizations on the bleeding edge of management theory and practice. That puts it out of scope for this book. Briefly, the Strengthening zone involves distilling teams’ collective insights and channeling them into organizational improvements. If you’d like to learn more, see the “Into the Future” chapter.
Summary of Agile Fluency Zones
Main benefit: Focus on business priorities; visibility into teams’ work; ability to change direction
Investments: Team structure; management; work environment
Approximate timing: 1-4 month performance dip; 2-6 months until fluency
Main benefit: Low defects and high productivity; technical longevity
Investments: Development skills; integrating testing and operations
Approximate timing: 2-6 month performance dip; 3-24 months until fluency
Main benefit: Higher-value releases and better product decisions
Investments: Embedded product management; team ownership of budgets and plans
Approximate timing: 1-3 month performance dip; 3-9 months until fluency
Choose Your Zones
Which fluency zones should your teams pursue? It depends on which zones your organization can support. In a vacuum, Focusing, Delivering, and Optimizing, all together, are your best choice. The combination of all three provides the best results and purest realization of Agile ideas.
But choosing all three zones also takes the most investment. If you can’t justify those investments, you’re likely to have trouble getting the support you need. And without sufficient investment, your teams will have trouble reaching fluency. You’ll incur the costs of learning without getting all the benefits. You might even see worse results than now.
In other words, choose only the zones your company both needs and is willing to pay for.
So, which zones should you choose?
Every Agile team needs Focusing fluency. It’s fundamental. If your company can’t at least invest in Focusing fluency, Agile probably isn’t a good fit, although you may be able to work your way up to it by starting with Delivering fluency instead.
Delivering fluency decreases costs and increases development speed. Without it, your code will eventually succumb to technical debt. That makes the Delivering zone a no-brainer for most teams. That said, some organizations aren’t ready to make the big investments in learning and code quality that the Delivering zone requires. It’s okay to start with Focusing fluency first, demonstrate success, and then use that to make the case for further investment.
Optimizing fluency is where Agile shines brightest. It’s also a lot to ask. For most organizations, it’s best to build trust by demonstrating fluency in the Focusing and Delivering zones first, then gradually take on more responsibility. But if your organization already has a culture of delegating decision-making authority to cross-functional teams, as is often seen in startups, Optimizing fluency will give you great results.
For details about each zone and their benefits, see the introductions to Part II, Part III, and Part IV. For a detailed summary of the investments required, see the “Summary of Investments” sidebar. If you aren’t sure which zones to choose, start with Focusing and Delivering.
Whichever zones you choose, invest in learning all their practices simultaneously. The practices in the later zones make the earlier zones work better, so you’re better off adopting them together rather than one at a time. But if you can’t invest in every zone you want, that’s okay. It takes longer, but you can build up to the other zones over time.
Once you know which zones you want, it’s time to consider your organization’s investments in more detail. We’ll study them in the next chapter.