The Agile Fluency Model

Introducing the Model

We’ve observed that agile teams pass through four distinct zones as they learn. Each zone brings specific benefits:

1. Focusing teams produce business value.
2. Delivering teams deliver on the market cadence.
3. Optimizing teams lead their market.
4. Strengthening teams make their organizations stronger.

Each zone depends on a set of agile proficiencies. A proficiency is an observable behavior—such as “The team works with a business representative who provides the team with the business's perspective and expectations”—that leads to the zone’s benefits.

In the Agile Fluency Model, we’re most interested in fluent proficiency: a habit of exhibiting the proficiency at all times, even when under pressure. Anyone can follow a set of techniques when given time to focus in a classroom; true fluency is skillful, routine ease that persists when your mind is distracted with other things.

Agile development is a team sport, so fluency is a trait of the team, not individual team members. In practice, some proficiencies will be exhibited by all team members and some will be the specialty of a few individuals. Either way, a team’s fluency comes from the ability of team members to self-organize so that individual skills are applied to the right problems at the right times.

A team is fluent in a zone when it’s fluent in all of the zone’s proficiencies, including predecessor zones. Although teams develop proficiencies in any order, even from multiple zones simultaneously, we’ve observed that teams tend to gain zone fluency in a predictable order.

You may use this diagram yourself so long as you preserve the copyright notice. Download the horizontal version (PNG, PDF); a vertical version (PNG, PDF); or a detailed version (PNG, PDF).

Choose Your Zone

Each fluency zone brings new benefits, so it may seem that the model should be treated as a maturity model, in which the goal is to reach maximum maturity. That would be a mistake. Unlike maturity models, where more mature is always better, the fluency model describes a collection of choices. Each zone represents a fully-mature choice. Each one brings value.

Think of fluency as a ride on a bus. When you get on a bus, you buy a ticket for the zone that you want to reach. A zone that’s further away isn’t inherently more valuable; it just costs more and takes longer to get to. Sometimes you’ll buy a bus ticket for the suburbs, because you want to go to a big box store. Sometimes you’ll buy a ticket for downtown, because you want to see a play. Neither is inherently better—it all depends on what you need that day.

Similarly, while each zone has value, each zone also brings challenges. Investing in more than you need could incur organizational backlash, and could even poison people’s perception of agile ideas in general.

The appropriate zone for your teams depends on your organization. Delivering or Optimizing are often the best targets, but Focusing and Strengthening can also be good choices.

• The Focusing zone represents agile fundamentals, and fluent teams provide noticeable benefits to transparency and teamwork. Although Focusing fluency doesn’t include sustainable technology practices, it’s a great way to demonstrate success and create buy-in for further investment. It’s also a good fit for teams, such as some digital agencies, that don’t maintain their software long-term.

• For teams that need to modify and enhance their software for more than a few months, Delivering fluency is often a better choice. This zone represents agile sustainability. Delivering teams have low defects, high productivity, and are responsive to business requests. Fluency here is a valuable leap forward for most teams.

• Organizations that wish to set the pace of change in their market, or who see the threat of market disruption on the horizon, will benefit from choosing the Optimizing zone. Optimizing represents the promise of agile: innovative business agility. Although it has dramatic payoffs, it also requires disruptive changes to organizational structure. Making those changes is often easiest in small, nimble organizations.

• Leaders who want to innovate management theory and practice, particularly in small- to mid-size organizations, may find the Strengthening zone to be the best fit for their teams. This zone is a possible future of agile. Cutting-edge agile practice appears to be moving in that direction. However, be cautioned that this zone requires researching cutting-edge management theory and inventing new ways of working.

Even within a single organization, different fluency zones can be appropriate for different teams. Later in this article, we describe the investments and benefits involved for each zone. As you read through the zones, remember that every zone has its own costs and trade-offs. Think carefully about the trade-offs that are right for you rather than simply assuming more is better.

Achieving Fluency

Fluency is more a matter of habits than skills. Although training can teach the underlying techniques, the skillful ease at the heart of fluent proficiency requires deliberate, thoughtful, day-in-day-out practice over months. It comes from a deliberate investment in learning through practice.

The proficiencies involved in later zones tend to require more time than the proficiencies for earlier zones. The sooner a team starts working on a zone’s proficiencies, the sooner the team will become fluent in them. Agile proficiencies are also mutually supportive. Accordingly, it’s best to choose the zone of fluency you want to reach and start practicing all the proficiencies needed for that zone—and all prior zones—simultaneously.

(Of course, you can always change your mind. There’s no harm in starting with one zone and targeting a different zone later. It just takes longer.)

As a team practices its proficiencies, fluency will develop in fits and starts. Rather than an orderly progression of proficiency from one zone to the next, proficiencies will develop in parallel across all zones. You’re likely to see encouraging signs quickly, but the mastery and reliability of true fluency can be frustratingly slow. Proficiencies plateau, jump forward and back, and progress at different rates.

One of the biggest factors affecting team fluency is organizational support. To continue the bus metaphor, the team has to ride the bus to their fluency zone. No one can do it for them. But the organization has to buy the bus ticket. An organization that expects fluency without providing appropriate support is bound to be disappointed. Even worse, insufficient support can cause turnover and create a cynical corporate culture that hinders improvements. Before embarking on your fluency journey, be sure your organization is prepared to offer the support the journey needs.

One of the biggest investments the organization will make is time. True fluency takes longer than anyone expects or wants. In our experience coaching teams, it takes a team two to six months to become fluent in the Focusing zone. Reaching the Delivering zone takes another 3-24 months, depending on the amount of technical debt in the code. Optimizing fluency can take another 1-5 years, depending on organizational trust and willingness to change reporting structures.

Losing Fluency

It’s rare for stable teams to lose fluency on their own. In our experience, it’s external disruption that causes fluency loss.

The most common cause of fluency loss is when new management decides that agile approaches don’t fit their vision. Without organizational support and the ability to continue practicing what they’ve learned, team fluency erodes quickly. This is often accompanied by loss of expertise as dissatisfied team members seek new positions.

Turnover is a related cause of fluency loss. A team that gains or loses too many members may have trouble sustaining what it’s learned. This is a particular problem for organizations that assemble new teams for every project.

Rapid growth and imposed processes can also lead to loss of fluency. Successful startups often struggle with this. When they're small, startups often instinctively operate in the Optimizing or even Strengthening zones. (They’re not necessarily fluent in every proficiency, but their instincts push them towards those zones.) Once a startup starts growing rapidly, they often introduce bureaucracy and processes that accidentally damage the ad-hoc processes and culture that enabled fluency.

Similarly, companies that have had success using agile ideas in individual teams sometimes impose a scaling framework on their teams. Most of these frameworks are only designed to support Focusing fluency, and some are designed more for management appeal than agile excellence. This makes developing and sustaining fluency at later zones difficult.

That’s not to say ad-hoc growth is the correct answer, either. The relationship between growth, scaling, and fluency is a complex topic deserving its own article. For now, we’ll just say that, to have fluency at scale, you must have fluency in each individual team. When you evaluate scaling options, consider how your choices support and hinder the proficiencies of the zones you want.

Organizational Fluency

In an agile organization, the work of the organization is done by teams of collaborative people who have a shared purpose and interdependent work. As a result, fluency derives from teams. An individual or organization may contribute to a team’s fluency, but they can’t be fluent on their own.

Although an organization itself can’t be fluent, it does make sense to talk about the fluency that an organization enables. Team fluency depends on more than just the skills of team members. It also depends on management structures, relationships, organizational culture, and more. Don't make the mistake of blaming individuals for a team’s lack of fluency, or assuming that one highly-skilled individual will guarantee fluency. The organizational context often matters more.

When a team hits a roadblock in their fluency development, they’ll typically struggle with a few specific proficiencies. Sometimes the problem is a lack of knowledge or skills, and training and mentoring is all the team needs.

More often, the team’s development is actually blocked by organizational constraints. You can check for organizational constraints by conducting a fluency diagnostic across several teams. (The Agile Fluency Project offers diagnostic options at agilefluency.org.) If multiple teams are having trouble with the same proficiencies, there’s a systemic issue that requires organization-level investment and change.

In the sections that follow, we describe the proficiencies and organizational investments needed for each zone. As you read them, think about which zones your organization is prepared to enable, and which ones it’s currently designed to hinder.

“Focusing” Teams Produce Business Value

Fluent Focusing teams work as a cohesive team with shared goals. They think and plan in terms of the benefits their sponsors, customers, and users will see from their software. This is in contrast to teams who are just starting their agile journey, who tend to think in terms of technical considerations, such as software layers, and who often work as individual contributors with individually-assigned tasks.

Scrum, Kanban, and the non-technical parts of Extreme Programming are examples of agile methods that teams use to reach Focusing fluency. User stories are one of the most common techniques teams adopt. Other techniques include backlogs, retrospectives, timeboxes (such as Sprints), and team task boards. Focusing teams also give attention to interaction concepts such as psychological safety, team chartering, group learning, and peer feedback.

Teams fluent in this zone show what they’re working on, and how it’s progressing from a business value perspective, at least once per month. This is the core metric for Focusing teams: it’s not the only benefit you should expect from a fluent team, but it’s an easy, quick way to check if a team might be fluent. If you don't have visibility into the team's business priorities, or if those priorities don't reflect what the team’s actually working on, then the team isn’t yet fluent.

Focusing benefits derive from effective communication, collaborative teamwork, and continuous team improvement. Fluent proficiency in these categories isn’t a technical challenge, but the shift to team culture can be difficult for some people. Team members must learn to plan in terms of business outcomes rather than technology. They need to learn to take responsibility for the whole team's success, not just their individual contributions. Managers must learn to support teamwork over individual rewards and task planning.

Investment/Value Tradeoff: It takes two to six months of practice for a group of independent individual contributors to make the shift to a collaborative, team-based work style. Their fluency depends not only on their efforts, but the investments of their organization. As we’ve said before, the team may be driving their fluency bus, but their organization needs to buy the bus ticket.

For many managers and organizations, the most challenging investments are non-monetary. Enabling a team to work effectively as a team can require changing management behavior, dedicating team members full-time to their team, and redesigning physical workspaces. In particular, managers must shift from managing the contributions of individuals to managing the work system—guiding team processes, work habits, skills, and context such that the team makes correct decisions without explicit management involvement.

We see many organizations that choose not to make these investments, but still expect fluency from their teams. In these instances, team proficiencies develop slowly and full fluency is rarely achieved. If your organization can’t make the requisite investments, agile approaches will disappoint.

In exchange for making these investments, you’ll have greater visibility into what your teams work on and you’ll be able to direct them towards the 20% of their work that provides 80% of the value.

“Delivering” Teams Ship on the Market Cadence

Fluent Delivering teams not only focus on business value, they realize that value by shipping as often as their market will accept it. This is called “shipping on the market’s cadence.” Delivering teams are distinguished from Focusing teams not only by their ability to ship, but their ability to ship at will.

Extreme Programming (XP) pioneered many of the techniques used by Delivering teams and it remains a major influence today. Nearly all fluent teams use its major innovations, such as continuous integration, test-driven development, and “merciless” refactoring.

In recent years, the DevOps movement has extended XP’s ideas to modern cloud-based environments. The movement’s Continuous Delivery and Continuous Deployment techniques are used by most Delivering teams. Other useful techniques include evolutionary design, collective ownership, and pair programming or mobbing.

Teams fluent at Delivering create low-defect software that can be shipped as often as your organization desires. If a team can’t release at will, they aren’t yet fluent.

Delivering is the most technically-intensive fluency zone. There are a lot of skills to learn. Some, such as test-driven development, are of the “moments to learn, lifetime to master” variety. Team members will benefit from studying and practicing techniques described by Extreme Programming, DevOps, and agile software quality gurus. Managers will need to ensure that the team is staffed with people who collectively have all the expertise needed, and they’ll need to work with stakeholders to establish an expectation that thoughtful work is valued over expediency.

Investment/Value Tradeoff: Developing team members’ skills to the point of fluency takes time and significant effort. Delivering fluency typically appears 3-24 months after Focusing fluency, depending on the amount of coaching the team receives and the amount of technical debt in their codebase. Large systems with very high amounts of technical debt could take even longer.

Training courses can introduce the concepts needed for Delivering fluency, but students often have difficulty translating course examples back to their real-world problems. In many cases, fluency also requires engaging skilled practitioner-coaches to work with the team on their real-world projects. In addition, productivity will often appear to decrease as the team learns new skills and pays off technical debt in existing code.

Despite the costs, the benefits of Delivering fluency are substantial. Fluent teams produce very low-defect software and keep technical debt to a minimum, which means they have more time for delivering features. It takes time for pre-existing technical debt to be paid off and benefits to appear, but once they do, you’ll see faster development times, higher quality software, and dramatically improved responsiveness.

“Optimizing” Teams Lead Their Market

Fluent Optimizing teams understand what their market wants, what your business needs, and how to meet those needs. Or, as in a startup environment, they know what they need to learn and how to go about learning it. In contrast to Delivering teams, Optimizing teams not only have the ability to deliver to market, they also know what to deliver to market.

Most agile methods are designed to help teams reach Focusing or Delivering fluency. To gain fluency in the Optimizing zone, start with a Delivering foundation (such as Scrum + XP + DevOps, Kanban + XP + DevOps, or just plain XP + DevOps) and layer product-centric techniques on top of that foundation.

Lean Startup and Lean Software Development—which, despite the similar names, are different approaches—are both good places to start. Managers will benefit from familiarizing themselves with Beyond Budgeting. From there, be prepared to seek out and experiment with product-focused agile techniques. Useful topics include customer discovery, continuous product discovery, design thinking, story mapping, and adaptive planning.

Fluent Optimizing teams understand their market. They know why they’re building something, not just what they’re building. At a minimum, conversations with a fluent Optimizing team will demonstrate a clear-headed view of where their products stand in the market. The team will define its own metrics (or other indicators of progress), they’ll be able to defend those choices, and they’ll have plans to improve their market position.

If a team doesn’t have this sort of understanding of their products and market, or if they produce less value than their opportunity costs, they aren’t yet fluent at Optimizing. As a corollary, fluent Optimizing teams will coordinate with leadership to cancel or pivot low-value products and initiatives.

One of the biggest challenges in enabling Optimizing fluency is giving the team true control over its product direction. The distinction between an Optimizing team and a Delivering team is that, within the constraints of its charter, the Optimizing team makes its own decisions about what to fund and where to focus their efforts. Managers need to delegate this power to teams, which is often a difficult change for organizations.

Of course, to own those decisions, teams need to have the insight to make the right decisions… or at least know which experiments will help them discover the right decisions. Gaining that expertise usually involves incorporating non-developers as full-time team members. Common examples include product managers, business analysts, and subject matter experts, but can also include staff from marketing, sales, or customer support.

These sorts of structural changes require high-level permission from the organization. It can be difficult to obtain. Although you may be tempted to hire new employees to fill the gaps, it’s usually more effective to include employees who already understand your business’s unique priorities and constraints.

Developers and QA personnel, particularly those with company seniority, can be a surprisingly useful source of product expertise. As you're looking for people to bring business expertise to your team, don’t overlook the possibility of training senior technical people in needed business skills. Sales calls and customer visits are a great way to provide new perspectives.

Investment/Value Tradeoff: Giving teams decision-making power and corresponding expertise challenges existing organizational structures. It can take several years—not because of the skills required, but because managers and organizational leaders must learn to trust their teams’ use of agile ideas before making changes that affect their power, control, and familiar ways of working.

Investing in these changes requires an understanding of positive political skills and a deep conviction in the value of the payoff. Advocates will need to spend their social capital to make it happen. Managers may need coaching in supporting high-performance agile environments, where their job changes from tactical decision-making to defining team direction and orchestrating cross-organization alignment.

Optimizing fluency reduces communication overhead, eliminates bureaucratic handoffs, and enables rapid response to changing business conditions. Its investments disrupt the status quo, so they aren’t appropriate for every organization. But for those organizations that wish to drive the pace of change in their market, an investment in Optimizing fluency is worth consideration.

“Strengthening” Teams Make Their Organizations Stronger

Where Optimizing teams have the ability to understand and fulfill the needs of their market, Strengthening teams also play a larger role in their organization.

Strengthening teams contribute to their organization in three ways. First, they understand how they are part of a larger system. They understand how their purpose aligns with other teams’ to achieve a greater strategy. They actively work to make that strategy more successful.

Second, they intentionally spread expertise in the organization. They look for opportunities to contribute their skills to other teams, and they seek opportunities to learn from other teams.

Third, the organization distributes directional decisions amongst teams. Leaders design deliberate structures for distilling teams’ collective insights and channeling them into organizational improvements.

We see glimmers of Strengthening approaches in organizations around the world. Companies like Valve Software, Semco, Zappos, and AppFolio are experimenting in this space. We also see cutting-edge techniques such as team self-selection and Open Space strategy meetings gaining traction in leading agile teams. That said, this zone is speculative. We think it may be the future of agile, but we don’t know exactly what it will look like.

Although we aren’t entirely certain of the shape this zone will take, we’ve seen enough examples to draw conclusions about the benefits fluent teams could provide.

This zone is most appropriate for organizations whose leaders want to be on the cutting edge of management theory and practice. It requires working at the leading edge of organizational theory and inventing new ways of applying it to agile teams.

If this zone is for you, research complexity theories, such as Cynefin and Human Systems Dynamics, and new ideas in organization design, including alternative governance structures such as Open Space Agility, Sociocracy, and Holocracy.

Even if you don’t desire fluency in this zone, some of the techniques being developed in this space are well worth considering. Just as a fluent Delivering team will have some proficiency in Optimizing techniques, you can benefit from Strengthening techniques. Two we’ve directly experienced are team self-selection and strategic Open Space sessions. Both are well worth piloting.

For most organizations, Strengthening fluency is probably best left as an idea to watch from afar, at least until Optimizing fluency is within reach. However, for smaller organizations that already emphasize Lean principles and systems thinking, who are predisposed to distribute decision-making to teams, and who value visionary approaches and innovative processes, the Strengthening zone offers a bold challenge and an intriguing puzzle.

Applying the Agile Fluency Model

As George Box said, “All models are wrong, but some models are useful.” The Agile Fluency Model is a simplified view of the real world. Despite its simplifications, we’ve found that it accurately reflects most organizations’ needs. Even when it isn’t a perfect match, the benefits, proficiencies, and investments we’ve described are useful conversation topics.

You can apply the model in three ways: First, use it to see what kind of agile investments your organization needs to make. Insufficient investment not only leads to slow progress, it creates lasting cynicism and resentment. We’ve seen this failure case too many times. Use the model to make sure your expectations and investments are aligned.

Second, if you aren’t seeing the fluency you expect, the model can help reveal what’s wrong. Conduct a diagnostic to discover which proficiencies teams are having difficulty with, then provide training and support. (The Agile Fluency Project offers diagnostic options at agilefluency.org.) If multiple teams are having trouble with the same proficiencies, the problem is probably systemic, so look into organizational changes.

Finally, the model is a useful way to align conversations about agile approaches. Discussions about agile ideas can easily get bogged down with arguments about specific methods, tools, and practices. Instead, use the model to foster discussion of what people want to achieve and how they’re going to make it possible.

The Agile Fluency Model diagram is available for you to adapt for your presentations. You can also share this article to create conversations about team proficiencies and organizational needs. For derivative works, such as republishing the lists of proficiencies, contact us for permission.

If you need help applying the model or diagnosing fluency challenges, the Agile Fluency Project has contacts and additional resources. Visit agilefluency.org for more.

Conclusion

In our work with agile teams and organizations, we’ve seen that teams follow a typical progression in their understanding of agile approaches and the benefits their organization receives. We’ve grouped this progression into four zones of fluency. Each zone is characterized by unique benefits and distinct challenges to adoption.

• The first zone, Focusing, requires a team to learn to work together to focus on creating business value rather than merely finishing technical tasks. In return, the organization gains greater insight into the team’s work and has more opportunities to influence that work in positive directions. This zone reflects agile fundamentals.

• The second zone, Delivering, requires a team to invest in learning a wide array of software development skills. This zone reflects agile sustainability. The skills don’t come easily, but with time and adequate organizational support, the team gains the ability to create and ship low-defect software as frequently as the market will accept it, which gives the organization new opportunities for achieving return on their software development investment.

• The third zone, Optimizing, represents the promise of agile: a team that dances and turns in response to changing market conditions, and collectively takes responsibility for building the best product your investment can buy. Achieving fluency in this zone means business experts must join the team as full-time contributors, and while this change to organizational structure can be challenging, it pays off in the team’s improved ability to serve your business.

• The fourth zone, Strengthening, represents agile’s future. Strengthening teams collaborate with other teams to improve their whole organization. Reaching this zone requires innovative thinking and a willingness to experiment.

All of these zones provide benefits, and every one is the right zone for some teams. Use the model to inspire conversations about which zones your organization wishes to support. Once you’ve chosen your zones, consider the investments needed to reach fluency and commit fully to making those investments.

Teams need time to develop their proficiencies. They’ll develop in fits and starts, moving forward and backwards, and reaching plateaus. Practice as many proficiencies as you can from the beginning. The fluency zones represent natural plateaus where you’ll see distinct benefits and challenges to overcome.

Be aware that organizational context can prevent fluency. Keep an eye out for systemic issues impacting multiple teams in the same way. This is usually a sign that an organizational change needs to be made.

We’ve seen teams go through these fluency zones time and time again. By sharing our experiences with you, we hope that you’ll gain greater insights into the possibilities of agile approaches, and greater understanding of the challenges they pose. May you and your teams achieve ever greater fluency, and ever greater success.