Choose Your Agility
Agile includes a lot of ideas. Which ones should you actually use? The answer depends on what you want to achieve, and what your organization is willing to invest in return. To decide, use the Agile Fluency Model.1
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, and, over the years, we noticed that they tend to cluster in different “zones” of capability. We captured these observations in the Agile Fluency Model. A simplified view is shown in Figure 4-1. [Link to Come]
Although this simplified figure shows a straightforward path from one zone to the next, reality is messier: the zones are actually clusters of skills, and they all develop in parallel. A team has term:[proficiency] in a zone when they’re able to apply all of its skills. They have term:[fluency] when they can do so without conscious effort. Teams can achieve fluency in any order, but the progression shown in the figure is most common.
Each zone is associated with a set of benefits. To reap those benefits, a team needs to be fluent in that zone. But achieving fluency isn’t just something do on their own. Your organization also has to invest in supporting them. That means more than paying lip service to Agile ideas. They have to make actual, meaningful changes that cost time, money, and political capital.
In other words, the results you get from your Agile teams depend on how well your company buys in to Agile ideas. When a company fails to achieve the results they want from Agile, it’s usually because they didn’t make the investments they needed to. Often, they don’t even realize they had to participate. So they don’t act, and fail by default.
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 tradeoffs 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.
The Focusing zone is about Agile fundamentals: focusing on business results; working as a team; taking ownership. Teams that are fluent in this zone see the improvements in value described in “Organizational Success” of Chapter 2. They focus development on their team’s core purpose, release their most valuable features first, and change direction in response to changing business needs.
They also see some of the improvements to personal success described in “Personal Success” of that chapter. Specifically, stakeholders like their improved visibility into the team’s work and their ability to influence teams’ plans.
To achieve these results, Focusing teams regularly review and change their plans. They work as a tightly-knit team to define their own work processes and self-organize around completing their work. All the while, they’re Focusing on the next piece of value for their organization.
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.
These changes correspond to the essence of Agile: Agile is adaptive rather than predictive, and people-oriented rather than process-oriented.
Can your organization buy into this core philosophy? Again, lip service isn’t enough. To succeed, they’ll need to make concrete investments in the form of changes to team structure, management, and work environment. (See Chapter 5 for details.) 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 Agile ideas. 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.2 Part II has the practices they’ll need.
Despite its benefits to organizational and personal success, the Focusing zone won’t improve technical success, and the cost savings described in “Organizational Success” of Chapter 2 aren’t likely to appear, either. In fact, technical quality could get worse. Traditional approaches to design rely on careful up-front work based on firm plans. That doesn’t mesh well with Agile’s emphasis on flexible, frequently changing plans. As a result, Focusing teams often end up with an ad-hoc approach to design, which isn’t sustainable.
Poor technical quality can be frustrating for team members, lowering their feelings of personal success. It usually prevents the team from making reliable forecasts and commitments, which can be frustrating for stakeholders.
To improve technical success and make useful forecasts, you’ll also need fluency in the Delivering zone.
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 by focusing on technical agility. They design their code so that it can absorb 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.
This results in the technical success described in “Technical Success” of Chapter 2, the cost reductions described in “Organizational Success”, and the team member success factors described in “Personal Success”. Combined with Focusing fluency, that’s all the success factors described in that chapter.
Achieving these results requires a substantial investment in team members’ skills, as well as structural changes to integrate people with skills such as testing and operations into each team. (See Chapter 5 for details.)
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. [Link to Come] has the practices. The exact amount of time each team needs will depends on the quality of their existing code and how much coaching they receive.
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. [Link to Come] 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, start with [Link to Come].
Choose Your Zones
Which Agile ideas should your teams use? It depends on which zones your organization can support. In a vacuum, Focusing, Delivering, and Optimizing, all together, is your best choice. They 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, only choose 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 isn’t a good fit.3
Delivering fluency decreases costs and increases development speed. It takes time to learn, but you’ll see benefits within 2-6 months, and it will pay for itself within a year. 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 Delivering zone 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.
If you aren’t sure, start with the Focusing and Delivering zones.
Whichever zones you choose, invest in learning all their practices simultaneously. The techniques 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 as long as you can at least invest in Focusing fluency, you can build up to the other zones over time.
Once you’ve chosen your zones, it’s time to consider your organization’s investments in more detail. We’ll study them in the next chapter.
1 “Agile Fluency” is a registered trademark of Agile Fluency Project LLC, founded by Diana Larsen and James Shore.
2 The time frames in this chapter are all ballpark figures based on my experience. Your experience may be different.
3 It’s technically possible to invest in Delivering or Optimizing fluency without also investing in Focusing fluency, but doing so is outside the scope of this book.