AoAD2 Practice: Whole Team

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

Whole Team


We have all the skills needed to deliver great results.

Modern software development takes a lot of skills. Not just programming skills; people skills. Artistic skills. Technical skills. And when those skills aren’t part of the team, performance suffers, as the “The Hole Team” sidebar shows. Rather than focusing on a feature and completing it, team members have to juggle multiple tasks as they send emails, wait for responses, and deal with misunderstandings.

To avoid these sorts of delays and errors, Agile teams are cross-functional whole teams. They’re composed of people with diverse skills and experience who collectively have all the skills the team needs. Broadly speaking, these skills can be grouped into customer skills, development skills, and coaching skills.

Customer Skills

People with the ability to represent customer, user, and business interests are called the team’s on-site customers, or just “customers.” They’re responsible for figuring out what to build.

One of the most difficult aspects of creating an Agile team is finding people with customer skills. Don’t neglect these skills; they’re essential to increasing the value of the product you deliver. A great team can produce technically excellent software without on-site customers, but to truly succeed, your software must also bring value to real customers, users, and your organization. This requires the participation of people with customer skills.

Customer skills fall in to several categories, as follows:

Product management (aka product ownership)

Product management involves managing all aspects of a product’s lifecycle, from the initial business case all the way to product launch and beyond. Most of these skills are out of the scope of this book.1

1If you’d like to know more, the Pragmatic Marketing courses, available at, come highly recommended.

Iteration Demo
Real Customer Involvement

On an Agile team, product managers work with stakeholders to discover what the team should work on and why it’s important, also called the team’s purpose; they discover who the team works with and what resources are available, also called the team’s context; they lead demos and seek out feedback; and they promote the team’s work in the organization.

I’ve used the term “product manager” as shorthand for “people with product management skills,” but that doesn’t mean everybody with those skills has “product manager” as their job title. It’s important to have people with the skills to perform the product management tasks I’m describing here, but it isn’t necessary to have someone with the title. The same goes for all the other skills.

Minimum Marketable Features
Visual Planning
Adaptive Planning

Product managers also lead the team’s release planning activities. They choose features; decide how to group features into releases; collaborate with the rest of the team to create an achievable plan; condense the team’s plan into a roadmap that can be shared with stakeholders; and help the team adapt their plans in response to feedback and changing business conditions.


Product management requires a deep understanding of the team’s markets, whether the market is one organization (as with custom software) or many (as with commercial software). Product managers need an intuitive understanding of what the team’s software will provide and why it’s the most important thing the team can do with their time. For Optimizing teams, this includes conducting experiments to test assumptions and discover new ways of serving customers.


In addition to product vision, product managers must have the organizational authority to make difficult trade-off decisions about what goes into the product and what stays out. They must have the political savvy to align diverse stakeholder interests, consolidate them into the product vision and purpose, and effectively say “no” to wishes that can’t be accommodated.

People with this caliber of skills and influence have a lot of demands on their time. You may have trouble getting their attention. Persevere. Product management is one of the most important skills on the team. If the software isn’t valuable enough to warrant the time of someone with good product management skills—someone who could mean the difference between success and failure—maybe it isn’t worth developing in the first place.

Optimizing teams require someone with product management skills to be dedicated to the team full-time. That’s best for Focusing and Delivering teams, too, but it’s common for teams in these zones to work with someone outside the team instead. That can work so long as the team is moving slowly, the work is predictable, and there are other people with solid customer skills on the team.

Whoever is handling product management responsibilities for your team, make sure they participate in every planning meeting and are able to respond to questions quickly. If they don’t, your team is likely to start drifting off-course. [Rooney 2006] experienced that problem, with regrettable results:

We weren’t sure what our priorities were. We weren’t exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer [product manager] in terms of what we should be working on. This went on for a few months.

Then, we found out that the Gold Owner [executive sponsor] was pissed—really pissed. We hadn’t been working on what this person thought we should.

Make sure your team has access to someone with solid product management skills.

Domain expertise (aka subject matter expertise)

Most software operates in a particular industry, such as finance, that has its own specialized rules for doing business. To succeed in that industry, the team’s software must implement those rules faithfully and exactly. Those rules are called domain rules, and knowledge of those rules is domain knowledge.

Most developers have gaps in their domain knowledge, even if they’ve worked in an industry for years. In many cases, the industry itself doesn’t clearly define its rules. The basics may be clear, but there are nitpicky details where domain rules are implicit or even contradictory. I once worked with two financial experts who were in total agreement that our software needed to support a specific thing, but when we asked them to define that thing, it turned out that they had exact opposite definitions.

The team needs people with domain expertise who are responsible for figuring out those details, resolving contradictions, and having the answers at their fingertips. These are people with deep experience. One Agile team I worked with was building software for chemical analysis, so they had an analytical chemist with a Masters’ degree on the team. (Their product manager was a Ph.D. chemist.) Another was building bank-to-bank collateral management software, so they had the two financial experts I mentioned earlier. A third was building life insurance software, and their domain expert was an actuary.

If your software doesn’t have complicated domain rules, you still need at least one person who’s responsible for figuring out the details of what your software should do. On some teams, that might be a product manager or user experience designer.

Lightweight Requirements
Customer Examples

In contrast to product managers, who spend most of their time with stakeholders, domain experts spend most of their time with the team. Most of their time is spent figuring out the details of upcoming work, creating examples of complicated rules, and answering questions when programmers ask.

User experience design (aka interaction design) and graphic design

Your software’s user interface is the face of your product. For many users, the UI is the product. They judge the product solely on their perception of the UI.

People with user experience (UX) and graphic design skills define the user interface. These skills focus on understanding users, their needs, and how they interact with the product. Tasks involve interviewing users, creating user personas, reviewing prototypes with users, observing usage of actual software, and consolidating this information into specific layouts and imagery.

Don’t confuse graphic design with UX design. Graphic design conveys ideas and moods via images and layout. User experience design focuses on the types of people using the product, their needs, and how the product can most seamlessly meet those needs.

UX designers divide their time between working with the team and working with users. They contribute to release planning by advising the team on user needs and priorities. They create mock-ups of UI elements for upcoming work. As work is completed, they review the look and feel of the finished UI and confirm that it works as expected.

Visual Planning

The fast, iterative, feedback-oriented nature of Agile development leads to a different environment than UX designers may be used to. Rather than spending time researching users and defining behaviors before development begins, the UX designers refine their models iteratively, alongside the iterative refinement of the software itself.

Although UX design is different with Agile than other approaches, it isn’t diminished. Agile teams produce software every week or two, which provides a rich grist for the UX designer’s mill. Designers have the opportunity to take real software to users, observe their usage patterns, and use that feedback to effect changes in a matter of days or weeks.

Project management

People with project management skills are adept at navigating the politics of an organization, understanding how to work with stakeholders, and managing expectations. They also tend to be good at helping the team organize their work so nothing slips through the cracks, but their main role on an Agile team is to help the team work with the rest of the organization.

You may not have anybody with a “project manager” title on an Agile team, but you still need people who understand how to work with stakeholders. This might be a product manager or senior developer. Similarly, if you do have someone with a “project manager” title, they’ll probably contribute other skills as well, such as product management, domain expertise, or coaching.

Development Skills

A great purpose requires solid execution. If customer skills are about figuring out what to do, development skills are about figuring out how to do it. People with development skills, such as programming, testing, or operations, are responsible for finding the most effective way of delivering the team’s software.

Some people call development skills “technical skills,” but that seems dismissive to me. It’s not as if analytical chemists and actuaries aren’t technical, after all. So, for lack of a better term, I’ll describe people who help build, test, and release the team’s software as having “development skills.”

It’s best if your team has people with all the development skills described below, but programming skills are the minimum... at first. Once they start pursuing Delivering fluency, they’ll need all of them. Until then, development on an Agile team looks similar to development on any other team.

Pair Programming
Mob Programming
Test Driven Development
Evolutionary Design

On a Delivering team, programmers spend most of their time pair programming or mobbing, which are ways of working together on code. They use test-driven development to write tests, implement code, refactor, and incrementally design and architect the software. They pay careful attention to design quality, and they’re keenly aware of its impact on development time and future maintenance costs.

No Bugs
Zero Friction
Continuous Deployment
Continuous Integration
Build for Production

Programmers also ensure that the team’s on-site customers can release their software whenever they choose. They produce software with very few bugs. They use version control and practice continuous integration, keeping all but the last few hours’ work ready to release. They maintain an automated build that can deploy the software at any time. Their coordinate with the rest of the team to create software that’s easy to monitor and manage in production.

Collective Code Ownership

This work is a joint effort of all programmers on the team. Programmers have the right and responsibility to fix any coding or design problem they see, no matter which part of the team’s software it touches. They establish working agreements that allow them to collectively share responsibility for the code. They work as generalizing specialists: although each programmer has their own areas of expertise, such as front-end or back-end development, they’re expected to be able to contribute to any part of the team’s software that needs attention.

Lightweight Requirements
Ubiquitous Language
Customer Examples

Programmers rely on team members with customer skills for decisions about what to build. Rather than guessing when they have a question, they ask one of the on-site customers. They design their code to use a ubiquitous language, so they can communicate clearly with customers, and they base their tests on customers’ examples.


Finally, programmers help ensure the long-term maintainability of their product by providing documentation when needed.

Design and architecture
Test Driven Development
Mob Programming
Pair Programming
Collective Code Ownership

Everyone on a Delivering team who codes, also designs and architects, and vice-versa. They use test-driven development to combine architecture, design, tests, and coding into a single, ongoing activity. Mobbing, pairing, and collective code ownership help ensure that the best designs emerge.

Evolutionary Design
Evolutionary Architecture
Simple Design
Reflective Design
Continous Design

People with expertise in design and architecture are still necessary. They contribute by leading the team’s incremental design and architecture efforts and by helping team members see ways of simplifying complex designs. They act as respected peers, guiding rather than dictating.

Lightweight Requirements
Customer Examples

People with testing skills help Delivering teams produce quality results from the beginning. They apply their critical thinking skills to help customers consider all possibilities when envisioning the product. They help identify holes in requirements and gaps in customers’ examples.

Exploratory Testing

Testers also act as technical investigators for the team. They use exploratory testing to help the team identify blind spots. They provide information about the software’s nonfunctional characteristics, such as performance, scalability, and stability, by using both exploratory testing and sophisticated automated tests.

No Bugs
Root Cause Analysis

Unlike most teams, Delivering teams’ testers don’t exhaustively test for bugs. Instead, the rest of the team is expected to produce nearly bug-free code on their own. When testers find bugs, they help the team figure out what went wrong so the team as a whole can prevent those types of bugs from occurring in the future.

Continuous Deployment

Team members with operations skills help the team deploy, monitor, and manage their software in production. In smaller organizations, they might be responsible for provisioning and managing hardware. In larger organizations, they’ll coordinate with a central operations group.

Build for Production
Root Cause Analysis
No Bugs

Operations team members also work with the rest of the team to make sure nonfunctional requirements such as performance and scalability are considered, and they help define requirements for monitoring and managing the team’s software in production. They coordinate with programmers to share pager duty and help analyze and prevent production incidents.

Coaching Skills

Teams that are new to Agile have a lot to learn: they need to learn how to apply Agile practices, and they also need to learn how to work together as effective self-organizing teams.

Their organizations have a lot to learn, too, about how to support their teams. Most of that support comes in the form of the investments described in the “Investing in Agility” chapter, but additional changes are always needed. And, although it’s best if organizations make the investments teams need up-front, teams often have to advocate for the investments they need after work has begun.

Team Dynamics
Circles and Soup

People with coaching skills help teams learn how to be effective Agile teams. They teach practices, facilitate discussions, guide self-organization and team development, and show the team how to work with managers and other business stakeholders to get the investments they need.

Teams new to Agile will typically have one person, sometimes two, who is explicitly identified as the team’s coach. The job of these coaches is to help the team become independently fluent, so they’re able to perform the skills they need without the participation of a coach. That doesn’t mean the coach leaves the team, but it means that they could, and if they stick around, they gradually transform into a regular member of the team.

Coaching ability typically falls into three categories:

  • coaching team development, self-organization, and Focusing zone practices

  • coaching Delivering zone technical practices

  • coaching Optimizing zone business development practices

It’s rare to find one person who can coach teams in all three categories, although experienced Delivering and Optimizing zone coaches can often handle the first category as well. Teams need coaching in all the skills they’re developing, so your team might need more than one coach if they’re developing fluency in multiple zones simultaneously.

My preferred type of Agile coach is the practitioner-coach: someone with genuine expertise in applying Agile practices who can lead by example. Their focus is still on helping the team and organization learn, not on delivering, but they have skills and background to show rather than tell, and that often involves helping team members with their work.

A variant of the practioner-coach is the player-coach, who has experience with Agile practices, and some coaching skills, but is focused more on delivery than on helping the team learn. Home-grown coaches often fall into this category—they might have a title like “technical lead” or “senior engineer”—as do most experienced Agile developers. They can be very effective at helping teams apply Agile practices, even to the point of fluency, but they tend to be less successful at helping teams become independently fluent. They can also have a hard time understanding how and when to influence organizational change.

One of the most common types of coaches is the facilitator-coach, often called a Scrum Master2, who leads from the sidelines by facilitating conversations and resolving organizational roadblocks. Although this style of coaching isn’t very effective at teaching Delivering and Optimizing practices, facilitator-coaches can still be effective in teaching Focusing zone practices and helping teams self-organize. They’re also useful for teams that have a lot of roadblocks—usually because their organization skimped on important investments—because they can advocate for those investments to be made. (See the “Investing in Agility” chapter for more about the investments teams need.) Player-coaches and facilitator-coaches can be a good combination, as they have complementary strengths and weaknesses.

2The name “Scrum Master” originated in the popular Scrum method. The name is misleading; it’s supposed to mean someone who has reached mastery in their understanding of Scrum, not someone who has authority or control over the team.

One downside of facilitator-coaches is that they don’t contribute a lot to day-to-day development. This can lead organizations to see them as underutilized, and assign them to several teams at once. This reduces the effectiveness of their coaching, as they’re not present to see and respond to team challenges. (Two teams can be okay. More than that is a stretch.) Coaches in this situation often end up as glorified meeting organizers, which isn’t a good use of their talents, and not good for their teams, either.

Team Dynamics
Circles and Soup

Speaking of facilitation, part of the job of the coach is to teach coaching skills to the rest of the team. Team members need to be able to facilitate their own discussions, improve their own team dynamics and practices, figure out which investments will make them more effective, and work with stakeholders to get those investments. As with all team skills, you don’t need everybody on the team to be able to do so, but the more that can, the more resilient the team will be.

Some coaches fall into the trap of doing these things for the team rather than teaching the team how to do it themselves. Make sure that’s not the case on your team.

Even after a team becomes independently fluent, it’s helpful for an experienced coach to join the team once in a while—say, every year or two—to help the team try new things and remember forgotten practices.

Staffing the Team

The exact roles and titles on your team aren’t important, so long as you have the skills you need. The titles on your team have more to do with your organization’s traditions than anything else.

In other words, if project managers and testers are typical for your organization, you’ll include them on your team to cover the “project management” and “testing” skills. If not, you don’t necessarily need to hire people with those titles. But you do need someone with those skills. Someone still has to be able to coordinate with stakeholders, and someone still needs to help the team identify its blind spots.

For new Agile teams, it’s helpful to explicitly identify the product manager and coach. For experienced Agile teams, assigned roles can get in the way, but people new to Agile appreciate knowing who to turn to when they have questions.

Some decisions will be made by people outside your team. For example, if your team is contributing to a larger product, decisions about system architecture may be out of your hands. That’s fine if those decisions are just part of the background. But if you’re constantly waiting for people outside the team to make a decision or do something for you, you don’t have a whole team. Those skills and responsibilities should be moved into the team, or that aspect of the product should be moved out of the team. (See the “Scaling Agility” chapter for more discussion of cross-team coordination.)

There are likely to be some skills that your team only has occasional need for. You can ask people with those skills to join your team temporarily. For example, if your team is building a complex server-side product with a very small user interface, you might ask a user experience designer to join your team only during the few weeks that you’re actually working on the UI.

Full-time team members

Every team member should be solely dedicated to the team. They should be able to give the team their complete attention. Assigning people to multiple teams simultaneously (fractional assignment) yields terrible results. Fractional workers don’t bond with their teams, often aren’t in the team room to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty. “[T]he minimum penalty is 15 percent... Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing.” [DeMarco 2002] (p. 19-20).

Team Room

The same goes for temporary team members. Agile relies on a lot of informal communication, so anybody who’s not in the team room—whether physical or virtual—will have trouble participating. If you have a temporary team member, make sure they’re fully dedicated to your team during the time that they’re with you. It’s better to have someone fully dedicated to your team for a week, and then another team for another week, than to have that same person assigned to both teams for two weeks. They’ll be much less than 50% as productive in the latter scenario.

Generalizing specialists

Agile teams work best when they’re composed of generalizing specialists. They’re also called “T-shaped people.” A generalizing specialist has deep expertise in several areas—that’s the vertical bar of the T—but also the ability to contribute broadly to other skills the team needs. That’s the horizontal bar. (Some people use the term “M-shaped people” or “paint drip people” to emphasize that generalizing specialists can develop multiple areas of expertise.)

Agile teams need generalizing specialists to prevent bottlenecks. Non-Agile organizations undertake complex “resource shaping” exercises to ensure that each team is staffed with the right specialists at the right time. Those exercises never quite work out, because software development work can’t be predicted as precisely as resource shaping requires. So they end up with teams waiting for people who were delayed, or rushing to find work for people who are ready before the team is. You tend to see a lot of fractional assignment as managers scramble to make everything line up. It leads to a lot of waste.

In an Agile organization, teams are the resource, not individual people, so resource shaping is much simpler. It’s all or nothing. Either the team is working a feature, or it’s not. Either a person is dedicated to a team, or they’re not.

But you can still end up with bottlenecks inside a team. Imagine a team with two front-end developers and two back-end developers. Sometimes, there will be more front-end work to do, and the back-end developers will twiddle their thumbs. (Or they’ll work ahead, which ultimately leads to wasteful rework, for reasons we’ll explore in the “Planning” chapter.) Other times, the situation will be reversed.

A team that has generalizing specialists avoids these sorts of bottlenecks. When there’s a lot of front-end work, the front-end specialists take the lead, but the back-end specialists are able to help out. When there’s a lot of back-end work, the back-end specialists take the lead. And it’s not just programming. Whatever bottlenecks the team may be facing, team members should be willing and able to jump in and help.

You don’t need team members to be generalizing specialists when you first form your team. It’s more a matter of attitude than ability. Any specialist can choose to learn to contribute to areas adjacent to their specialty. When your team agrees to try Agile (see the “How to Be Agile” chapter), be sure they’re willing to help out with tasks outside their specialty.

Team size

The guidelines in this book are appropriate for teams with 3-20 people. For new teams, 4-8 people is a good starting point. Once you get past 12 people, you’ll start seeing breakdowns in communication, so be cautious about creating large teams.

Even larger teams are possible, as described in the “Scaling Agility” chapter, but they’re out of the scope of this book.

Teams smaller than three people can use the practices in this book, but some of them will be overkill. If you’re in an organization with a lot of very small teams, consider combining them into larger teams. You’ll reduce your overhead, and you’ll be less vulnerable to any one person leaving.

For most teams, programming will be the bottleneck—at first—so when you think about team size, start by thinking of how many programmers you need. For convenience, I’ll call a person fully dedicated to programming “one programmer,” but that doesn’t mean that your team has to have strictly defined roles.

Teams without Delivering fluency typically have 3-5 programmers. As the team grows past that size, they’ll start to have trouble coordinating. Either there will be too many simultaneous streams of work for people to keep track of, or bottlenecks will form as different specialities end up with differing amounts of work to do.

Collective Code Ownership
Pair Programming

Teams that use pair programming can have 4-10 programmers, assuming they also use collective code ownership. Six is the sweet spot. (For teams new to Delivering practices, avoid growing past 6-7 programmers until you have more experience.) Pairing can support more programmers because it cuts the number of simultaneous streams of work in half, making it easier for programmers to keep track of each others’ work, and collective code ownership ensures that they work together, without specialties forming bottlenecks.

Mob Programming

Teams that use mob programming tend to have 3-5 programmers. You can mob with much larger groups—it’s a great teaching technique—but you reach a point of diminishing returns.

You’ll typically staff the rest of your team proportionally to the number of full-time programmers. You want the ratio to be about equivalent to the amount of work to do, so bottlenecks don’t form, with generalizing specialists giving you some slack to handle variations in workload. In general, plan for:

  • One to two customers for every three programmers. At least one of the customers should have product management skills, unless the team is working with an outside product manager.

  • One tester for every 2-4 programmers, if the team doesn’t have Delivering fluency.

  • One tester for every 4-8 programmers, if the team does have Delivering fluency.

  • Zero to two operations people, depending on the nature of the production environment.

  • One or two coaches, depending on the skills your coaches have and fluency zones your team is pursuing.

Again, this isn’t meant to imply strict roles. As an extreme example, for the first bullet point, you could have a team of five programmers, all of whom have customer skills, and who spend about two-fifths of their time on customer-type tasks.

A Team of Peers

Nobody on the team is in charge of anyone else. That doesn’t mean every decision is up for discussion; people have final say over their areas of expertise. For example, programmers can’t override customers’ opinions about product priorities, and customers can’t override programmers’ opinions about technical necessity. Similarly, you’ll still have senior team members who take the lead on important decisions. But there is no reporting structure within the team. Even people with fancy titles like “product manager” or “project manager” aren’t managing the team.

This is an important part of being a self-organizing team. A self-organizing team decides for itself who’s going to take the lead on any given task. It’s not a hard decision; for teams that know each other well, deciding who will take the lead is usually automatic. It’ll be the person who knows most about the task, or who has expressed the most interest in learning more, or is next in rotation, or anything, really.

Something that’s hard to convey about high-performance Agile teams is how much fun they have. Brian Marick, one of the Agile Manifesto authors, used to say that “Joy” was another Agile value.3 He’s right. Great Agile teams have a feel to them. They’re optimistic, enthusiastic, and genuinely enjoy working together. There’s a spirit of excellence, but it’s not overly serious. For example, when there’s a task no one wants to do, the conversation about who will do it is playful and fun. And it’s quick. Effective Agile teams make decisions easily.

3Marick identified four values that he saw on early Agile teams: Skill, Ease, [Self] Discipline, and Joy.

Team Dynamics

It takes time—and work—to become this effective. The “Team Dynamics” practice shows how.

One thing a self-organizing team is not: It’s not self-managing. Yes, many of the decisions that are made by managers in a non-Agile team are made by team members in an Agile team. But the manager still has an important role to play: they set the team up for success. See the “Change Team Management Style” section for details.


What if there aren’t enough people to staff every team with the skills they need?

First, check if your company is over-hiring programmers relative to other skills their software teams need. It’s a common mistake. If so, see if you can change your hiring priorities.

If you can’t hire the people you need, one option is for your company to form a central support team that’s responsible for providing guidance, standards, and training to other teams. ([Skelton and Paid 2019] calls this an “Enabling Team.”) The central team trains team members how to apply the guidance and standards on their teams. For example, a central UX team could establish a style guide and train people how to use it for their team’s software. That gives teams the ability to solve their own problems without requiring full-blown expertise.

If you have central support teams, make sure their role is to enable other teams to work autonomously, rather than doing the work themselves. Otherwise, they’ll end up as a bottleneck.

When more expertise is needed, you can ask for somebody with those skills to be assigned to your team temporarily. Delay any work that needs those skills until they’re available. That way you don’t end up with half-done work, which leads to waste, as we’ll see in the “Planning” chapter.

What if we don’t need a certain skill all the time?

Let’s say you have a need for a skill, such as UX design, but only about ten hours’ worth per week. The most resilient way to deal with this situation is for people to cross-train, so that team members can contribute UX design as well as other skills. If that’s not an option, you can schedule someone to join your team periodically, such as one week every month. As before, delay work that needs their skills until they’re available.

Are junior members of the team equal to everyone else?

Team members aren’t necessarily equal—everyone has different skills and experience—but they are peers. It’s smart for junior team members to seek out more experienced team members for advice and mentoring. It’s also smart for senior team members to treat everyone with respect, to create collegial relationships, and to help junior members grow by stepping back so they can take the lead.

How do team members develop specialized skills without being on a team dedicated to that skill?

Many Agile organizations form “communities of practice” around specific specialties, such as UX design, front-end programming, operations, and so forth. These may be led by a manager, a centralized support team, or just interested volunteers. They’ll typically hold a variety of events to provide training, socializing, and other opportunities for learning from each other.


Creating a whole team requires buy-in and support from management, and agreement from team members to work together as an Agile team. See the “How to Be Agile” chapter for more about creating buy-in.


When you have a whole team:

  • Your team is able to solve problems and do their work without waiting for people outside the team.

  • People on the team work outside their specialty to prevent bottlenecks from slowing the team down.

  • Your team is able to make decisions smoothly and effectively.

  • People on the team seamlessly switch leadership roles from task to task.

Alternatives and Experiments

The theory behind this practice is pretty straightforward. To avoid delays and communication problems:

  1. Find everybody needed to ship your software.

  2. Put them on the same team.

  3. Have them work in concert towards the same goal.

This is a core Agile idea, and there aren’t really any alternatives that stay true to the Agile philosophy. But there are a lot of opportunities to customize the details. Once you’ve had a few months of experience applying this practice as written, try some experiments.

One experiment is to try different ways of dealing with roles. Does your team work better when people have sharply defined roles and responsibilities? In other words, when one person owns product management, another owns domain expertise, and someone else owns operations? Or is it better when you loosely share skills and responsibilities, with people contributing to multiple roles? How loose is too loose?

What about self-organization? How can your team experiment with changing how decisions are made? Does it work better to have someone explicitly facilitate discussions? Or to just let discussions happen naturally? Should some decisions be assigned to specific people? Or should leadership responsibility be more fluid?

One of the bigger Agile challenges is figuring out how to create whole teams in a large organization. It’s not always clear how teams that are working on the same set of products should divide their responsibilities. These are the sorts of decisions you need to make in order to have a successful large-scale Agile system, as we discuss in the “Scaling Agility” chapter. Mastering the Whole Team practice is the first step to understanding how to scale Agile well.

To better understand these scaling issues, experiment with how teams relate to each other. When two teams depend on the same thing, which team should have responsibility for it, and how should they coordinate? Similarly, what’s the correct amount of consistency to have across teams, and how can you achieve that consistency? What do “customer skills” entail when a team is building something solely for another team to use?

There are no cut-and-dry answers to these questions. Make a guess. Try it, see how it works, and make a different guess. Try that, too. Never stop experimenting. That’s how you master the art.

Further Reading

Agile Conversations [Squirrel and Fredrick 2013] is an excellent resource for coaches who are helping their teams and organizations develop an Agile culture.

Team Topologies [Skelton and Paid 2019] is an in-depth look at the different ways teams can be organized, with an emphasis on creating whole teams in large-scale Agile systems.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, 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.