Jan 28: 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 28th: User Stories

User stories. Possibly more ink has been spilled on this topic than any other aspect of Agile. In this session, we’ll take a close look at user stories: how to create, split, and use them. We’re joined by Bill Wake, an agile coach who is known for the INVEST acronym for user stories, the Arrange-Act-Assert TDD pattern, and for articles at xp123.com.

WhenJanuary 28th, 8-8:45am Pacific (calendar invite)
Where🎙 Zoom link
Reading 📖 Stories
Discussion🧑‍💻 Discord invite

Discussion prompts:

  • As Alistair Cockburn says, stories are “promissory notes for future conversation.” And yet many organizations use stories as a form of documentation instead. What are the pros and cons of this approach?

  • The Connextra template for stories (“as an X I want Y so that Z”) has a lot of adherents. Do you have a preferred template? Why or why not?

  • Splitting stories so that they’re both small and customer-centric takes a lot of practice. What are your favorite techniques for splitting stories?

  • If you could magically change just one thing about the way organizations approach user stories, what would it be?

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

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

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

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


Whole Team

We plan our work in small, customer-centric pieces.

Stories may be the most misunderstood idea in all of Agile. They’re not requirements. They’re not use cases. They’re not even narratives. They’re much simpler than that.

Each story is a reminder to have a conversation.

Stories are for planning. They’re the playing pieces of the planning game. That’s it! Alistair Cockburn calls them “promissory notes for future conversation.” Each story is a reminder to talk about something the team needs to do. They’re written on index cards, or the virtual equivalent, so you can pick them up, move them around, and talk about how they fit into your plan.

Whole Team
Team Room

Because stories are just a reminder to have a conversation, they don’t need to be detailed. In fact, detailed stories are a sign that people are missing the point. You’re supposed to have a whole team, a team room, and talk together regularly. The story is the reminder. A way of sparking conversations about the details.

Although stories are supposed to be brief, it’s okay to add additional notes when it’s helpful. If there’s something important you want to remember, or a technical detail that you need keep track of, go ahead and jot it down. Just don’t feel obligated to add more detail. The card isn’t meant to be a requirements document. Just a reminder.

How to Create a Story

The Planning Game

Everything that your team needs to do, other than normal overhead, needs a story. That’s how work gets prioritized. No matter your role on the team, when you learn about something the team needs to do, write it on a card and queue it up for discussion in your next planning game. You just need to write enough to start the conversation and jog people’s memories in the future. For example:

  • “Warehouse inventory report”

  • “Full-screen demo option for job fair”

  • “Customizable branding on login screen”

You don’t have to use a story template.

Some people like to use the Connextra template for writing stories, like this: “As a (role) I want (something) so that (result).” You’re welcome to use that format, if you want, but it’s not required. Connextra created that template as an experiment, to help remind them of how they were serving their users. You’re free to try your own experiments, or to just jot down a few words.

Although stories are short, they still have two important characteristics:

  1. Stories represent customer value and are described in customers’ terminology. They describe work that customers recognize and value, not implementation details. This allows your on-site customers to make informed prioritization trade-offs.

  2. Stories have clear completion criteria. It doesn’t have to be written on the card, but on-site customers need to understand what it means for a story to be “done” and be able to describe it when asked.

The following examples are not good stories:

  • “Automate integration build” doesn’t represent customer value.

  • “Deploy to staging server outside the firewall” describes implementation details rather than an end result, doesn’t use customer terminology, and would likely be difficult for on-site customers to prioritize. “Make demo available to customers” would be better.

Customer Value

Stories need to be customer-centric. Write them from customers’ point of view, and make sure they provide something that benefits customers, users, or business stakeholders. On-site customers are in charge of priorities, so if they don’t think a story has value, they won’t include it in the plan.

Customer-centric stories aren’t necessarily valuable to the end user, but they should always be valuable from the perspective of on-site customers. For example, a story to produce a trade-show demo doesn’t help end users, but it helps your business sell the product.

Similarly, some stories will be too small for real customers to care about. For example, if you’re creating a credit card billing system, one of your stories might be, “Special handling for merchant decline code 54.” But on-site customers should know how each story contributes to the overall whole and be able to make prioritization trade-off decisions. (“We can postpone code 54 for now, but we absolutely must handle code 41, because that’s a fraud alert.”)

A good way to ensure that your stories are customer-centric is for on-site customers to write the stories themselves.

One practical result of customer-centric stories is that you won’t have stories for technical issues. There should be no “Design domain layer” story, for example—customers wouldn’t know how to prioritize it. Although developers can tell customers how to prioritize technical stories, that distracts the team from focusing on value and can leave on-site customers feeling disenfranchised.

Incremental Design

Instead, spread technical considerations across all stories. Rather than a single “Design domain layer” story, for example, incrementally modify the design of your domain layer with every story. This is easier if you use evolutionary design, which I discuss in the “Design” chapter.

Developers often struggle with making stories customer-centric. Keep practicing! Without customer-centric stories, on-site customers have trouble making good prioritization decisions, and ruthless prioritization is the secret to releasing sooner.

Ruthless prioritization is the secret to releasing sooner.

Developers, to make your stories customer-centric, talk them over with your on-site customers. Explain the outcome you’re trying to create and ask customers to write the story in their own words. If you need to, you can add a note to remind you of the technology the story relates to.

For example, if you think that the team needs to switch to another database technology, you could explain it this way: “We need to move our articles to a database that handles full-text search better. Searches already take over half a second, and it will keep getting worse as more articles are added.” A customer might write, “Stop article search performance from getting worse,” and you can add, “(full-text search database).”

Splitting and Combining Stories

Stories can be any size. When you first come up with an idea, your stories could be fairly large and vague: for example, an online store might have a “check-out page” story.

The Planning Game

To provide visibility and control, though, the team needs to finish multiple stories every week. During the planning game, you’ll split those big stories into smaller ones and combine small stories into bigger ones.

Combining stories is easy. Take several related stories, staple them together, and write your new estimate on the front, if you’re using estimates. In a virtual team room, cut and paste the story descriptions onto a single virtual card.

Splitting stories is more difficult, because they need to remain customer-centric. The trick is to find the essence of the story, not the individual steps it involves. What is the fundamental value the story provides, and what are the embellishments that build on that fundamental value? Write that fundamental essence as a story and each embellishment as an additional story.

If that’s hard to imagine, Mike Cohn has an excellent chapter on how to split stories in his book Agile Estimating and Planning. [Cohn2005] He provides the following options. (The examples are my own.)

  • Split according to priorities. For example, the “check-out page” story could be split into “check out” (high priority), “coupons” (medium-high priority), “gift receipts” (medium-low priority), and “gift wrap” (low priority).

  • Split along the boundaries of data supported by the story. For example, a story about collecting billing information could be split into “collect credit card info,” “collect gift card info,” and “collect PayPal info.”

  • Split based on the operations that are performed within the story. For example, a story about processing credit card payment could be split into “collect credit card info,” “validate credit card info,” and “charge credit card.”

  • Split into separate CRUD (Create, Read, Update, Delete) operations. For example, a story about administering customer data could be split into “add customer,” “view customer,” “edit customer,” and “delete customer,” as well as “list customers” and “sort customers.”

  • Split out cross-cutting concerns (such as security, logging, and error handling) by making multiple versions of your stories. For example, a story about charging credit cards could be split into “charge credit card,” “log credit card charges,” and “handle credit card rejection.”

  • Split out nonfunctional concerns (such as performance, stability, scalability, and so forth). For example, a story about charging credit cards could be split into “charge credit card” and “support 100–200 credit card transactions per minute.”

The best splits are the ones that allow you to prioritize stories separately and in any order. That takes practice and isn’t always possible, so don’t worry if you have trouble doing so.

Tiny stories

The more you split a story, the harder it can be to make it customer-centric. Don’t give up. If you can’t think of anything else, at least describe the technical work in business terms. This allows on-site customers to understand and remain in control of priorities. It also makes it easier to explain your plans and progress to others.

For example, if you have a story to “send an email when wire transfer completes,” programmers might say it involves the following tasks:

  1. Register callback with banking service

  2. Log webhook calls

  3. Secure webhook

  4. Parse webhook transaction data and query database

  5. POST to transactional email service

Turn them into stories by restating them in business terms:

  1. Tell bank to notify us when wire transfer completes

  2. Log wire transfer notifications

  3. Prevent forged wire transfer notifications

  4. Look up customer associated with wire transfer notification

  5. Send email to customer when wire transfer notification received

Again, it’s better to have stories that are independent of each other, but this is a good fallback option when you can’t figure out what else to do.

Special Stories

Most stories will add new capabilities to your software, but anything that requires the team’s time and isn’t part of their normal day-to-day work needs a story.

Documentation stories
Incremental Requirements
Incremental Design

Agile teams need very little documentation to do their work, due to their use of incremental requirements and evolutionary design, but you may need the team to produce documentation for other reasons. Typically, that documentation will be part of the work for a larger story, but you can also have documentation-specific stories.

Stories for creating documentation are just like any other: make them customer-centric and be sure you can identify specific completion criteria. An example of a documentation story is “tutorial for setting up billing.” See the “Documentation” section for more details.

Bug stories
No Bugs
Done Done

Ideally, your team will fix bugs as soon as it finds them, before declaring a story “done.” Nobody’s perfect, though, and you will miss some bugs. Track these bugs with stories such as “fix multiple-user editing bug.” Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

Bug stories can be difficult to size. Often, the biggest timesink when debugging is figuring out what’s wrong, and you usually won’t know how long that will take until you’ve done it. Instead, put a timebox around it: “We’ll spend up to a day investigating this bug. If we haven’t fixed it by then, we’ll discuss it as a team and schedule another story.” On the card, write “timebox 1 day.”

“Nonfunctional” stories

Performance, scalability, and stability—nonfunctional requirements—should be scheduled with stories, too. Like all stories, they need a concrete, customer-valued goal. Unlike other stories, though, you’re likely to need developers to help define the goal. It’s not enough to say, “the software needs to be stable” or “the software needs to be fast.” You need to be able to describe exactly how stable or fast it should be.

When creating nonfunctional stories, think about acceptable performance—the minimum necessary for satisfactory results—and best possible performance—the point at which further optimization adds little value. You don’t have to write these numbers on the card, or necessarily decide on them right away, but it’s often useful to do so.

Why have two numbers? Nonfunctional requirements, particularly performance optimization, can consume an infinite amount of time. Sometimes you reach your “best” goal early: this tells you when to stop. Other times you struggle even to meet the “acceptable” goal: this tells you when to keep going. For example, the performance criteria for a web page might be, “support 500–1,000 requests per minute, with a latency of 50–200 ms.”

Like bug stories, nonfunctional stories can be difficult to size. You can use timeboxes for them, too.

Operation and security stories
Build for Operation
Whole Team

It’s not enough to build software for users. If it’s online, you have to build it to be monitored, managed, and secured as well. For example, you’ll need to be alerted when performance degrades, and you’ll need a way to conduct security audits and respond to breaches.

On-site customers often have trouble thinking of these sorts of stories, which is why it’s important that people with operations and security skills be part of the planning process. To help on-site customers understand their priority, discuss the stories in terms of the value they provide, not the technical work to be done.

Often, that value comes in the form of reduced risk. For example, a story to add distributed tracing could be described as, “Make it easier to find source of performance problems during performance emergencies (distributed tracing).”

Spike stories
The purpose of a spike story is to size another story.

Sometimes, developers won’t be able to size a story because they don’t know enough about the technology required to implement the story. When this happens, create a spike story to research that technology. The purpose of a spike story is to size the other story, not to design the solution or research every nook and cranny. For example, “figure out if ‘send HTML email’ story should be split.” Or, more concisely, “spike ‘send HTML email.’”

Spike Solutions

They’re called spike stories because you’ll often use a spike solution to do the research. But you don’t have to.

Clean-up stories

Agile teams are expected to work in a way that allows them to continue indefinitely, and this includes having enough slack in their schedule to constantly improve their codebase. If you use slack correctly, you shouldn’t need to explicitly schedule time for cleanup. The parts of the code you work on most often will automatically get cleaner over time. That said, sometimes you inherit crufty code, and it’s worth dedicating extra time to cleaning it up.

You shouldn’t need clean-up stories to keep your code clean.

Like any other story, clean-up stories need to be customer-centric. They must be entirely optional. You shouldn’t need clean-up stories to keep your code clean. You don’t ever want to be in a position where developers have to ask customers for permission to do necessary work, and you don’t want customers to have to ask developers for permission to ignore a story.

If you do make a clean-up story, speak in terms of the business benefit it provides. Often, that benefit is in the form of decreased development time. Crufty code is bug-prone and tends to take a lot of time to change safely. So, for example, instead of saying “refactor authentication service,” say “reduce likelihood of authentication bugs,” or “decrease time needed to make authentication changes.”

You probably won’t be able to quantify the improvement, but be prepared to provide examples that illustrate the benefit. Like this: “Know how we keep running into problems and delays whenever we change something related to login? This will solve that.”

Reflective Design

For clean-up stories that don’t have a clear stopping point, use a timebox. To make sure you can stop when your time is up, avoid rewriting code. Instead, incrementally refactor it, keeping the code working at all times.

Meetings and overhead

Don’t create stories for activities such as the planning game, all-hands meetings, and other organizational overhead. If you have an unusual time commitment, such as training or an off-site day, just expect to get fewer stories done that week.

Architecture, design, technical infrastructure
Incremental Design
Evolutionary System Architecture

Don’t create stories for technical details. Development tasks are part of the cost of implementing stories. Use evolutionary design and architecture to break large technical prerequisites into small pieces that you can implement incrementally.


Our customers understand development. Do we still have to write stories to be customer-centric?

It’s much more difficult to create customer-centric stories than developer-centric stories, so it’s tempting to find excuses to avoid them. “Our customers don’t mind if we have developer-centric stories” is one such excuse.

Your plan should be about value, and so should your stories.

Even if customers understand developer-centric stories, customer-centric stories lead to better plans. Your plan should be about value, and so should your stories.

If your customers are developers—if you’re developing software for developers, such as a library or framework—then your stories can use developer-centric language. Even so, they should reflect your customers’ perspective. Create stories about your customers’ needs, not your implementation details.

Shouldn’t developers make the software fast by default? Why do we need performance stories?

Nothing comes for free in software development. You don’t have to create performance stories, but you do need to know what “fast” means in your situation, and developers will need to spend time to make it happen. Splitting nonfunctional requirements into separate stories doesn’t change the amount of time required; it just gives you more insight and control over how that time is spent.

How do we make time for technical infrastructure and large refactorings, such as replacing a test framework?

Incremental Design
Reflective Design

Perform this sort of work incrementally, using evolutionary design and the slack in your team’s schedule. For large refactorings, you can also use clean-up stories, but working incrementally is usually better.


Incremental Requirements

Stories are no replacement for requirements. You need another way of getting details, whether through on-site customers and incremental requirements (the Agile way) or a requirements document (the traditional way).


When you use stories well:

  • On-site customers understand all the work they approve and schedule.

  • It’s easy to explain to stakeholders what the team is working on and why it matters.

  • Your team works on small, manageable pieces and makes customer-valued progress multiple times per week.

  • Stories are cheap to create and easy to discard.

Alternatives and Experiments

The main distinction between stories and the line items in most plans is that stories are customer-centric. If you can’t use customer-centric stories for some reason, customers cannot participate effectively in planning. This will eliminate one of Agile’s primary benefits: the ability to create better plans by blending insights from both customers and developers. You’ll also have trouble explaining progress to stakeholders. Unfortunately, no alternative practice will help.

Stories are a simple idea, but they’re also connected to a perennial software development problem: deciding what to build. Simple idea plus important problem means everybody has their own spin on stories. You can find any amount of templates and story writing advice online. All will claim to solve this problem or that so the team can build better software.

These experiments tend to miss the point. Stories are about the conversation, not the card. Any change that puts more focus on writing than talking—a template, more detail, a taxonomy of stories—is going in the wrong direction.

Similarly, stories aren’t how you decide what to build. They’re just a reminder. There are a lot of very good ways of understanding customer and business needs and turning that understanding into action. (I cover some of them in the “Visual Planning” practice.) Don’t use stories to create business understanding. Create business understanding first, make decisions, and use stories to remind you about those conversations and decisions.

Jeff Patton says stories are like a vacation photo: they remind you what happened. Because stories are just a reminder, they don’t need to be complicated. When you experiment with stories, think of ways of putting more emphasis on the conversation and less emphasis on the story, while still doing just enough to remind people what was discussed and decided. Make the vacation better, not the photo.

Finally, another common change is to track stories in a spreadsheet, or issue tracking tool, rather than on index cards. That can make lists of stories easier to read, but it makes visualizations and collaboration more difficult. It’s a net loss that’s hard to appreciate without experience. Give cards at least three months before trying alternatives. Even if your team is remote, use virtual index cards on your virtual whiteboard rather than a spreadsheet or issue tracking tool.

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


Agile is adaptive, not predictive. It’s one of the things that sets Agile apart—the very source of its name!—and one of the biggest culture shocks for organizations new to Agile. And nowhere is it more apparent than in the way Agile teams plan their work.

This chapter has the practices you need to effectively make and adapt your plans. Because adaptive planning can take time for organizations to accept, it also discusses how to make predictive plans with an Agile team.

  • The “Stories” practice helps your team plan its work in small, customer-centric pieces.

  • The “Adaptive Planning” practice balances adaptability with predictability to focus your team’s plans on value.

  • The “Visual Planning” practice creates plans that communicate context and options.

  • The “The Planning Game” practice creates a detailed plan for guiding your team’s next steps.

  • The “Real Customer Involvement” practice allows your team to include customers’ perspectives in their plans.

  • The “Incremental Requirements” practice determines requirements details just before they’re needed.

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