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

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

Allies
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 their 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 based on their position in the org chart.

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.

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 the participation of people with customer skills.

Customer skills fall into several categories:

Product management (aka product ownership)

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. The “Product Management Practices” table lists the practices.

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.

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

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.

Table 1. Product management practices

Practice
The “Purpose” practice
The “Context” practice
The “Adaptive Planning” practice
The “Visual Planning” practice
The “The Planning Game” practice
The “Stories” practice
The “Incremental Requirements” practice
The “Real Customer Involvement” practice
The “Done Done” practice
The “Forecasting” practice
The “Trust” practice
The “Roadmaps” practice
The “Stakeholder Demos” practice
The “Reporting” practice
The “Autonomy” practice
The “Discovery” practice
The “Experimentation” practice
XXX revise all these tables when the book is complete: double-check names, compare to 'Audience' blocks, check ordering
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.

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.

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. The “Domain Expertise Practices” table lists the practices.

Table 2. Domain expertise practices

Practice
The “Incremental Requirements” practice
The “Customer Examples” practice
The “Customer Review” practice
The “No Bugs” practice
The “Ubiquitous Language” practice
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.

The fast, iterative, feedback-oriented nature of Agile development leads to a different environment than UX designers may be used to. Rather 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 effect changes in a matter of days or weeks.

The results of that user feedback is used to guide the team’s plans and implementation. The “User Experience Design Practices” table has the practices.

Table 3. User experience design practices

Practice
The “Visual Planning” practice
The “The Planning Game” practice
The “Stories” practice
The “Incremental Requirements” practice
The “Real Customer Involvement” practice
The “Stakeholder Demos” practice
The “Customer Review” practice
The “No Bugs” practice
The “Discovery” practice
The “Experimentation” practice
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. The “Project Management Practices” table lists the practices.

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.

Table 4. Project management practices

Practice
The “Purpose” practice
The “Context” practice
The “Real Customer Involvement” practice
The “Done Done” practice
The “Trust” practice
The “Roadmaps” practice
The “Stakeholder Demos” practice
The “Reporting” practice
The “Circles and Soup” practice

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

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.

Programming, design, and architecture

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. They use 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. The “Programming Practices” table has the practices.

Table 5. Programming practices

Practice
The “The Planning Game” practice
The “Stories” practice
The “Task Planning” practice
The “Capacity” practice
The “Done Done” practice
The “Collective Code Ownership” practice
The “Pair Programming” practice
The “Mob Programming” practice
The “Zero Friction” practice
The “Test-Driven Development” practice
The “Refactoring” practice
The “Spike Solutions” practice
The “Performance Optimization” practice
The “Simple Design” practice
The “Reflective Design” practice
The “Continuous Design” practice
The “Evolutionary Design” practice
The “Evolutionary Architecture” practice
The “Build for Production” practice
The “Trunk-Based Development” practice
The “Feature Toggles” practice
The “Continuous Integration” practice
The “Continuous Deployment” practice
The “Ubiquitous Language” practice
The “No Bugs” practice
Testing

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 their blind spots and providing information about non-functional characteristics such as performance and security. The “Testing Practices” table has the practices.

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 their habits to prevent those types of bugs from occurring in the future.

Table 6. Testing practices

Practice
The “The Planning Game” practice
The “Stories” practice
The “Incremental Requirements” practice
The “Customer Examples” practice
The “Exploratory Testing” practice
The “Root Cause Analysis” practice
The “No Bugs” practice
Operations
Allies
Continuous Deployment

Team members with operations skills help the team deploy, monitor, manage, and secure 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.

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. The “Operations Practices” table lists the practices.

Table 7. Operations practices

Practice
The “The Planning Game” practice
The “Stories” practice
The “Build for Production” practice
The “Continuous Deployment” practice
The “Root-Cause Analysis” practice
The “No Bugs” practice

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

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.

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 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 Master,1 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 “Invest 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.

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

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. The “Coaching Practices” table lists the practices related to these skills.

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.

Table 8. Coaching practices

Practice
The “Whole Team” practice
The “Team Room” practice
The “Purpose” practice
The “Context” practice
The “Alignment” practice
The “Real Customer Involvement” practice
The “Stand-Up Meetings” practice
The “Done Done” practice
The “Informative Workspace” practice
The “Trust” practice
The “Retrospectives” practice
The “Team Dynamics” practice
The “Circles and Soup” practice
The “Slack” practice

Staffing the Team

The exact roles and titles on your team aren’t important, so long as it has all the skills needed. 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.

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:2

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

Bas Vodde

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

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.

Fully dedicated team members

Every team member should be solely dedicated to the team. Assigning people to multiple teams simultaneously (fractional assignment) 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.” [DeMarco 2002] (p. 19-20).

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

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 accomplishes their purpose, don’t create a new team for the next one. Instead, keep the team together and give them a new purpose.

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 only add or remove one person per month.

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” 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, as you’ll see in “Key Idea: Minimize Work in Progress”.) 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 choosing team members, be sure they’re willing to help out with tasks outside their specialty.

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.

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

Allies
Collective Code Ownership
Pair Programming
Mob 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 amount of simultaneous 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.

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

  • One to two people focused on customer skills for every three people focused on programming. A quarter to 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.

  • One person focused on testing for every 2-4 people focused on programming, if the team doesn’t have Delivering fluency, or one for every 4-8 programmers if they do.

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

  • 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, a sixth of their time on customer skills, a sixth of their time on testing, and a sixth of their time on operations.

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 (see “Key Idea: Self-Organizing Teams”). 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 “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, [Self] Discipline, Ease, and Joy. [Marick 2007]

Allies
Team Dynamics

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

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 ship on their own. They had to coordinate with outside QA, ops, and back-end 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 front-end programmers (one with full-stack experience), a back-end 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 doesn’t stick around, 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 front-end, back-end, 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?

First, check if your company is over-hiring 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 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 you’ll see in “Key Idea: Minimize Work in Progress”.

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 starting work that needs their skills until they’re available, and dedicate them to the team for that week rather than splitting their attention with fractional assignment.

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 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 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 “How to Be Agile” chapter for more about creating buy-in.

Indicators

When you have a whole team:

  • Your team is able to solve problems and fulfill their 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 towards 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.

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

XXX Thomas Owens recommends:

  • Dynamic Reteaming: The Art and Wisdom of Changing Teams

  • Coaching Agile Teams

  • Agile Coaching

XXX Other to consider:

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.