Whole Team

Audience

Coaches

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. 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.

Ally

Purpose

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 to fulfill its purpose. Broadly speaking, these skills can be grouped into customer skills, development skills, and coaching skills.

Agile teams need skills, not roles.

Note that Agile teams need skills, not roles. Sometimes senior programmers with a lot of company history make the best product managers. Sometimes project managers have great testing skills. Not only that, Agile teams learn and grow over time. Everybody works to broaden their skills, especially customer-related skills.

Throughout this book, when I refer to a “product manager,” “developer,” or other title, I’m referring to someone on the team with those skills, not someone with that literal title or role on the team. Agile teams work best when people contribute based on their skills and experience, not their position in the org chart.

Cargo Cult: The Hole Team

“Okay, you’re Agile now,” your manager says, vanishing in a puff of golf-scented smoke.

The four of you look nervously at one another. You’re a team of frontend programmers, and you’re not quite sure what you’re supposed to be doing. You’ve heard rumors of a new initiative, and your team is going to be involved with that...somehow?

The next day, Claudine swoops in. “Hi, I’m your Scrum Master,” she says. “Sorry I wasn’t here yesterday. I’ve got four other teams, and I just learned I’d be working with you. Ramonita will be your product owner, but she can’t make it today. I’ve set up a meeting for the week after next.”

Claudine brings you up to speed about the product you’ll be working on. Your team is building the UI, and several other teams are building the backend microservices. Testing will be done by the QA department, like normal, and when you’re ready to deploy, you’ll file a ticket with Ops, who will be responsible for monitoring and up-time. “Here’s the UI mock-up the design department made,” Claudine says, “and Ramonita put stories in the issue tracker with all the requirements. I’ll check in with you every day for our stand-up meeting. Just tell me what you did and I’ll update the issue tracker.”

Claudine swoops out, her voice vanishing down the hall. “Let me know if you need anything!” You all look at one another, shrug, and open up the issue tracker. The stories aren’t entirely clear, so you shoot off a few emails. In the meantime, you start building.

Months pass. It isn’t great. You meet with Ramonita every other week and end up having to rework a lot of the stuff she asks for. The requirements in the issue tracker aren’t always clear, so you have to send an email and just make your best guess in the meantime.

Even once you think something’s done, QA constantly finds issues with things that you were sure you did right, but the stories left open for interpretation. You ask Ramonita to put in more detail, but there’s never enough. The backend systems never quite work the way you thought they would, either, and it takes forever for Ops to update the development environment with new builds.

But at last, you ship. You don’t know how well it will be received, but at this point, it doesn’t matter. You’re just ready to move on to something else. At least it’s Ops’s problem now.

Customer Skills

Ally

Real Customer Involvement

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. Depending on the type of software you’re creating, your on-site customers might be your real customers, or they might be people who represent your real customers.

To truly succeed, your software must bring value to customers, users, and your organization.

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 customer skills. They fall into several categories:

Product management (aka product ownership)

Allies

Purpose

Context

Adaptive Planning

Visual Planning

Stakeholder Demos

Stakeholder Trust

Agile teams focus on value, but how do they know what’s valuable? That’s where product management comes in. Team members with product management skills work with stakeholders to discover what the team should work on, why it’s important, and who the team needs to satisfy; they lead demos and seek out feedback; and they promote the team’s work in the organization. For most teams, this is a full-time job.

Product managers must also have the organizational authority to make difficult trade-off decisions about what goes into the product and what stays out. They need the political savvy to align diverse stakeholder interests, consolidate them into the team’s 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.

Many companies spread their product managers too thin. This can work for slow-moving teams who have predictable work, but it usually causes teams to waste time building the wrong things. [Rooney2006] 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.

Don’t make the mistake of skimping on product management.

Don’t make the mistake of skimping on product management. Remember, though: teams need people with product management skills, not people with a product management title. Senior developers can make excellent product managers, with training, particularly if they have a long history with their product and company. At Toyota, for example, the chief engineer of a vehicle has complete responsibility for everything from concept to economic outcomes.

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.

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 it had an analytical chemist with a master's degree on the team. Another was building bank-to-bank collateral management software, so it had two financial experts. A third was building life insurance software, and its domain expert was an actuary.

Even if your software doesn’t have complicated domain rules, you still need people who can figure out the details of what your software should do. On some teams, that might be a product manager, user experience designer, or business analyst.

Allies

Incremental Requirements

Customer Examples

Ubiquitous Language

In contrast to product management, which involves spending a lot of time with stakeholders, domain expertise requires spending time with the team. Most of that time is spent figuring out the details of upcoming work, creating examples of complicated rules, and answering questions about the domain.

User experience design (aka interaction 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 UX skills define the UI. 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.

The fast, iterative, feedback-oriented nature of Agile development leads to a different environment than UX designers may be used to. Rather than undertaking an up-front user research phase, UX design is performed iteratively, alongside the iterative refinement of the software itself. Agile teams produce software every week or two, which gives designers the opportunity to take real software to users, observe their usage patterns, and use that feedback to guide the team’s plans.

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 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.”

Programming, design, and architecture

Allies

Test-Driven Development

Simple Design

Incremental Design

Reflective Design

Evolutionary System Architecture

The Planning Game

No Bugs

Build for Operation

Programming skill, of course, is necessary for any team that develops software. In a Delivering team, though, everyone who codes also designs and architects, and vice versa. The team uses test-driven development to combine architecture, design, tests, and coding into a single ongoing activity.

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

Programming skills are also needed for planning, preventing defects, and making sure the software is easy to deploy and manage in production.

Testing

Allies

Incremental Requirements

Customer Examples

Blind Spot Discovery

No Bugs

On a Delivering team, people with testing skills help the team produce quality results from the beginning. They apply their critical thinking skills to help customers consider all possibilities when envisioning the product. They also act as technical investigators for the team, helping the team identify its blind spots and providing information about nonfunctional characteristics such as performance and security.

Unlike most teams, testing on a Delivering team doesn’t involve exhaustively testing for bugs. Instead, the rest of the team is expected to produce nearly bug-free code on their own. When a bug does slip through, the team changes its habits to prevent those types of bugs from occurring in the future.

Operations

Allies

Continuous Deployment

Build for Operation

Incident Analysis

Delivering teams require team members with operations skills. They help the team deploy, monitor, manage, and secure its 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.

Operations skills also involve helping the team stay on top of production realities: planning for production needs such as security, performance, scalability, monitoring, and management; creating an equitable pager duty rotation (when needed); and helping to analyze and prevent production incidents.

Coaching Skills

Teams 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 “Invest in Agility” chapter, but additional changes are always needed. And, although it’s best if organizations make the investments teams need upfront, teams often have to advocate for the investments they need after work has begun.

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 it needs.

The job of a coach is to help the team become independently fluent.

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 team members are 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.

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 so—to help the team try new things and remember forgotten practices.

Teams need coaching in up to four categories, depending on which fluency zones they’re pursuing. This might require more than one coach.

• Team development, self-organization, and facilitation (all teams)

• Focusing zone planning and teamwork practices

• Delivering zone development practices

• Optimizing zone business development practices

Allies

Retrospectives

Team Dynamics

Impediment Removal

Part of the job of the coach is to teach the team to be self-reliant. 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 team members 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 team members how to do it themselves. Make sure that’s not the case on your team.

Practitioner-coaches

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 the skills and background to show rather than tell, and that often involves helping team members with their work. Experienced practitioner-coaches can work with one or two teams simultaneously, or guide player-coaches on multiple teams.

Player-coaches

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. Homegrown coaches often fall into this category—they might have a title like “technical lead” or “senior engineer”—as do most experienced Agile developers.

Player-coaches 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. They should be dedicated to a single team.

Facilitator-coaches

One of the most common types of coaches is the facilitator-coach, often called a Scrum Master,¹ who leads from the sidelines by facilitating conversations and resolving organizational roadblocks. They typically teach Focusing zone practices and help teams become self-reliant. They’re also useful for teams that have a lot of roadblocks, because they can advocate for those investments to be made. A player-coach and facilitator-coach can be a good team-up, as they have complementary strengths and weaknesses.

¹The 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.

Experienced facilitator-coaches can work with one or two teams simultaneously. One downside of facilitator-coaches is that they don’t contribute a lot to day-to-day development, which can lead organizations to see them as underutilized and assign them to too many teams. But then they’re not present to see and respond to team challenges. Coaches in this situation often end up as glorified meeting organizers, which isn’t a good use of their talents.

Generalizing Specialists

Agile teams work best when they’re composed of generalizing specialists, 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” 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 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 teams end up 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 frontend developers and two backend developers. Sometimes, there will be more frontend work to do, and the backend developers will twiddle their thumbs. (Or they’ll work ahead, which ultimately leads to wasteful rework, as I’ll discuss in the “Key Idea: Minimize Work in Progress” sidebar.) Other times, the situation will be reversed.

Teams with generalizing specialists avoid these sorts of bottlenecks. When there’s a lot of frontend work, the frontend specialists take the lead, but the backend specialists help out. When there’s a lot of backend work, the backend 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 choosing team members, be sure they’re willing to help out with tasks outside their specialty.

Staffing the Team

The exact roles and titles on your team aren’t important, as long as it has all the skills needed. The titles on your team will have more to do with your organization’s traditions than anything else.

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.

Part-time product owners won’t be able to keep up in the long-term.

You might not be able to get someone with product management skills or domain expertise to join your team. In many companies, somebody with these skills is assigned to coordinate with the team part-time as their “product owner.” Take that as a sign that team members need to develop their own product management and domain expertise. Although that outside product owner can help you get started, they won’t be able to keep up in the long-term. The best Agile teams have deep customer skills of their own. Bas Vodde put it well:²

²Via personal communication

I consider most teams who I work with to be on a journey changing from “programmers” to “product developers.” Which means the team (whole team!) deeply understands the customer and customer domain rather than depending on someone to clarify for them and hand-off the result of that clarification. Yes, I love to have people with deep customer knowledge on my team, but mostly with the goal of helping the entire team to improve.

Even with a highly skilled team, 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.

Fully dedicated team members

Every permanent team member should be solely dedicated to the team. Fractional assignment—assigning people to multiple teams simultaneously—yields terrible results. Fractional workers don’t bond with their teams, often aren’t present 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.” [DeMarco2002] (ch. 3).

There are likely to be some skills your team has only 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.

Even if someone is part of the team only temporarily, make sure they’re fully dedicated to your team while they’re with you. It’s better to have someone fully dedicated to your team for a week, and then to another team for another week, than to have that same person assigned to both teams for two weeks.

Stable teams

Ally

Team Dynamics

It can take several months for teams to learn how to work together effectively. In some organizations, teams are created and disbanded for every new project. It’s less wasteful, though, to keep teams together. Even if the team’s purpose or product reaches the end of its life, don’t disband the team. Instead, give them a new one.

This applies to changing team composition, too. If you add a person to an existing team, they’ll assimilate into existing team culture and norms. If you add a lot of people, though, the team effectively starts over from scratch. My rule of thumb is to add or remove only one person per month.

Team Size

The guidelines in this book are appropriate for teams of 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. Conversely, if your teams are very small, consider combining them together. You’ll reduce your overhead and be less vulnerable to turnover.

Allies

Pair Programming

Mob Programming

For most teams, programming will be the bottleneck—at first—so when you think about team size, start by thinking of how much time is spent programming. 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 that don’t use pairing or mobbing should have 3–5 programmers. As they grow larger, they’ll start to have trouble coordinating.

• Teams that pair program should have 4–10 programmers. Six is the sweet spot. Teams new to Delivering practices should avoid growing past 6–7 programmers until they have more experience.

• Teams that mob program should 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 amount of programming being done. 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:

• Customer skills: One to two on-site customers for every three programmers. One-quarter to one-half of their time will be spent on product management. The rest will be spent on a mix of domain expertise, UX design, and UI design, depending on the nature of your software.

• Testing skills: One tester for every 2–4 programmers, if the team doesn’t have Delivering fluency, or one for every 4–8 programmers if they do.

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

• Coaching skills: One or two coaches, who might split their time with another team.

Again, this isn’t meant to imply strict roles. For example, you could have a team of six programmers, including a player-coach, who spend about half their time programming, one-sixth of their time on customer skills, one-sixth of their time on testing, and one-sixth of their time on operations.

Why So Many Customers?

Two customers for every three programmers seems like a lot, doesn’t it? Initially, I started with a much smaller ratio, but I often observed customers struggling to keep up with programmers. Eventually I arrived at the two-to-three ratio after trying different ratios on several successful teams.

These teams were all fluent Delivering teams that included product management on the team. Most involved complex problem domains. If your software is straightforward, you’re not pursuing Delivering fluency, or you don’t have product management inside the team, you’ll probably be able to have fewer customers.

But keep in mind that customers have a lot of work to do. They need to figure out what provides the most value, set the appropriate priorities for the work, identify all the details that developers will ask about, and fit in time for customer reviews and examples. They need to do all this while staying one step ahead of the programmers, who—especially on Delivering teams—are right behind them, crunching through work like a freight train. It’s a big job. Don’t underestimate it.

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” 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 one another 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 “Joy” was another Agile value.³ 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.

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

Ally

Team Dynamics

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

Key Idea: Self-Organizing Teams

Agile teams decide for themselves what to work on, who will do it, and how the work will be done. It’s a core Agile idea: the people who do the work are the ones most qualified to decide how it should be done. That’s why this book has so many practices about planning, collaboration, and working with stakeholders. Teams are in charge of these things, not managers. They’re expected to collectively take responsibility and work together to achieve their purpose.

That doesn’t mean teams’ managers have nothing to do. In fact, by delegating details to their teams, managers are freed up to focus on activities that have more impact. Their job is to set their teams up for success by managing the larger system that their teams are embedded within. For details, see the “Management” practice.

The Hole Team Revisited

Take a second look at the story in the “The Hole Team” sidebar. What went wrong?

• The team’s manager surprised and abandoned the team rather than setting them up for success.

• The coach, Claudine, didn’t help the team learn.

• The product manager, Ramonita, didn’t make time for the team.

• The team didn’t have anybody with customer skills.

• The team didn’t have the ability to release on its own. It had to coordinate with outside QA, ops, and backend teams.

Here’s how it should have gone.

“Okay, today’s Agile day,” your manager says. You agreed to try Agile weeks ago, so no one’s surprised. “As we discussed, we’re forming a new team to work on this product. Why don’t you all re-introduce yourselves?”

You go around the room. There are three frontend programmers (one with full stack experience), a backend programmer, a tester, and a UX designer. You’ve already met your coach, Claudine. She introduces Ramonita, your product manager.

Claudine steps in. “I know you’re all eager to see how Agile works, so I’ll get right to it. We’re going to start out with an activity called ‘chartering.’ Ramonita’s been working with our main stakeholders to understand what we’re building, why, and who it affects. We’ll be meeting with them in a few minutes. We’ll also take some time to figure out how to best work together.”

Over the next few days, you figure out how you’re going to tackle the work, then you start stringing together your core technologies. Ramonita isn’t part of the team, but Mickey, your UX designer, works closely with her to flesh out your team’s plans.

Weeks pass. Ramonita checks in frequently, and Mickey learns to stand in for her when she’s not available. With frontend, backend, testing, and ops all in the same team, you’re able to move quickly. You have your first stakeholder demo after a month and the reception is energizing. It’s a good team. You’re looking forward to what’s next.

Questions

What if there aren’t enough people to staff every team with the skills they need, or a team doesn’t need a certain skill all the time?

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

If you have several teams working on the same product, consider using vertical scaling to pool your efforts, as described in the “Scaling Vertically” section.

If those options don’t work, your company can form an “enabling team” that’s responsible for providing guidance, standards, and training to other teams, as described in the “Scaling Horizontally” section. 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.

When more expertise is needed, you can ask for somebody with those skills to be assigned to your team temporarily. They can cross-train team members at the same time. 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 I’ll discuss in the “Key Idea: Minimize Work in Progress” sidebar.

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 functional specialties. 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 developing those skills.

Prerequisites

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 “Invest in Change” chapter for more about creating buy-in.

Indicators

When you have a whole team:

• Your team is able to solve problems and fulfill its purpose 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 achieve your goals.

2. Put them on the same team.

3. Have them work in concert toward those goals.

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.

For example, 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?

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

The Wisdom of Teams: Creating the High Performance Organization [Katzenback2015] is a classic about high-performance teams.

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