The 6-Figure Developer Podcast

I appeared on the 6-Figure Developer podcast recently talking about the new edition of The Art of Agile Development. We had a great conversation about Agile development, influencing change, what it takes to reliably ship low-defect software, and more.

Listen to it here.

Fridays: Art of Agile Development Book Club

Fridays from 8:00 – 8:45am Pacific, I host an online discussion inspired by the new edition of my book, The Art of Agile Development. Each session uses a chapter from the book as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Attendance is free!

To learn more about The Art of Agile Development, see the book home page. You can buy a copy from Amazon or your favorite purveyor of software development books.

December 3rd: Whole Team

Agile is all about teamwork, which makes “Whole Team” one of the most foundational practices in the book. On December 3rd, we look at what it means to have a successful Agile team.

WhenDecember 3rd, 8-8:45am Pacific (calendar invite)
WhereZoom link
Reading 📖 Whole Team
DiscussionDiscord invite

Discussion prompts:

  • The reading talks about customer skills, development skills, and coaching skills. Which skills have been important for your teams? Why?

  • A successful team is cross-functional, with all the skills needed to accomplish its purpose. What barriers have you encountered in creating cross-functional teams, and how have you overcome them (or not)?

  • Generalizing specialists, or “T-shaped people,” are an important concept for Agile teams, but sometimes hard for people to accept. How have you seen folks react to the idea? What are some ways to help them accept it?

  • Agile teams are made up of peers who self-organize around their work. What does this look like when it’s at its best?

December 10th: Team Room

Great collaboration depends on a great workplace, whether that’s physical or virtual. On December 10th, we discuss how to create effective collaboration.

WhenDecember 10th, 8-8:45am Pacific (calendar invite)
WhereZoom link
Reading 📖 Team Room
DiscussionDiscord invite

Discussion prompts:

  • What are some of your favorite collaboration techniques, either in-person or virtual?

  • If you could design the perfect in-person team room, what would it look like?

  • What techniques do you recommend for improving collaboration and team cohesiveness in remote teams?

  • What kind of extra support do junior developers need in a remote team?

Session Recordings

See below for recordings of past sessions.

Note: The Art of Agile Development Book Club sessions are recorded. By appearing on the show, you consent to be recorded and for your appearance to be edited, broadcast, and distributed in any format and for any purpose without limitation, including promotional purposes. You agree Titanium I.T. LLC owns the copyright to the entire recording, including your contribution, and has no financial obligations to you as the result of your appearance. You acknowledge that your attendance at the book club is reasonable and fair consideration for this agreement.

If you don’t want to be recorded, that’s fine—just keep your camera and microphone muted. You’re still welcome to attend!

AoAD2 Practice: Team Room

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

📖 The full text of this section is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

Team Room

Whole Team, Coaches

We collaborate rapidly and effectively.

When people can’t communicate directly, the effectiveness of their communication decreases, as the “Key Idea: Face-to-Face Conversation” sidebar discusses. Misunderstandings occur and delays creep in. People start guessing to avoid the hassle of waiting for answers. Mistakes appear. Us-versus-them attitudes start to form.

To combat this problem, many teams attempt to reduce the need for direct communication. It’s a sensible response. If questions lead to delays and errors, reduce the need to ask questions! They spend more time up front to figure out requirements and document every need. Later, the theory goes, programmers won’t need to talk to an expert; they can just look up all the answers in the document.

It’s too easy for writing to be misunderstood.

It sounds reasonable, but it doesn’t work well in practice. It’s too hard to anticipate every question in advance, and too easy for writing to be misunderstood. It also stretches out the development process: before work can begin, people need to spend time writing, handing off, and reading documents.

Whole Team

So instead, Agile teams use a team room to communicate directly. It’s a place, either physical or virtual, where the team works and collaborates together. Rather than having someone talk to domain experts and write a document for programmers to read later, Agile teams include domain experts and other on-site customers on the team. When programmers need to understand what to do, they talk to the on-site customers directly.

Incremental Requirements

Working together in a team room has enormous benefits. In a field study of six colocated teams, [Teasley2002] found that sitting together doubled productivity and cut time to market to almost one-third of the company baseline.

Those results are worth repeating: the teams delivered software in one-third their normal time. After the pilot study, 11 more teams achieved the same result.

Secrets of Collaboration

Whole Team

To get the most out of your team room, be sure you have a whole team. You won’t get the advantages of cross-functional collaboration if the people you need to talk to aren’t part of your team. For people whose work takes them outside the team room frequently—product managers tend to fall into this category—make sure someone else on the team is available to act as their backup.

Even if you don’t have a whole team, though, working together in a team room gives you new opportunities to supercharge your collaboration. Here are some of my favorite techniques:

Always ask, always help

If you’re stuck on a problem and somebody on the team knows the answer, ask them to help. There’s no sense in banging your head against a wall. To support this, many teams have a working agreement: “We always help when a team member asks.”

Agile focuses on team performance, not individual performance.

Some people hear this rule and worry that they won’t be as productive. And they’re right, to a degree. If you spend a lot of time answering questions, you might not be as productive. But Agile is about the team. Even if you end up spending more time than you save, the team will be more productive overall.

What about programming and other work that requires deep focus? According to [DeMarco2013], it takes a programmer 15 minutes or more to get back into flow after an interruption. Won’t a culture of asking for help hurt overall programming productivity?

It can. At the same time, short-circuiting programming problems by asking for help is one of your best opportunities for improving team performance. So instead of avoiding interruptions, find ways to prevent interruptions from being distracting.

Pair Programming
Mob Programming

The best way to prevent questions from being disruptive is to use pair programming or mob programming. With pairing, one person answers the question while the other keeps thinking about the problem at hand. When the interruption is over, a quick “Where were we?” gets things moving again. With mobbing, interruptions are even less of an issue; they tend not to happen in the first place, because everyone’s working together. When they do, the person being interrupted just steps away while the rest of the mob keeps working.


If pairing or mobbing aren’t an option, your team will need to establish working agreements around interrupting work that requires deep focus. One approach is to put up an indicator—such as headphones when in person, or a status setting when remote—that means “fewer interruptions, please.” But remember that the goal is still to maximize the performance of the team, not the individual.

Drop in and drop out

A team room allows you to spend much less time in meetings. When you need to discuss an issue with other people on the team, don’t schedule a meeting; just tell the room what you want to discuss. Either stand up and say something (when colocated) or drop a note in the group chat (when remote). Then just start talking to one another. Each conversation needs to include only the people affected, and it should end as soon as the issue is resolved. If it turns out there’s someone else on the team who should participate, ask them to join.

When somebody starts a conversation, you don’t have to participate. Listen to the proposed topic and decide whether it’s something that needs your input. Similarly, if it turns out that the discussion isn’t relevant to you, you don’t have to stick around. You can go back to your work. It’s called the Law of Mobility: “At any time, if you are neither learning nor contributing, move yourself to a place where you are.”1 And vice versa! If a conversation turns out to be relevant to you, go ahead and join in.

1The Law of Mobility comes from Harrison Owen’s Open Space Technology, which is a superb approach for organizing large groups into productive discussions.

In a physical team room, it’s polite to move conversations away from people who are concentrating. Most team rooms have a separate conversation area for this purpose. It’s located close enough to the rest of the team that people can overhear and drop in if they want, but separated enough that conversations aren’t distracting.

Remote teams have the opposite problem: it’s too hard to overhear other people’s conversations. Once a conversation begins, it’s usually most effective to take it out of the group chat and into a videoconference. But then nobody can overhear what’s being discussed. So consider putting occasional updates in the group chat so people can decide whether they want to drop in.

Create visualizations

When people communicate, they each have their own model of the world in their head. When their mental models are too different, misunderstandings occur.

To prevent misunderstandings, turn your internal model into an external model. Create a visualization that everyone can see, compare to their own mental model, and change. Whiteboard drawings work, but models that encourage collaboration are even better. Index cards and sticky notes, or their virtual equivalent, work best. Write your ideas on cards, then move them around to visualize relationships.

Visual Planning
Task Planning

You’ll see examples of these visualizations throughout this book, such as in the visual planning and task planning practices. Don’t limit yourself to the visualizations described in this book, though. Whenever you have a discussion, particularly if people are having trouble understanding each other or coming to agreement, create a model that participants can manipulate.

Work simultaneously
Don’t bottleneck contributions behind a single person.

When working together, don’t bottleneck contributions behind a single person. Make sure everybody can contribute simultaneously. For example, when planning, don’t have one person sit at a computer and type everything into an electronic planning tool. Instead, visualize the plan with index cards or their virtual equivalent. That way, multiple people can write new cards at the same time, and multiple people can change the plan—and discuss their changes—by moving cards around and pointing at them.

This sort of simultaneous collaboration is enormously effective. It requires the person who’s normally at the keyboard to let go of control, but once they do, your discussions will be so much faster. For colocated teams, people will naturally segregate into small groups to discuss items of interest. You’ll get two to three times as much work done in the same amount of time. Remote teams won’t see quite as much benefit, because it’s harder to form small group discussions, but they’ll still be effective.

One of my favorite ways of working simultaneously is simultaneous brainstorming. In simultaneous brainstorming, someone asks the group to come up with ideas relating to a topic, just like normal brainstorming. When somebody thinks of an idea, they say it out loud, write it on an index card, and put it where everyone can see. (One idea per card, for ease of sorting later.) Saying it out loud inspires other people to have new ideas, and writing the idea down yourself prevents the group from bottlenecking behind a note-taker.

Remember not to critique ideas while brainstorming. Brainstorming works best when it’s two parts: first, free-form idea generation where anything goes; second, refining and filtering the ideas.

Sometimes I’ll follow simultaneous brainstorming with affinity mapping. To make an affinity map, take all the cards your group brainstormed and spread them out randomly on a table or virtual whiteboard. Then move the cards around so the ideas that are most similar are closest together, and the ideas that are least similar are farthest apart. Everybody works at the same time, moving cards as they see fit. In the end, the cards should end up forming clusters that you can name.

A variant of affinity mapping is mute mapping, which is the same as affinity mapping, except nobody is allowed to talk while the cards are being moved. It’s good for preventing arguments about where cards should go, and can lead to some fun mimed interactions, too.

Another way to filter your ideas after brainstorming is to use dot voting. In dot voting, each person gets a certain number of votes. (I multiply the number of choices by three, then divide by the number of people.) Everyone votes, all simultaneously, by putting a dot on the options they prefer. It’s okay to vote for one option multiple times. For example, if you have four votes, you could put one dot on four separate options, put four dots on one option, or anywhere in between. The options with the most votes win.

Seek consent

What do you do when people disagree? Unilateral decisions shut people out. Majority-rules results in a disappointed minority. Consensus takes too long and can deadlock.

Instead, use a consent vote. In a consent vote, somebody makes a proposal, then everybody votes “I agree” (thumbs up in person, “+1” in group chat), “I’ll go along with the group” (thumb sideways or “+0”), or “I disagree and want to explain why” (thumbs down or “–1”). To avoid accidentally pressuring people, you can optionally have everyone reveal their vote on a count of three.

If nobody votes “I agree,” the proposal fails for lack of interest. Otherwise, if nobody disagrees, it passes. If someone does disagree, though, they explain their objection, and the group adjusts the proposal to address it. The proposal doesn’t pass until all objections are addressed.

Consent votes work for two reasons. First, they leave room for people to withhold support without stopping a proposal from going forward. Second, if someone does feel strongly enough to veto a proposal, they have to explain why, which gives the group an opportunity to address their concerns.

Agree to experiment

Some decisions won’t have an obvious answer, or there will be multiple equally valid options. Discussions about these decisions can easily devolve into endless speculation about what might go wrong.

When you notice a discussion drifting into speculation, propose a concrete experiment.

When you notice a discussion drifting into speculation, propose a concrete experiment. For example, Extreme Programming includes the “ten-minute rule”: when a pair argues about a design direction for more than ten minutes, they split up, each write temporary code illustrating the design idea, and then compare results.

Physical Team Rooms

Team rooms can be physical or virtual. When it’s possible for team members to colocate, build a physical team room. It’s more expensive than a virtual team room, but despite advances in technology, face-to-face communication is still the most effective way for teams to collaborate.

Bjorn Freeman-Benson, a technology leader with years of experience leading remote teams, said, “We got much less creativity out of our [remote teams]. We had to overstaff to get the same amount of creativity... The key thing in any business I’ve been in is the creative output. [In a remote team,] you get less of it because of friction. You may even get more units of work, but Jira tickets don’t pay the bills.” [Shore2019]

The cocktail party effect

Part of the reason physical team rooms are more effective is the cocktail party effect, which [Cockburn2006] calls osmotic communication. Have you ever been talking with someone in a crowded room and then heard your name out of the blue? Even though you were focused on your conversation, your brain was paying attention to all the other conversations in the room. When it heard your name, it replayed the sounds into your conscious mind. You not only hear your name, you hear a bit of the conversation around it, too.

Imagine a Delivering team that sits together. Team members are working in pairs and holding quiet conversations. Then somebody mentions something about managing database connections, and another programmer perks up. “Oh, Kaley and I refactored the database connection pool last week. You don’t need to manage the connections manually anymore.” When team members are comfortable speaking up like this, it happens often—at least once per day—and saves time and money every time.

Designing your team room

Design your workspace to encourage collaboration. Provide straight desks that allow two people to sit and collaborate side-by-side, rather than using an “L” shape with the monitor in the corner. Provide plenty of whiteboards and wall space for sketching ideas and posting charts. Make sure there’s a conversation area with a large table that the team can use to spread out index cards and build visualizations, and include a projector or large TV, if possible, for group discussions that involve a computer.

Group people according to the conversations they need to overhear. Typically, developers (programmers, testers, operations, etc.) should sit close together. On-site customers don’t need to be so close, but they should be close enough to answer questions as needed.

Similarly, design your workspace to minimize distracting noise. The team’s conversation area should be located away from people’s desks. Consider providing an enclosed room with a door for phone calls and private conversations, particularly if your team includes people who spend a lot of time on the phone or in videoconferences.

Pay attention to the human side.

Finally, pay attention to the human side. People are more comfortable when their workspace includes natural light, plants, and color. Leave room for individuality, too. If people don’t have assigned desks, as often happens with mobbing and pairing, make sure they have a place for personal effects. Include books—like this one!—for people to flip through or reference.

If possible, make sure all the furniture can be moved, rather than bolting it in place, so team members can adjust their workspace to better fit their needs.

Multiple teams

Agile teams produce a buzz of conversation in their team rooms, with occasional exuberant celebrations. This isn’t likely to bother your team members, but it could bother your neighbors. Make sure there’s good insulation between your team and the rest of the organization.

That said, if teams need to collaborate frequently, put them next to each other and make sure they can overhear each other. For teams that don’t need to collaborate, separate them more, either with distance, walls, or noise barriers.

In-person equipment and supplies

Stock your physical team room with the following equipment and supplies. Although some of these can be replaced with electronic tools, invest in the physical equipment. It’s not very expensive and it will allow your team to take advantage of the strengths of face-to-face collaboration.

  • Two big magnetic whiteboards for planning purposes. I like to use a single double-sided, six-foot-wide magnetic whiteboard on wheels. It makes it easy for the team to roll their plans into meeting rooms. It needs to be magnetic so you can stick cards to it easily.

  • Lots of additional whiteboard space, preferably magnetic, for discussions and charts.

  • A large plastic perpetual calendar (three months or more) for marking important dates.

  • Sound-damping partitions to define the team’s workspace and prevent noise pollution, or an enclosed team room.

  • Stools or other ways to easily sit with someone temporarily.

  • Notepads or handheld whiteboards for sketching ideas while seated.

  • Miscellaneous toys and conversation pieces to inspire discussion and interaction among team members.

  • Flip-chart paper, one or two flip-chart easels, and a way to attach flip-chart pages to walls (such as blue tape, poster tack, or T-pins).

  • Index cards in a variety of colors (at least 2,000 of each color). Make sure everyone on the team can distinguish the colors.2

  • Sticky notes in a variety of colors, sizes, and shapes.

  • Pencils, pens, and water-based felt-tip pens for writing on cards and sticky notes. Avoid permanent markers such as Sharpies; they have a strong odor and invariably get used on a whiteboard.3

  • Dry-erase markers for whiteboards, water-based flip-chart markers for flip-charts, and wet-erase markers for semi-permanent whiteboard notes and the perpetual calendar. Avoid scented markers.

  • Magnetic push-pins for attaching index cards and documents to whiteboards.

  • A copy of this book and any other useful reference material.

2One out of eight men have some form of color blindness.

3Pro tip: you can remove permanent marker from whiteboards by writing over it with a whiteboard marker, then immediately erasing.

In-person teams using pair programming also need pairing stations (see the “Pair Programming” practice for details):

  • Wide desks suitable for side-by-side work. Some teams prefer a mix of standing and sitting desks, or adjustable-height desks.

  • One development-grade computer at each pairing station.

  • Two keyboards and mice at each station. Some people prefer to use their own keyboard and mouse; in that case, make sure each computer’s USB ports are easily accessible, because they’ll be moving between pairing stations multiple times per day.

  • At least two monitors at each station.

In-person teams using mob programming need a mobbing station (see the “Mob Programming” practice for details):

  • Desks with enough seats for every member of the team, plus a few guests, with room for people to easily switch seats.

  • A “driver’s seat,” easily accessible, with a mouse, keyboard, and development-grade computer.

  • A “navigator’s seat” at the same desk as the driver’s seat, or close enough for the driver and navigator to easily talk to each other.

  • At least one monitor, typically 60" diagonal or more, that’s large enough to be seen clearly from all seats. 4K TVs often work well for this purpose. Make sure to accommodate everyone’s vision needs.

Do not purchase Agile Lifecycle Management software.

Do not purchase Agile Lifecycle Management software or other tracking software unless the team explicitly requests it, and even then, wait until team members have several months of experience using the planning practices in this book first. See the “Corporate Tracking Tools” section for details.

Sample team rooms

The workspace shown in the “Spotify-Inspired Team Room” figure is based on team rooms I saw at Spotify’s headquarters in 2015. Each room had a work area with a lot of whiteboards, a conversation area, and a room for private conversations that could accommodate three to five people. Outside the room, there was a wide corridor with comfy couches and chairs, and a coat rack.

Spotify's team rooms were among the best I’ve seen, but they had a few flaws, according to the people that I talked to. The divider between the team room and the corridor was originally meant to be glass, but instead it was a kind of mesh (possibly due to fire codes), which allowed noisy conversations in the corridor to disturb the team. Also, the room wasn’t flexible: although Spotify had different-sized rooms for different-sized teams, teams didn’t like having to move rooms when they grew or shrank.

A diagram of a team room. The left half of the room is set aside for team member desks. The right side of the room is split between a shared conversation space, with a table, and an enclosed room. Outside the room is a casual seating area. The room has windows along the top and an entrance on the bottom, and whiteboards along the walls.

Figure 1. Spotify-inspired team room

The workspace shown in the “Budget Team Room” figure is based on a room created by an up-and-coming startup when they moved into new offices. They didn’t have the budget for a fancy workspace, so they made do with what they had. They put five pairing stations along a long wall with outside windows. Two of the desks were standing desks and the other three were repurposed from segments of a round conference table. A second round conference table was used for group conversations. The space was demarcated by cubicle dividers with whiteboards. Team members had a small pod of cubicles off to the side, and there were conference rooms nearby that could be used for private conversations.

It was a great workspace with one serious problem: there was a divider between the programmers and the product manager. (I’ve removed it from the figure.) As a result, the product manager was seated outside the team room—just barely!—and that was enough that he didn’t overhear or participate in team discussions. Team members couldn’t get ready answers to their questions and often struggled with requirements.

A diagram of a team room. The top half of the room has five tables for working in pairs. They’re next to an exterior wall with windows. To the right of the pairing stations, there’s a round conference table. In the bottom half of the room, there are two open offices (with no wall or door on the top side), one with two desks and the other with one. There are whiteboards on the walls surrounding the pairing stations and conference table.

Figure 2. Budget team room

Adopting a physical team room

Some people may resist moving to a physical team room. Common concerns include loss of individuality and privacy, implied reduction in status from losing a private office, and managers not recognizing individual contributions.

In my experience, most people come to enjoy the benefits that sitting together provides, but it can take a few months. Teams I’ve worked with that set aside a lot of individual space in their team rooms ended up not using it. The Teasley case study found similar results: team members initially preferred cubicles to the open workspace, but by the end of the study, they preferred the open workspace.

However, forcing people to sit together in hopes that they’ll come to like it is a bad idea. Instead, talk with the team about their concerns and the trade-offs of moving to a team room. Discuss how team members will be evaluated in an Agile environment—it should emphasis team contributions, as the “Key Idea: Collective Ownership” sidebar discusses—and what provisions you can make for privacy.

One manager I talked to set up a team room for their team, with pairing stations, but didn’t require team members to use it. A few people on the team wanted to try pair programming, so they moved to the team room. Over time, more and more members of the team migrated to the team room so they could work with the people who were there. Eventually, the whole team had moved to pair programming and the shared team room, without any coercion.

Virtual Team Rooms

If you have a remote team, you can create a virtual team room using online tools. This works for hybrid and partially remote teams, too,4 but be careful: in-person conversations shut remote team members out. If some people are remote, the people working in person need to use the virtual team room for all their collaboration, too. A decision to use a virtual team room is a decision to act as if everyone is remote.

4A hybrid-remote team is in person some days and remote others. A partially remote team has some people in person and some remote.

Remote equipment and tools

Remote teams need an electronic version of the team workspace:

  • Videoconferencing software, such as Zoom, for real-time conversation

  • Messaging software, such as Slack, for asynchronous conversation

  • Virtual whiteboard software, such as Miro or Mural, for freeform, simultaneous collaboration

  • Collaborative versions of task-specific tools, where possible, such as Figma for UX and UI design

  • A document store, such as DropBox, Google Drive, or a wiki

  • Inexpensive tablets for collaborative whiteboard sketches

  • An additional monitor or tablet for videoconferencing, so people can see one another and work at the same time

  • For Delivering teams, collaborative programming tools, such as Tuple or Visual Studio Live Share, that support pairing or mobbing (see the “Pair Programming” practice and the “Mob Programming” practice for details)

As with an in-person workspace, do not purchase Agile Lifecycle Management software or other tracking software.

Designing remote collaboration

Collaboration is easy when people are colocated. Achieving the same level of collaboration in a remote environment takes careful design. When your team establishes its working agreements during alignment chartering, make a point of discussing how you’ll collaborate. Remember that the goal is to maximize the performance of the team, not the individual. As work progresses, be sure to evaluate and improve your communication techniques frequently.

I asked people who had experience with great in-person and remote collaboration experience for their remote collaboration tricks.5 There were several excellent suggestions:

5Thanks to Dave Pool, Gabriel Haukness, Alexander Bird, Chris Fenton, Brian Shef, and Dave Rooney for sharing their techniques on Twitter. Thanks also to Brent Miller, Dennis McMillan, Seth McCarthy, Jeff Olfert, and Matt Plavcan for their suggestions.

  • Make time for personal connections. In-person teams form bonds of friendship and mutual respect, and this allows them to make decisions quickly and effectively. In a remote team, be sure to set aside time to socialize and keep up with each other’s lives. Options include virtual coffee breaks to help ease tension, a dedicated chat channel for greetings and personal updates as people arrive and leave their office, and a 30-minute call every day for chatting or playing games. One team made a habit of reserving the first 5–10 minutes of every meeting for socializing; people could either show up early to chat or just come for the content as their mood dictated. Another set aside time specifically for celebrating successes.

  • Ensure safety. In an in-person team, people can joke around and be themselves without worrying that it will come back to haunt them. In a virtual environment, anything can be recorded. Establish clear guidelines about when it’s okay to record or share a conversation. Another way to create safety is to create a private channel in your group chat that’s only accessible to the team.

  • Make the implicit explicit. In an in-person conversation, many social cues come from subtle changes in facial expression and body language. In a remote conversation, those cues are often invisible. So instead, make them explicit. For example, one person created index cards he could hold up during video calls, labeled with phrases such as “+1,” “Concern,” “+1,000,000” and “Yeesss, do eeeet.” (Have some fun with it!) Similarly, be explicit about your availability. Put notes in the group chat about where you are, what you’re doing, and whether you’re open for conversation.

  • Upgrade your medium. Low-bandwidth communication, such as text chat, is good for brief updates, but it tends to lead to long and slow back-and-forth when discussing meaty issues. When you notice this happening, switch to a medium with more bandwidth. For example, one team established a standard of moving to a video call as soon as more than two people were discussing a subject in the team’s chat room.

  • Enable simultaneous conversation. When a bunch of people work on a visualization at the same time, they often split off into little two- to three-person person discussion groups. Establish ways of getting the same benefit from your tools. Videoconference tools have break-out rooms, and group chat applications support creating separate channels or threads.

  • Create a “wall.” In an in-person team room, information that everyone needs to see or remember is posted on the wall. For your remote team, consider creating a small number of shared documents to store the same sort of information.

  • Get tablets. It’s much more convenient to sketch diagrams on a tablet than with a mouse or trackpad, and they’re not very expensive. Get a tablet for each member of the team and leave it logged in to your virtual whiteboard. When you need to sketch something in a discussion, the tablet’s ready to go.

  • Respect differences in access. People’s internet connections vary widely. Just 10 miles can mean the difference between high-speed urban bandwidth and flaky rural bandwidth, let alone differences between countries. Talk about people’s needs and choose communication strategies that work for everyone.

Junior team members

Bjorn Freeman-Benson describes “The Junior People Problem” as one of the three challenges of distributed teams:

When a developer is just starting, they have a lot of questions. They don’t know how to do the work. But at the same time, they’re at the bottom of the pecking order. They’re hesitant to interrupt and don’t want to be seen as a burden.

...With InVision’s 100% remote teams [where Bjorn was CTO], junior developers couldn’t see what other developers were doing. They were afraid to interrupt. “They froze and got stuck,” Bjorn said, “until much later when they were explicitly asked what they were doing.” [Shore2019]

"Bjorn Freeman-Benson: Three Challenges of Distributed Teams"

Pair Programming
Mob Programming

Be sure to establish ways for junior team members to get up to speed without feeling lost or in the way. Pairing and mobbing are both excellent techniques. If those aren’t a good fit for your team, consider establishing daily check-ins, one-on-one mentoring, or other ways of ensuring junior team members aren’t left behind.


My physical team room is too noisy for me to concentrate. What can I do?


Sometimes, the team gets a little noisy and rambunctious. It’s okay to ask for quiet. When you discuss working agreements during your initial conversation about alignment, talk about how to make sure everybody’s needs are being met. If that’s not enough, bring it up during your team retrospectives, too.

Remember that pair programming is an excellent way to focus your attention away from background noise. You won’t notice it as much if you’re talking with your pair partner. Similarly, mob programming avoids the problem entirely by focusing everybody’s attention on the same thing.

Whenever a conversation starts, the whole team stops what they’re doing to listen. What can we do to prevent people from being distracted so easily?

Especially in the beginning, it’s possible that the whole team really does need to hear these conversations. It helps establish context and gets everyone on the same page. As time goes on, team members will learn which conversations they can comfortably ignore.

If it’s a continuing problem, especially in a physical team room, try stepping a little farther away from the rest of the team when a conversation starts. Interested team members can join the conversation while the rest of the team continues working.


Team members need to share a set of core hours to collaborate effectively, even if they’re remote. If team members are so widely dispersed that shared hours aren’t possible, you actually have multiple teams, and you should design your work accordingly. (See the “Scaling Agility” chapter for more about scaling to multiple Agile teams.)

For physical team rooms, the hardest part is making the space. You’ll typically need approval from Facilities and support from management. It can take weeks or even months to complete, so start arranging for your shared workspace early.

In addition to getting management and Facilities buy-in, make sure team members agree to share a physical team room. Changes to work space can be hard for a lot of people. If they’re forced into a new arrangement against their will, they’re likely to find a way to leave the team, even if it means leaving the company. For more about getting buy-in, see the “Invest in Change” chapter.

Pair Programming
Mob Programming

If your team doesn’t use pair programming or mob programming, be careful to design your workspace and working agreements to minimize noise and distraction.


When you have a successful team room:

  • Communication between team members is fast and effective.

  • You’re aware of when people are working on problems that you can contribute to, and they’re happy for you to join the discussion.

  • You don’t need to guess at answers. If anyone on the team knows the answer, you can ask and get a quick response.

  • Team members spontaneously form cross-functional groups to solve problems.

  • The team has a feeling of camaraderie and mutual respect.

Alternatives and Experiments

This practice is really about frictionless communication, and it doesn’t matter if you have a literal team room or not. But if you haven’t experienced the effortless collaboration of a team room—particularly a physical team room—try it for several months before experimenting with alternatives. It’s hard to appreciate how effective it can be until you’ve seen it for yourself.

Mob Programming

Mob programming turns up the dial on collaboration even further, by having everybody on the team work together at a single computer. It may sound ridiculous, but, in a way, it’s “easy mode” for collaboration. It’s particularly effective for remote teams, who otherwise have a lot of work to do before they can reproduce the effectiveness of a physical team room.

Other than mobbing, the core idea of the shared workspace is hard to beat. Your best experiments will be in the details. How can you improve communication? Can you convert regularly scheduled meetings to continuous or ad-hoc collaboration? How can you change your tools, both physical and virtual, to enable new ways of working together? What about your workspace? Is there any way to rearrange furniture, or change your working agreements, to make communication more effective? As you work, notice where communication has friction, and try experiments that could smooth it out.

Further Reading

Agile Software Development [Cockburn2006] has an excellent chapter on communication. Chapter 3, “Communicating, Cooperating Teams,” discusses information radiators, communication quality, and many other concepts related to sharing a team room.

The Remote Facilitator’s Pocket Guide [Clacey2020] is quick, useful read about facilitation. It’s particularly geared towards remote sessions, but its advice is valuable for people working in person, too.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

Agile Book Club: Scaling Agility

This book club was about scaling agility, and we had a fantastic special guest joining us: Bas Vodde. Bas co-created Large-Scale Scrum (LeSS) with Craig Larman. LeSS is one of the earliest and most popular Agile scaling approaches, and my go-to recommendation for organizations looking to scale Agile. Bas and Craig’s book, Large-Scale Scrum: More with LeSS, is well worth reading.

Discussion prompts:

  • The book discusses scaling organizational capability as well as scaling product teams. How have you seen organizations approach scaling their capability (or not)? How did it turn out?

  • Team-level coaching capabililty is an important part of scaling agility. If you could do anything, how would you scale out coaching capability?

  • The book describes two approaches to scaling product teams: vertical scaling and horizontal scaling. What do you see as the strengths and weaknesses of each approach?

  • Share some stories about scaling product teams. What worked well, and what didn’t?

About the Book Club

The Art of Agile Development Book Club takes place Fridays from 8:00 – 8:45am Pacific. Each session uses an excerpt from the new edition of my book, The Art of Agile Development, as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Visit the event page for more information, including an archive of past sessions. For more about the book, visit the Art of Agile Development home page.

Agile Book Club: Investing In Change

For this book club session, we had a special guest: Diana Larsen! Diana Larsen is a team dynamics expert and change guru who’s been part of the Agile community since the beginning. She’s best known for coauthoring Agile Retrospectives: Making Good Teams Great with Esther Derby. She contributed two practices on team dynamics and improvement to the book and I’m thrilled she was able to join us to discuss organizational change.

Discussion topics:

  • Have you been part of a change, or led a change (Agile or not)? What was it like? Tell some stories from your experience.

  • What have you seen work, and not work, when people try to create change?

  • The book talks about the importance of manager, team member, and business stakeholder buy-in. In your experience, how do those groups react to change similarly and differently?

  • What’s the first thing you would do if you were asked to lead an Agile change? What would come next?

About the Book Club

The Art of Agile Development Book Club takes place Fridays from 8:00 – 8:45am Pacific. Each session uses an excerpt from the new edition of my book, The Art of Agile Development, as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Visit the event page for more information, including an archive of past sessions. For more about the book, visit the Art of Agile Development home page.

Agile Book Club: Investing In Agility

To succeed with Agile, your organization needs to support it by changing the constraints teams are under. What changes should they make? That’s the subject of this book club session.

Discussion topics:

  • How have you seen organizations invest in their agility? How did it turn out?

  • In your opinion, which investments are most important for Agile to succeed?

  • Tell a story about an organization failing to invest in agility. What happened?

  • When it’s at its best, what does investing in agility look like? Tell a real-world story or share your opinion.

About the Book Club

The Art of Agile Development Book Club takes place Fridays from 8:00 – 8:45am Pacific. Each session uses an excerpt from the new edition of my book, The Art of Agile Development, as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Visit the event page for more information, including an archive of past sessions. For more about the book, visit the Art of Agile Development home page.

AoAD2 Practice: Whole Team

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

📖 The full text of this section is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

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

Customer Skills

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

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

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.

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

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.


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.


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.


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

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.

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

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

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.

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

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


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.


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.


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.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

AoAD2 Chapter: Teamwork (Introduction)

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

📖 The full text of this section is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.


The best architectures, requirements, and designs emerge from self-organizing teams.

Business people and developers must work together daily throughout the project.

Manifesto for Agile Software Development

Cross-functional, self-organizing teams are the fundamental “resource” of any Agile organization. But who should be part of an Agile team? How do they know what to work on? What makes it possible for them to work well together?

This chapter has the practices you need to create a great Agile team.

  • The “Whole Team” practice creates a cross-functional team with all the skills it needs.

  • The “Team Room” practice builds a space, either physical or virtual, where the team can collaborate effectively.

  • The “Safety” practice creates an environment where team members are able to share their experience and insights.

  • The “Purpose” practice helps team members understand how their work supports the company’s big-picture plans.

  • The “Context” practice clarifies your team’s stakeholders and committed resources.

  • The “Alignment” practice establishes norms that allow team members to work together effectively.

  • The “Energized Work” practice encourages working in a way your team can sustain indefinitely.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

AoAD2 Part II: Focusing on Value (Introduction)

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

📖 The full text of this section is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

Focusing on Value

You walk into work on a crisp October morning. Your last team was fully remote, but your current team prefers in-person work. Communication styles are very different, you muse to yourself, but Agile is much the same.

Your team is a fluent Focusing team. As a team, you’re very good at understanding customer needs, coming up with good ideas, and focusing your work on the most valuable thing you can do. There’s room for improvement, particularly around defects and deployment, and people have been talking about investing in Delivering zone fluency to solve those problems, but management is very happy with your work.

Some people on the team are advocating for your team to take full ownership as an Optimizing team, but, for now, your team’s priorities are determined by Hanna, a product manager in the marketing department. She’s pretty busy and her boss isn’t willing to assign her to your team full-time.

Speaking of product direction, today is demo day. Every week, your team releases a new version of its software, then makes a plan for the next week of development. Once per month, you gather together your major stakeholders, show what you’ve done, and get their feedback. You used to do it more often, but stakeholders couldn’t be bothered to show up that frequently. So now you have less frequent, chunkier demos, and people are excited to see what’s new. When you want faster feedback, you give private demos to interested individuals.

Hanna leads the demo, as usual. She originally wanted team members to run the demo, but you found that having Hanna in charge of the demo meant she paid more attention to what you were building. It led to better feedback and better results. Plus, she’s much better at speaking stakeholders’ language.

Stakeholders seem happy with your progress this month. There’s a lot of interest in the whitelabel feature you’re working on, and the usual smattering of suggestions. Hanna makes note of them.

After the demo, it’s time for your weekly team retrospective. It’s an opportunity for your team to look at your practices, team dynamics, and organizational roadblocks to experiment with possible improvements. Your monthly demo cadence was the result of one of those experiments.

You rotate who facilitates the retrospective every week. This week, it’s Shayna’s turn. You’re looking forward to it. Shayna always comes up with creative exercises to liven up the retrospective, and she’s good about making sure that the team follows through with an experiment to try.

Your team takes a break after the retrospective, then Hanna begins your weekly planning session by pulling over your visual planning board. It’s a large whiteboard with a bunch of index cards stuck to it with magnets. The cards form clusters, and each cluster has a name like “resellers,” “actuaries,” or “accountants.” They represent your customer groups. There’s another large group of cards marked “whitelabel.”

“We had some good ideas in the demo,” Hanna says, “but I want to stay focused on the whitelabel feature for resellers.” Everybody nods. You’ve been working on this for a few weeks, so it’s no surprise. “We’re getting close to being done with the whitelabeling itself, so next up is the administrator screens. Before that, I’d like to set up a trial run with one of our major resellers. I’ll send an email with the details.”

Hanna nods to Colton, the team’s UX designer, and he speaks up. “Hanna and I are going to be going over the trial run and whitelabel administration later today. You’re welcome to join. Afterward, I’d like to work up a story map and do a planning game to flesh out the stories. It shouldn’t be too complicated. I’ll let you know when I’m ready to schedule it.”

Hanna grabs a handful of blue story cards from the “whitelabel” section of the release board. “We still have enough stories to get us through this week. Our capacity is still 12 points, right?” Everyone nods. “Great. Here’s 3...6...8, 11, 12. These should get us pretty close to being able to trial with real customers.” She holds up the first card, which says “whitelabel color scheme.” “Okay, for this one, we need to be able to change the site color scheme to match each reseller’s colors.” She briefly explains the remaining cards. There are a few clarifying questions, but you’ve all seen these before, so it goes quickly.

“Okay, that’s the plan!” Hanna concludes. “Colton should be able to answer any questions about the details. I’ve got some emails to take care of, but I’ll be over here”—she points to a corner—“until you’re done with planning. Let me know if you need me to clarify anything.”

Hanna sits down and Shayna takes the lead. You decided a while ago—it was another retrospective experiment—that the person who led the retrospective would facilitate all team meetings for the week. You haven’t heard of any other teams working this way, but for your team, having a predefined facilitator helps you stay on track, especially now that your coach has moved to a different team.

Shayna spins the planning board around. On the back is your weekly plan. “Okay, you know the drill,” she says. She points at the five story cards Hanna chose. “Go ahead and spread those out and start brainstorming tasks onto yellow cards. I’ll prep the board.”

The team members gather around the table and start writing tasks on yellow index cards. As they do, they call out their ideas, which in turn inspires more ideas. “Update the DB schema to include color scheme.” “Factor out CSS variables.” “Serve reseller-specific CSS file.” “Add reseller CSS file to top-level template.” Before long, there’s an orderly grid of cards showing everything that the team needs to do this week. Shayna helps transfer it to the whiteboard. You’ve heard that other teams visualize their plans differently, but your team likes this approach.

“Let’s do our stand-up,” Shayna says. You gather around the whiteboard and have a brief discussion about what to work on first, then everybody grabs a task card off the board. The tasks take only a few hours each, so as each one is finished, you'll mark it done and get a new card from the board. Every day, you’ll have another stand-up meeting around the board to review your progress and make sure the week is on track.

“I think that’s it,” says Shayna. The stand-up took only a few minutes, and the whole planning session has taken less than an hour. With the retrospective and demo, it’s getting close to noon. “Who’s up for lunch?”

Welcome to the Focusing Zone

The Focusing zone is for teams who want to focus on what their company values most.

The Focusing fluency zone is for teams who want to focus on what their company values most. They work closely with their business partners to understand priorities, provide visibility, and act on feedback. Specifically, teams that are fluent at Focusing:1

1These lists are derived from [Shore2018b].

  • Plan their work in terms of business value, not technical tasks, and align their work to their company’s business priorities

  • Demonstrate progress at least once per month, and do so in terms of business value, not technical tasks

  • Change direction to match changes in business priorities

  • Provide visiblity into their progress, so management can intervene when the team is building the wrong thing or isn’t making progress

  • Regularly improve their work habits, reducing costs and improving effectiveness

  • Collaborate well within their team, reducing misunderstandings and handoff delays within the team

To achieve these benefits, teams need to develop the following skills. Doing so requires the investments described in the “Invest in Agility” chapter.

The team responds to business needs:

  • The team works with a business representative who provides the team with organizational perspective and expectations.

  • Business stakeholders can rely on the team to work on whatever the team’s business representative says is their most valuable priority.

  • The team plans its work, and shows progress, in chunks that its business representative understands and values.

  • The team’s business representative sees, and can change, the team’s direction at least monthly.

  • Management enables the team to work at a pace that allows it to respond to business needs indefinitely.

The team works effectively as a team:

  • The team generates its own day-to-day tasks and plan, based on its business representative’s priorities.

  • Team members consider their plan to be the team’s work, not individuals’ work.

  • Team members share accountability for getting their plan done.

  • Management considers the plan to be the team’s work rather than assigning accountability to individuals.

The team pursues team greatness:

  • The team embraces, and continuously improves, a joint approach to its work.

  • The team is aware of how intrateam relationships affect its ability to succeed and proactively attempts to improve them.

  • The team is aware of how the work environment affects its ability to do work and proactively attempts to improve it.

Achieving Focusing Fluency

The chapters in this part will help your team achieve fluency in Focusing zone skills. They contain practices to help you work as a team, plan valuable releases, own and be accountable for your work, and steadily improve.

  • The “Teamwork” chapter describes how to work effectively as a team.

  • The “Planning” chapter describes how to plan and prioritize work according to business value.

  • The “Ownership” chapter describes how to take ownership of your day-to-day process and plans.

  • The “Accountability” chapter describes how to provide visibility into your work and gain stakeholders’ trust.

  • The “Improvement” chapter describes how to improve your team’s work habits, relationships, and environment.

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

Two Art of Agile Development Podcast Appearances

I’ve been making the podcast rounds promoting the release of The Art of Agile Development, Second Edition. First up is the Agile In Action podcast. Bill Raymond and I had a nice, detailed look at what’s in the new edition. Stick around until the end for one of my favorite stories from the book.

Listen to the Agile In Action podcast here.

I also appeared on the Azure DevOps Podcast. Jeffrey Palermo and I had a fun, wide-ranging conversation about various aspects of Agile, ranging from teamwork to forecasting to engineering practices.

Listen to the Azure DevOps Podcast here.

Dec 8: Agile Toronto Quicktalk (Online)

On December 8th at 6pm east coast time, I’ll be giving a “Quicktalk” to Agile Toronto about the new edition of The Art of Agile Development:

At this session, James will share the first chapter of the book, and we'll have an opportunity to discuss what 'Agile' means to us, how that might align with our organizations, and what it looks like at it's best.

A “Quicktalk” is a short, 30-minute appearance that starts with a 10-15 minute presentation (in this case, I’ll be reading an excerpt from the book) and 15-20 minutes of Q&A. It’s short, sweet, and free—don’t miss it! Register here.

AoAD2 Chapter: Scaling Agility

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Scaling Agility

In a perfect world, every Agile team would be perfectly isolated, completely owning its product or portfolio of products. Cross-team coordination is a common source of delays and errors. If every team were isolated, that wouldn’t be a problem.

It’s also not at all realistic. A typical Agile team has 4–10 people. That’s often not enough.

So, then, how do you scale? Although this book is focused on individual Agile teams, the question is important enough to deserve a chapter of its own.

Scaling Fluency

Far too often, organizations invest in scaling Agile without investing in teams’ fluency or organizational capability.

Far too often, organizations try to scale Agile without actually having the ability to be Agile in the first place. They invest a lot of time and money in the large-scale Agile flavor of the day, without investing in teams’ fluency or organizational capability. It never works.

To scale Agile, you’ll need to scale your organization’s ability to be Agile. This involves three parts: organizational capability, coaching capability, and team capability. continue reading, buy the book!

In this Section

  1. Scaling Agility
    1. Scaling Fluency
      1. Organizational Capability
      2. Coaching Capability
      3. Team Capability
        1. Sidebar: Second Adopter Syndrome
    2. Scaling Products and Portfolios
      1. Scaling Vertically
        1. LeSS
        2. Adopting LeSS
        3. FAST
        4. Adopting FAST
        5. Challenges and benefits of vertical scaling
      2. Scaling Horizontally
      3. Scaling Vertically and Horizontally
      4. My Recommendation
        1. Sidebar: What About SAFe?

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

Agile Book Club: Choose Your Agility

There are many ways to be Agile, and no one way is right for everyone. Which ones should you choose? We discussed it in this book club session.

Discussion topics:

  • Which Agile ideas and fluency zones are important for your teams, and why?

  • Which aspects of Agile has your organization chosen to embrace, and how did it make that choice?

  • What does your organization want from Agile? How do its investments in agility reflect those goals?

  • If you could change anything, what would you improve about your team or organization’s approach to Agile?

About the Book Club

The Art of Agile Development Book Club takes place Fridays from 8:00 – 8:45am Pacific. Each session uses an excerpt from the new edition of my book, The Art of Agile Development, as a jumping-off point for a wide-ranging discussion about Agile ideas and practices.

Visit the event page for more information, including an archive of past sessions. For more about the book, visit the Art of Agile Development home page.

AoAD2 Chapter: Invest in Change

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Invest in Change

You’ve decided that Agile will make your teams more successful. You know which zones have the best cost/benefit tradeoffs. You’ve figured out which investments your company needs to make. Now, how do you make it happen?

Understanding Change

Change is disruptive, and introducing Agile is no exception.

Change is disruptive, and introducing Agile is no exception. Exactly how disruptive it is depends on how many teams are affected and how well you manage the change. If you have one team that’s eager to try Agile with your organization’s full support, it doesn’t have to be a big deal. If you’re trying to change 50 teams in an organization that’s unfamiliar with Agile ideas...well, now it’s a very big deal.

One way to understand how people respond to change is Virginia Satir’s Change Model, shown in the “Satir Change Model” figure.1 As the figure shows, there are five stages to a change. Here’s how they apply to Agile:

1Steven Smith has a good article on the Satir Change Model that includes tips for helping team members through each stage.

  1. Late Status Quo. This is the pre-Agile way of working. It’s comfortable and familiar. Everyone knows what’s expected of them and how to do their job. Some people aren’t completely happy, though, and they think Agile will help. They push for change.

  2. Resistance. The people who want change start getting traction, and some sort of Agile change becomes likely. This is called a foreign element. People start responding to the possibility of change. Many oppose it. They say Agile is unnecessary, unlikely to succeed, or a waste of time. Some are angry. The more people affected, the more resistance you see.

  3. Chaos. The Agile change is approved and teams start using Agile practices. Old ways of working and familiar expectations no longer apply. People feel lost and confused, and moods are volatile. Some days are good; some are bad. People occasionally revert to childish behavior. Performance and morale decline.

  4. Integration. With practice, people start to become familiar with their new ways of working. They discover an aspect of Agile—called a transforming idea—that is particularly compelling to them. (This is different for each person.) They embrace the possibilities Agile brings and start putting real effort into making Agile work. Feelings of chaos decrease, morale improves, and performance climbs.

  5. New Status Quo. People have made their way through the change and come out the other side. Their new Agile ways of working are comfortable and familiar, and they’re confident enough to continue to make small changes. Performance has stabilized at a higher level than before the change and continues to increase gradually as people experiment with further small changes.

A chart with two axes. The horizontal axis is labelled “Time,” with an arrow pointing to the right. The vertical axis is labelled “Performance,” with an arrow pointing up. Within the chart, a line travels from left to right. The line starts in the middle of the performance axis with a section labelled “late status quo.” It is mostly horizontal, with small vertical pertubations and a slight upward trend. Next, there’s a star labelled “foreign element.” The line continues as before through a short section labelled “resistance,” before plunging down (indicating lowered performance) with dramatic up-and-down spikes (indicating highly-varying performance). This section is labelled “chaos.” None of the spikes exceed the midline performance of the late status quo. About halfway along the horizontal axis, one of the spikes is labelled with another star and the title “transforming idea.” The spikes gradually climb, indicating increased performance, and the size of the swings decrease. This section is labelled “integration.” Finally, the spikes flatten out, at a higher level of performance than the beginning, with small vertical pertubations and a slight upward trend. This final section is labelled “new status quo.”

Figure 1. The Satir Change Model

Trying to rush change just makes things worse.

This reaction to change is unavoidable. Trying to rush it just makes things worse. That’s why organizations need to set aside time for learning Agile (see the “Make Time for Learning” section). Note the parallel between the Satir Change Model shown in the “Satir Change Model” figure and the J-curve shown in the “Agile Performance Over Time” figure.

Everybody goes through these stages at their own pace. The length of the change, and the depth of the chaos, depends on how much their day-to-day life is affected. Someone who’s only peripherally involved will respond less than a person who’s part of a newly Agile team. Individual personalities matter, too; some people love trying new things, whereas others want stability and predictability.

You can decrease (but not eliminate!) the chaos by using a technique I learned from Diana Larsen: Support, Information, and Structure (SIS).2

2Thanks to Diana Larsen for assisting with this list.

  • Support. Help people understand how to do their job in the changed environment. Provide training, coaching, and other ways for people to get help without feeling judged. Make the investments described in the “Invest in Agility” chapter. Make sure everyone has someone they can talk to, either at work or in their personal life, when they’re feeling overwhelmed.

  • Information. Be transparent about what’s happening, what’s known, and what’s yet to be determined. Address people’s career concerns. If you can do so honestly, make an explicit promise that no one’s getting fired as a result of the change. Communicate more than you think should be needed.3

  • Structure. People need ground to stand on, so provide a roadmap for the change. If you’re using this book as the basis for your change, provide copies, and tell people which parts you’re using. When things are uncertain, describe what you need to do to make them certain, and when you expect that to happen. If there’s an interim step, such as temporary teams, be clear that it’s temporary, and describe what’s going to happen next.

3Diana says, “Communciate until you want to throw up. And then more.” continue reading, buy the book!

In this Section

  1. Invest in Change
    1. Understanding Change
    2. Large-Scale Change
    3. Making Changes
    4. Get Management Buy-In
      1. 1. Start with a Conversation
      2. 2. Get the Economic Buyer’s Approval
      3. 3. Make a Formal Proposal
        1. Sidebar: Reaching the Economic Buyer
      4. If this sounds like too much work...
      5. If management thinks they’re already Agile...
      6. If management isn’t supportive...
        1. Sidebar: Change Your Organization
    5. Get Team Buy-In
      1. If team members are skeptical...
      2. If a few team members refuse...
      3. If the majority of the team refuses...
      4. If people lie about their acceptance...
    6. Get Stakeholder Buy-In
      1. If concrete commitments are required...
      2. If stakeholders don’t buy in...
    7. Further Reading

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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

AoAD2 Chapter: Invest in Agility

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Invest in Agility

As we saw in the previous chapter, for your teams to get the benefits of Agile, your organization has to buy into the underlying Agile philosophy. Not just spending money—that’s comparatively easy—but making real, meaningful changes to organizational structures, systems, and behaviors.

If that sounds like a lot of work...well, that’s because it is. Are these investments really so important?

Yes. They really are.

Most of what holds teams back isn’t the processes they use; it’s the constraints they’re under.

Investing in Agile is important because you’re investing in changing your constraints. Most of what holds teams back isn’t the processes they use; it’s the constraints they’re under. Make the investments and ignore the practices, and your teams are still likely to improve. Perform the practices and ignore the investments? They’ll struggle.

As Martin Fowler said:1

1Excerpted from Fowler’s “Enterprise Rails” article.

I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck [creator of Extreme Programming]. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them...they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails, which really give the industry a jolt.

Martin Fowler

Make the investments. They’re the secret to Agile success.

The following sections describe the investments your teams need from your organization. You may not be able to get all of them, so I’ve provided alternatives. But the alternatives come at the cost of reduced effectiveness, so work hard to get as many as you can. I’ve included only the ones that are important. continue reading, buy the book!

In this Section

  1. Invest in Agility
    1. Sidebar: Summary of Investments
    2. Make Time for Learning
      1. If there’s no time for learning...
      2. If there’s no budget for help...
    3. Choose or Create Agile Teams
      1. If you can’t dedicate people to their teams...
      2. If team members don’t get along...
      3. If you can’t create long-lived teams...
      4. If you can’t get the business, customer, or user expertise you need...
      5. If you can’t get all the developer skills you need...
    4. Choose Agile Coaches
      1. If you can’t hire the coaches you need...
    5. Delegate Authority and Responsibility to Teams
      1. If work must be assigned to individuals...
      2. If tools don’t support team-based work...
      3. If teams have to use a corporate tracking tool...
      4. If teams don’t have access to stakeholders...
      5. If Delivering teams don’t have control over their release processes...
      6. If Optimizing teams don’t have control over their product plans and spending...
    6. Change Team Management Style
      1. If managers have trouble letting go...
    7. Create Team Rooms
      1. If a team is remote...
      2. If you can’t create a physical team room for an in-person team...
    8. Establish a Learning-Friendly Purpose for Each Team
      1. If there’s an important deadline...
      2. If there’s no valuable green-field work to do...
    9. Replace Waterfall Governance Assumptions
      1. If waterfall governance is required...
        1. Sidebar: Succeeding with Waterfall
    10. Change Harmful HR Policies
      1. If HR policies are set in stone...
    11. Address Security Concerns
      1. If there’s no flexibility around security requirements...
      2. If you’re required to have a separate code review step...
        1. Sidebar: Troubleshooting Guide

Discuss the book on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

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