AoAD2 Chapter: Autonomy

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.


Optimizing fluency is fairly rare, but it’s not because the Optimizing zone represents a big change in Agile practices. On the contrary: Optimizing is mostly an application of the practices found throughout the rest of this book. Optimizing fluency isn’t rare because it’s hard; it’s rare because it requires a level of team autonomy most organizations aren’t ready to support.

Optimizing requires a level of team autonomy most organizations aren’t ready to support.

Everybody knows Agile teams are supposed to be autonomous, but organizations with Optimizing teams really mean it. For them, autonomy is more than just enabling teams to work independently. They give their teams full responsibility for their finances and product plans, too.

Business Expertise

Whole Team

Of course, for your team to own its financial and product decisions, the team needs to have the ability to make good decisions. A whole team consisting of both business and development expertise has always been the goal, but many organizations short-change the business side of their teams. They assign a product manager who can participate only a few hours a week, or assign product “owners” who have no real decision-making authority. Some teams get the worst of both worlds: product owners who are spread too thin and have no decision-making authority.

Optimizing teams have real business authority and expertise. It’s not siloed behind a single person, either. Everybody on the team takes an interest in producing value. Some more than others, of course, but there’s no jealous hoarding of responsibility. You’ll get the best results when your entire team sees its job as learning how to better serve customers, users, and stakeholders.

Business Decisions

One of the most striking things about Optimizing teams is their lack of emphasis on user stories. They have stories, of course, as a planning mechanism, but they’re not the topic of their conversations with stakeholders. Instead, they’re all about business results and value. They’re not trying to deliver a set of stories; that’s a detail. They’re trying to make a meaningful difference to their organization.

Stakeholder Trust

This is particularly true of their relationship with management. Optimizing teams have the trust of their organization. Executives and managers know they can give the team funding and a mission, then stand back. The team will work out how to achieve the mission on its own. The team will let its executives know how the funding is being spent, what results it's achieving, and what support it needs to be more successful.

Adaptive Planning

One of the consequences of this approach is that Optimizing teams rarely follow a predetermined plan. In general, their valuable increments are small, their plans highly adaptive, and their planning horizons are short. Rather than working a big, static plan, they’re constantly testing ideas and making incremental progress. (At least from the perspective of internal stakeholders. They can still choose to save up work for a big splashy release.)


As a result, Optimizing teams tend not to have traditional deadlines or roadmaps. When they do set a deadline, it’s a choice they make for themselves. They do so because there’s a compelling business reason, such as coordinating with a marketing effort, not because it satisfies a bureaucratic requirement. If they realize they won’t be able to achieve a deadline, they decide for themselves how and when to change their plans.

Accountability and Oversight

Optimizing teams aren’t without oversight. They may have control over their budget and plans, but that doesn’t mean they get to do whatever they want. They still have to show their work and justify their big-picture decisions. They just don’t have to get advance approval for their decisions, so as long as they relate to the team’s purpose and don’t require additional resources from the organization.


The organization uses the team’s purpose to put guide rails around the team’s work. The team’s purpose sets out the big-picture direction for the team (the vision), their current near-term goal (the mission), and the signposts that lead to success (the indicators). Management provides the general direction, and the team collaborates with them and other stakeholders to work out the details. When the team sees an opportunity to change its purpose to be more valuable, team members talk it over with management.

The team demonstrates its accountability, not by showing the stories it’s delivered, but by focusing on business results: both what it's achieved so far and what it hopes to achieve in the future. These results may be straightforward, such as revenue numbers, or more subtle, such as employee satisfaction scores. Either way, the emphasis is on outcomes, not deliverables and dates.

Stakeholder Demos

Optimizing teams aren’t just trying to achieve short-term outcomes, though. They’re also constantly learning how to better serve their users and their market. So they also talk about what they’ve learned, what they want to learn next, and how they plan to do so. All this information is shared through the team’s internal demos, their internal roadmaps, and private conversations with management.


The team’s funding is another of the organization’s oversight mechanisms. Optimizing teams are typically funded on an ongoing “business as usual” basis (see the “Agile Governance” section). The organization allocates those funds based on the outcomes it expects from the team. The team can also procure one-off funds and resources by going to management with its justification.


If team members don't think they can achieve their purpose with the funds and other resources they have, they can ask their sponsor for more. If the sponsor doesn’t agree, the team and their sponsor collaborate to find a balance that can be achieved, or the team pivots to a new, more valuable purpose. This discussion typically happens during context chartering.

As the team’s work progresses, the organization’s predictions about value will come true...or not. This is an opportunity to adjust the team’s purpose. If the team is producing more value than expected, the funding can be increased, and the team can double down on its successes. If it’s producing less, the funding can be decreased, or the team can pivot to a more valuable purpose.

Experiments and Further Reading

As I’ve mentioned, autonomy and ownership can be a difficult shift for organizations and managers. The Agile Culture: Leading through Trust and Ownership [Pixton2014] can help managers learn how to make this shift. Another option is Turn the Ship Around! A True Story of Turning Followers Into Leaders. [Marquet2013] It’s also a great read.

In terms of experiments, one of the most interesting is “Beyond Budgeting.” It has an emphasis on disseminating decision making to customer-focused teams, similar to what I’ve described here, but it goes into much more depth on the management side of things. To learn more, see Jeremy Hope and Robin Fraser’s book, Beyond Budgeting. [Hope2003]

The Agile community is full of other interesting ideas and experiments for improving autonomy. Many of these experiments push into the Strengthening zone of fluency. I touch upon them in the “Into the Future” chapter.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. For videos and interviews regarding the book, see the book club archive.

For more excerpts from the book, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.