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

January 21st: Pairing & Mobbing

Pair programming and its descendent, mob programming, are two of the strangest ideas to come out of Extreme Programming. They’re also surprisingly effective. In this session, we’ll be looking at them in depth. We’re joined by two of mob programming’s pioneers: Woody Zuill and Chris Lucian.

Woody Zuill is an Agile and Lean Software Development guide who has been programming computers for almost 40 years. He is an originator and pioneer of the Mob Programming approach to teamwork in software development, and a founder of the “No Estimates” discussion.

Chris Lucian is the director of software development at Hunder Industries, a founder of mob programming, co-host of the Mob Mentality show, and international keynote speaker. He’s passionate about the advancement of software craftsmanship and machine learning.

WhenJanuary 21st, 8-8:45am Pacific (calendar invite)
Where🎙 Zoom link
Reading 📖 Collective Code Ownership
📖 Pair Programming
📖 Mob Programming
Discussion🧑‍💻 Discord invite

Discussion prompts:

  • Pairing and mobbing are based on an underlying appreciation of collective code ownership—the idea that it’s good and desirable for the whole team to be responsible for all its code. How have you seen people respond to this idea, and how have you helped them accept it?

  • What tricks and tools do you use to make remote pairing and mobbing work well?

  • People often worry that pairing and mobbing won’t work for introverts. Although that fear is often overstated, what can teams do to make pairing and mobbing safe and enjoyable for everyone involved?

  • What are the tradeoffs between pairing and mobbing? Are there any situations where one is a better choice than the other?

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

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.

Mob Programming

Whole Team

We bring the insights of the whole team to bear.

In the early days of Extreme Programming, when pair programming first became popular, people used to mock it. “If pairing is good, why not triple!” they laughed. “Or just put the whole team in front of one computer!”

They were trying to put down XP, but the Agile way is to experiment, learn, and improve. Rather than assume something won’t work, we try an experiment. Some experiments work; some don’t. Either way, we share what we learn.

That’s what happened with mob programming. Woody Zuill had a group teaching technique he used for coding dojos. His team at Hunter Industries was in a bind. They decided to try Woody’s group technique on real-world work and put the whole team in front of one computer.

It worked, and worked well. Woody and the team shared what they learned. And now mob programming is used around the world.

In some parts of the world, the term “mob programming” has unpleasant connotations, so people call it ensemble programming instead. Woody Zuill’s original name for it was “Whole Team programming.” But, he says, “I have always said, I don’t care what it’s called. Learning to work well as a team is worthwhile and I invite people to call it what they will.”1

1Quoted from a conversation with Woody Zuill on Twitter.

How to Mob

Pair Programming

Mob programming is a variant of pair programming. Like pairing, it has a driver, who codes, and navigators, who provide direction. Unlike pairing, the whole team is present. While one person drives, the rest of the team navigates.

You’re welcome to try any approach to mobbing that you like. As Woody Zuill said, “There are no rules except the general guideline of ‘Let’s figure out how to turn up our ability to collaborate well.’”2 Experiment and find what works for you.

2Another excerpt of the Twitter conversation with Woody Zuill.

To get started, try Woody Zuill’s approach. It starts with the whole team present and ready to participate. Some people, such as on-site customers, may not be focused on the programming specifically, but they’re available to answer questions and they’re working on the same stories the programmers are.

On top of that base, layer on Llewellyn Falco’s strong-style pairing: all ideas must pass through somebody else’s fingers. [Falco2014] When it’s your turn to drive, your job is to act as a very clever input device. How clever, exactly, depends on your familiarity with the code and the editor. In some cases, a navigator might say, “Now handle error cases,” and the driver will test-drive four tests and the accompanying production code without further prompting. In other cases, a navigator might say, “Now extract the method,” and the driver will have to ask what to type. Customize the level of detail to each driver’s experience with the code and tools.

Finally, add a timer. Seven minutes is a good starting point. When the timer goes off, the driver stops. Another person takes over and work continues right where the previous driver left off. Rotate through everybody who’s interested in programming.

Why Mobbing Works

Mob programming is “easy mode” for collaboration.

Mob programming works because it’s “easy mode” for collaboration. So much of Agile centers around communication and collaboration. It’s the secret sauce that makes Agile more effective than other approaches. And mobbing makes a lot of the Agile collaboration practices irrelevant. They’re simply not needed when you mob.

Stand-up meetings? Gone. Collective code ownership? Automatic. Team room? A no-brainer. Task planning? Still useful, but kind of unnecessary.

When I first heard about mobbing, I poo-poo'd it. “I get the same benefits from having a cross-functional team, a team room, pairing, frequent pair switching, and good collaboration,” I said. And I was right. Mobbing doesn’t get you anything you don’t already get on a good team. But it’s so easy. Getting people to pair and collaborate well is hard. Mobbing? It’s practically automatic.

The Mobbing Station

If you have a physical team room, it’s pretty easy to set up a place for mobbing. You need a projector or big-screen TV (or several), tables for people to sit at, and a development workstation. Make sure everybody can sit comfortably, has access to laptops and whiteboards (for looking stuff up and discussing ideas), and has enough room to switch drivers easily. Some teams provide a mobbing station as well as pairing stations so people can switch back and forth as desired.

If your team is remote, set up a videoconference and have the driver share their screen. When it’s time to switch drivers, the previous driver pushes their code to a temporary branch and the next driver pulls it. A script such as the one found at https://mob.sh can help with this process. You might find that you need to set a longer timer—perhaps 10 minutes instead of 7—to reduce the amount of switching needed.

Making Mobbing Work

Mobbing is fun and easy, but it can still be tiring to work with the whole team day-in and day-out. Here are some things to consider:

Team dynamics
Team Dynamics

Pay attention to the interactions between team members and make sure everybody’s voices are being heard. Establish working agreements, make it safe for people to express disagreement and concerns, and pay attention to team dynamics. If there’s someone who tends to dominate, remind them to let others speak; if there’s someone who has trouble speaking up, ask for their opinion.

When you first start mobbing, it’s worth spending a few minutes at the end of each day for a very short retrospective. Focus on what worked well and how to do more of it. Woody Zuill calls this “turn up the good.”

Energized work
Energized Work

Mobbing isn’t supposed to wear you out, but it can be overwhelming to be constantly surrounded by the whole team. Take care of yourself. You don’t need to be “on” at every moment.

One of the advantages of mobbing is that it’s not dependent on any one person. People can drop in and out as needed. If you need a coffee break, or just want to clear your head, step away. Similarly, if you need to check your email or make a phone call, you can do that. The mob will continue on without you. You don’t have to align your work hours, either.

Spike Solutions

All changes to the production code go through the driver, but you can still use your computer when you aren’t driving. If you need to look up an API call, or have a side discussion about a design idea at the whiteboard, or create a spike solution, you can do that.

Strict navigator role

When you start mobbing, your team might have so many people shouting ideas that the driver has trouble understanding what to do. In this case, rather than having the whole team act as navigators, you can appoint one person to be navigator. This role rotates just like the driver role does. (I like to have the driver become the next navigator.) Their job is to condense the ideas of the mob into specific directions for the navigator. The driver has to listen to only the navigator, not the whole mob.


Everybody in the mob can be a driver, even people who don’t know how to program. This can be an exciting opportunity for non-programmers to develop new skills. They may not become experts, but they’ll learn enough to contribute, and learning to drive could improve their ability to collaborate with programmers.

Remember to guide your driver at the level they’re capable of following. For non-programmers, this may require providing direction at the level of specific keyboard shortcuts, menu items, and mouse clicks, at first.

But nobody is required to be a driver. Some people on the team may find that their time is better spent helping the mob in other ways. A tester and a domain expert might have a side conversation about customer examples related to the current story. A product manager may step out to conduct an interview with an important stakeholder. An interaction designer may work on user personas.

As with anything else, experiment with varying people’s level of involvement to find what works best for your team. But start by trying more involvement, rather than less. People often underestimate the power of working as a team. That conversation about customer examples, or stakeholder interview, or user persona work could be something that the mob learns from doing together.

Mini-mobs and part-time mobs
Task Planning
Stand-Up Meetings

You don’t have to choose between pairing or mobbing. (Although I do recommend doing one or the other for all code you have to maintain.) You can mob part-time and pair the rest of the time. Or you can form a “mini-mob” of three or four people while the rest of the team pairs.

If you don’t mob full-time, be sure to keep other team coordination mechanisms, such as the task board and stand-up meetings, at least to start. The mobbing sessions may allow you to keep in sync without them, but make sure that’s true before removing them.


Is mobbing really more effective than working alone or in pairs?

For new teams, almost certainly. Teams’ effectiveness depends on how well they know the code and one another, and mobbing excels at this sort of learning. This is why I recommend that teams start with mobbing. (See the “Your First Week” section.)

For established teams, in my experience, pairing is more effective than working alone. Is mobbing even more effective than pairing? For teams with a good team room and great collaboration, maybe not. For other teams, it probably is. There are too many variables to say for sure, so try it and find out.

We’re having trouble remembering to switch drivers. What should we do?

If people are ignoring your timer, try using a tool such as Mobster (available at http://mobster.cc). When the time is up, it blanks the screen so the driver has to stop.


Mobbing requires permission from the team and management. Other than that, the only requirement is a comfortable work environment and appropriate mobbing setup.


When your team mobs well:

  • The whole team directs its entire effort toward one story at a time, finishing work with minimal delays and wait time.

  • The team collaborates well and enjoys working together.

  • Internal quality improves.

  • When a tough problem arises, the mob solves it while the driver continues moving forward.

  • Decisions are made quickly and effectively.

Alternatives and Experiments

Pair Programming
Collective Code Ownership
Task Planning
Stand-Up Meetings

“All the brilliant minds, in the same place, at the same time, working on the same thing.” That’s the core idea of mob programming. Beyond that, the details are up to you. Start with the basic structure described here, then think about something to improve every day.

If mobbing isn’t a good fit, the best alternative is pair programming. Pairing doesn’t have the same automatic collaboration that mobbing does, so you’ll need to put more effort into collective ownership, task planning, and stand-up meetings.

Further Reading

Woody Zuill and Kevin Meadows’ Mob Programming: A Whole Team Approach [Zuill2021] is an in-depth look at the how’s and why’s of mobbing.

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 Practice: Pair Programming

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.

Pair Programming

Developers, Whole Team

We help each other succeed.

Do you want somebody to watch over your shoulder all day? Do you want to waste half your time sitting in sullen silence watching somebody else code?

Of course not. Luckily, that’s not how pair programming works.

Pair programming involves two people working at the same computer, at the same time, on the same thing. It’s one of the most controversial Agile ideas. Two people working at the same computer? It’s weird. It’s also extremely powerful and, once you get used to it, tons of fun. Most programmers I know who tried pairing for a month found that they preferred it to programming alone.

Collective Code Ownership

More importantly, pair programming is one of the most effective ways to achieve collective code ownership and truly collaborate on code as a team.

Why Pair?

There’s more to pairing than sharing knowledge. Pairing also improves the quality of your results. That’s because pair programming doubles your brainpower.

When you pair, one person is the driver. Their job is to code. The other person is the navigator. Their job is to think. As navigator, sometimes you think about what the driver is typing. (Don’t rush to point out missing semicolons, though. That’s annoying.) Sometimes you think about what comes next. Sometimes you think about how your work best fits into the overall design.

This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator produce higher-quality work, more quickly, than either could produce on their own.1

1One study found that pairing takes about 15% more effort than one individual working alone, but produces results more quickly and with 15% fewer defects. [Cockburn2001] Every team is different, so take these results with a grain of salt.

Pairing also reinforces good programming skills. Delivering practices take a lot of self-discipline. When pairing, you’ll have positive peer pressure to do the things that need to be done. You’ll also spread coding knowledge and tips throughout the team.

Surprisingly, you’ll also spend more time in flow—that highly productive state in which you’re totally focused on the code. It’s a different kind of flow than when you’re working alone, but it’s far more resilient to interruptions. To start with, you’ll discover that your office mates are far less likely to interrupt you when you’re working with someone. When they do, one member of the pair will handle the interruption while the other continues working. Further, you’ll find that background noise is less distracting: your conversation with your pairing partner will keep you focused.

If that isn’t enough, pairing really is a lot of fun. The added brainpower will help you get past roadblocks more easily. For the most part, you’ll be collaborating with smart, like-minded people. Plus, if your wrists get sore, you can hand off the keyboard to your partner and continue to be productive.

Pairing Stations

To enjoy pair programming, a good workspace is essential, whether your team is in-person or remote. For in-person teams, make sure you have plenty of room for both people to sit side by side. Typical cubicles, with a monitor located in a corner, won’t work. They’re uncomfortable and require one person to sit behind the other, adding psychological as well as physical barriers to what’s meant to be peer collaboration.

You don’t need fancy furniture to make a good pairing station. A simple table will do. It should be six feet wide, so two people can sit comfortably side by side. Each table needs a high-powered development workstation. Plug in two keyboards and mice so each person can have a set. If people have a preferred mouse and keyboard, they can bring it with them. Make sure the USB ports are easily accessible in this case.

Splurge on large monitors so both people can see clearly. Be sure to respect differences in people’s vision needs, particularly with regards to font sizes and colors. Some teams set up three monitors, with the two outer monitors mirrored, so each person can see the code on a monitor in front of them, while using the middle display for additional material. If you do this, try installing a utility that makes the mouse wrap around the edges of your desktop. It will let both programmers reach the center screen easily.

If your team is remote, you’ll need a collaborative code editor and a videoconference. Make sure you have multiple screens, so you can see each other and the code at the same time.

There are a variety of IDE add-ins and standalone tools for collaborative editing, such as CodeTogether, Tuple, Floobits, and Visual Studio’s Live Share. You can also share your screen in your videoconferencing tool, but a collaborative code editor will allow you to switch drivers much more easily. If you have to use screen-sharing, though, you can hand off control by pushing the code to a temporary work-in-progress branch. Write a little script to automate the process.

Jeff Langr has a good rundown of remote code collaboration options in [Langr2020].

How to Pair

I recommend pairing on all production code. Teams who pair frequently, but not exclusively, say they find more defects in solo code. That matches pair programming studies, such as [Cockburn2001], that find that pairs produce higher-quality code. A good rule of thumb is to pair on anything that you need to maintain, which includes tests and automation.

When you start working on a task, ask another programmer to work with you. If someone else asks for help, make yourself available. Managers should never assign partners: pairs are fluid, forming naturally and shifting throughout the day. Over the course of the week, pair with every developer on the team. This will improve team cohesion and spread skills and knowledge throughout the team.

Get a fresh perspective by switching partners.

When you need a fresh perspective, switch partners. I usually switch when I’m feeling frustrated or stuck. Have one person stay on task and bring the new partner up to speed. Often, even explaining a problem to someone new will help you resolve it.

It’s a good idea to switch partners several times per day even if you don’t feel stuck. This will help keep everyone informed and moving quickly. I switch whenever I finish a task. If I’m working on a big task, I switch within four hours.

Some teams switch partners at strictly defined intervals. [Belshee2005] reports interesting results from switching every 90 minutes. While this could be a great way to get in the habit of switching pairs, make sure everybody is willing to try it.

When you sit down to pair, make sure you’re physically comfortable. If you’re colocated, position your chairs side by side, allowing for each other’s personal space, and make sure the monitor is clearly visible. When you’re driving, place the keyboard directly in front of you. Keep an eye out for this one—for some reason, people new to pairing tend to contort themselves to reach the keyboard and mouse rather than moving them closer.

Take a moment to check in with your partner about each other’s preferences, too. When driving, do you want your navigator to give you time to think things through on your own? Or would you rather that they keep on top of things so you never have to stop and think? When navigating, do you want your driver to verbalize what they’re thinking, so you understand where they’re going? Or do you want to be able to concentrate on what’s next? Do you want strict separation of driver and navigator roles? Or a casual, informal approach?

Expect to feel clumsy and fumble-fingered, at first, when it’s your turn to drive. You may feel that your navigator sees ideas and problems much more quickly than you do. They do—navigators have more time to think than drivers do. The situation will be reversed when you navigate. Pairing will feel natural in time.

Test-Driven Development

Pairs produce code through conversation. As you work, think out loud. Take small steps—test-driven development works well—and talk about your assumptions, short-term goals, general direction, and any relevant history. If you’re confused about something, ask questions. The discussion may enlighten your partner as much as you.

As you pair, switch the driver and navigator roles frequently—at least every half hour, and possibly every few minutes. If you’re navigating and find yourself telling the driver which keys to press, ask for the keyboard. If you’re driving and need a break, pass the keyboard off to your navigator.

Energized Work

Expect to feel tired at the end of the day. Pairs typically feel that they have worked harder and accomplished more together than when working alone. Practice energized work to maintain your ability to pair every day.

Effective Navigating

When navigating, you may feel like you want to step in and take the keyboard away from your partner. Be patient. Your driver will often communicate an idea with both words and code. They’ll make typos and little mistakes—give them time to correct themselves. Use your extra time to think about the bigger picture. What other tests do you need to write? How does this code fit into the rest of the system? Is there duplication you want to remove? Can the code be more clear? Can the overall design be better? Is there friction that should be polished away?

Pay attention to your driver’s needs, too. Somebody’s who’s unfamiliar with the IDE or codebase may need specific guidance. But resist the urge to micromanage. Give them room to figure out things on their own, if that’s what they prefer.

As navigator, your role is to help your driver be more productive. Think about what’s going to happen next and be prepared with suggestions. When I’m navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of something, I write my ideas on the index card and wait for a break in the action to bring them up. At the end of the pairing session, I tear up the card and throw it away.

Spike Solutions

Similarly, when a question arises, take a moment to look up the answer while the driver continues to work. Some teams keep spare laptops on hand for this purpose. If you need more than a few minutes, pause coding to research the solution together. Sometimes the best way to do this is to split up, pursue parallel lines of inquiry, and come back together to share what you’ve learned. Spike solutions are a particularly powerful approach.

Although the navigator generally has more time to think than the driver, that doesn’t mean the driver is a mindless automaton. They’ll have design ideas too. Encourage your driver to share their thoughts, and when they have a design idea for later, offer to make a note. Also, if you get to a tricky design question, it’s okay to stop coding, grab a whiteboard, and spend some time working through ideas together.

Teaching Through Pairing

Although pairing works best as a peer collaboration, sometimes people with different levels of experience will work together. In this situation, it’s important to restore the peer balance. Highlight the skills each person is bringing to the table. Even if one person needs to teach the other about the code, treat it as a lack of knowledge that’s easily rectified, not a lack of ability on the part of the learner, or sign of superiority on the part of the teacher.

The goal is to maximize the team’s performance.

If you need to bring your partner up to speed on some part of the code, remember to be patient. Teaching your pair partner how the code works slows you down, but the goal isn’t to maximize your performance...it’s to maximize the team’s performance. A good developer works quickly and well, but the best developers help everyone do so.

To use pairing to teach someone about the code, start by letting them drive. That will allow them to control the pace. As you guide them, refrain from telling them exactly what to do. Instead, provide big-picture direction—maybe even start with a whiteboard diagram—and give them space to figure out the details.

For example, when making changes to a service, don’t say, “We need to change SuperMailClient. Click source...now click infrastructure...now click rest...” Instead, provide context and direction: “Our task is to replace our transactional mail vendor, SuperMail, with BetterMail. They both provide REST APIs, so all we need to do is change our SuperMail wrapper to use BetterMail instead. (Sketches the project structure on the whiteboard.) All our REST clients are in the infrastructure/rest folder and each service has its own wrapper.” Then let your partner navigate through the project files and find the file to work on themselves.

Once the person you’re teaching can find their way around, you can switch roles. Ask them to navigate and tell you what needs to be done next. Be careful, though: when you’re driving, it’s tempting to rush ahead and just do what you know needs to be done. For it to work as a teaching technique, you have to suppress that desire and let your partner set the pace.


Pairing can feel awkward or unpleasant at first. These feelings are natural and typically go away after a month or two. Here are some common challenges and how to resolve them:


It bears repeating: pairing is no fun if you’re uncomfortable. When you sit down to pair, adjust your position and equipment so you can sit comfortably. Clear debris off the desk and make sure there’s room for your legs, feet, and knees. Check in with your partner about font sizes and monitor position. If you’re pairing remotely, take time before you begin to make sure all your tooling is set up and frictionless.

Some people (like me) need a lot of personal space. Others like to get up close and personal. When you start to pair, discuss your personal space needs and ask about your partner’s.

Similarly, while it goes without saying that personal hygiene is essential, remember that strong flavors such as coffee, garlic, onions, and spicy foods can lead to foul breath.

Introversion and social anxiety

Introverts often worry pairing won’t work for them, but—as an introvert myself—I haven’t found that to be true in practice. Although pairing can be tiring, it’s also very focused on ideas and results. There’s no need to engage in small talk, and you’re typically working with people whom you know well and respect. It’s a very productive, very cerebral collaboration, and that can be a lot of fun. Most introverts I’ve met who have tried pairing have liked it, once they got past the initial learning curve.


Of course, people don’t fit neatly into predefined personality trait boxes. Pairing—and Agile in general—can be difficult for people with social anxiety. If you think pairing might be difficult for you or someone on your team, talk about ways to make pairing more comfortable, or if there are other ways your team can achieve collective code ownership. The alignment session is a good time for this conversation.

Communication style

New drivers sometimes have difficulty involving their partners; they take over the keyboard and shut down communication. To practice communicating and switching roles while pairing, consider ping-pong pairing. In this exercise, one person writes a test. The other person makes it pass and writes a new test. Then the first person makes it pass and repeats the process by writing another test.

Another approach to try is strong-style pairing. In strong-style pairing, invented by Llewellyn Falco, all ideas must pass through the other person’s fingers. [Falco2014] So if you come up with an idea, you have to pass the keyboard to the other person and tell them how to implement it. Then when they come up with an idea, they pass the keyboard back to you and tell you what to do. Even if this isn’t something you want to do all the time, it’s a great way to practice communicating with your partner.

The flip side of too little communication is too much communication—or rather, too much blunt communication. Frank criticism of code and design is valuable, but it may be difficult to appreciate at first. Different people have different thresholds, so pay attention to how your partner receives your comments. Try transforming declarations (such as “This method is too long”) into questions or suggestions (“Could we make this method shorter?” or “Should we extract this code block into a new method?”). Adopt an attitude of collaborative problem solving. See the “Learn How to Give and Receive Feedback” section for more ideas.

Tools and keybindings

Even if you don’t fall victim to the endless vi versus emacs editor war, you may find your coworkers’ tool preferences annoying. Try to standardize on a particular toolset. Some teams even create a standard image and check it into version control. When you discuss working agreements during your alignment discussion, discuss these issues as well.

Keyboards and mice can be another source of contention. If they are, you don’t have to standardize. People with strong input device preferences can take their devices with them when they switch pairing stations. Just make sure they have easily accessible USB ports.


Isn’t it wasteful to have two people do the work of one?

In pair programming, two people aren’t really doing the work of one. Although only one keyboard is in use at a time, there’s more to programming than typing. One person is programming and the other is thinking ahead, anticipating problems, and strategizing.

How can I convince my team or organization to try pair programming?

Ask permission to try it as an experiment. Set aside a month in which everyone pairs on all production code. Be sure to keep going for the entire month, as pair programming may be uncomfortable for the first few weeks.

Don’t just ask permission of management; get the consent of your fellow team members, too. They don’t have to love the idea, but do make sure they’re not opposed to it.

Do we really have to pair program all the time? Some code doesn’t need it.

If you’re bored while pairing, it’s an indication of a design flaw.

Some production tasks are so repetitive, they don’t require the extra brainpower a pair provides. Before abandoning pairing, however, consider why your design requires so much repetition. It’s a common indication of a design flaw. Use the navigator’s extra time to think about design improvements and consider discussing it with your whole team.

How can I concentrate with someone talking to me?

When you navigate, you shouldn’t have too much trouble staying several steps ahead of your driver. If you do have trouble, ask your driver to think out loud so you can understand their thought process, or ask to drive so you can control the pace.

As driver, you may sometimes find that you’re having trouble solving a problem. Let your navigator know—they may have a suggestion that will help you through the roadblock. At other times, you may just need a few moments of silence to think through the problem. It’s okay to say so.

Test-Driven Development
Spike Solutions

If you find yourself in this situation a lot, you may be taking steps that are too large. Use test-driven development and take very small steps. Rely on your navigator to keep track of what you still need to do (tell them if you have an idea; they’ll write it down) and focus only on the few lines of code needed to make the next test pass.

Mob Programming
Blind Spot Discovery
Zero Friction

If you’re working with a technology you don’t completely understand, consider taking a few minutes to work on a spike solution. You and your partner can work on this together or separately.

What if we have an odd number of programmers?

If your team room includes a mobbing station, you can form a “mini-mob” of three people. Otherwise, there are many ways for a programmer flying solo to be productive without touching production code. They can research new technologies or learn more about a technology the team is using. They can pair with a customer or tester to review recent changes, polish the application, or do exploratory testing. They can take care of administrative tasks for the team, such as responding to team emails.

Alternatively, a solo programmer may wish to improve the team’s capacity. They can research solutions to friction the team is experiencing, such as slow builds, flaky tests, or unreliable deployment pipelines. They can review the overall design—either to improve their own understanding or to come up with ideas for improving problem areas. If a large refactoring is partially complete, the team may wish to authorize a conscientious programmer to finish those refactorings.


Pairing requires a comfortable work environment. Most offices just aren’t set up that way. Before trying pairing full-time, adjust your physical space. If your team is remote, get your tooling in place.

Make sure everyone wants to participate before you try pairing. Pairing is a big change to programmers’ work styles and you may encounter resistance. I usually work around this by asking people to try it for a month or two, then decide. If that doesn’t work, you can try pairing part-time, or with just the people who are interested, although I find that pairing works best when the whole team does it full-time.

Mob Programming

Mob programming tends to be less intimidating than pairing. If people don’t want to try pairing, see if they’d like to try mobbing instead.


When your team pairs well:

  • You’re focused and engaged throughout the day.

  • You enjoy the camaraderie of working with your teammates.

  • At the end of the day, you feel tired and satisfied.

  • For small interruptions, one person deals with the problem while the other continues working. Afterward, they slide back into the flow of work immediately.

  • Internal quality improves.

  • Knowledge and coding tips travel quickly through the team, raising everyone’s level of competence.

  • New team members integrate into the team quickly and easily.

Alternatives and Experiments

Pairing is a very powerful tool. Other than mobbing, I’m not aware of any other technique that’s as effective. Give pairing (or mobbing) a real try before experimenting with alternatives.

When you look at alternatives, don’t make the mistake of thinking that pairing is just a fancy type of code review. To truly replace pairing, you need to replace all these benefits:

Collective Code Ownership

Code quality. Because pairing brings so many perspectives to the code, and results in so much conversation about the code, it reduces defects and improves design quality. The frequent pair switching shares knowledge among team members, which enhances collective code ownership. By having people work together, it helps people focus, supports self-discipline, and reduces distractions. It does all this without sacrificing productivity.

Formal code reviews can also reduce defects, improve quality, and support self-discipline. In a sense, pairing is just continuous code review. Code reviews don’t share knowledge as thoroughly as pairing, though, so if you’re using collective code ownership, you probably need to supplement code reviews with additional design discussions.

Flow. Pairing’s benefits to flow are more subtle. Because it focuses two people on the same problem, pairing is sort of like having a backup brain. If one person gets distracted, the other person can “reboot” their attention and get them back on track quickly. It’s also easier to ignore the ever-present distractions provided by smartphones, email, instant messaging, and the other demands on our attention. In an environment without pairing, you’ll need another way to help people stay focused.

Collaboration. Pairing’s resilience to distractions makes intra-team collaboration easier. Ideally, when one team member gets stuck on a question that another team member can answer, you want them to ask for help rather than spinning their wheels. If you’re pairing, there’s very little cost to answering a question because your pairing partner keeps working. It makes sense to ask for help anytime you need help.

If you aren’t pairing, interruptions are much more costly. Now you have to decide whether the time saved by asking the question is worth the disruption to someone else’s flow. In practice, there’s far less collaboration on a team that doesn’t pair.

Noise cancellation with situational awareness. Pair programming has another benefit that’s even less obvious. In a physical team room, pairing creates a low buzz of conversation. You might expect this to be distracting, but it actually recedes into the background as your brain focuses on your interaction with your partner. But the background conversation still enhances your situational awareness. It’s the cocktail-party effect: when somebody says something important to you, your subconscious picks it out of the background and brings it to your conscious attention.

For teams that don’t pair, side conversations are distracting and can make it hard to concentrate. In that situation, independent offices or cubicles—or headphones—can be better. But now you don’t have the same situational awareness.

In other words, pairing has a lot of unobvious benefits that reinforce other Agile practices. Although it’s definitely weird, and can be a lot to ask, it’s worth putting in the effort to give it a real try. Don’t just dismiss it out of hand. If pairing isn’t a good fit, try mobbing instead.

Further Reading

Birgitta Böckeler and Nina Siessegger’s “On Pair Programming” [Bockeler2020] is a nice online article that goes into more depth about pairing.

“Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” [Belshee2005] is an intriguing look at the benefits of switching pairs at strict intervals.

“Adventures in Promiscuous Pairing: Seeking Beginner’s Mind” [Lacey2006] explores the costs and challenges of promiscuous pairing. It‘s a must-read if you plan to try Belshee’s approach.

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 Practice: Collective Code Ownership

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.

Collective Code Ownership


We are all responsible for all our code.

Agile teams collectively own their work, as described in the “Key Idea: Collective Ownership” sidebar. But how does that apply to code?

Collective code ownership means the team shares responsibility for its code. Rather than assigning modules, classes, or stories to specific individuals, the team owns it all. It’s the right and responsibility to make improvements to any aspect of your team’s code at any time.

Fix problems no matter where you find them.

In fact, improved code quality is one of the hidden benefits of collective code ownership. Collective ownership allows—no, expects—everyone to fix the problems they find. If you encounter duplication, unclear names, poor automation, or even poorly designed code, it doesn’t matter who wrote it. It’s your code. Fix it!

Making Collective Ownership Work

Mob Programming
Task Planning

Collective code ownership requires careful coordination around design and planning. If you’re using mob programming, that coordination comes for free. Otherwise, your task planning meeting is a good time to start the discussion. When you discuss how to break down tasks, talk about your design. Write tasks in terms of how your design will change: “Add endpoint to UserReportController.” “Update ContactRecord.” “Add columns to GdprConsent database table.”

When you’re ready for a new task, you can pick up any task from the planning board. In many cases, you’ll just take the next one off the list, but it’s okay to jump ahead a bit to choose a task that you’re interested in or particularly well-suited for.

Done Done

In an ideal world, your team will swarm each story: everyone will choose tasks for the same story and focus on getting the story “done done” before moving on to the next. This minimizes work in progress (see the “Key Idea: Minimize Work in Progress” sidebar) and exposes risks early.

Don’t jump ahead to another story just because you don’t know how to coordinate.

In practice, it’s okay for people to jump ahead to the next story when the current one is close to completion. Just be careful: when you’re new to collective ownership, it’s going to be easy to accidentally end up with everyone taking de facto ownership of separate stories rather than truly working together. Don’t jump ahead to another story just because you don’t know how to coordinate.

When you pick up a task that’s closely related to another person or pair’s, have a quick discussion with them. Perhaps they’ve grabbed a frontend task and you’ve grabbed the corresponding backend task. Take a moment to get on the same page about the API. One or both of you can stub in the API with do-nothing code, then one of you can be responsible for filling it in. Whoever commits their code second is responsible for double-checking that it works together.

Pair Programming

As you work on the code, you’ll come up with ideas that affect other people’s work. Pairing will help them spread around the team. You can also use the daily stand-up to summarize new ideas. If you’re not using pairing or mobbing, you might need to add a daily design review.

Some ideas warrant immediate discussion. In a physical team room, just stand up and announce what you want to talk about. People will come join you. In a remote team room, announce the topic in your group chat, and invite people to join you in a videoconference. The “Drop in and Drop Out” section has more details.

Egoless Programming

Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team’s code. Rather than complaining when someone modifies code you wrote, enjoy how the code improves when you’re not working on it. Rather than pushing your personal design vision, discuss design possibilities with your teammates and agree on a shared solution.

Collective ownership also requires a joint commitment from team members to produce good code. When you see a problem, fix it. When writing new code, don’t assume somebody else will fix your mistakes. Write the best code you can.

On the other hand, collective ownership also means you don’t have to be perfect. If your code works and you’re not sure how to make it better, don’t hesitate to let it go. Someone else will improve it later, if and when the code needs it.

Always leave the code a little better than you found it.

Conversely, when you’re working in “someone else’s” code (but it’s not someone else’s—it’s yours!), avoid the temptation to make personal judgments about them based on their code. But do always leave the code a little better than you found it. If you see an opportunity for improvement, don’t be shy. You don’t need to ask permission. Do it!

Collaborating Without Conflict

At first, collective code ownership is an opportunity for conflict. All the little annoyances about your colleagues’ work styles are double-underlined with a bright purple highlighter. This is a good thing—really!—because it gives you a chance to align your style. But it can be frustrating at first.

Mob Programming
Team Dynamics

To help the process go more smoothly, decide on important coding, design, and architectural standards as part of your alignment chartering session. When you first adopt collective code ownership, try mob programming for a week or two so you can hash out important differences. Bring up areas of disagreement in your retrospectives and come up with plans for resolving them. Pay attention to team dynamics.

Stand-Up Meetings
Task Planning
Pair Programming
Continuous Integration

If you don’t use mob programming, you’ll need a way to avoid stepping on each other's toes during day-to-day work. Daily stand-up meetings are a good way to coordinate, as long as they’re kept brief and focused. The task planning board will help maintain your situational awareness, especially if it’s visible from where you sit.

Pair programming will help you keep up with everyone’s changes. Your partner will often be aware of changes you aren’t, and vice versa. When they aren’t, pair programming makes it easier to ask another pair for help. People who are pairing can take brief interruptions without disturbing their progress—one person just keeps going while their partner deals with the interruption.

In fact, make a point of encouraging people to ask for help when they’re stuck. There’s no point in somebody banging their head against a wall for 30 minutes if somebody else on the team already knows the answer.

Finally, continuous integration will prevent painful merge conflicts and keep everyone’s code in sync.

Working with Unfamiliar Code

If you’re working on a project that has knowledge silos—pockets of code that only one or two people understand—then collective code ownership might seem daunting. How can you take ownership of code that you don’t understand?

Mob programming may be your best choice, at least to start. It will help the whole team share their knowledge with one another quickly. If that’s not to your taste, pair programming also works.

To use pairing to expand your knowledge, volunteer to work on tasks that you don’t understand. Ask somebody who knows that part of the system to pair with you. While pairing, resist the temptation to sit back and watch. Instead, take the keyboard and ask them to guide you. Use your control of the keyboard to control the pace: ask questions and make sure you understand what you’re being asked to do. The “Teaching Through Pairing” section has more.

If nobody understands the code, exercise your inference skills. You don’t need to know exactly what’s happening in every line. In a well-designed system, all you need to know is what each package, namespace, or folder is responsible for. Then you can infer high-level class responsibilities and method behaviors from their names. The “Reverse-Engineering the Design” section goes into more detail.

Test-Driven Development

Well-written tests also act as documentation and a safety net. Skim the test names to get an idea of what the corresponding production code is responsible for. If you’re not sure how something works, change it anyway and see what the tests say. An effective test suite will tell you when your assumptions are wrong.

As you learn, refactor the code to reflect your improved understanding. Fix confusing names and extract variables and functions. This will codify your understanding and help the next person, too. Arlo Belshee’s “Naming as a Process” technique [Belshee2019] is a nice formalization of this approach.

If you’re working with poorly designed code that nobody understands and that doesn’t have any tests, all is not lost. You can use characterization tests to refactor safely. See the “Adding Tests to Existing Code” section for details.

Benefits to Programmers

Of course nobody can understand it...it’s job security!

Old programmer joke

Collective ownership makes a lot of sense for an organization. It reduces risk, improves cycle time, and improves quality by bringing more minds to bear on the code. But does it make sense for programmers? Won’t collective ownership make it more difficult for your contributions to be recognized?

Honestly...it could. As discussed in the “Change Harmful HR Policies” section, Agile requires that your organization recognize and value team contributions more than individual heroics. If that’s not true for your organization, collective code ownership might not be a good fit.

Even if your organization values teamwork, it’s not easy to let a great piece of code out of your hands. It can be difficult to subsume the desire to take credit for a particularly clever or elegant solution.

But it is good for you as a programmer. Why? The whole codebase is yours—not just to modify, but to support and improve. You get to expand your technical skills. You’ll learn new design and coding techniques from working with other team members. When teaching people about your area of expertise, you get to practice your mentoring skills, too.

You don’t have to carry the maintenance burden for every piece of code you write, either. The whole team has your back. Over time, they’ll know your code as well as you do, and you’ll be able to go on vacation without being called with questions or emergencies.

It’s a little scary, at first, to come into work and not know exactly which part of the system you’ll work on, but it’s also freeing. You no longer have long subprojects lingering overnight or over the weekend. You get variety and challenge and change. Try it—you’ll like it.


We have a really good frontend developer/database programmer/scalability guru. Why not take advantage of their skills?

Please do! Collective code ownership means everybody contributes to every part of the system, but you’ll still need experts to lead the way.

How can everyone learn the entire codebase?

People naturally gravitate to one part of the system or another. They become expert in particular areas. Everyone gains a general understanding of the overall codebase, but they don’t know every detail.

Simple Design
Test-Driven Development
Pair Programming
Mob Programming

Several practices enable this approach to work. Simple design and its focus on code clarity make it easier to understand unfamiliar code. Tests act as a safety net and documentation. Pairing and mobbing allow you to work with people who have the details you don’t.

Different programmers on our team are responsible for different products. Should the team collectively own all these products?

If you’ve combined programmers onto a single team, then yes, the whole team should take responsibility for all of their code. If you have multiple teams, then they may or may not share ownership across teams, depending on how you approach scaling. See the “Scaling Agility” chapter for details.


Team Room
Task Planning
Stand-Up Meetings
Mob Programming
Pair Programming
Continuous Integration
Simple Design
Test-Driven Development

Collective code ownership is socially difficult. Some organizations have trouble letting go of individual rewards and accountability. Some programmers have trouble letting go of taking individual credit, or refuse to use certain programming languages. For these reasons, it’s important to talk with managers and team members about collective code ownership before trying it. These concerns should be part of your initial discussions about whether or not to try Agile (see the “Invest in Change” chapter) and brought up again during your alignment session.

Safety is critical. If team members don’t feel safe expressing and receiving criticism, or if they fear being attacked when they raise ideas or concerns, they won’t be able to share ownership of code. Instead, little fiefdoms will pop up. “Don’t change that code yet. You should talk to Antony first to make sure he’s okay with it.”

Collective ownership also requires good communication. You’ll need a team room, either physical or virtual, where people communicate fluidly. Use task planning and your task board to help people understand the work and stand-up meetings to coordinate it.

You need a way to ensure knowledge about changes spread throughout the team. Because anybody can make any change at any time, it’s easy to feel lost. Mob programming or pair programming are the easiest ways to do this. If those aren’t an option, you’ll need to put extra effort into communicating about changes. Code reviews aren’t likely to be enough. Most people instinctively migrate to documentation as a solution, but it’s costly, as the “Key Idea: Face-to-Face Conversation” sidebar discusses. Try lighter-weight solutions first. One option is to hold a 30-minute “design recap” every day to discuss new ideas and recent changes.

Because collective code ownership increases the likelihood that people will touch the same code, you need to minimize the likelihood of painful merge conflicts. Continuous integration is the best option. For new codebases, merge conflicts are more likely because there’s so little code. Mob programming can be a good way to bootstrap the codebase even if it’s not something you plan to use long-term.

Although they’re not strictly necessary, simple design and test-driven development are a good idea for teams using collective code ownership. They make the code easier to understand and change.

Despite this long list of prerequisites, collective code ownership is easy to practice once the necessary conditions are in place. All you need is a shared team agreement that everyone can and should work in any part of the code, seeking out and providing assistance as needed. You don’t need everybody to know every part of the code; team members just need to be able to ask for help when working in an unfamiliar part of the code, and to be generous in providing help in return.


When your team practices collective code ownership well:

  • Everyone on the team constantly makes minor improvements to all parts of the code.

  • Nobody complains about team members changing code without asking permission first.

  • When you come back to code you originally wrote, you find that it improved without your involvement.

  • When a team member leaves or takes a vacation, the rest of the team handles their work without interruption.

Alternatives and Experiments

The main alternatives to collective code ownership are weak code ownership and strong code ownership. In weak code ownership, people can change any part of the code, but particular developers are responsible for ensuring their quality, and it’s polite to coordinate changes with them. In strong code ownership, all changes must go through the owner.

Both of these approaches detract from Agile’s emphasis on teamwork, although weak code ownership isn’t as bad as strong code ownership. It can be useful for teams that don’t use pairing or mobbing, or who have trouble leaving code better than they found it.

But try to use collective code ownership, if you can. Collective ownership is one of those Agile ideas that’s often overlooked, but is actually essential. It doesn’t always mean collective code ownership, but I think it’s an important part of the equation. Although it may be possible to have a fluent Delivering team without collective code ownership, I have yet to see it. Stick with this practice until you have a lot of experience as a fluent Delivering team.

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


In addition to the teamwork expected of any Agile team (see the “Teamwork” chapter), Delivering teams also have high standards of technical excellence and collaboration. They’re expected to work together to keep internal quality high and deliver their most important business priority.

These practices will help your team collaborate:

  • The “Collective Code Ownership” practice encourages team members to improve each other's code.

  • The “Pair Programming” practice cross-pollinates ideas and helps team members understand each other’s work.

  • The “Mob Programming” practice gets your whole team working together.

  • The “Ubiquitous Language” practice helps team members understand one another.

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 III: Delivering Reliably (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.

Delivering Reliably

It’s October again. Over the past year (see Part II), your team has been working hard at developing its Delivering fluency, and now you’re a well-oiled machine. You’ve never enjoyed your work more: the little annoyances and friction you associate with professional software development—broken builds, frustrating bug hunts, painstaking change analysis—have all melted away. Now you can start a task and have it in production a few hours later.

Your only regret is that your team didn’t pursue Delivering fluency from the beginning. In retrospect, it would have been faster and easier, but people wanted to take it slow. Oh, well. Now you know.

As you enter the team room, you see Valeri and Bo working together at a pairing station. They both like to come in early to beat rush-hour traffic. Valeri sees you putting away your backpack and catches your attention.

“Are you available to pair this morning?” she asks. She’s never been one for chit-chat. “Bo and I have been working on the real-time updates and he said you might have some ideas about how to test the networking code.”

You nod. “Duncan and I spiked it yesterday and came up with something promising. Do you want to pair, or should the three of us mini-mob?”

“You can pair with Valeri,” Bo calls over, getting up and stretching. “I need a break from networking code.” He mock-shudders. “Even CSS is better than this.” Valeri rolls her eyes and shakes her head. “I’ll let you get settled in,” she says to you. “I need more coffee.”

Half an hour later, you and Valeri are making good progress on the networking code. A steady series of soft chimes comes from the workstation. Every time you save your changes, a watch script runs your tests, then chimes a second later to indicate if the tests passed or failed.

You’ve gotten into a steady rhythm. At the moment, you’re driving and Valeri is navigating. “Okay, now let’s make sure it throws an error when the message is empty,” she says. You add a test. Dong. The test fails. Without a pause, you switch to the production code, add an `if` statement, and save. Ding! The test passes. “Now when the message is corrupted,” Valeri says. You add a line to the test. Dong. Another `if` statement. Ding! “Okay, I’ve got some notes about more edge cases,” Valeri says, “but I think we need to clean up these `if` statements first. If you factor out a `validateMessage()` method, that should help.” You nod, select the code, and hit the Extract Method keystroke. Ding! No problems.

The sounds were the result of an experiment a few months ago. Despite the jokes about “Pavlov’s programmers,” they were a hit. Your team works in such small steps that, most of the time, the code does exactly what you expect it to. Your incremental test runs take less than a second, so the sounds act as instant feedback. You only need to look at the test runner when something goes wrong. The rest of the time, you stay in the zone, switching back and forth between tests, code, and refactoring, with the steady chimes assuring you that you’re on track and in control.

Another half hour later, the networking changes are done. You stretch as Valeri pulls the latest code from the integration branch and runs the full test suite. A minute later, it’s passed, and she runs the deployment script. “Done!” she says. “Time for more coffee. Keep an eye on the deploy for me?”

You settle back in your chair and watch the deployment script run through its paces. It tests your code on a separate machine, then merges it into the shared integration branch. Everybody on the team merges their code from and to this branch every few hours. It keeps the team in sync and ensures merge conflicts are resolved early, before they become a problem. Then the script deploys the code to a canary production server. A few minutes later, the deploy is confirmed and the script tags your repository with the success.

You saunter back to the task board and mark the networking task green. “All done, Bo!” you call. “Ready for some CSS?”

Welcome to the Delivering Zone

The Delivering zone is for teams who want to deliver software reliably.

The Delivering fluency zone is for teams who want to deliver software reliably. Team members develop their technical skills so that their software is low maintenance, easy to improve and deploy, and has very few bugs. Specifically, teams that are fluent at Delivering:1

1These lists are derived from [Shore2018b].

  • Release their latest work, at minimal risk and cost, whenever their business stakeholders desire

  • Discover and fix flaws in the production lifecycle early, before they can do damage

  • Are able to provide useful forecasts

  • Have low defect rates, so they spend less time fixing bugs and more time building features

  • Create software with good internal quality, which makes changes cheaper and faster

  • Have high job satisfaction and morale, which improves retention and performance

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’s code is production-grade and the latest work is deployed to a production-equivalent environment at least daily.

  • The team’s business representative may release the team’s latest work at will.

  • The team provides useful release forecasts to its business representative upon request.

  • The team coordinates with its business stakeholders to develop in a way that allows its software to be maintained, inexpensively, and indefinitely.

The team works effectively as a team:

  • Developers consider code and similar artifacts to belong to the team, not individuals, and they share responsibility for changing and improving it.

  • All day-to-day skills needed to design, develop, test, deploy, monitor, maintain, etc., the team’s work are immediately accessible to the team.

The team pursues technical excellence:

  • When making changes, team members leave their software’s internal quality a little better than they found it.

  • The team actively responds to errors by improving the underlying system that made the error likely, reducing the probability of future errors.

  • Deploying and releasing is automated and takes no more than 10 minutes of manual effort.

  • No manual testing is required prior to deployment.

  • Team members are aware of how their skills affect their ability to accomplish the team’s goals and improve internal quality, and they proactively seek to improve those skills.

Achieving Delivering Fluency

The practices in this part of the book will help your team achieve fluency in Delivering zone skills. For the most part, they center around simultaneous phases.

Most teams, even Agile teams, use a phase-based approach to development. They may work in iterations, but within each iteration, they follow a phase-based approach of requirements analysis, designing, coding, testing, and deploying, as shown in parts (a) and (b) of the “Software Development Lifecycles” figure. Even teams using continuous flow tend to develop each story through a series of phases, using a swim-lane visualization to track progress.

A figure in three parts. Part “a” is labelled “Waterfall,” and it shows development progressing through six phases: Plan, Analyze, Design, Code, Test, and Deploy. The whole cycle takes 3-24 months and only has the ability to release at the end. Part “b” is labelled “Phase-based Agile.” It shows the same waterfall cycle of part “a,” but now it’s compressed into multiple cycles lasting 1-4 weeks each, with the ability to release at the end of each cycle. Part “c” is labelled “XP-style Agile.” It also shows multiple cycles, but rather than showing the phases happening in order, the phases are stacked on top of each other and extend the entire length of the cycle. Each cycle lasts 1-2 weeks and has the ability to release at any point during the cycle.

Figure 1. Software development lifecycles

But Agile is inherently iterative and incremental. Each story is only a day or two of work. That’s not enough time for high-quality phases. In practice, design and testing get shortchanged. Code quality degrades over time, teams have trouble figuring out how to schedule necessary infrastructure and design work, and they run out of time for testing and bug fixing.

To prevent these problems, Extreme Programming introduced techniques to allow software development to be truly incremental. Rather than working in phases, XP teams work on all aspects of development incrementally and continuously, as shown in part (c) of the “Software Development Lifecycles” figure.

Adaptive Planning
Incremental Requirements

Despite being created in the 1990s, XP’s testing, coding, and design practices remain state of the art. They yield the highest-quality, most productive code I’ve ever seen. They’ve since been extended by the DevOps movement to support modern cloud-based deployment. Together with incremental planning and requirements analysis, these techniques allow teams to deliver high-quality software regularly and reliably.

The practices in this part are based on XP. If you apply them thoughtfully and rigorously, you’ll achieve Delivering fluency. They’re grouped into five chapters:

  • The “Collaboration” chapter describes how to build software as a team.

  • The “Development” chapter describes how to incrementally build, test, and automate.

  • The “Design” chapter describes how to incrementally design code.

  • The “DevOps” chapter describes how to deploy software reliably and at will.

  • The “Quality” chapter describes how to create software that does what it's supposed to.

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.

JavaScript Colors and the Corruption of Buy vs. Build

In an apparent fit of pique, the maintainer of the popular JavaScript “colors” package has intentionally released a broken update that causes any program importing the package to go into an infinite loop. (Colors is a tool that inserts ANSI color codes into a string, making it easy to output colored text.)

This is part of a larger conversation in the wake of the Log4Shell exploit around open source maintainers’ high maintenance burden and low compensation.

What interests me about colors, though, is how widely used it is. Twenty-two million weekly downloads, according to npm. In my mind, “colors” represents a corruption of the “buy vs. build” tradeoff. It’s no longer “buy vs. build,” but “only build when you can’t find any other alternative.” “Not invented here” is an insult. And so people use third-party code without thinking it through.

As it happens, just last month I needed a JavaScript library for colorizing strings, and “colors” was one of the packages I looked at. I immediately decided against it, though. Whenever I evaluate a new dependency, I’m looking at two things:

  1. How much time will this save me now?
  2. How much time will this cost me later?

Looking at the “colors” documentation and code didn’t fill me with confidence. This is a library that loves fun. Not only will it color-code your strings, it will make rainbows. It will substitute Unicode characters. It will “zalgo-ify” your text.

Let’s be honest. The long tail of open source libraries is filled with crap. I get the impression that the majority of them are created by early-twenties college students and fresh grads with lots of time on their hands and an eagerness to make a name for themselves. They’re filled with bad coding practices.

So where others see “fun,” I see risk. That feeling was clinched when I saw that, by default, “colors” monkeypatches the String global. No thank you.

I looked into other options, but they didn’t impress either. “How hard could this be?” I asked myself. One Stack Overflow search later, I had my answer: not hard at all.

  1. How much time will “colors” save me now? Probably an hour or two.
  2. How much time will it cost me later? The code has a lot of red flags. It’s high risk, and could easily cost me more time than it saves.

So I built it myself. It took a few hours, according to my git logs, and less than a hundred lines of code.

It’s rare that my hunches are vindicated so quickly, but less than a month later, “colors” imploded. Those few hours have already been saved.

The moral of the story? Don’t let the “not invented here” epithet scare you. With attention to tests and good design, you can create code that is much simpler and easier to maintain than third-party code. In general, if something will take me less than a day a two of work, I’ll build it myself. Third-party code is so much harder to tweak to match my needs, and quality tends to be worse, too. Even when it’s not, third-party code is an ongoing tax on development. It’s not custom-tailored to my needs, so it takes additional time to understand and integrate, and updates and API changes force continual maintenance.

The pendulum has swung too far in favor of “buy” over “build.” It’s time it swung back.

In case you’re curious, here’s the code I wrote. You’re welcome to use this yourself, on the condition that you don’t ask me for support.


const { red } = require("./colors");    // import other colors as needed
console.log(red("red text"));
console.log(red.underline("red text with underline"));


// Copyright 2021 Titanium I.T. LLC.
// This code is licensed under the terms of the MIT license (https://mit-license.org/)
// under the condition that you do not request support without a paid support contract.
"use strict";

const describe = require("tests/describe");
const assert = require("tests/assert");
const colors = require("./colors");

module.exports = describe("Colors", ({ describe, it }) => {

  const { red } = colors;    // see production code for other supported colors

  it("color-codes text", () => {
    assert.equal(red("text"), "\u001b[31mtext\u001b[0m");

  it("has styling", () => {
    // note that support for styles depends on terminal emulator

    assert.equal(red.bold("text"), "\u001b[1;31mtext\u001b[0m", "bold");
    assert.equal(red.dim("text"), "\u001b[2;31mtext\u001b[0m", "dim");
    assert.equal(red.underline("text"), "\u001b[4;31mtext\u001b[0m", "underline");
    assert.equal(red.blink("text"), "\u001b[5;31mtext\u001b[0m", "blink");
    assert.equal(red.inverse("text"), "\u001b[7;31mtext\u001b[0m", "inverse");

  it("can chain styles", () => {
    assert.equal(red.bold.underline("text"), "\u001b[1;4;31mtext\u001b[0m", "multiple styles");
    assert.equal(red.underline.bold("text"), "\u001b[4;1;31mtext\u001b[0m", "use any order");

    assert.isUndefined(red.bold.bold, "doesn't repeat styles");
    assert.isUndefined(red.bold.underline.bold, "doesn't repeat styles even recursively");



// Copyright Titanium I.T. LLC.
// This code is licensed under the terms of the MIT license (https://mit-license.org/)
// under the condition that you do not request support without a paid support contract.
"use strict";

const COLOR_STYLES = {
  bold: "1;",
  dim: "2;",
  underline: "4;",
  blink: "5;",
  inverse: "7;",

module.exports = {
  // this brute-force approach works better with IDE code completion than building the object at run-time.
  black: colorFn(30),
  red: colorFn(31),
  green: colorFn(32),
  yellow: colorFn(33),
  blue: colorFn(34),
  purple: colorFn(35),
  cyan: colorFn(36),
  white: colorFn(37),
  brightBlack: colorFn(90),
  brightRed: colorFn(91),
  brightGreen: colorFn(92),
  brightYellow: colorFn(93),
  brightBlue: colorFn(94),
  brightPurple: colorFn(95),
  brightCyan: colorFn(96),
  brightWhite: colorFn(97),

function colorFn(color) {
  const fn = encodeFn("", color);
  combinatorialize(fn, "", color, COLOR_STYLES);
  return fn;

  function encodeFn(style, color) {
    return (text) => {
      return `\u001b[${style}${color}m${text}\u001b[0m`;

  function combinatorialize(fn, baseStyle, color, styles) {
    // adds .bold, .dim, etc. to fn, and does so recursively.
    Object.keys(styles).forEach(styleKey => {
      const myStyle = baseStyle + styles[styleKey];
      fn[styleKey] = encodeFn(myStyle, color);

      const remainingStyles = { ...styles };
      delete remainingStyles[styleKey];
      combinatorialize(fn[styleKey], myStyle, color, remainingStyles);

Agile Book Club: Whole Team

Agile is all about teamwork, which makes “Whole Team” one of the most foundational practices in the book. In this book club session, we looked at what it means to have a successful Agile team.

📖 Reading: Whole Team

🎙 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?

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

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

with Gitte Klitgaard

We share conflicting viewpoints without fear.

In 2012, Google launched Project Aristotle, an internal research effort intended to identify why some teams excelled and others did not. Google looked at a number of factors: team composition, socialization outside of work, educational background, extroversion versus introversion, colocation versus remote, seniority, team size, individual performance, and more. None of them made a significant difference to effectiveness. Not even seniority or individual performance.

What mattered? Psychological safety.

Of the five key dynamics of effective teams that the researchers identified, psychological safety was by far the most important. The Google researchers found that individuals on teams with higher psychological safety are less likely to leave Google, they’re more likely to harness the power of diverse ideas from their teammates, they bring in more revenue, and they’re rated as effective twice as often by executives.[Google2021]

Understanding Team Effectiveness

Although Google’s findings have brought psychological safety into the limelight, it’s not a new idea. It was originally introduced in 1965 by Edgar Schein and Warren Bennis, in the context of making personal and organizational changes. “In order for [discomfort] to lead to an increased desire to learn rather than heightened anxiety...An environment must be created with maximum psychological safety.” [Schein1965] (p. 44)

Understanding Psychological Safety

Psychological safety—often abbreviated to just “safety,” because modern offices have physical safety covered—is the ability to be yourself without fear of negative consequences, whether to your career, status, or self-image. It’s the ability to propose ideas, ask questions, raise concerns, and even make mistakes without being punished or humiliated.1

1The first half of this definition of psychological safety (“ability to be yourself”) is based on [Kahn1990]. The second half (“ability to propose ideas”) is based on [Edmonson2014].

Safety means team members are safe to disagree.

Safety doesn’t mean your team has no conflicts. It means the exact opposite. It means that everyone on your team is able to express their opinion without fear of retribution or belittlement. They are safe to disagree with each other. And they do. It may be uncomfortable, yet it is still safe.

Through that creative tension, they consider ideas that might have been forgotten. They take into account objections that could have been swept under the rug. In the end, everyone’s voice is heard, and that creates better results.

How to Create Safety

Safety is very individual. It’s context-based and intangible. An exchange that’s safe for some participants can still feel unsafe to others. For example, you might start a conversation with a bit of small talk: “What did you do this weekend?” One man speaks up confidently: “I went to the mountains with my wife.” Another is reluctant to speak. He spent the weekend with his boyfriend, and he worries that bringing it up will lead to uncomfortable conversations about his sexual orientation.

Past experiences are a factor, too. I (Gitte) worked with a 60-year-old who always avoided mentioning the gender of his husband. He said “my partner,” rather than “my husband,” and never used pronouns. Intellectually, he knew that I was comfortable with his relationship and would never treat him badly, but he grew up in a time when being gay was punished and instinctively protected himself.

People’s personalities, the neurodiversity in the team, and other differences in the way people think also play a part. Does that mean safety is impossible? Not at all! But it does mean there’s no magic answer. You can do everything right, and people can still feel unsafe. You can’t force safety on anyone. You can only create a situation where safety is possible, and you can have discussions to figure out what safety means to your team.

The following techniques will help create safety.

Enable all voices

One of the big benefits of safety is that it creates space for everyone's voices. By feeling safe, team members speak up, disagree, suggest new ideas, bring up problems, and in general bring in options. It doesn’t mean all ideas are implemented; it means that your team has considered more options before making a decision—options you might not otherwise see.

Even if people feel safe enough to speak up, some people are naturally shy, have social anxiety, or are just uncomfortable speaking up in group settings. You can make it easier for them to participate by taking these differences into account.

One way is to start each meeting with a brief check-in. It can be small, such as “Say one word about your mood today,” or “Tell us what the weather outside your window looks like right now.” When a person has spoken once in a meeting, it’s safer for them to speak again later. Be sure to give the option to pass, too. It shows that it’s also safe to not speak up.

Another option is to split large discussions into small groups of two to four people each. One person from each group shares the group’s conclusions with everyone else. This allows people who are uncomfortable speaking up in large settings to have a voice, without requiring them to speak to the larger group.

Be open about mistakes

When we make a mistake, it’s easy to want to defend ourselves, especially if we’ve just committed a social faux pas. Resist the urge to ignore or cover up your mistakes. Instead, admit them. You’ll make it safe for others to admit their mistakes, too.

Matt Smith has a technique called “the failure bow.” [Smith2012] It works best when it’s a shared team norm. When you make a mistake, stand up and stretch your hands high in the air. “I failed!” Say it with a big smile. Everyone else will smile, too, and maybe even applaud. Make failures fun. It takes the sting out of it.

Some people will have trouble admitting mistakes. A person may blame themselves for a mistake, then assume that the team will hate them for it, and they will get fired. I’ve done this myself, as a recovering perfectionist.

In other words, although you can create an environment where it’s perfectly safe to speak up about mistakes, some people may still feel unsafe making mistakes. Allow people to share their mistakes, or not, in the way that works best for them.

Be curious

Show genuine interest in other people’s opinions. If someone is quiet or reluctant to speak, ask them what they think. It lets them know their voice has value. But keep in mind that they may not feel safe to be called upon in a group setting. If you’re in doubt, take the discussion to a smaller setting—perhaps just the two of you.

Listen to understand, not to respond.

Listen to understand, not to respond. It’s all too easy to focus on what you want to say next, rather than listen to what the other person is saying. If you already have your next question or statement lined up, you’re listening to respond. Instead, focus on what they’re saying and what they’re trying to convey.

Learn how to give and receive feedback

In an effective team, disagreements and conflicting opinions are not only normal, they’re expected. They’re how the best ideas emerge. Make disagreements safe by focusing on things and ideas, not the people suggesting them. Use an old improv trick: say “yes, and...” to build on each others’ ideas.

For example, if someone is proposing a change to the code, but didn’t consider error handling, don’t say “You forgot to include error handling.” That puts the focus on them and what they forgot to do. Instead, focus on the idea and build on it. “Where should we put error handling?” Or, “Let’s add error handling here.”

Some disagreements will be personal. For example, someone might make an insensitive joke. Diana Larsen provides the following process for giving interpersonal feedback:

  1. Create an opening. Ask permission to provide feedback. Don’t blindside them. “Georgetta, can I give you feedback about something you said in today’s stand-up meeting?”

  2. Describe the behavior. Be specific about what happened. “Today in the stand-up meeting, you made a joke about short people not getting dates. That was your third short joke this week.”

  3. State the impact. Describe how it affected you. “I’m sensitive about my height, and although I laughed it off, I felt down all morning.”

  4. Make the request. Explain what you would like to change, encourage, or discourage. “I’d like you to stop making short jokes.”

  5. Listen to the response. The other person will respond. Listen to understand and let them finish their thoughts.

  6. Negotiate next steps. Focus on what you can both do going forward, with an eye toward building the relationship. “I love your sense of humor, and I hope you’ll keep making jokes about other things. I’m working on being less sensitive, but it’s not easy. I appreciate you agreeing to make this change for me.”

Be sure to give feedback to encourage behavior you want to see as well as to correct behavior you want to change.

People may need a few days to digest feedback, especially if it’s something serious. Don’t expect them to respond right away. A lot of people find it hard to receive positive feedback, too. It took me a few years of consciously training myself before I was able to take positive feedback gracefully, and I still have trouble on bad days.

Receiving interpersonal feedback can be particularly uncomfortable if you’ve done something that hurt someone’s feelings. When that happens, avoid being defensive or minimizing the other person’s concerns. Don’t make a nonapology, such as “I’m sorry if you felt offended.” Instead, acknowledge your error and make amends. “I didn’t intend to upset you with my jokes, but I did. I apologize. I’ll avoid those sorts of jokes in the future. Please remind me if I slip up.”

Consider establishing working agreements around giving and receiving interpersonal feedback. The “Right-Size Conflicts with Feedback” section has suggestions.

Use empathy

People are prone to the Fundamental Attribution Error: we tend to assume people do things because of their underlying personality, not the situation they’re in. For example, if we cut someone off on the highway, it’s because we almost missed our exit. If someone else cuts us off, it’s because they’re a bad driver with no respect for others.

When you disagree with someone, assume positive intent.

When you disagree with someone, put yourself in their shoes. Rather than assuming malice or incompetence, assume positive intent: the other person is just as smart and well-meaning as you are, but coming to a different conclusion. Try to understand their position and why their conclusion is different from yours.

You can develop your empathy by roleplaying disagreements after the fact. Ask someone to listen as you explain the disagreement. Explain it from your point of view, then from the other person’s point of view. Make the best, most reasonable argument you can for their position.

Agile Conversations [Squirrel2020] is an excellent resource for understanding the impact of your conversations and how to be more effective.

Allow yourself to be vulnerable

Share personal details and allow people to see your vulnerabilities. This can start small: a hobby, favorite toy as a kid, or pet. This creates relationships and trust. Over time, as you grow to trust your teammates, you can open up further.

Whole humans go to work. In other words, things that happen at home affect us at work, too, as do all the other things that make us who we are. Sharing a good day, or bad day, helps people understand your mood, which creates safety. For example, if you didn’t get enough sleep, you might be grumpy. Sharing that information will help people understand that you’re not upset with them...you’re just grumpy.

In 2007, I was under examination for uterine cancer. I panicked and cried, and told my team. It was very uncomfortable, but it was safe. When it was time to go to the doctor for the examination, three people on the team called me at home to make sure I had someone to take me there. They knew I lived alone, and they supported me. This was a wonderful feeling. (Eventually, the diagnosis came back—there was no cancer.)

Leaders’ Role

People in a position of power have an outsized effect on safety. That includes traditional sources of power, such as a team lead or manager, but it also includes informal power, such as when a senior developer speaks to a junior developer.

If you’re in a position of power, your words and actions have more weight. Take this seriously. It means that you can’t speak as casually as you might like, at least not at first. Learn to read the room: pay attention to how your words and actions affect others.

The following techniques will help you create safety in your teams.

Model the behaviors you want to see

Demonstrate all the behaviors you want to see from the rest of the team. Enable everyone’s voice, be open about your mistakes, be curious, give feedback, show empathy, and allow yourself to be vulnerable. It’s not enough to tell people to be safe, or to assume that they’re safe. Show it.

When discussing mistakes, be careful not to place or take blame. Don’t say things like, “Oh, I made a mistake, I’m so stupid.” That sends the message that mistakes are stupid. Instead, frame the work as a vehicle for learning, where mistakes are expected, and learning is part of the result. “I made a mistake, and this is what I learned.”

Be explicit about expectations

Agile teams are self-organizing and own their work, but that doesn’t mean they have no expectations or direction. Be clear about what you expect from your fellow team members, and what you can do to help. During meetings and activities, such as a retrospective, start by clearly stating your expectations for the session.

Don’t shy away from conflict
Safety doesn’t mean people always get what they want.

Safety doesn’t mean people always get what they want. It means everyone’s opinion has been taken into consideration.

In an effort to create a sense of safety, some teams will engage in false harmony instead. They’ll avoid conflict and suppress dissenting opinions. This may feel safe, but the conflict doesn’t go away. It just bubbles and grows under the surface.

Some leaders make the mistake of emphasizing positivity on their teams. They say things like, “don’t be so negative,” or “be a team player”—by which they mean, “go along with the rest of the group.” This tells people they aren’t safe to express disagreement.

Instead, if you notice people suppressing their opinions, ask them to share. If people seem to be indulging in false harmony, ask them about the downsides of an idea. If you see a problem that no one else mentions, bring it up, in a kind way.

At the same time, be prepared to be fallible. Don’t focus on being right; focus on getting every opinion out in the open, where they can be discussed, debated, and improved.

Team Dynamics

False harmony and groupthink are a common challenge for teams in the “Norming” stage of development. See the “Norming” section for more ideas.


No matter what I do, one of our other team members doesn’t like to speak up. How can I help them?

As with many team issues, listening is a good first step. Talk to them about why they don’t like to speak up. Be sure to emphasize that this isn’t a problem they need to solve, but a challenge for the team. You want to make it easier for them to contribute their voice.

As you discuss options, keep in mind that, while you want to ensure their voice is heard, it doesn’t have to be their literal voice. For some people, carefully organizing their thoughts in writing is more comfortable than sharing in the spur of the moment.

Another option is for them to talk their ideas through with a buddy on the team. This can be a way to practice what they want to say in advance, or they can ask their buddy to represent their point of view.

I’ve seen something that I know impacted a person, but I’m concerned that they don’t feel safe enough to speak up. What should I do?

It depends on the severity of the situation, and also whether you feel safe enough to act on it yourself.

In most cases, start by talking to the person who was impacted. Ask them if they're okay and if they’d like to talk about it. If you feel safe to do so, offer to bring up the problem on their behalf. Even if you don’t, it can help the other person to know they’ve been seen, and that someone cares.

If I feel that something has crossed a line, I’ll speak up on the spot. For example, imagine Von says something in a meeting but is ignored. Normally, I’d discuss this with Von afterward. But later in the meeting, Max repeats what Von said, and this time, everyone listens. At this point, I’ll step in. I have a standard phrase for this situation: “Max, I really like how you rephrased what Von said earlier.”

Isn’t our time better spent getting work done, not talking about our feelings?

Simple, repetitive tasks may not need safety, but software development requires creativity, learning, and thinking. Your team needs all brains and voices to create the best possible results. Without safety, you could miss out on ideas, people could be reluctant to point out mistakes, and opportunities could be ignored due to perceived risk.

Remember the Project Aristotle findings. Safety was the number one predictor of team performance at Google. And even if that wasn’t true, work is an enormous part of your life. Don’t you want it to be an environment where you and your teammates can express yourselves without fear?


Almost any team can establish psychological safety. Some organizations have a culture of suppressing disagreement or placing blame, and they can make safety difficult, but you can still establish a pocket of safety within your team.

If your team is remote, be careful about recording conversations. If the team has safety and people express themselves freely, you don’t want the broader organization to use that against team members in the future. If you can, set your chat room to delete old conversations, and default to not recording video calls, unless there’s a specific reason to do so.


When your team has psychological safety:

  • Team members speak up about mistakes and what they’ve learned.

  • Team members disagree constructively.

  • Team members bring up ideas and problems.

  • The team creates better products that incorporate more ideas.

  • It’s easier to hire and retain people with diverse backgrounds.

Alternatives and Experiments

Psychological safety is a way for people to learn, share their learning, disagree, and speak up. This practice has focused on ways to change your environment to make that easier.

An alternative is to try to change the people, rather than the environment. In theory, you can work on developing their courage, so they’re comfortable speaking up even when they don’t feel safe. But I don’t recommend this approach. People can only change themselves; you can’t do it for them. Even if they do have the courage to speak up when they’re feeling unsafe, that fear will reduce their creativity.

Experiments, on the other hand, are a great way to improve safety. Be explicit about the experiments you try: even framing something as an experiment, with a follow-up date, can create more safety, because people know the change can be reverted if it doesn’t work. Create a culture of trying new ideas, both regarding safety and within your team in general.


One way to get started is to conduct a retrospective with “safety” as a theme. Discuss what you’ve noticed regarding safety, on this team and others, and choose some experiments to try.

Further Reading

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth [Edmonson2018] is the latest book from Amy Edmonson, a professor at Harvard Business School. It’s a good book about the many aspects of psychological safety she has researched.

“Building a Psychologically Safe Workplace,” [Edmonson2014] Amy Edmonson’s TEDx talk, is a nice, quick introduction to the topic.

Time to Think: Listening to Ignite the Human Mind [Kline2015] is about creating space and time to think at work. The book includes practical advice that I personally include in most of my meetings.

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 Practice: Energized Work

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.

Energized Work

Coaches, Whole Team

We work at a pace that allows us to do our best, most productive work indefinitely.

I love my work. I enjoy solving problems, writing good code, watching tests pass, and I especially love removing code while refactoring.

But if I’m on a team with unclear goals, little collective responsibility, and infighting, I’ll wake up dreading going into work. I’ll put in my hours at the office, but I’ll be tempted to spend my mornings reading email and my afternoons picking at code while surfing through marginally related websites.

We’ve all been in this situation. Because we’re professionals, we strive to produce quality work even when we feel demoralized. Still, consider the times of greatest productivity in your career. Do you notice a big difference when you wake up and feel eager to start work? Isn’t it much more satisfying to stop on time at the end of the day, knowing that you accomplished something solid and useful?

Professionals do their best, most productive work when they’re energized and motivated.

Energized work is about recognizing that although professionals can do good work under difficult circumstances, they do their best, most productive work when they’re energized and motivated.

How to Be Energized

One of the simplest ways to be energized is to take care of yourself. Go home on time every day. Take your mind off work and spend time with family and friends. Eat healthy foods, exercise, and get plenty of sleep. When you’re busy with these other things, your brain will turn over the events of the day. You’ll often have new insights in the morning.

If quality time off is the yin of energized work, focused work is the yang. While at work, give it your full attention. Turn off interruptions, such as email and instant messaging, unless they’re part of your virtual team room. Silence your phones. Ask your manager to shield you from unnecessary meetings and organizational politics.

When the yin and yang balance perfectly, you’ll wake up in the morning well-rested and eager to start your day. At the end of the day, you’ll be tired—not exhausted—and satisfied with the work you’ve done.

This isn’t easy. Energized work requires a supportive workplace and home life. It’s also a personal choice. There’s no way to force someone to be energized. However, you can remove roadblocks.

Supporting Energized Work

As a coach, one of my favorite techniques is to remind people to go home on time. Tired people make mistakes and take shortcuts. The resulting errors end up costing more than the work is worth. This is particularly true when someone comes to work sick; in addition to doing poor work, they could infect other people.

Pair Programming
Mob Programming

Pair programming is another way to encourage energized work. It encourages focus like no other practice I know. After a full day of pairing, you’ll be tired and satisfied. It’s particularly useful when you’re not at your best: pairing with someone who’s alert can help you stay focused. Mob programming isn’t as good at ensuring focus—it’s easy to tune out—but it is good for preventing the errors that occur when you’re tired.

Agile teams are highly collaborative and are constantly communicating. This may sound like an introvert’s nightmare, but—speaking as an introvert myself—it’s not as bad as it sounds. The collaboration is focused on ideas and results, not small talk. Even so, be respectful of introverts’ need to recharge, and consider creating working agreements to support one another in staying energized.

Having healthy food available in the workplace is another way to support energized work. Fruits and vegetables are a good choice. Donuts and other junk food, while popular, contribute to mid-afternoon lows.


The nature of the work also makes a difference. Not every team can feed the poor or solve NP-complete problems, but a clear, compelling purpose can go a long way. Creating and communicating the team’s purpose is the responsibility of team members with product management skills.


To be compelling, the team’s purpose also needs to be achievable. Nothing destroys morale faster than behind held accountable for an unachievable goal. If the team is responsible for meeting specific date and scope targets, make sure the targets are realistic and based on the team’s forecasts.

Speaking of targets, every organization has some amount of politics. Sometimes, politics lead to healthy negotiation and compromises. Other times, they lead to unreasonable demands and blaming. Team members with political savvy should deal with organizational politics, letting other team members know what’s important and shielding them from what isn’t.

Informative Workspace

Politically savvy team members can also help the team by pushing back on unnecessary meetings and conference calls. Providing an informative workspace and appropriate roadmaps can eliminate the need for status meetings. In an environment with a lot of external distractions, consider setting aside core hours each day—maybe just an hour or two to start—during which everyone agrees not to interrupt the team.

Every organization has standard processes and technologies it requires teams to use. When those standards get in the way of a team’s work, though, it can be frustrating and demoralizing for team members. Be sure to communicate the “why” behind such standards, as well as the “what,” and provide a way for teams to discuss making an exception. Team managers can advocate for these changes and help their teams navigate the bureaucracy.

Team Dynamics

Finally, “norming” teams (see the “Norming” section) have a lot of energy. They’re a lot of fun, too. You can recognize such a team by how much its members enjoy spending time together. They go to lunch together, share in-jokes, and may even socialize outside of work. You develop a “norming” team by paying attention to team dynamics.

Taking Breaks

When you make more mistakes than progress, it’s time to take a break. If you’re like me, though, that’s the hardest time to stop. I feel like the solution is just around the corner—even if it’s been just around the corner for the last 45 minutes—and I don’t want to stop until I find it. That’s why it’s helpful for someone else to remind me to stop. After a break or a good night’s sleep, I usually see my mistake right away.

Pair Programming
Team Room

Sometimes a snack or walk around the block is good enough. For programmers, switching pairs can help. If it’s already the end of the day, though, going home is a good idea.

In a physical team room, you can usually tell when somebody needs a break. Angry concentration, cursing at the computer, and abrupt movements are all signs. Going dark—not talking—can also be a sign that someone needs a break. When I notice a pair or programmers whispering to each other, I ask how long it’s been since their last passing test. I often get a sheepish reply, and that’s when I remind them to take a break.

Suggesting a break requires a certain amount of delicacy. If someone respects you as a leader, then you might be able to just tell them to stop working. Otherwise, get them away from the problem for a minute so they can clear their head. Try asking them to help you for a moment, or to take a short walk with you to discuss some issue you’re facing.


I work in a startup and a normal work week just isn’t enough. Can I work longer hours?

A startup environment often has a lot of excitement and camaraderie. This leads to more energy and might mean that you can work long hours and still focus. On the other hand, startups sometimes confuse long work hours with dedication to the cause. Be careful not to let dedication override your good judgment about when you’re too tired to make useful contributions.

We have an important deadline and there’s no way to make it without putting our heads down and pushing through. Do we set aside energized work for now?

There’s nothing quite like a late-night codefest when the team brings in pizza, everybody works hard, all cylinders fire, and the work comes together at the last moment. A great sprint to the finish line can help the team jell, giving them a sense of accomplishment in the face of adversity. However...

Extended overtime won’t solve your schedule problems.

Sprinting to the finish line is one thing; sprinting for miles is another. Extended overtime won’t solve your schedule problems. In fact, it has serious negative consequences. Tom DeMarco calls extended overtime “an important productivity-reduction technique,” leading to reduced quality, personnel burnout, increased turnover of staff, and ineffective use of time during normal hours [DeMarco2002] (ch. 9).

If you work overtime one week, don’t work overtime again the next week. If I see a team sprinting in this way every quarter, or every release, I look for deeper problems.


It’s counterproductive, but some organizations judge employees based on the number of extra hours they work. In this environment, you may be better off sacrificing energized work and working long hours. It’s a personal choice that only you and your family can make.

Conversely, energized work is not an excuse to goof off. Generate trust by putting in a fair day’s work.


When your team is energized:

  • The team has a sense of excitement and camaraderie.

  • The team is engaged in its work and eager to make it better.

  • The team makes consistent progress every week, and you feel capable of maintaining that progress indefinitely.

  • You value health over short-term progress and feel productive and successful.

Alternatives and Experiments

Pair Programming
Mob Programming

This practice is also called “sustainable pace,” and the alternative is, well, unsustainable. But some organizations still make energized work difficult. If that’s the case in your organization, pair programming or mob programming can help tired team members stay focused and catch each other’s errors. Ironically, your software will probably need more time to develop—to find and fix the errors tired team members introduce—so adjust your plans accordingly.

The one common characteristic among death marches is low expected value.

Some organizations require employees to work extensive overtime week after week. Sadly, these death marches, also called crunch mode, don’t happen because of the massive value to be gained; just the opposite. Tom DeMarco and Timothy Lister explain:

“In our experience, the one common characteristic among death-march projects is low expected value. They are projects aimed at putting out products of monumental insignificance. The only real justification for the death march is that the value is so miniscule, doing the project at normal cost would clearly result in costs that are greater than benefits... if the project is so essential, why can’t the company spend the time and money to do it properly?” [DeMarco2003] (ch. 21)

Your best experiments when faced with this sort of organization are the ones that involve sending resumes.

Further Reading

Peopleware: Productive Projects and Teams [DeMarco2013] is a classic work on programmer motivation and productivity. It should be at the top of every software development manager’s reading list.

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [DeMarco2002] looks at the effects of extended overtime and overscheduling.

Joy, Inc. [Sheridan2013] describes how Menlo Innovations uses their variant of Extreme Programming to create an energized workplace. It’s an enjoyable read written from the CEO’s perspective.

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

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.


Coaches, Whole Team

We agree on how we work together.

What is a “team?” It’s not just a bunch of people who sit in the same room. It’s not even a group that’s been assigned to work on the same thing.

Interdependency is the hallmark of a team.

A team is a group of people who depend on one another to accomplish a shared goal. That interdependency is the hallmark of a team. It’s what makes teams so successful...and also what makes them so difficult.

You probably remember working on group assignments in school. They tend to be tolerated at best. We’ve all heard the horror stories about one person who ended up doing all the work while the others mooched off their grade.

But we’ve also heard stories of amazing teams. Maybe you’ve had that experience, too: being part of a great sports team, a band, or a volunteer group. When teams work, they’re electrifying.

What’s the difference between bad teams and good teams? Alignment. Team members in an aligned team not only depend on one another to accomplish a shared goal, they’re in agreement about how they’re going to work together.

Chartering Alignment


Your chartering session is a good time to discuss alignment. (See the “Planning Your Chartering Session” sidebar.) Unlike the other parts of the chartering session—purpose and context—stakeholders don’t participate in the alignment discussion. It’s just for team members and people who work closely with the team, such as a product manager.

As with the other chartering discussions, alignment can raise some sensitive topics. It’s best if you have a neutral facilitator. A good facilitator will help mediate conflicts and make sure everyone’s voice is heard.

During your alignment conversation, you’ll learn about the people on the team, create working agreements to guide team behavior, and establish standards.1

1This agenda is based on [Larsen2016] (ch. 6), with some changes.

Get to know one another

Start your alignment discussion by getting to know one another better. The “A Connection-Building Exercise” sidebar can be a good way to break the ice. Then hold a group discussion of the following questions:

  1. Who am I? Say a bit about your background, then share some of your positive personal qualities, such as “detail-oriented,” “patient,” or “friendly.”

  2. What’s something people learn about me once they’ve gotten to know me? Possibilities include a hobby, favored vacation destination, or beloved pet.

  3. Why do I believe this group is well-suited to achieving the team’s purpose?

  4. What’s the most important thing that others need to know about working with me effectively?

  5. What’s in it for me? What do I want to get out of being part of this team and accomplishing our purpose?

Go around the room, one question at a time, and ask each person to answer. People can skip their turn if they need time to think, but come back to them before moving on to the next question.

Having this discussion will help team members start to see one another as whole people, rather than just names, faces, and titles. If you have a remote team, make an extra effort to have this conversation with video on.

Create working agreements

Working agreements guide your team’s behavior by describing what you expect from one another. Over time, the agreements will change. As the team matures, some of the working agreements will become second nature and can be taken off the list. Others will be added to take advantage of new ideas.

To create your team’s working agreements, start by sharing stories of other teams you’ve worked with. Describe how they worked together, either good or bad. You can do this in round-robin order, or just randomly, according to who wants to talk next.

  1. Thinking back on your experiences as part of a team (any kind of team, including a sports team, church group, band, or choir), when were you most effective as a team member? Tell us a short story about that time. What workplace conditions fostered effective teamwork?

  2. Reflect on the times and situations in your life when you have collaborated on a team. What do you notice about yourself, or your contribution, that you value? What do you value most about those teams?

  3. What do you consider to be the core factor that creates, nurtures, and sustains effective teams in organizations? What is the core factor that creates, nurtures, and sustains effective teamwork? Is there any difference?

  4. What three wishes would you make to cause your experience on this team to be most worthwhile?

As people share their experiences, pause to make a note of potential working agreements. They can be anything: behavioral standards, such as, “We don’t interrupt when people are talking;” specific practices, such as, “We use pair programming for all production code;” work habits, such as, “When we change tasks, we drop a note in the group chat;” and more. Include anything that will help your team work together better. Don’t critique the suggestions yet; just collect them.

After you share your stories, check whether you’ve covered the following categories. If you haven’t, suggest working agreements for them, too. You won’t have to choose them, but make sure they’re considered.

  • The practices your team will use. I recommend starting with every practice in your team’s chosen zones.

  • For remote teams, how you’ll communicate. (See the “Designing Remote Collaboration” section.)

  • How you’ll make decisions.

  • For in-person teams, how you’ll deal with distracting background noise.

  • For teams that don’t use pairing or mobbing, how you’ll ask for help without being disruptive. (See the “Always Ask Always Help” section.)

  • The core hours when you can expect people to be available.

Choose working agreements that need attention, not ones the team will do automatically.

After generating ideas, narrow down the list by using dot voting (see the “Work Simultaneously” section) to select the top five. A few more or less is fine. Tell people to vote for proposals that they think the team needs to pay extra attention to, not the ones they will do automatically.

Make sure everyone’s okay with the final list by conducting a consent vote (see the “Seek Consent” section). If you’re unable to get consent for a particular working agreement, just drop it from the list for now. You’ll be able to revisit it later.

Finish off by rephrasing the working agreements and transferring them to a cleaned-up list. Each working agreement should finish the sentence, “We work together best when...” Describe what to do instead of what not to do. In other words, rather than saying, “We don’t interrupt one another,” say, “We let people finish their thought before adding our own.”

Team Room

Post the final list of agreements prominently in your team room. You can start using them immediately.

Define standards

Standards are special working agreements that apply to specific types of tasks. Coding standards, UI design guidelines, and operational standards are all examples.

Standards tend to be a source of conflict if they’re not addressed, so it’s good to define them. What’s not as important is their actual content. You’ll amend and improve them over time. Remember, few decisions are irrevocable in Agile. Ward Cunningham put it well:

It was a turning point in my programming career when I realized that I didn’t have to win every argument. I’d be talking about code with someone, and I’d say, “I think the best way to do it is A.” And they’d say, “I think the best way to do it is B.” I’d say, “Well no, it’s really A.” And they’d say, “Well, we want to do B.” It was a turning point when I could say, ”Fine. Do B. It’s not going to hurt us that much if I’m wrong. It’s not going to hurt us that much if I’m right and you do B, because we can correct mistakes. So [let’s] find out if it’s a mistake.”

To that end, use these two guidelines to define your standards:

  1. Create the minimal set of standards you can live with.

  2. Focus on consistency and consensus over perfection.

Done Done

For your first standard, decide what it means for work to be “done.” Start your discussion by asking participants to propose an industry standard as your baseline. (For the definition of “done,” you can use the “Done Done” checklist in this book.) If your company already defines a standard, start with that.

If there are multiple proposals for the baseline standard, take a moment to discuss the options and choose one by consent. Limit your discussion to five minutes. If you can’t agree on one in that time, start without a baseline.

Next, use simultaneous brainstorming to think of additions or changes. Group the ideas using affinity mapping (see the “Work Simultaneously” section), then dot vote to choose the most important categories.

Starting with the category that received the most votes, ask someone to propose a specific standard. Conduct a consent vote, resolve objections, and move on to the next proposal.

Limit each consent discussion to five minutes. If you haven’t reached consent by that time, then just skip that proposal for now. Again, you’ll have a chance to revise your standards later. Limit the entire discussion to 45 minutes.

After you’ve created your definition of “done,” repeat the process with any other standards you need, such as coding standards. You can do this in parallel by splitting up into specialties, such as programming, UX design, and operations.

To summarize:

  1. Start by consenting to a baseline standard. (Limit to five minutes.)

  2. Brainstorm additions or changes. Group them into categories. Dot vote.

  3. For each category, consent to a specific standard. (Limit to five minutes.)

  4. Limit entire discussion to 45 minutes.

No matter which standards your group chooses, some are likely to feel jarring or grating at first. Over time, you'll become more comfortable with them. In many ways, standards are an aesthetic choice. One of the marks of a professional is the willingness to put aside personal aesthetics for a team aesthetic.

Iterating Alignment

Your list of working agreements, not including your standards, is for habits you’re actively working on establishing. It’s best to limit this list to about five agreements. When an agreement becomes second nature, take it off the list and make room for a new agreement.

Standards tend to need some time to bake. Schedule a meeting to discuss your standards a few days after you start working together, and another one a few weeks after that. An hour should be enough. This will allow you to put your standards into practice. If there’s disagreement about a standard after that time, agree to experiment with one approach, then the other, then revisit the question.


You can change your working agreements and standards at any time. Just announce your intention to the team, get consent, then change the flip chart or virtual equivalent. Retrospectives are another good time to discuss changes to working agreements.

Adhering to Agreements

People make mistakes. Assume your colleagues are professional and well-meaning. If someone isn’t following an agreement, assume there’s a good reason, despite evidence to the contrary. Your challenge is to find that reason and address it. This approach shows respect for others and will improve their respect for you.

Pair Programming
Mob Programming
Collective Code Ownership

Pairing, mobbing, and collective code ownership all help team members catch mistakes and maintain self-discipline. They also provide a way to discuss questions not addressed by your team’s agreements. They’re also an excellent way to improve your standards; it’s much easier to suggest an improvement after you’ve talked it over with someone first.

Automated enforcement of standards tends to be less effective. Some people use automated tools to check their source code for adherance to coding standards, or automatically reformat code upon check-in. Although this can work when the team is in agreement, teams commonly fall into an over-enforcement trap.

Even worse, people often use tools as a bludgeon to enforce their opinion. Although it’s tempting to come up with a technical solution to interpersonal problems, it won’t work. You have to solve the interpersonal issue first. Tools have no nuance. At best, they’ll paper over the disagreement. They won’t solve it; they’ll just shove it out of sight to fester and grow.

Start by assuming good faith.

Instead, it’s best to start by assuming good faith. Perhaps the other person misunderstood the agreement, or feels it no longer applies, or something in their life is making it difficult for them to comply.

If someone consistently violates the team’s agreements, talk with them alone to see if there’s a disagreement. Take an attitude of collaborative problem solving. Instead of saying, “Why aren’t you handling nulls like we agreed?” ask, “What do you think about the null-handling standard we agreed on? Should we change it?” Give objections full consideration, raise them with the rest of the team, and consider changing the agreement.

If someone is on board with the agreement, but still not following it, it’s possible that the agreement isn’t appropriate in every situation. Ask about specific cases you’ve noticed. Again, be collaborative, not confrontational. Say something like, “I agree with you about how we should handle nulls. In that case, can you explain what’s happening in this function? I don’t understand why this code doesn’t check for nulls.”

During this discussion, you may learn that they don’t understand the agreement. By this time, you should be in a good situation to discuss the agreement and what it means. If they’re a junior team member who needs more help, coordinate with the rest of the team to make sure they get plenty of mentoring from more experienced team members.

There’s another possibility for teams new to Agile. Changing work habits is disruptive and can make people feel like they’ve lost control. Sometimes they react by picking small things that they refuse to change. An obstinate desire to stick with a particular standard or communication style, regardless of the wishes of the rest of the team, might be a symptom of this reaction.

In this case, your best solution may be to let the infractions slide for several months. Over time, as team members become more comfortable with the changes in their environment, they’ll relax and be more willing to compromise.


What if we can’t agree on standards or other working agreements?

It’s possible to pressure people into accepting agreements that they don’t agree with, but it’s not a good idea. The disagreement will just keep coming up in other conversations.

Instead, try to let it go. Is the working agreement really so important? Focus on the things you do agree on. As work progresses, your differences will resolve.

If it’s not something you can safely ignore, your team needs the help of a professional mediator. Talk to your coach or manager about finding someone who can help. Your HR department may have someone on staff. In the worst case, it may turn out that your group isn’t suited to be a team, and you’re better off teaming up with different people.

We have pre-existing work that doesn’t fit our standards. Should we fix it?

It’s expensive and risky to spend a lot of time fixing things that aren’t broken, so if your previous work, well, works, go ahead and leave it alone. Bring each piece up to standard when you need to change it.

Some standards, such as code formatting, can be automated. Don’t spend too much time on this, but if you can do it easily, it’s fine to do so. Be sure to coordinate automated changes with other team members so their work isn’t disrupted, and separate the automated changes from normal changes so your version control history is easy to read.


Team members have to be willing to work as a team before they can create effective working agreements. See the “Invest in Change” chapter for more about team buy-in.


When your team has effective working agreements:

  • Your team uses your agreements to prevent and resolve conflicts.

  • Your standards improve the readability and maintainability of your code and other artifacts.

  • Your standards allow team members to more easily understand unfamiliar parts of the system.

Alternatives and Experiments

Some teams work together so well that they don’t need explicit agreements. Their agreements are implicit.

For new teams, though, and even most existing teams, taking the time to explicitly discuss your agreements will help prevent disruptive arguments in the future. The exact format of that discussion isn’t important. The format in this book was chosen because it’s relatively quick and nonconfrontational, but you could use another approach.

Stick with the approach in this book until you’ve had experience with several successful alignment discussions. Alignment can be contentious, particularly when teams get down to concrete agreements such as standards, and that’s why this book emphasizes setting aside divisive agreements.

Once you’ve had that experience, experiment with changes. Would small group discussions or interviews help? Is there any preparation that people could do in advance? Would different exercises be faster or more effective? There’s no limit to what you can try.

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

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.


Product Managers, Coaches

We know who and what we have to work with.

Which skills are available to your team? What resources do you have? Who are your stakeholders?

If you don’t understand your context, you risk being blindsided by people and expectations.

These are all part of your team’s context: the larger system they’re embedded within. Understanding your context is important for reducing risk. If you don’t understand your context, it’s easy to get blindsided by people or expectations you weren’t even aware existed.

Chartering Context


Your team’s chartering session, discussed in the “Planning Your Chartering Session” sidebar, is a good time to discuss your team’s context. You can also discuss context in a separate session, if that’s more convenient, but it’s best if you solidify your team’s purpose first. That will help everyone understand what your team is meant to do.

During the context discussion, you’ll work with key stakeholders to consider three aspects of your team’s context: the skills available to your team, the team’s boundaries and interactions, and the resources committed to your team. Afterward, you’ll review the results with your executive sponsor and get their commitment to supply anything that’s missing.1

1This agenda is based on [Larsen2016] (ch. 7), with some changes. I’ve added the skills inventory, inspired in part by their Core Team activity, and I’ve removed their Prospective Analysis activity because I’ve saved it for the “Visual Planning” practice instead.

Available skills

Start by reviewing the skills available to your team. Ask each team member to introduce themselves and describe the skills and experience they bring to the team. They can also describe any relevant connections or permissions they have. As each person speaks, the facilitator should scribe their answers onto a flip chart. For remote teams, mark off an area of your virtual whiteboard to use as a virtual flip chart. Label it “Skills Inventory.”

“Permissions” includes electronic permissions, such as “I have the ability to view the production database;” legal permissions, such as “I have a corporate credit card and signing authority for equipment purchases;” and social permissions, such as “I’m allowed to talk to that one customer who’s so easily upset.”

For example, someone with an operations background might say, “I’m Ha Lam, and I’ve been working in ops for five years, two at this company. My speciality is infrastructure-as-code, and I have a lot of experience with Kubernetes. I have good connections with our platform team and permission to do production deployments.”

After all team members speak, make a separate list of people who contribute to your team, but aren’t fully dedicated to the team. This might include your product manager and coach. If they’re present, they can introduce themselves; otherwise, whoever knows them best should describe their skills. In addition to listing their skills, experience, and so forth, also include their availability and the best ways to communicate with them.


Once people’s skills have been noted, draw everyone’s attention to the team’s purpose. (You might have it on a flip chart or a shared document, or you can hand out copies.) Read a few salient points, then ask participants to take a moment to review the skills inventory. Are there any skills or permissions missing that the team needs? Ask participants to use simultaneous brainstorming (see the “Work Simultaneously” section) to create a sticky note, or its virtual equivalent, for each one.

While they’re doing that, prepare two more flip charts. Label one “Skills Needed” and the other “Permissions Needed.” Then ask everyone to post their sticky notes on each chart. Duplicates can be combined or discarded. When you’re done, take a moment to review the results, then set the charts aside temporarily.

Boundaries and interactions

In your next activity, you’ll create a context diagram that identifies all the different groups that your team needs to work with. Start by preparing a large surface for the diagram. (It’s best to prepare it in advance.) It needs to be big, so tape several flip charts together on a wall or table, or use a large whiteboard. Remote teams will use their virtual whiteboard as normal. Draw a circle in the center to represent your team.

When you’re ready, ask participants to use simultaneous brainstorming to create a sticky note for each stakeholder group that your team needs to interact with. Think very broadly: everyone who affects or is affected by your team’s work, either positively or negatively. That includes software teams that your team interacts with, including teams that own systems that your software will communicate with; other groups within the company, such as Marketing, Sales, and Operations; groups outside the company, such as your customers, competitors, and suppliers; and even groups further afield, such as government regulatory bodies.

When people run out of ideas, have them arrange the stickies in a large circle around the center team. Stickies that are similar can be combined. For example, you might group most software vendors into a single sticky labeled “Software Vendors,” but keep a separate sticky for your cloud infrastructure provider. Similarly, groups that have minimal impact on your team (and vice versa) can be discarded.

After the stickies are on the chart, ask participants to think of what they provide to each stakeholder group, and what they receive from each group. Have them draw an arrow for each interaction and label it with a brief description. If your chart is on paper, start with something temporary, like pencil or another sticky note, so you can make changes easily.

While participants work on the context diagram, prepare a few more flip charts. Label them “Resources Needed” and “Communication to Provide” and put them next to the “Skills Needed” and “Permissions Needed” flip charts.

Agile teams avoid calling people “resources.” It’s dehumanizing. By resources, I mean things like time, money, goods, and services.

Once the context diagram is done, you’re ready to analyze it. Break into small, cross-functional groups and divide the stakeholder groups from the context diagram among them. For each stakeholder group, discuss how the team will interact with that group and brainstorm the skills, permissions, and resources the team needs to do so. Similarly, think about what sorts of communication that group needs from the team. Write each idea on a sticky note and post it on the appropriate flip chart—“Skills Needed,” “Permissions Needed,” “Resources Needed,” or “Communication to Provide.”

Finally, have the whole group review the “Communication to Provide” chart and decide how to combine and simplify your communications. Some communication can satisfy multiple groups. For example, you can use a mailing list to inform people about progress and roadmaps. Just create a rough plan for now; the team will refine it in the weeks to come.

For each type of communication, choose someone to be responsible for that communication. Choose someone else who will check in and help everyone remember to follow through. Once your team establishes a rhythm, these responsibilities can be more flexible, but in the beginning, it’s easy for things to fall through the cracks. It’s best to have clearly defined responsibilities.

If deciding how to follow through on communication takes more than a few minutes, set it aside until after the meeting. (Just don’t forget!) You don’t want to waste the other participants’ time.

Committed resources

After the previous two exercises, you should have three charts that describe what your team needs: “Skills Needed,” “Permissions Needed,” and “Resources Needed.” Have participants work simultaneously to sort the stickies on each chart into four categories: must have, should have, could have, and don’t need.2 As they work, if they think of new items, they can add them.

2This is called MoSCoW prioritization. The last category is usually “won’t have,” but I’ve called it “don’t need” to distinguish it from things you want, but can’t have.

Take a moment to review the results with everyone present, and make sure the team and stakeholders are in broad agreement about the items needed and how they’re categorized. It’s okay to have minor disagreements about the details, so don’t try for perfection.

Once that’s done, you can discard the “don’t need” stickies. Update the remaining stickies with a note describing:

  1. Who can provide each item

  2. How committed they are to providing it

  3. How to get it, if it isn’t obvious

The group can work on multiple stickies simultaneously.

Finally, ask everyone to take a step back and review all the needs. Is there anything important the team needs, but can’t easily get? If so, highlight each one. You’ll need to ask your sponsor to provide them. Prepare a few options for your sponsor to consider. For example, if you need database tuning skills, you could ask to engage with a consultancy, obtain training, or hire someone.

Sponsor commitment

Wrap up your discussion of context by inviting your sponsor back into the room if they’re not already there. If you also chartered your team’s purpose, now is a good time to have the sponsor ratify those changes. Then turn your attention to your team’s needs.

Review the skills, permissions, and resources your team can’t get on their own, and ask the sponsor to commit to providing them. If they do, you’re done. Decide who on the team will be responsible for following up on those commitments, and who else will help that person remember, just as before.

If your sponsor can’t provide everything your team needs, have a frank conversation about trade-offs.

If your sponsor can’t provide everything you need, take a closer look at the trade-offs involved. How does the lack of each resource, skill, or permission affect your team’s ability to fulfill its purpose? Have a frank conversation with your sponsor about what they’re risking and what they need from your team.

As you have this conversation, remember that sponsors have to make difficult trade-offs. They’re often stuck with a choice of two bad options. Sponsors own the team’s budget, yes, but their resources aren’t unlimited. Sometimes they have to make a tough choice between giving a team everything it asks for, and making a bet that the team will be resourceful enough to deliver even without it.

Some things you need will be essential, though, and your team won’t be able to achieve its purpose without them. If there are any essential resources that you can’t get, you’ll need to work with your sponsor to change, cancel, or postpone the team’s purpose.

Iterating Context

Team Room

After the chartering session is finished, keep a copy of the skills inventory, context diagram, and committed resources somewhere accessible to your team. You’ll refer back to them and update them as needed. Post the context diagram prominently in your team room.

Remember to take time to follow through on the communication plans you created during the “Boundaries and Interactions” activity. Be sure to follow through with your sponsor, too, regarding your committed resources.

After each of the first several times you communicate with a stakeholder group, take a moment to evaluate and improve the communication plan. Over time, your communication will settle into a comfortable groove.

It’s a good idea to revisit the team’s context from time to time—every six months or so—to refresh everyone’s memory, bring the information up-to-date, and revise communication plans. You don’t necessarily need to hold a full-blown meeting with stakeholders; it can be just a quick review in your team room. Do include your product manager, though, if they aren’t already part of your team.


What if we don’t have the resources we need, but our sponsor won’t listen?

That’s a tough situation to be in. If you know anybody with political savvy—such as a product manager, project manager, or coach—ask them to help convey the message. In the meantime, work on what you can, and keep reminding your sponsor and business stakeholders that you’re expected to do X, Y, and Z, but you’re only able to do X and Z because of the resources you’re missing.


Collecting the context information described here requires the participation of people who have a lot of knowledge about how your organization works. Be sure to include people with the perspective you need.


When your team understands their context and has the appropriate committed resources:

  • Your team has access to everything it needs to accomplish its purpose.

  • Your team isn’t blindsided by previously unknown stakeholder groups or expectations.

  • Communication with stakeholder groups is smooth and steady.

Alternatives and Experiments

Chartering context gives you a bunch of information about your team’s situation, but these three results are particularly important:

  1. Learning who your stakeholder groups are and what you need from one another.

  2. Deciding how you’re going to communicate with stakeholders.

  3. Adjusting your purpose and stakeholder expectations to match the skills, permissions, and resources available to your team.

The chartering agenda described here is just one way of achieving these results. You can use any approach.

Some organizations, rather than holding a chartering session, have project managers or business analysts interview stakeholders and create a set of documents. That can work, too, but don’t discount the value of having the team and stakeholders work directly together to learn each other’s perspectives. Having a chartering session in collaboration with your key stakeholders is great for creating connections and empathy in both directions. It’s much more visceral and memorable than a set of documents some people will never take the time to read.

You still have plenty of room for experimentation even if you keep the basic idea of a chartering session. Start with the practice as written, preferably with the help of a skilled facilitator, just to get a sense of how it’s supposed to work. Then experiment.

For example, a big two-day meeting can be pretty draining. What would happen if you spread it out over several smaller meetings? What about the specific activities? Can you think of ways of improving them, or replacing them? What if you do more pre-work up front? Or include different people?

If you’re in a large organization, try volunteering to conduct chartering sessions for other teams. They’re valuable for any team, not just Agile teams, and not just software teams, either. They don’t have to happen when a team first forms; if a team hasn’t been chartered before, team members are likely to benefit regardless of how long they’ve been working together. You’ll have plenty of opportunities to experiment, and there are lots of things you could try. See what you can learn.

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

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.


Product Managers, Coaches

We understand the reasons for our work.

Every team has a purpose: a reason for its existence and expectations about its output. But, far too often, that purpose isn’t communicated to the team. Instead, team members are told a lot of details about what to do...but not why they’re going to do it, or how it helps the company achieve its goals.

The Purpose practice is about making sure everyone understands the big picture, not just the details.

Start With the Vision

Before a product has a team, someone in the company has an idea. Suppose it’s someone in the Wizzle-Frobitz company. (Not a real company.) “Hey!” they exclaim, knocking their coffee off their desk. “We could frobitz the wizzles so much better if we had software to sort the wizzles first!”

Okay, it’s usually not that dramatic. The point is, a team’s purpose starts out as an idea focused on results. Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Sell more cloud services by providing machine learning technology. These are all real examples from teams that I’ve worked with.

Somewhere in the transition from idea to team, the compelling part—the vision of a better future—often gets lost. Details crowd it out. You have to staff a team with programmers, domain experts, and UX designers. You have to define features, plan releases, and report on progress. Hustle, people, hustle!

Nothing matters more than delivering the vision.

That’s a shame, because nothing matters more than delivering the vision. If the goal is to sell more cloud services through machine learning, then even the most amazing machine learning product is no good unless it’s part of the cloud platform. If you’re scaling so you can attract bigger customers, you’ve got to make sure the way you scale fits with those new customers’ needs. Conversely, if you figure out a way to attract those customers that barely involves scaling at all, does it really matter how you did it?

Identify the Purpose

The money for your team comes from somebody’s budget. They’re typically called the team’s executive sponsor. Although the sponsor technically has final say over the team’s purpose, it’s not always so cut and dry. They’re influenced by a variety of people, called key stakeholders, whose support is also necessary for your team to succeed.

Whole Team

Somebody has to unify all their ideas into a coherent purpose. They need to make sure the executive sponsor is enthusiastic about the purpose, the team understands it, key stakeholders agree with it, and other stakeholders accept it. As the “Whole Team” practice discusses, these skills are called “product management,” and at least one person who has those skills should be part of your team.

If there’s one clear visionary, the best approach is for that visionary to act as the product manager directly. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the team’s chances of delivering an impressive product.

Real Customer Involvement

If the visionary isn’t available to participate fully, as often happens, someone else must act as product manager. Try to get someone who is as close to the key stakeholders as possible. Like the children’s game of telephone, every step between the product manager and the key stakeholders reduces their ability to maintain and promote the team’s purpose.

In some cases, your team will actually have multiple purposes. If key stakeholders’ visions are significantly different, and they all have to be fulfilled, you can create a purpose for each one. Work on one at a time, switching between them periodically.

Document the Purpose

The goal of your conversations is to create alignment about the team’s work.

Product managers, as you talk with the sponsor and key stakeholders, refine their ideas into a draft purpose document. The goal of your conversations is to create alignment about what the team should work on, why it's working on it, and what success looks like. Your purpose document is a living document that reflects that joint understanding. You’ll revise it regularly.

Your draft purpose document is the first rough take at documenting that conversation. It’s used to help drive the conversation forward. The format of the document depends on your company’s standards. Some companies like to use Key Performance Indicators (KPIs) or Objectives and Key Results (OKRs). Whatever the format, it ultimately needs to answer three questions:

  1. Vision. Why is the team’s work valuable? Describe how the world—or, at least, your small part of it—will be different when the team is successful. Clarify why this is important to the company and its customers. Think long-term and focus on value.

  2. Mission. In the next three to six months, how will the team help achieve the vision? Describe what the team is expected to accomplish and what’s out of scope, but only at a high level. Leave plenty of room for the team to work out the details. Focus on outcomes and value before deliverables. It can be helpful to think of concrete deliverables first, but work backward from there to start with the why, not the what.

  3. Indicators. How will team members know they’re on the right track? Describe up to five high-level success indicators. Be concrete and unambiguous. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect. Explain how the indicator shows the mission’s value is being achieved. If this is difficult, it may mean your mission isn’t focused on value.

The purpose document is a vehicle for collaboration, not a contract.

The purpose document is a guide, not a set of hard and fast rules. It’s a way of helping people understand what the team is trying to achieve. As such, it represents people’s best understanding of the situation as it exists today. If the indicators are missed, that doesn’t mean the team is penalized. If they’re achieved, that doesn’t mean everybody stops working.

Remember the Agile Manifesto: “Customer collaboration over contract negotiation.” The purpose document is a vehicle for collaboration, not a contract. As work progresses and everyone gains new insights about the market, the team’s purpose will change.

Charter the Purpose

After you’ve created a draft purpose document and validated it with key stakeholders, you’re ready to discuss it with the rest of the team. This will typically happen during a chartering session, also called a liftoff, after the book of the same name [Larsen2016]. For details about how to plan the session, see the “Planning Your Chartering Session” sidebar.

Your chartering session typically represents the launch of your new effort, but it’s also valuable for any team that wants to better understand the big picture, even if it has already been working for years. It’s also fine for a chartering session to precede the team’s actual start date by a few weeks.

Review the draft purpose

The chartering session starts with a discussion of the team’s purpose.1 Begin by presenting the draft vision. It’s best if the person who led the creation of the draft is the one to present it. Typically, this will be the team’s product manager.

1This agenda is based on [Larsen2016] (ch. 5), with some small changes.

When you present the purpose, don’t just read it; explain the thinking behind it. The conversations that occurred. The trade-offs that were made. The compromises needed. This background will help everyone understand the “why” of the purpose better.

Consent to the vision

After reviewing the purpose, conduct a consent vote on the vision. (See the “Seek Consent” section.) The vision is owned by the sponsor, so it’s not likely to change, but conducting a consent vote will expose any major objections. If changes are needed, the sponsor will have to approve them. If the sponsor isn’t available, the person who led the creation of the draft purpose can act as their proxy in the meantime.

Improve the mission
The vision is owned by the sponsor, but the mission is owned by the team.

Although the vision is owned by the sponsor, the mission is owned by the team. It's responsible for making the mission happen, so the team needs to take ownership.

To help create that ownership, solicit feedback from team members about the mission. (Not the indicators, yet. Just the mission.) Ask for reactions and comments, then break into small groups, each with a cross-functional mix of team members and stakeholders. Each group will make improvements to the mission, which can range from minor wording fixes to major changes.

When time is up, each group presents their changes, their reasoning, and the rest of the group offers feedback. The facilitator then helps everyone consolidate their ideas back into a single mission. This might require another round of small-group sessions. Sometimes mixing up the groups can help.

Once the team has a revised mission, it’s time for another round of consent votes. Does the revised mission still meet the vision? Are the stakeholders satisfied that the mission will meet their needs? Is the team ready to take ownership and accountability for achieving the mission? As you conduct these votes, emphasize that the mission doesn’t need to be perfect. It will change over time. It just needs to be good enough for now.

Revise the indicators

Finally, it’s time to revise the indicators. This part can be the most contentious because they’re the most concrete. Good indicators are unambiguous. That can be a little scary.

Indicators are a guide, not a contract.

Remind everyone that the indicators are not a contract. They’re a guide. A way of checking if the team is on track or not. If your team isn’t on track to meet the indicators, it means you need more help or lower expectations. If you’ve exceeded the indicators, it means you’re ready to raise your expectations and shoot higher. The indicators will be iterated, just like everything else, and they’re not the only business metrics worth paying attention to.

To revise the indicators, break up into small cross-functional groups again. Divide the indicators among the groups. For each indicator, make sure it can be used to check progress toward achieving the mission, that it has a clear “yes” or “no” answer, and that the team is able to make it happen. Review the changes in the larger group, check consent, and continue revising until all objections are resolved.

As the group works on each piece, you may discover new things that cause you to go back and revise earlier parts of the purpose. That’s okay, and expected. It’s an iterative process.

Commit to the purpose

When you’re done, conduct a final consent vote. Does everyone present agree that the purpose is clear, valuable, and achievable? If so, it’s time to commit. Ask everyone present to record their commitment, either with a physical signature (if in person) or electronically (if remote).

After the purpose is ratified, ask your sponsor to return, if they aren’t already present. Review the changes to the purpose, ask them to commit to supporting it, and get their signature.

If your chartering session includes both purpose and context (see the “Context” practice), you can wait to bring your sponsor back until after discussing context.

Promote the Purpose

Informative Workspace
Visual Planning
Stakeholder Demos

Once the purpose is ratified, make it a constant touchstone. Use it to evangelize the team’s work to stakeholders. Refer to it when explaining your plans and priorities. Post a copy prominently in your team room, and refer back to it in planning sessions.

Be sure to continue to include your sponsor and other key stakeholders as work progresses. Invite them to visual planning sessions. Make sure they see demos, even if that means a private showing. Solicit their feedback about progress and ask for their help in improving your plans.

Involving your key stakeholders may be difficult, but make the effort. Stakeholders’ passion and excitement communicates far more clearly than any document can. If team members interact with their key stakeholders frequently, they’ll understand their purpose better, and they’ll come up with more ideas for increasing value and decreasing cost.

Make the effort to involve your key stakeholders.

If the mountain won’t come to the team, then the team must go to the mountain. In other words, if stakeholders don’t want to come to the team’s planning sessions, then the team’s product managers need to bridge the gap. Share the plan, get feedback, and conduct private demos. This is less effective than involving stakeholders directly in planning, and you need to make sure your product managers are able to effectively communicate stakeholders’ perspectives back to the team. If you don’t have anyone who can do that, talk to your executive sponsor about the risks of building the wrong thing. Your team might be better off doing something else until the stakeholders are available.

Iterate the Purpose

The team’s purpose will change over time. Indicators will age out and the team will learn new things about its stakeholders, customers, and market. Eventually, you’ll need to update the purpose. It’s a living document.

Set a specific time to revisit and revise the purpose. Every three or six months is a good idea. When you do, create a new draft and conduct another chartering session. It’s likely to go more quickly than your first one. Typically, the vision won’t change much, the mission will need some revision, and the indicators will need to be updated or replaced.


Can the whole team participate in the draft purpose discussions?

Absolutely. It’s a great way for team members to gain insight into their stakeholders. Typically, some team members will be more interested than others. Discuss how to divide the work as a team, deferring to team members with more stakeholder experience.

Discussing our purpose has led to contentious arguments, and there’s no agreement in sight. Should we proceed anyway?

You don’t need every stakeholder to agree on your team’s purpose, but you do need your key stakeholders to agree. Even if conversations about the team’s purpose lead to a lot of arguments, you should still pursue a unified vision and purpose. Otherwise, you’re likely to release software that’s equally fragmented and unsatisfactory.

It may be possible to split the purpose into multiple pieces that the team can execute serially. If that doesn’t work, consider engaging the services of a professional facilitator to help mediate the discussion.

Our sponsor is constantly changing their mind. How can we get them to pick a direction and stick with it?

Rapidly shifting goals tend to be common with entrepreneurial sponsors. It isn’t due to lack of vision or consistency; instead, they see a variety of opportunities and change direction to match.

If the purpose is constantly changing, it may be a sign that what you think of as the team’s purpose is actually a temporary strategy in a larger, overarching purpose. Take your concerns to the sponsor and stakeholders and try to identify that larger purpose.

Adaptive Planning

If you succeed in discovering the larger purpose, adaptive planning can help you keep up with your sponsor. Optimizing fluency may be a good fit as well. Its emphasis on learning and taking advantage of opportunities will fit in perfectly with your sponsor’s entrepreneurial spirit.

Your sponsor may continue to shift direction more quickly than you can implement their ideas. Your product managers should act as a buffer in this case, protecting the team from rapid shifts and explaining to your sponsor what the team can reasonably accomplish.


Every team needs a purpose. It doesn’t have to be in the format described here, but every team needs to know what’s expected from it and why. Identifying that purpose—correctly—can be tricky. It takes stakeholder buy-in and people with strong product management skills.

If you don’t have someone with the needed skills, your company is at risk of wasting a lot of money on the wrong results. Ask your executive sponsor to help resolve that risk before continuing.


When your team has a clear, compelling purpose that’s shared by the team and its stakeholders:

  • Prioritizing features is easy.

  • Product managers have no trouble justifying their prioritization decisions to stakeholders.

  • Developers contribute to planning discussions by suggesting ways to increase value while reducing cost.

  • Key stakeholders trust that the team is building what they need.

  • The organization supports the team’s efforts.

Alternatives and Experiments

Ultimately, this practice is about making sure everyone is on the same page about the high-level what and why of the team’s work. The exact way you achieve that agreement isn’t important. You can use a chartering session and purpose document as I’ve described here, but you can also try other approaches.

One startup I worked with started out with a normal purpose document, but they found that their business changed too rapidly for that to be useful. Instead, they maintained a wall of sticky notes with business priorities, in several categories (“BizDev,” “Cost Control,” “Capacity,” and “Risk Reduction”), and assigned each team to one or two of the priorities. The board was a central part of the founders’ weekly strategy review.

Some companies are so small and tightly knit that the team’s purpose may seem obvious to everyone involved. Even these teams can benefit from discussing their purpose in some form. Putting a team’s purpose in concrete terms tends to clarify people’s thinking and provides a forum for new ideas.

Further Reading

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen2016] is a comprehensive guide to Agile chartering. It’s the basis for this book’s Purpose, Context, and Alignment practices. Its guidance about preparing and facilitating chartering sessions is particularly useful.

Impact Mapping [Adzic2012] has a nice discussion of how to discover goals and create good indicators (the author calls them “measurements”) in the “Creating an Impact Map” chapter.

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.

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.

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.