AoAD2 Practice: Alignment

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.


Coaches, Whole Team

We have norms that allow us to work together without conflict.

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.

A team is a group of people who depend on each other 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 each other 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 “Charter the Team” 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 [Larsen and Nies 2016] (Chapter 6), with some changes. I’ve removed their “simple rules” activity and added the standards discussion.

Get to know each other

Start your alignment discussion by getting to know each other better. If you’ve conducted the context discussion, you’ll have already created a skills inventory. Now it’s time to go deeper.


This activity requires a bit of advance preparation. First, post the team’s purpose and skills inventory in a prominent location. (If you haven’t created a skills inventory yet, you can do so when people answer the first question in this activity.) Second, provide a handout with the following questions.

  1. Who am I? Recap the skills, experience, connections, and permissions from the skills inventory, 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 better? 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?

When you’re ready to start, 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 each other as whole people, rather than just names, faces, and titles. It’s most effective when done face-to-face, so if you have a remote team, make an extra effort to have this conversation by video.

Next, prepare a whiteboard, flipchart, or portion of your virtual shared workspace with three columns. Label the first two “Same” and “Different.” Then ask the group to use simultaneous brainstorming (see the “Work Simultaneously” section) to answer two questions: “In what ways are we the same?” and “In what ways are we different?” Put each answer on a sticky note, or its virtual equivalent, and add it to the board. Prompt participants to go broad, including everything from the obvious to the profound.

People might be reluctant to speak up, at first, so let the brainstorming exercise go on a bit longer than is comfortable. When the ideas trickle to a stop, wait longer—a minute, two, or even three—and allow the silence to stretch out. People will often add a few more ideas that they were holding back, and these last ideas can be the most valuable.

Give everyone a moment to review the sticky notes, then label the third column “DTMD,” for “differences that make a difference.” Ask participants to discuss the differences they’ve brainstormed. Which differences will have the most impact on the team and their ability to achieve their purpose? As people nominate sticky notes, move them from the “Different” column to the “DTMD” column.

After the important differences have been collected, discuss the list and narrow them down to the top 5-10 most important. Take a few minutes for a free-form discussion about what these differences mean for the team.

This activity can feel awkward or “touchy-feely.” It’s worth doing anyway. The best teams are composed of people with diverse backgrounds and experiences, because diversity of experience leads to diversity of ideas. Those ideas will help fuel your team’s success.

This activity does more than just help team members get to know each other better. By taking the time to understand and embrace your differences, you’re helping to ensure that people with unusual experiences will be comfortable sharing the wisdom gained from those experiences, and you’re ensuring that people with mainstream experiences are aware of the viewpoints their fellow team members can bring to bear.

Create working agreements

Working agreements guide your team’s behavior by describing what you expect from each other. 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.

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 in these categories, too. You won’t have to choose them, but make sure they’re considered.

  • The practices your team will use. (I recommend starting by-the-book with every practice in your team’s chosen zones, as discussed in the “How to Be Agile” chapter.)

  • For remote teams, how you’ll coordinate and collaborate (see the “Designing Remote Collaboration” section).

  • How you’ll make decisions (see the “Work Simultaneously” section, the “Seek Consent” section, and the “Agree to Experiment” section)

  • For in-person teams, how you’ll deal with distracting background noise (see the “Team Room Prequisites” section).

  • 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 (see the “Team Room Prequisites” section).

After generating the 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 not to vote for proposals that they think everyone on your team will do automatically—you’re selecting the agreements that need your team’s attention.

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 have opportunities to improve your working agreements 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 each other,” 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 a 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 your team needs standards. What’s not as important is their actual content. Over time, you’ll amend and improve them. The most important thing you may learn from defining standards is how to disagree constructively.

Remember, few decisions are irrevocable in Agile; mistakes are opportunities to learn and improve. Ward Cunningham put it well:2

2Quoted at

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

Once you have your definition of “done,” define any industry-specific standards you need, such as coding standards, by splitting up into corresponding specialties. Anybody who doesn’t need to define a standard can take a break or join another group. If somebody has multiple specialties, they should choose one group to work with, and agree to accept the decisions of the other groups. (Remember, the standards can change later!) Limit the discussion to one hour or less, following the same process that you used for the definition of “done.”

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

Iterating Alignment

As with everything else Agile, your agreements (which includes your standards) aren’t set in stone. The standards, in particular, need some time to bake. Schedule another meeting to discuss your standards a few days after you start working together, and then another one a few weeks after that. An hour should be enough. This will allow you to try your standards in practice. If there’s still disagreement about a standard after that time, agree to experiment with one approach, then the other, then revisit the question.

Team Room

After these initial standards meetings—which you can use to revise your other working agreements, too—you can change your agreements 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.

Your list of team agreements (the first list, not the standards) is meant to be for agreements that you’re actively working on establishing. It’s best to limit this list to about five agreements. When an agreement becomes second nature, you can take it off the list and make room for a new agreement.

Adhering to Agreements

People make mistakes. Assume your colleagues are professional and well-meaning. If someone isn’t following an agreement, assume that there’s a good reason, even if all the evidence is 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

For technical agreements such as standards, pairing, mobbing, and collective code ownership are 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.

Violations of social agreements are trickier, but it’s still best to start by assuming good faith. Perhaps they misunderstood the agreement, or feel 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, whether technical or social, start by talking 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 the objector is on board with the agreement but still isn’t 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 accepts a null.”

During this discussion, you may learn that the objector doesn’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 need 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 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, like code formatting, can be automated. Don’t spend too much time on this, but if you can do it easily, you might as well. Be sure to coordinate automated changes with other team members so their work isn’t disrupted.


Your team has to be willing to work as a team before they can create effective working agreements. See the “How to Be Agile” chapter for more about team buy-in.


When your team has effective working agreements and standards:

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

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

  • The standards allow team members to more easily understand parts of the system they aren’t familiar with.

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 distracting 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 non-confrontational, but you could use many other facilitation techniques.

Be careful conducting experiments before 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 have experience with successful alignment discussions, go ahead and experiment with changes to the format. 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.

Further Reading

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen and Nies 2016] has much more detail about facilitating chartering discussions. It also includes an additional activity, Simple Rules, that I left out of this book.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Practice: Context

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.


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?

These are all part of your team’s context: the larger system that 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, which typically includes purpose and alignment discussions as well, is a good time to discuss your team’s context. As discussed in the “Charter the Team” sidebar, the chartering session includes your team’s key stakeholders, team members, and product manager (if they’re not already part of the team). The team’s executive sponsor might also participate, and it’s best if you have a neutral facilitator.

You can discuss context in a separate session instead, if that’s more convenient. You’ll still need the same participants, and 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 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. Afterwards, 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 [Larsen and Nies 2016] (Chapter 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 XXX 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 or shared document. 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 flip charts or their virtual equivalents. 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 collaborative workspace as normal. Draw a circle in the center for your team.

Next, 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. That includes 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. Groups that are similar can be combined. For example, you might group most software vendors into a single sticky labelled “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 flip-chart paper, start with something temporary, like pencil or another sticky note, so you can make changes easily.

While the group works on the context diagram, prepare a few more flipcharts (or virtual equivalents). Label them “Resources Needed” and “Communication to Provide” and put them next to the “Skills Needed” and “Permission 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 in order 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. (It’s best if this is someone with good organizational skills.) 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 need, but won’t be able to get.

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; and

  3. The process needed 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.

Sponsor commitment

Wrap up your discussion of context by inviting your sponsor back into the room, if they’re not already there. If you’re also chartering 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 you need, take a closer look at the tradeoffs involved. How does the lack of each resource (or skill, or permission) affect your team’s ability to fulfill their 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 tradeoffs. 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 they ask 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 their purpose without them. If you have any essential resources that you can’t get, you’ll need to work with your sponsor to change, cancel, or postpone the purpose.

Iterating Context

Team Room
Whole Team

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. (You might want to transfer them to a cleaned-up document.) It might be useful to 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. (You can also bring it up in the team retrospective.) 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 back up to date, and revise communication plans. You don’t necessarily need to hold a full-blown meeting with stakeholders; it can just be 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 doesn’t want to hear it?

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. Make sure you 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 they need to accomplish their purpose.

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

  • 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 each other.

  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, they’re likely to benefit regardless of how long they’ve been working together. You’ll have plenty of opportunities to experiment, and there’s lots of things to try. See what you can learn.

Further Reading

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen and Nies 2016] has more information about chartering context and facilitation in general.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Practice: Purpose

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.


Product Managers, Coaches

We understand why our team is valuable.

Every team has a purpose: a reason for their existence, and expectations about their output. But, far too often, that purpose isn’t communicated to the team. Instead, the team is 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!

That’s a shame, because nothing matter 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 Vision

The money for your team comes from somebody’s budget. As III used to say, the person who owns that budget is your team’s Gold Owner. They’re also the team’s Goal Donor. (Say them both out loud.) That’s because of the Golden Rule: they that has the gold, makes the rules.

Ultimately, the team needs to satisfy the Gold Owner, who, more prosaically, is typically called the team’s executive sponsor. And although the Gold Owner, as the Goal Donor, should be in charge of the team’s purpose, it’s not always so cut and dry.

Sometimes the vision strikes as a single, compelling idea. One person gets a bright idea, evangelizes it, and convinces the executive sponsor to pursue it. More often, the vision isn’t as clear. There are multiple stakeholders, each with their own unique idea of what the team should deliver, and each with their own influence over the sponsor.

Whole Team

The team needs a single, clear purpose. Somebody has to unify the visions into a purpose, communicate it, and promote it. They need to make sure the executive sponsor is enthusiastic about the purpose, the team understands it, influential stakeholders agree with it, and other stakeholders accept it. As the “Whole Team” practice discusses, people with the skill to so are called “product managers,” and at least one should be helping your team.

Like the children’s game of telephone, every step between the product manager and the original visionaries reduces their ability to maintain and promote the team’s purpose. If there’s one clear visionary, the best approach is for that visionary act as the product manager directly. This reduces the possibility of any telephone-game confusion. 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.

If the visionary isn’t available to participate fully, as often happens, someone else must act as product manager. The next best option is to choose someone the visionary and sponsor both know and trust: someone who regularly interacts with both and understands how they think.

Frequently, the team will have multiple stakeholders who influence the overall vision. It’s particularly common when developing tools for internal use. If this is the case, you need a product manager with the skill and political savvy to unify their visions.

Before you go too far down that road, however, question whether the ideas should be combined. Is each stakeholder’s vision significantly different? Can you execute them serially, one at a time? If so, you probably have multiple purposes, and working on one at a time—switching off periodically—might be a better approach.

Create a Draft Purpose

As you work with the sponsor and key stakeholders, refine their ideas into a document that describes your team’s overall purpose. The way you do so will depend on your company’s standards. Some companies like to use Key Performance Indicators (KPIs). Others will use a template of some sort. Whatever the format, you ultimately need 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.

  2. Mission. What will the team do to help achieve the vision? Describe what the team is expected to accomplish, but only at a high level. Describe what isn’t part of the mission, too. Leave plenty of room for the team to work out the details.

  3. Mission Tests. How will the team know they’re on the right track? Describe up to five high-level success indicators. Be concrete, include time frames, and make sure each has an unambiguous yes/no result. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect.

The draft purpose 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 mission tests 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 draft purpose 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.

Chartering Purpose

With the draft purpose in hand, 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 [Larsen and Nies 2016]. Your chartering session typically represents the launch of your new effort. For details about how to plan the session, see the “Planning Your Chartering Session” sidebar.

Chartering isn’t just for when work starts. It’s valuable for any team that wants to better understand the big picture, even if they’ve 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 [Larsen and Nies 2016] (Chapter 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—remember the Golden Rule—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

Although the vision is owned by the sponsor, the mission is owned by the team. They’re the ones responsible for making it happen, so they need to take ownership.

To help create that ownership, solicit feedback from team members about the mission. (Not the mission tests, 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 Mission Tests

Finally, it’s time to revise the mission tests. This part can be the most contentious, because they’re the most concrete. Good mission tests have a “yes” or “no” answer. They have a concrete date and an explicit business goal. That can be a little scary.

Remind everyone that the mission tests 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 mission tests, it means you need more help or lower expectations. If you’ve exceeded the mission tests, it means you’re ready to raise your expectations and shoot higher. The mission tests will be iterated, just like everything else, and they’re not the only business metrics worth paying attention to.

To revise the tests, break up into small cross-functional groups again. Divide the mission tests among the groups. For each test, make sure each test can be used to check progress towards achieving the mission, that it has a concrete point at which it can be evaluated, 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 all 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

Team Room
Informative Workspace
Release Planning
Iteration Demo

Once the purpose is decided, 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 release planning sessions. Make sure they see demos, even if that means a private showing. Involve them in discussions with real customers. Solicit their feedback about progress and ask for their help in improving your plans. They can be invaluable for helping with company politics, too.

Involving your key stakeholders may be difficult, but make the effort. The less your team and key stakeholders communicate, the less your team will understand the product they’re building. While the purpose document is necessary and valuable, stakeholders’ passion and excitement communicates far more clearly. If the team interacts 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.

When I’m faced with inaccessible sponsors or stakeholders, I don’t assume that the problem is insurmountable. Because their participation is so valuable, I take extra steps to include them in any way I can. I don’t take organizational structures for granted, and I push to remove barriers.

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. Mission tests will age out and the team will learn new things about their 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 focused on the purpose. It’s likely to go a lot quicker than your first one. Typically, the vision won’t change much, the mission will need some revision, and the mission tests will need to be updated or replaced.


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, but you do need the most important stakeholders to agree. (Who’s “most important?” That’s for your sponsor and product managers to decide.) 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 visionary 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 visionaries. It isn’t due to lack of vision or consistency; instead, your sponsor sees a variety of opportunities and changes 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 visionary and stakeholders and try to identify that larger purpose.

Adaptive Planning

If you succeed in discovering the larger purpose, adaptive release 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 visionary’s entrepreneurial spirit.

Your visionary 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 visionary what the team can reasonably accomplish.

Can individual releases each have their own purpose?

Absolutely! This can be a great way to iterate on the team’s purpose. Often, the vision will stay the same, but the mission and mission tests will change to meet the needs of each release. It’s a great way to prepare for the next round of release planning.


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 them 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 their 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 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 [Larsen and Nies 2016] 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.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Practice: Energized Work

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

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 especially 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 web sites.

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?

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. Spend time with family and friends and engage in activities that take your mind off of work. 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 as ensuring focus—it’s easy to tune out—but it is good for preventing the errors that occur when you’re tired.

It may sound silly, but having healthy food available in the workplace is another way to support energized work. Fruits, vegetables, and yogurt 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. [McConnell 1996] reports that software developers are motivated to do good, intellectually challenging work. 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 targets, make sure the targets are realistic and based on the team’s forecasts.

Whole Team

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 product and project management skills should deal with organizational politics, letting the rest of the team know what’s important and shielding them from what isn’t.

Informative Workspace

People with project management skills can also help team members by pushing back on unnecessary meetings and conference calls. Providing an informative workspace and appropriate reporting 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.

Team Dynamics

Finally, jelled teams have a lot of energy. They’re a lot of fun, too. You can recognize a jelled 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. As with energized work, you can’t force jelling, but you encourage it with by paying attention to team dynamics. The classic work on this subject, Peopleware: Productive Projects and Teams, now in its third edition [DeMarco and Lister 2013], is well worth reading.

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

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.

Team Room

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

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

If you work overtime one week, don’t work overtime again the next week. If I see team sprinting in this way more than once or twice per quarter, I look for deeper problems.


Some organizations may make energized work difficult. If your organization uses the number of hours worked as a yardstick to judge dedication, you may be better off sacrificing energized work and working long hours. The choice between quality of life and career advancement is a personal one 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.

  • Your team pays attention to detail and looks for opportunities to improve their work habits.

  • 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 extreme form of this organization is the death march organization, which requires employees to work extensive overtime week after week. Sadly, death marches don’t happen because of the massive value to be gained; just the opposite. [DeMarco and Lister 2003] (p. 161) explains: “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?”

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

Further Reading

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

Rapid Development: Taming Wild Software Schedules [McConnell 1996] has a chapter called “Motivation” with a nice chart comparing programmer motivations to the motivations of managers and the general population.

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

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Practice: Team Room

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

Questions for reviewers:

  • Are there any additional collaboration techniques I should include?

  • Are the Cargo Cult stories unfair or unrealistic?

Team Room

Whole Team, Coaches

We collaborate rapidly and effectively.

When people can’t communicate directly, the effectiveness of their communication decreases. Misunderstandings occur and delays creep in. People start guessing to avoid the hassle of waiting for answers. Mistakes appear. Us-versus-them attitudes start to form.

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

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

Whole Team

So instead, Agile teams communicate directly using a team room. A team room is a space, either physical or virtual, where the team works and collaborates together. Rather than having someone talk to domain experts and write a document for programmers to read later, Agile teams include domain experts and other on-site customers on the team. When programmers need to understand what to do, they talk to the on-site customers directly. If they have a question, they just ask.

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

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

Consider the “The Rest of the Story” sidebar from this new perspective. You’re a programmer who needs some information from your domain expert, Lynn. For the sake of this example, assume you have a physical team room.

This time, rather than sending an email, you turn your head. “Lynn, can you clarify something for me?”

Lynn says, “Sure. What do you need?”

You explain the problem, and Lynn gives his answer. “No, no,” you reply. “That’s a different problem. Here, let me show you on the whiteboard.”

A few minutes later, you’ve hashed out the issue and you’re back to coding again. Except now there’s an edge case you hadn’t considered. “What a second, Lynn,” you say. “There’s something we didn’t consider. What about...”

After some more discussion, the answer is clear. You’re a little surprised: Lynn’s answer was completely different than you expected. It’s good you talked it over. Now, back to work! You’ve already spent 20 minutes on this nitpicky little issue.

Secrets of Collaboration

Whole Team

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

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

Always ask, always help

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

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

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

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

Pair Programming
Mob Programming

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


If pairing or mobbing aren’t an option, your team will need to establish working agreements around interrupting work that requires deep focus. One approach is to put up an indicator—such as headphones when in person, or a status setting when remote—that means “less interruptions, please.” But remember that the goal is still to maximize the productivity of the team, not the individual. (And even if you don’t pair regularly, consider it for work that requires a lot of concentration. In addition to reducing the impact of interruptions, it increases the brainpower you can bring to bear on a problem.)

Drop in and drop out

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

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

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

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

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

Create boundary objects

A boundary object is a concrete, visible representation of what people are thinking. It’s a way of modeling the group’s shared idea. For example, a physical planning board with index cards is an example of a boundary object.

When you have a discussion, particularly if people are having trouble understanding each other, create a boundary object that they can manipulate. A whiteboard drawing works, but index cards and their virtual equivalent are even better, because they’re tactile. People can revise the boundary object just by picking up a card and moving it around.

There are many possible boundary objects on an Agile team. Release planning boards. Weekly planning boards. Architecture diagrams. Design diagrams. UI mockups. Every team will have their own ideal way of representing their boundary objects, because each team has its own unique combination of people and thought processes.

Work simultaneously

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

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

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

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

Sometimes I‘ll follow simultaneous brainstorming with affinity mapping. To make an affinity map, take all the cards your group brainstormed and spread them out randomly on a table or in your free-form collaboration tool. Then move the cards around so that the ideas that are most similar are closest to each other, and the ideas that are least similar are furthest apart. Everybody works at the same time, moving cards as they see fit. In the end, the cards should end up forming clusters which you can name.

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

Another way to filter your ideas after brainstorming is to use dot voting. In dot voting, each person gets a certain number of votes—let’s say four, for the sake of example.2 They vote, all simultaneously, by putting a dot on the options they prefer. It’s okay to vote for one option multiple times. For example, if you have four votes, you could put one dot on four separate options, put four dots on one option, or anywhere in between. The options with the most votes win.

2The number of votes is arbitrary, but this formula works well: multiply the number of choices by three, then divide by the number of people.

Seek consent

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

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

If nobody votes “I agree,” the proposal fails for lack of interest. If it otherwise passes but anybody votes “I disagree,” then they explain their objection, and the group adjusts the proposal to address it.

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

Agree to experiment

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

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

Physical Team Rooms

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

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

The cocktail party effect

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

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

Designing your team room

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

If you’re using mob programming, your workspace needs will be different. See the “Mob Programming” practice for details.

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

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

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

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

Multiple teams

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

That said, the same theory of information flow applies across teams as it does within a team: if teams need to collaborate frequently, put them next to each other and make sure they can overhear each other. For teams that don’t need to collaborate, separate them more, either with distance, walls, or noise barriers.

Sample team rooms

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

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

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

Figure 1. Spotify-inspired team room

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

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

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

Figure 2. Budget team room

Adopting a physical team room

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

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

However, forcing people to sit together in hopes that they’ll come to like it is a bad idea. When I’ve forced team members to do so, they’ve invariably found a way to leave the team, even if it meant quitting the company. Instead, talk with the team about their concerns and the trade-offs of moving to a team room. Discuss how team members will be evaluated in an Agile environment—it should emphasis team contributions, as the “Change Team Management Style” section discusses—and what provisions for privacy you can make.

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

Virtual Team Rooms

If you can’t colocate your team, you can create a virtual team room using online tools. This works for teams that are partially remote, too, but be careful: in-person conversations shut remote team members out. If your team has a mix of remote and colocated people, the colocated people need to use the online tools for all their collaboration, too. A decision to use a virtual team room is a decision to act as if everyone is remote.

You’ll need a variety of tools: group text chat, such as Slack, for light conversation and asynchronous notes; videoconference and screen-sharing, such as Zoom, for in-depth “face-to-face” conversation; free-form shared workspaces, such as Miro or Mural, for simultaneous whiteboarding and boundary object manipulation; and a document store, such as DropBox, Google Docs, or a wiki, for semi-permanent artifacts.

Make sure your team has collaborative versions of their creation tools, too. Although you can make do with screen-sharing, it bottlenecks participation behind a single person. Instead, look for tools that allow multiple people to work together, such as Google Docs for office tools, Tuple or Visual Studio Live Share for programming, and Figma for UX and graphic design.

Designing remote collaboration

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

During the Covid-19 pandemic, when everybody had to work remotely, I asked people who had experience with great in-person collaboration for their remote collaboration tricks.3 There were several excellent suggestions:

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

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

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

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

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

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

  6. Create a “wall.” In an in-person team room, information that everyone needs to see or remember is posted on the wall. For your remote team, consider creating a small number of free-form shared documents (such as Google Docs) to store the same sort of information.

  7. Get tablets. It’s much more convenient to sketch diagrams on a tablet than with a mouse or trackpad, and they’re not very expensive. Get a tablet for each member of the team and leave it logged in to your shared workspace (such as Miro or Mural). When you need to sketch something in a discussion, the tablet’s ready to go.

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

Junior team members

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

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

At New Relic [where Bjorn headed up engineering], which had developers sitting next to each other, juniors could see what people were doing and ask questions at convenient times, when they knew they weren’t interrupting.

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

“Typically, we get much more from juniors than we pay them,” Bjorn said. That’s because junior developers aren’t paid much and they develop their skills quickly. At InVision, though, juniors “didn’t develop their skills and didn’t get much work done, so hiring juniors wasn’t a good use of money.” [Shore 2019]

Bjorn Freeman-Benson: Three Challenges of Distributed Teams

Pair Programming
Mob Programming

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


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


Sometimes, the team gets a little noisy and rambunctious. It’s okay to ask for quiet. The sound in the team room should be a hum, not a full-throated chorus. Some teams have a bell for team members to ring when they want the team to be more quiet. When you discuss working agreements during your initial conversation about alignment, talk about how to make sure everybody’s needs are being met. If that’s not enough, bring it up during your team retrospectives, too.

Pair Programming
Mob Programming

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

Alternatively, you can put on headphones, wear earplugs, or sit further away from the team for a while. You’ll miss out on the cocktail party effect, but at least you’ll be able to concentrate.

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

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

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


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

For physical team rooms, the hardest part is making the space. You’ll typically need approval from Facilities and support from management. It can take weeks or even months to complete, so start arranging for your shared workspace early. For more about getting buy-in, see the “How to Be Agile” chapter.

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

Pair Programming
Mob Programming

If your team doesn’t use pair programming or mob programming, be careful to design your workspace and working agreements to minimize noise and distraction. Pair programming makes it easy to ignore background noise, and in mob programming, everybody works together all the time. Individual programming, on the other hand, requires a quiet workspace.


When you have a successful team room:

  • Communication between team members is fast and effective.

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

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

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

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

Alternatives and Experiments

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

Mob Programming

One alternative to a traditional team room is mob programming. Mobbing turns up the dial on collaboration even further, by having everybody on the team work together on the same problem. It may sound ridiculous, but, in a way, it’s “easy mode” for collaboration. It’s particularly effective for remote teams, which otherwise have a lot of work to do before they can reproduce the effectiveness of a physical team room.

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

Further Reading

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

XXX Further reading to consider (courtesy Diana Larsen):

  • Jutta Eckstein, Agile Software Development with Distributed Teams (2010)

  • Scott Berkun, The Year Without Pants (2013)

  • Johanna Rothmand & Mark Kilby, From Chaos to Successful Distributed Agile Teams (2019)

  • Kimball Fisher, The Distance Manager: a hands-on guide to managing off-site employees and virtual teams (2001)

  • KIrsten Clacey & Jay-Allen Morris, The Remote Facilitator’s Pocket Guide (2020)

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Practice: Whole Team

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

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

Whole Team


We have all the skills needed to deliver great results.

Modern software development takes a lot of skills. Not just programming skills; people skills. Artistic skills. Technical skills. And when those skills aren’t part of the team, performance suffers, as the “The Hole Team” sidebar shows. Rather than focusing on a feature and completing it, team members have to juggle multiple tasks as they send emails, wait for responses, and deal with misunderstandings.

To avoid these sorts of delays and errors, Agile teams are cross-functional whole teams. They’re composed of people with diverse skills and experience who collectively have all the skills the team needs. Broadly speaking, these skills can be grouped into customer skills, development skills, and coaching skills.

Customer Skills

People with the ability to represent customer, user, and business interests are called the team’s on-site customers, or just “customers.” They’re responsible for figuring out what to build.

One of the most difficult aspects of creating an Agile team is finding people with customer skills. Don’t neglect these skills; they’re essential to increasing the value of the product you deliver. A great team can produce technically excellent software without on-site customers, but to truly succeed, your software must also bring value to real customers, users, and your organization. This requires the participation of people with customer skills.

Customer skills fall in to several categories, as follows:

Product management (aka product ownership)

Product management involves managing all aspects of a product’s lifecycle, from the initial business case all the way to product launch and beyond. Most of these skills are out of the scope of this book.1

1If you’d like to know more, the Pragmatic Marketing courses, available at, come highly recommended.

Iteration Demo
Real Customer Involvement

On an Agile team, product managers work with stakeholders to discover what the team should work on and why it’s important, also called the team’s purpose; they discover who the team works with and what resources are available, also called the team’s context; they lead demos and seek out feedback; and they promote the team’s work in the organization.

I’ve used the term “product manager” as shorthand for “people with product management skills,” but that doesn’t mean everybody with those skills has “product manager” as their job title. It’s important to have people with the skills to perform the product management tasks I’m describing here, but it isn’t necessary to have someone with the title. The same goes for all the other skills.

Minimum Marketable Features
Visual Planning
Adaptive Planning

Product managers also lead the team’s release planning activities. They choose features; decide how to group features into releases; collaborate with the rest of the team to create an achievable plan; condense the team’s plan into a roadmap that can be shared with stakeholders; and help the team adapt their plans in response to feedback and changing business conditions.


Product management requires a deep understanding of the team’s markets, whether the market is one organization (as with custom software) or many (as with commercial software). Product managers need an intuitive understanding of what the team’s software will provide and why it’s the most important thing the team can do with their time. For Optimizing teams, this includes conducting experiments to test assumptions and discover new ways of serving customers.


In addition to product vision, product managers must have the organizational authority to make difficult trade-off decisions about what goes into the product and what stays out. They must have the political savvy to align diverse stakeholder interests, consolidate them into the product vision and purpose, and effectively say “no” to wishes that can’t be accommodated.

People with this caliber of skills and influence have a lot of demands on their time. You may have trouble getting their attention. Persevere. Product management is one of the most important skills on the team. If the software isn’t valuable enough to warrant the time of someone with good product management skills—someone who could mean the difference between success and failure—maybe it isn’t worth developing in the first place.

Optimizing teams require someone with product management skills to be dedicated to the team full-time. That’s best for Focusing and Delivering teams, too, but it’s common for teams in these zones to work with someone outside the team instead. That can work so long as the team is moving slowly, the work is predictable, and there are other people with solid customer skills on the team.

Whoever is handling product management responsibilities for your team, make sure they participate in every planning meeting and are able to respond to questions quickly. If they don’t, your team is likely to start drifting off-course. [Rooney 2006] experienced that problem, with regrettable results:

We weren’t sure what our priorities were. We weren’t exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer [product manager] in terms of what we should be working on. This went on for a few months.

Then, we found out that the Gold Owner [executive sponsor] was pissed—really pissed. We hadn’t been working on what this person thought we should.

Make sure your team has access to someone with solid product management skills.

Domain expertise (aka subject matter expertise)

Most software operates in a particular industry, such as finance, that has its own specialized rules for doing business. To succeed in that industry, the team’s software must implement those rules faithfully and exactly. Those rules are called domain rules, and knowledge of those rules is domain knowledge.

Most developers have gaps in their domain knowledge, even if they’ve worked in an industry for years. In many cases, the industry itself doesn’t clearly define its rules. The basics may be clear, but there are nitpicky details where domain rules are implicit or even contradictory. I once worked with two financial experts who were in total agreement that our software needed to support a specific thing, but when we asked them to define that thing, it turned out that they had exact opposite definitions.

The team needs people with domain expertise who are responsible for figuring out those details, resolving contradictions, and having the answers at their fingertips. These are people with deep experience. One Agile team I worked with was building software for chemical analysis, so they had an analytical chemist with a Masters’ degree on the team. (Their product manager was a Ph.D. chemist.) Another was building bank-to-bank collateral management software, so they had the two financial experts I mentioned earlier. A third was building life insurance software, and their domain expert was an actuary.

If your software doesn’t have complicated domain rules, you still need at least one person who’s responsible for figuring out the details of what your software should do. On some teams, that might be a product manager or user experience designer.

Lightweight Requirements
Customer Examples

In contrast to product managers, who spend most of their time with stakeholders, domain experts spend most of their time with the team. Most of their time is spent figuring out the details of upcoming work, creating examples of complicated rules, and answering questions when programmers ask.

User experience design (aka interaction design) and graphic design

Your software’s user interface is the face of your product. For many users, the UI is the product. They judge the product solely on their perception of the UI.

People with user experience (UX) and graphic design skills define the user interface. These skills focus on understanding users, their needs, and how they interact with the product. Tasks involve interviewing users, creating user personas, reviewing prototypes with users, observing usage of actual software, and consolidating this information into specific layouts and imagery.

Don’t confuse graphic design with UX design. Graphic design conveys ideas and moods via images and layout. User experience design focuses on the types of people using the product, their needs, and how the product can most seamlessly meet those needs.

UX designers divide their time between working with the team and working with users. They contribute to release planning by advising the team on user needs and priorities. They create mock-ups of UI elements for upcoming work. As work is completed, they review the look and feel of the finished UI and confirm that it works as expected.

Visual Planning

The fast, iterative, feedback-oriented nature of Agile development leads to a different environment than UX designers may be used to. Rather than spending time researching users and defining behaviors before development begins, the UX designers refine their models iteratively, alongside the iterative refinement of the software itself.

Although UX design is different with Agile than other approaches, it isn’t diminished. Agile teams produce software every week or two, which provides a rich grist for the UX designer’s mill. Designers have the opportunity to take real software to users, observe their usage patterns, and use that feedback to effect changes in a matter of days or weeks.

Project management

People with project management skills are adept at navigating the politics of an organization, understanding how to work with stakeholders, and managing expectations. They also tend to be good at helping the team organize their work so nothing slips through the cracks, but their main role on an Agile team is to help the team work with the rest of the organization.

You may not have anybody with a “project manager” title on an Agile team, but you still need people who understand how to work with stakeholders. This might be a product manager or senior developer. Similarly, if you do have someone with a “project manager” title, they’ll probably contribute other skills as well, such as product management, domain expertise, or coaching.

Development Skills

A great purpose requires solid execution. If customer skills are about figuring out what to do, development skills are about figuring out how to do it. People with development skills, such as programming, testing, or operations, are responsible for finding the most effective way of delivering the team’s software.

Some people call development skills “technical skills,” but that seems dismissive to me. It’s not as if analytical chemists and actuaries aren’t technical, after all. So, for lack of a better term, I’ll describe people who help build, test, and release the team’s software as having “development skills.”

It’s best if your team has people with all the development skills described below, but programming skills are the minimum... at first. Once they start pursuing Delivering fluency, they’ll need all of them. Until then, development on an Agile team looks similar to development on any other team.

Pair Programming
Mob Programming
Test Driven Development
Evolutionary Design

On a Delivering team, programmers spend most of their time pair programming or mobbing, which are ways of working together on code. They use test-driven development to write tests, implement code, refactor, and incrementally design and architect the software. They pay careful attention to design quality, and they’re keenly aware of its impact on development time and future maintenance costs.

No Bugs
Zero Friction
Continuous Deployment
Continuous Integration
Build for Production

Programmers also ensure that the team’s on-site customers can release their software whenever they choose. They produce software with very few bugs. They use version control and practice continuous integration, keeping all but the last few hours’ work ready to release. They maintain an automated build that can deploy the software at any time. Their coordinate with the rest of the team to create software that’s easy to monitor and manage in production.

Collective Code Ownership

This work is a joint effort of all programmers on the team. Programmers have the right and responsibility to fix any coding or design problem they see, no matter which part of the team’s software it touches. They establish working agreements that allow them to collectively share responsibility for the code. They work as generalizing specialists: although each programmer has their own areas of expertise, such as front-end or back-end development, they’re expected to be able to contribute to any part of the team’s software that needs attention.

Lightweight Requirements
Ubiquitous Language
Customer Examples

Programmers rely on team members with customer skills for decisions about what to build. Rather than guessing when they have a question, they ask one of the on-site customers. They design their code to use a ubiquitous language, so they can communicate clearly with customers, and they base their tests on customers’ examples.


Finally, programmers help ensure the long-term maintainability of their product by providing documentation when needed.

Design and architecture
Test Driven Development
Mob Programming
Pair Programming
Collective Code Ownership

Everyone on a Delivering team who codes, also designs and architects, and vice-versa. They use test-driven development to combine architecture, design, tests, and coding into a single, ongoing activity. Mobbing, pairing, and collective code ownership help ensure that the best designs emerge.

Evolutionary Design
Evolutionary Architecture
Simple Design
Reflective Design
Continous Design

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

Lightweight Requirements
Customer Examples

People with testing skills help Delivering teams produce quality results from the beginning. They apply their critical thinking skills to help customers consider all possibilities when envisioning the product. They help identify holes in requirements and gaps in customers’ examples.

Exploratory Testing

Testers also act as technical investigators for the team. They use exploratory testing to help the team identify blind spots. They provide information about the software’s nonfunctional characteristics, such as performance, scalability, and stability, by using both exploratory testing and sophisticated automated tests.

No Bugs
Root Cause Analysis

Unlike most teams, Delivering teams’ testers don’t exhaustively test for bugs. Instead, the rest of the team is expected to produce nearly bug-free code on their own. When testers find bugs, they help the team figure out what went wrong so the team as a whole can prevent those types of bugs from occurring in the future.

Continuous Deployment

Team members with operations skills help the team deploy, monitor, and manage their software in production. In smaller organizations, they might be responsible for provisioning and managing hardware. In larger organizations, they’ll coordinate with a central operations group.

Build for Production
Root Cause Analysis
No Bugs

Operations team members also work with the rest of the team to make sure nonfunctional requirements such as performance and scalability are considered, and they help define requirements for monitoring and managing the team’s software in production. They coordinate with programmers to share pager duty and help analyze and prevent production incidents.

Coaching Skills

Teams that are new to Agile have a lot to learn: they need to learn how to apply Agile practices, and they also need to learn how to work together as effective self-organizing teams.

Their organizations have a lot to learn, too, about how to support their teams. Most of that support comes in the form of the investments described in the “Investing in Agility” chapter, but additional changes are always needed. And, although it’s best if organizations make the investments teams need up-front, teams often have to advocate for the investments they need after work has begun.

Team Dynamics
Circles and Soup

People with coaching skills help teams learn how to be effective Agile teams. They teach practices, facilitate discussions, guide self-organization and team development, and show the team how to work with managers and other business stakeholders to get the investments they need.

Teams new to Agile will typically have one person, sometimes two, who is explicitly identified as the team’s coach. The job of these coaches is to help the team become independently fluent, so they’re able to perform the skills they need without the participation of a coach. That doesn’t mean the coach leaves the team, but it means that they could, and if they stick around, they gradually transform into a regular member of the team.

Coaching ability typically falls into three categories:

  • coaching team development, self-organization, and Focusing zone practices

  • coaching Delivering zone technical practices

  • coaching Optimizing zone business development practices

It’s rare to find one person who can coach teams in all three categories, although experienced Delivering and Optimizing zone coaches can often handle the first category as well. Teams need coaching in all the skills they’re developing, so your team might need more than one coach if they’re developing fluency in multiple zones simultaneously.

My preferred type of Agile coach is the practitioner-coach: someone with genuine expertise in applying Agile practices who can lead by example. Their focus is still on helping the team and organization learn, not on delivering, but they have skills and background to show rather than tell, and that often involves helping team members with their work.

A variant of the practioner-coach is the player-coach, who has experience with Agile practices, and some coaching skills, but is focused more on delivery than on helping the team learn. Home-grown coaches often fall into this category—they might have a title like “technical lead” or “senior engineer”—as do most experienced Agile developers. They can be very effective at helping teams apply Agile practices, even to the point of fluency, but they tend to be less successful at helping teams become independently fluent. They can also have a hard time understanding how and when to influence organizational change.

One of the most common types of coaches is the facilitator-coach, often called a Scrum Master2, who leads from the sidelines by facilitating conversations and resolving organizational roadblocks. Although this style of coaching isn’t very effective at teaching Delivering and Optimizing practices, facilitator-coaches can still be effective in teaching Focusing zone practices and helping teams self-organize. They’re also useful for teams that have a lot of roadblocks—usually because their organization skimped on important investments—because they can advocate for those investments to be made. (See the “Investing in Agility” chapter for more about the investments teams need.) Player-coaches and facilitator-coaches can be a good combination, as they have complementary strengths and weaknesses.

2The name “Scrum Master” originated in the popular Scrum method. The name is misleading; it’s supposed to mean someone who has reached mastery in their understanding of Scrum, not someone who has authority or control over the team.

One downside of facilitator-coaches is that they don’t contribute a lot to day-to-day development. This can lead organizations to see them as underutilized, and assign them to several teams at once. This reduces the effectiveness of their coaching, as they’re not present to see and respond to team challenges. (Two teams can be okay. More than that is a stretch.) Coaches in this situation often end up as glorified meeting organizers, which isn’t a good use of their talents, and not good for their teams, either.

Team Dynamics
Circles and Soup

Speaking of facilitation, part of the job of the coach is to teach coaching skills to the rest of the team. Team members need to be able to facilitate their own discussions, improve their own team dynamics and practices, figure out which investments will make them more effective, and work with stakeholders to get those investments. As with all team skills, you don’t need everybody on the team to be able to do so, but the more that can, the more resilient the team will be.

Some coaches fall into the trap of doing these things for the team rather than teaching the team how to do it themselves. Make sure that’s not the case on your team.

Even after a team becomes independently fluent, it’s helpful for an experienced coach to join the team once in a while—say, every year or two—to help the team try new things and remember forgotten practices.

Staffing the Team

The exact roles and titles on your team aren’t important, so long as you have the skills you need. The titles on your team have more to do with your organization’s traditions than anything else.

In other words, if project managers and testers are typical for your organization, you’ll include them on your team to cover the “project management” and “testing” skills. If not, you don’t necessarily need to hire people with those titles. But you do need someone with those skills. Someone still has to be able to coordinate with stakeholders, and someone still needs to help the team identify its blind spots.

For new Agile teams, it’s helpful to explicitly identify the product manager and coach. For experienced Agile teams, assigned roles can get in the way, but people new to Agile appreciate knowing who to turn to when they have questions.

Some decisions will be made by people outside your team. For example, if your team is contributing to a larger product, decisions about system architecture may be out of your hands. That’s fine if those decisions are just part of the background. But if you’re constantly waiting for people outside the team to make a decision or do something for you, you don’t have a whole team. Those skills and responsibilities should be moved into the team, or that aspect of the product should be moved out of the team. (See the “Scaling Agility” chapter for more discussion of cross-team coordination.)

There are likely to be some skills that your team only has occasional need for. You can ask people with those skills to join your team temporarily. For example, if your team is building a complex server-side product with a very small user interface, you might ask a user experience designer to join your team only during the few weeks that you’re actually working on the UI.

Full-time team members

Every team member should be solely dedicated to the team. They should be able to give the team their complete attention. Assigning people to multiple teams simultaneously (fractional assignment) yields terrible results. Fractional workers don’t bond with their teams, often aren’t in the team room to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty. “[T]he minimum penalty is 15 percent... Fragmented knowledge workers may look busy, but a lot of their busyness is just thrashing.” [DeMarco 2002] (p. 19-20).

Team Room

The same goes for temporary team members. Agile relies on a lot of informal communication, so anybody who’s not in the team room—whether physical or virtual—will have trouble participating. If you have a temporary team member, make sure they’re fully dedicated to your team during the time that they’re with you. It’s better to have someone fully dedicated to your team for a week, and then another team for another week, than to have that same person assigned to both teams for two weeks. They’ll be much less than 50% as productive in the latter scenario.

Generalizing specialists

Agile teams work best when they’re composed of generalizing specialists. They’re also called “T-shaped people.” A generalizing specialist has deep expertise in several areas—that’s the vertical bar of the T—but also the ability to contribute broadly to other skills the team needs. That’s the horizontal bar. (Some people use the term “M-shaped people” or “paint drip people” to emphasize that generalizing specialists can develop multiple areas of expertise.)

Agile teams need generalizing specialists to prevent bottlenecks. Non-Agile organizations undertake complex “resource shaping” exercises to ensure that each team is staffed with the right specialists at the right time. Those exercises never quite work out, because software development work can’t be predicted as precisely as resource shaping requires. So they end up with teams waiting for people who were delayed, or rushing to find work for people who are ready before the team is. You tend to see a lot of fractional assignment as managers scramble to make everything line up. It leads to a lot of waste.

In an Agile organization, teams are the resource, not individual people, so resource shaping is much simpler. It’s all or nothing. Either the team is working a feature, or it’s not. Either a person is dedicated to a team, or they’re not.

But you can still end up with bottlenecks inside a team. Imagine a team with two front-end developers and two back-end developers. Sometimes, there will be more front-end work to do, and the back-end developers will twiddle their thumbs. (Or they’ll work ahead, which ultimately leads to wasteful rework, for reasons we’ll explore in the “Planning” chapter.) Other times, the situation will be reversed.

A team that has generalizing specialists avoids these sorts of bottlenecks. When there’s a lot of front-end work, the front-end specialists take the lead, but the back-end specialists are able to help out. When there’s a lot of back-end work, the back-end specialists take the lead. And it’s not just programming. Whatever bottlenecks the team may be facing, team members should be willing and able to jump in and help.

You don’t need team members to be generalizing specialists when you first form your team. It’s more a matter of attitude than ability. Any specialist can choose to learn to contribute to areas adjacent to their specialty. When your team agrees to try Agile (see the “How to Be Agile” chapter), be sure they’re willing to help out with tasks outside their specialty.

Team size

The guidelines in this book are appropriate for teams with 3-20 people. For new teams, 4-8 people is a good starting point. Once you get past 12 people, you’ll start seeing breakdowns in communication, so be cautious about creating large teams.

Even larger teams are possible, as described in the “Scaling Agility” chapter, but they’re out of the scope of this book.

Teams smaller than three people can use the practices in this book, but some of them will be overkill. If you’re in an organization with a lot of very small teams, consider combining them into larger teams. You’ll reduce your overhead, and you’ll be less vulnerable to any one person leaving.

For most teams, programming will be the bottleneck—at first—so when you think about team size, start by thinking of how many programmers you need. For convenience, I’ll call a person fully dedicated to programming “one programmer,” but that doesn’t mean that your team has to have strictly defined roles.

Teams without Delivering fluency typically have 3-5 programmers. As the team grows past that size, they’ll start to have trouble coordinating. Either there will be too many simultaneous streams of work for people to keep track of, or bottlenecks will form as different specialities end up with differing amounts of work to do.

Collective Code Ownership
Pair Programming

Teams that use pair programming can have 4-10 programmers, assuming they also use collective code ownership. Six is the sweet spot. (For teams new to Delivering practices, avoid growing past 6-7 programmers until you have more experience.) Pairing can support more programmers because it cuts the number of simultaneous streams of work in half, making it easier for programmers to keep track of each others’ work, and collective code ownership ensures that they work together, without specialties forming bottlenecks.

Mob Programming

Teams that use mob programming tend to have 3-5 programmers. You can mob with much larger groups—it’s a great teaching technique—but you reach a point of diminishing returns.

You’ll typically staff the rest of your team proportionally to the number of full-time programmers. You want the ratio to be about equivalent to the amount of work to do, so bottlenecks don’t form, with generalizing specialists giving you some slack to handle variations in workload. In general, plan for:

  • One to two customers for every three programmers. At least one of the customers should have product management skills, unless the team is working with an outside product manager.

  • One tester for every 2-4 programmers, if the team doesn’t have Delivering fluency.

  • One tester for every 4-8 programmers, if the team does have Delivering fluency.

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

  • One or two coaches, depending on the skills your coaches have and fluency zones your team is pursuing.

Again, this isn’t meant to imply strict roles. As an extreme example, for the first bullet point, you could have a team of five programmers, all of whom have customer skills, and who spend about two-fifths of their time on customer-type tasks.

A Team of Peers

Nobody on the team is in charge of anyone else. That doesn’t mean every decision is up for discussion; people have final say over their areas of expertise. For example, programmers can’t override customers’ opinions about product priorities, and customers can’t override programmers’ opinions about technical necessity. Similarly, you’ll still have senior team members who take the lead on important decisions. But there is no reporting structure within the team. Even people with fancy titles like “product manager” or “project manager” aren’t managing the team.

This is an important part of being a self-organizing team. A self-organizing team decides for itself who’s going to take the lead on any given task. It’s not a hard decision; for teams that know each other well, deciding who will take the lead is usually automatic. It’ll be the person who knows most about the task, or who has expressed the most interest in learning more, or is next in rotation, or anything, really.

Something that’s hard to convey about high-performance Agile teams is how much fun they have. Brian Marick, one of the Agile Manifesto authors, used to say that “Joy” was another Agile value.3 He’s right. Great Agile teams have a feel to them. They’re optimistic, enthusiastic, and genuinely enjoy working together. There’s a spirit of excellence, but it’s not overly serious. For example, when there’s a task no one wants to do, the conversation about who will do it is playful and fun. And it’s quick. Effective Agile teams make decisions easily.

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

Team Dynamics

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

One thing a self-organizing team is not: It’s not self-managing. Yes, many of the decisions that are made by managers in a non-Agile team are made by team members in an Agile team. But the manager still has an important role to play: they set the team up for success. See the “Change Team Management Style” section for details.


What if there aren’t enough people to staff every team with the skills they need?

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

If you can’t hire the people you need, one option is for your company to form a central support team that’s responsible for providing guidance, standards, and training to other teams. ([Skelton and Paid 2019] calls this an “Enabling Team.”) The central team trains team members how to apply the guidance and standards on their teams. For example, a central UX team could establish a style guide and train people how to use it for their team’s software. That gives teams the ability to solve their own problems without requiring full-blown expertise.

If you have central support teams, make sure their role is to enable other teams to work autonomously, rather than doing the work themselves. Otherwise, they’ll end up as a bottleneck.

When more expertise is needed, you can ask for somebody with those skills to be assigned to your team temporarily. Delay any work that needs those skills until they’re available. That way you don’t end up with half-done work, which leads to waste, as we’ll see in the “Planning” chapter.

What if we don’t need a certain skill all the time?

Let’s say you have a need for a skill, such as UX design, but only about ten hours’ worth per week. The most resilient way to deal with this situation is for people to cross-train, so that team members can contribute UX design as well as other skills. If that’s not an option, you can schedule someone to join your team periodically, such as one week every month. As before, delay work that needs their skills until they’re available.

Are junior members of the team equal to everyone else?

Team members aren’t necessarily equal—everyone has different skills and experience—but they are peers. It’s smart for junior team members to seek out more experienced team members for advice and mentoring. It’s also smart for senior team members to treat everyone with respect, to create collegial relationships, and to help junior members grow by stepping back so they can take the lead.

How do team members develop specialized skills without being on a team dedicated to that skill?

Many Agile organizations form “communities of practice” around specific specialties, such as UX design, front-end programming, operations, and so forth. These may be led by a manager, a centralized support team, or just interested volunteers. They’ll typically hold a variety of events to provide training, socializing, and other opportunities for learning from each other.


Creating a whole team requires buy-in and support from management, and agreement from team members to work together as an Agile team. See the “How to Be Agile” chapter for more about creating buy-in.


When you have a whole team:

  • Your team is able to solve problems and do their work without waiting for people outside the team.

  • People on the team work outside their specialty to prevent bottlenecks from slowing the team down.

  • Your team is able to make decisions smoothly and effectively.

  • People on the team seamlessly switch leadership roles from task to task.

Alternatives and Experiments

The theory behind this practice is pretty straightforward. To avoid delays and communication problems:

  1. Find everybody needed to ship your software.

  2. Put them on the same team.

  3. Have them work in concert towards the same goal.

This is a core Agile idea, and there aren’t really any alternatives that stay true to the Agile philosophy. But there are a lot of opportunities to customize the details. Once you’ve had a few months of experience applying this practice as written, try some experiments.

One experiment is to try different ways of dealing with roles. Does your team work better when people have sharply defined roles and responsibilities? In other words, when one person owns product management, another owns domain expertise, and someone else owns operations? Or is it better when you loosely share skills and responsibilities, with people contributing to multiple roles? How loose is too loose?

What about self-organization? How can your team experiment with changing how decisions are made? Does it work better to have someone explicitly facilitate discussions? Or to just let discussions happen naturally? Should some decisions be assigned to specific people? Or should leadership responsibility be more fluid?

One of the bigger Agile challenges is figuring out how to create whole teams in a large organization. It’s not always clear how teams that are working on the same set of products should divide their responsibilities. These are the sorts of decisions you need to make in order to have a successful large-scale Agile system, as we discuss in the “Scaling Agility” chapter. Mastering the Whole Team practice is the first step to understanding how to scale Agile well.

To better understand these scaling issues, experiment with how teams relate to each other. When two teams depend on the same thing, which team should have responsibility for it, and how should they coordinate? Similarly, what’s the correct amount of consistency to have across teams, and how can you achieve that consistency? What do “customer skills” entail when a team is building something solely for another team to use?

There are no cut-and-dry answers to these questions. Make a guess. Try it, see how it works, and make a different guess. Try that, too. Never stop experimenting. That’s how you master the art.

Further Reading

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

Team Topologies [Skelton and Paid 2019] is an in-depth look at the different ways teams can be organized, with an emphasis on creating whole teams in large-scale Agile systems.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Chapter: Teamwork (Introduction)

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.


Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.1 [Beck et al. 2001]

1When the Agile Manifesto was written, people thought about software development in terms of projects. Today, the Agile community prefers to focus on products or capabilities instead.

The Agile Manifesto

Cross-functional, self-organizing teams are the heart of any Agile organization. They’re the fundamental “resource” of the organization. It’s a constant refrain in Agile literature:

Software development teams where everyone is alike, while comfortable, are not effective. Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. [Beck 2004]

Extreme Programming Explained

Scrum leaves the actual determination of who does what up to the team... the team is going to sink or swim together. There are no individual heroics, just team heroics. When a team member is weak, other team members have to pick up the slack. Nothing helps people do their best, despite their shortcomings, as much as group pressure and a team environment. [Schwaber and Beedle 2002]

Agile Software Development with Scrum

In a lean organization, the people who add value are the center of organizational energy. Frontline workers have process design authority and decision-making responsibility; they are the focus of resources, information, and training. [Poppendieck and Poppendieck 2003]

Lean Software Development: An Agile Toolkit

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

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The best architectures, requirements, and designs emerge from self-organizing teams. [Beck et al. 2001]

Excerpts from the Agile Manifesto

But who should be part of an Agile team? How do they know what to work on? What makes it possible for them to work well together?

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

  • The “Whole Team” practice: Create a team that has everybody needed to get their work done.

  • The “Team Room” practice: Build a space, either physical or virtual, where everyone can collaborate effectively.

  • The “Purpose” practice: Show how the team’s work supports the company’s big-picture plans.

  • The “Context” practice: Clarify the team’s relationships with stakeholders and other groups.

  • The “Alignment” practice: Establish norms that allow team members to work together without conflict.

  • The “Safety” practice: Create an environment where team members are comfortable sharing their experience and insights.

  • The “Energized Work” practice: Work in a way that the team can sustain indefinitely.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Part II: Focusing on Value (Introduction)

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

Focusing on Value

You walk into work on a crisp October morning. After the Covid-19 pandemic, your team was eager to return to in-person work. Other teams chose to stick with remote work. Agile feels much the same either way, you muse to yourself, despite differences in the details.

Your team is a fluent Focusing team. As a team, you’re very good at understanding customer needs, defining useful features, and focusing your work on the most valuable thing you can do. There’s room for improvement, particularly around defects and deployment, and people have been talking about investing in Delivering zone fluency to solve those problems, but management is very happy with your output. Some people on the team really want your team to take full ownership as an Optimizing team, but, for now, your team’s priorities are determined by Hanna, a product manager in the marketing department. She’s pretty busy and her boss isn’t willing to assign her to your team full-time.

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

Before the demo, though, you have your weekly team retrospective. It’s an opportunity for your team to look at your practices, team dynamics, and organizational roadblocks to see what you can improve. You rotate who facilitates every week. This week, it’s Shayna’s turn. You’re looking forward to it. She always comes up with creative exercises to liven up the retrospective, and she’s good about making sure that the team follows through with an experiment to try.

After the retrospective, you all meet with Hanna, your product manager, for the stakeholder demo. Hanna takes the lead, as usual. She originally wanted team members to run the demo, but you found that having Hanna in charge of the demo meant she paid more attention to what you were building. (That was the result of a retrospective experiment, in fact.) It led to better feedback and better results. Plus, she’s much better at speaking stakeholders’ language.

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

After a break, it’s time for your weekly planning session. Hanna pulls over your release planning board. It’s a large whiteboard with a bunch of index cards stuck to it with magnets. The cards form clusters, and each cluster has a name like “resellers,” “actuaries,” or “accountants.” They represent your customer groups. There’s another large group of cards marked “whitelabel.”

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

Hanna nods to Colton, the team’s UX designer, and he speaks up. “Hanna and I are going to be going over the trial run and whitelabel administration features later today. You’re welcome to join. After, I’m going to mock up a few designs and then I’d like to have a story break-down session later this week. I’ll let you know when I’m ready to schedule it.”

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

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

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

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

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

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

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

Welcome to the Focusing Zone

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

1These lists are derived from [Shore and Larsen 2018]. Used with permission.

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

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

  • Change direction to match changes in business priorities.

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

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

  • Collaborate well within their team, reducing misunderstandings and hand-off delays within the team.

To achieve these benefits, organizations need to make the following investments (see the “Investing in Agility” chapter for details):

  • Create long-lived, cross-functional teams. Compose each team of people who work well together and have the skills and background needed to accomplish the team’s work. Allocate them 100% to their team.

  • Provide each team with a coach who can teach self-organization, team development, and the Focusing zone practices in this part of the book.

  • Create a productivity-focused workspace for each team, either physical or virtual.

  • Ensure each team has access to someone with business expertise who’s responsible for setting product direction and goals. They don’t need to be a team member, but they do need to participate in every planning session. (Some people call this person a “product owner” or a “product manager.” Generically, they’re the team’s business representative.)

  • Ensure that each team includes at least one person who’s able to determine the details of what the team’s software will do.

  • Remove, revise, or work around HR policies that impede effective teamwork, such as competitive ranking and individually-focused rewards.

  • Train managers how to create an environment that supports teamwork and how to manage the work system rather than individual contributions.

The Focusing zone involves the following skills. The team is proficient at the zone when the team exhibits all these skills. It’s fluent when it exhibits these skills with unconscious ease, even when under pressure.

The team responds to business needs:

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

  • Business stakeholders can rely on the team to work on whatever their business representative views to be their most valuable priority.

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

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

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

The team works effectively as a team:

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

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

  • Team members share accountability for getting their plan done.

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

The team pursues team greatness:

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

  • The team is aware of how intra-team relationships affect their ability to succeed and proactively attempts to improve them.

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

The team doesn’t need everybody on the team to have these skills. Instead, they need the ability, as a whole team, to bring the right people to bear at the right times. There are several levels of maturity:

  1. Learning. The team is learning the skills.

  2. Proficient. The team is able to exhibit the skills when they concentrate on them.

  3. Fluent. The team exhibits the skills automatically, without conscious effort, so long as they have a coach as part of the team.

  4. Independently Fluent. The team exhibits the skills automatically, without needing a coach, so long as key team members are present.

  5. Resiliently Fluent. The team exhibits the skills automatically, regardless of who on the team is present.

The chapters in this part have practices that will help your team develop these skills.

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

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

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

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

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

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Chapter 4: Investing in Agility

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

Investing in Agility

One of the recurring themes in this book is that, in order to be Agile, your organization has to buy in to the underlying Agile philosophy. Not just spending money—that’s comparatively easy—but making real, meaningful changes to organizational structures, systems, and behaviors.

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

Yes. They really are.

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

As Martin Fowler said:1

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

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

Martin Fowler

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

The following sections describe the investments your teams need from your organization. You may not be able to get all of them, so I’ve provided alternatives. But the alternatives come at the cost of reduced effectiveness, so work hard to get as many as you can.

1. Make Time for Learning

Changes are disruptive, and new ideas take time to learn. Learning Agile will slow your teams down at first.

How much will they slow down? There’s no objective measure of software productivity [Fowler 2003], but from experience, I’d estimate a 10-20% performance dip at first. As they become proficient with Agile skills, their performance will increase. It will continue to increase until they achieve fluency, and then the increase will gradually level off, as the “Agile Performance Over Time” figure illustrates.

A graph showing how an Agile team’s performance changes over time. It shows an Agile change starting out at the same performance level as the status quo, which is marked “Agile introduction; preparing for change.” Then the performance of the Agile change drops rapidly, a period marked “Introducing practices; some resistance to change.” Performance stays low for an unspecified period of time, which is marked “Initial learning; chaos of change.” Then it rises in the shape of an S-curve, which is marked “Gaining proficincy; becoming comfortable with change.” The S-curve crosses the status quo, showing the Agile change’s performance surpassing the status quo, then gradually levels off in a period marked “Reaching fluency; change established.” Finally, it continues improving at a gradual rate, which is marked “Continuous minor improvements.”

Figure 1. Agile performance over time

The time investment will typically pay for itself in the first year. The length of the initial dip depends on the fluency zones the teams are learning:

  • Focusing: one to four months

  • Delivering: two to six months

  • Optimizing: one to three months

These periods overlap, so a team that’s learning Focusing and Delivering skills together will have a productivity dip that lasts about 2-6 months. In contrast, a team that learns Focusing skills first and moves to Delivering later will have two dips: a 1-4 month dip when they learn Focusing skills and another 2-6 month dip when they learn Delivering skills.

Agile teams’ performance changes in other ways, too. Agile teams focus on getting features completely done before moving on to the next feature. This is particularly true for Delivering teams, which build quality in from the beginning rather than fixing bugs at the end. This improves throughput and performance, but—ironically—it feels like a slow-down to people who are used to seeing multiple features in progress at once.

The net result is that stakeholders can be frustrated by the pace of Agile development, particularly in the first 3-12 months, when they’re dealing with three hits all at once: a real delay from learning, a perceived delay from focusing on getting things done, and the cost of finishing work on pre-Agile features that were declared “done” without actually being done.

This frustration can lead to teams being redirected away from learning how to be Agile, and solely focused on delivering software, before they’ve finished learning. This is counterproductive for everyone: teams will feel yanked around and frustrated, and the organization will have wasted the investments they’ve made so far. Before teams begin their Agile journey, make sure managers and stakeholders are on board with the first-year performance dip.

Your organization can trade money for time by hiring people to help your teams. This won’t eliminate the cost of learning, but it will shift the cost towards the faster end of the range. There’s a wide variety of help available: occasional mentoring; training; help with process design and implementation; and full-time (or near-full-time) coaching. The most effective help you can get is to hire experienced practitioners to coach each team full-time.

As you consider who to hire, ignore the myriad Agile certification schemes. They’re money grabs. Most demonstrate nothing more than the ability to connect butt to chair for a few days. Some are connected to excellent training courses, but that’s due to the trainer, not the certification, so evaluate training courses independently of the certifications they tout. The same goes when hiring consultants and coaches. Ask your network for recommendations, sample publicly-available materials, and check references.

As you apply this book’s practices, you’re likely to run into problems and challenges specific to your situation. Be sure you have a mentor you can reach out to for questions. This doesn’t have to cost money; a respected colleague at a company who’s done it before, a local user group, or an online mailing list are all good options.

If there’s no time for learning...

You can make the performance dip less noticeable, at the cost of larger overall expense, by starting with just the Focusing zone and easing into Agile’s focus on getting things done.

If your organization won’t accept any productivity dip at all, now isn’t a good time to invest in change. If there’s never a good time, that’s a big red flag. You’ll need to convince them to make time for change before you continue.

If there’s no budget for help...

With this book, the many free resources available online, and a dedication to learning, your teams can teach themselves everything they need to know. Outside help is, well, helpful, but it’s not required.

2. Choose or Create Agile Teams

I can’t overstate how important teams are in an Agile organization. Most organizations consider people their fundamental work-producing “resource.” In Agile, teams are the resource.

An Agile team is:

  • Cross-functional. The people on the team collectively have all the expertise needed for the team to complete its work.

  • Full-time. Everybody on the team is assigned to the team 100%. Specialists can come help from time to time, but core team members are dedicated solely to their team.

  • Collaborative. Team members have friendly, collegial relationships and work closely together. Over time, the team “jells” into a high-performance whole that’s greater than the sum of its individual contributors.

  • Long-lived. A highly-productive “jelled” team is worth its weight in gold. It can take months for team members to figure out how to work most effectively together, so keep teams together for as long as possible.

The size and composition of each team depends on which fluency zones you’re pursuing. The “Whole Team” practice has the details, but briefly:

  • Every team needs programming skills. The specific programming skills depend on the team’s purpose.

  • Every team needs a way to determine what the team will work on next. Although it’s best if the team has the skill to do this themselves, Focusing and Delivering teams can work with a business representative who’s outside the team. The representative needs to be readily available to answer questions and attend planning meetings.

  • Focusing teams focus on achieving business results. They need people with the ability to put themselves in users’ and customers’ shoes to determine exactly what the software will do. If the team’s purpose is user-centric, that includes people with UI/UX skills.

  • Delivering teams take responsibility for end-to-end delivery of their software. They need all skills required to build and deploy their product. Responsibilities that were previously handed off to other teams need to be brought into the team. This includes build management, database administration, testing, and operations.

  • Optimizing teams take responsibility for the broad business success of their product. They also take responsibility for coordinating with stakeholders and deciding product priorities. They need team members who have business, market, and product expertise.

You may already have teams that fit the bill. If you’re creating new Agile teams, follow these steps. Either way, remember to get teams’ buy-in, as described in the “Get Team Buy-In” section.

  1. Decide the purpose of each team.

  2. Decide how many people will be on each team, based on how valuable the team’s purpose is, subject to the size limits described in the “Whole Team” practice.

  3. Determine which skills each team needs.

  4. Choose people and coaches that have the skills each team needs, are likely to work well together, and are willing to try Agile.

If you’re creating or reorganizing a lot of teams, consider using team self-selection. It’s surprisingly effective at creating highly-productive teams that are excited to work together. The book Creating Great Teams: How Self-Selection Lets People Excel [Mamoli and Mole 2015] describes how it works.

If you can’t allocate people full-time...

Agile depends on close collaboration, and that doesn’t work well if people aren’t available. Occasional outside responsibilities are fine, but if you can’t get dedicated team members, it’s unlikely Agile will work for you.

If you can’t create long-lived teams...

It’s wasteful to break up high-performing teams, but it won’t stop your teams from being Agile.

If team members don’t get along...

It’s normal for new teams to go through a rough patch while they figure out how to work together, so don’t worry if a team struggles at first. The team’s coach and manager can help mediate conflicts.

If a team has a history of interpersonal conflict, they might not be a good fit for Agile. If there’s just one person whose behavior causes conflicts, you might be able to solve the problem with individual mentoring or by moving them to a different team.

If you can’t get the business, customer, or user expertise you need...

[Coffin 2006] describes an experience with two nearly identical teams: one that didn’t include users’ perspective and one that did. The team with no users took 15 months to produce a product with mediocre value:

The total cost of the project exceeded initial expectations and the application under delivered on the user’s functional expectations for the system... real business value was not delivered until the second and third [releases] and even then the new system was not perceived as valuable by its users because it required them to change while providing no significant benefit.

A team composed of many of the same developers, at the same company, using the same Agile process, later produced a product with compelling value in one-fifth the time.

The first production release was ready after 9 weeks of development... it surpassed scheduling and functional expectations, while still coming in on-budget... In the first two months of live production usage over 25,000 citations were entered using the new system. The application development team continued to deliver new releases to production approximately every six weeks thereafter. Every release was an exciting opportunity for the team of developers and users to provide value to the company and to improve the user’s ability to accomplish their jobs.

One of the primary reasons for this success was user involvement.

Many of the shortcomings of the [first] system stemmed from a breakdown in the collaborative atmosphere that was initially established. Had users been more involved throughout the project, the end result would have been a system that much more closely aligned with their actual needs. They would have had a greater sense of ownership and communication between the various groups would have been less tense.


The success of the [second] system caused many people in the organization to take note and embrace the lessons learned in this project... other project teams restructured their physical arrangements into a shared project room as the [second] team had done.

Customer involvement makes a huge difference to product success. It’s one of the things that sets Agile apart from its predecessors. Make an extra effort to include business, customer, and user perspectives in your teams. If you don’t, the products they deliver are likely to disappoint.

If you can’t get the Delivering skills you need...

Delivering practices have a lot of benefits, so they’re still worth learning even if teams can’t be responsible for every aspect of their products’ delivery. They won’t reach fluency until they can, but, over time, they can use their experience to make the case for bringing in the people or training they need.

If you can’t get the Optimizing skills you need...

An Optimizing team needs business expertise, but they don’t necessarily need a traditional product manager. Sometimes technical team members with a lot of company history know their product and its market better than anyone else. If that’s the case, you’re good to go.

If a team doesn’t have anybody with business expertise, though, the Optimizing zone is a mistake. Stick with the Focusing and Delivering zones.

3. Choose Agile Coaches

Agile relies on self-organizing teams. A self-organizing team doesn’t have a predefined leader; instead, the team decides for itself who is in charge of what. They seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved.

When a team first forms, though, people won’t work together so easily. In addition, when teams are new to Agile, they have a lot to learn about how Agile works. Somebody needs to help team members learn.

This person is the Agile coach. Their job is twofold: first, to help the team learn how to use their Agile method; second, to help the team learn how to work together as an effective self-organizing team, which includes working together to remove organizational roadblocks. Ultimately, the job of the Agile coach is to make themselves unnecessary, so they can move on to another team.2

2As Andrew Stellman points out on Twitter (, companies need to ensure that this sort of lateral movement enhances, rather than harms, their coaches’ careers.

Coaching ability typically falls into three categories:

  • coaching self-organization, team development, and Focusing zone practices

  • coaching Delivering zone technical practices

  • coaching Optimizing zone business development practices

It’s rare to find one person who can coach teams in all three categories, although experienced Delivering and Optimizing zone coaches can often handle the first category as well. Teams need coaching in all the skills they’re developing, so you might need more than one coach per team if your teams are developing fluency in multiple zones simultaneously.

Choose your teams’ coaches when you form the teams. For pre-existing teams, if no one on the team is qualified to be the coach, you’ll need to add a coach to the team. Make sure the team accepts their coach. The most effective coaches lead from a position of earned respect, not organizational fiat. Similarly, don’t put coaches in a position of authority over the teams they’re on. It’s easier for people to learn if they’re not afraid of being judged.

My preferred type of Agile coach is the player-coach: a full-time member of the team who has genuine expertise and leads by example. Another popular approach is the facilitator-coach, often called a Scrum Master,3 who leads from the sidelines by facilitating conversations and resolving organizational roadblocks.

3The name “Scrum Master” originated in the popular “Scrum” method. The name is misleading; it‘s supposed to mean someone who has reached mastery in their understanding of Scrum, not someone who has authority or control over the team.

One of the reasons I prefer player-coaches is that there usually isn’t enough work to justify a full-time Scrum Master on each team.4 A single Scrum Master typically ends up serving multiple teams, which reduces the effectiveness of their coaching, as they’re not present to see and respond to team challenges. Scrum Masters often end up as glorified meeting organizers, which isn’t a good use of their talents.

4If you make the investments in this chapter, that is. If you don’t make the investments, there will be plenty of roadblocks for your Scrum Masters to beat their heads against. Think of it as a jobs program.

If you can’t hire any coaches...

You can grow your own Agile coaches. Choose senior practitioners that team members respect and trust—if they’re not immediately obvious, ask your teams for recommendations—and ask them to take on the challenge. Player-coaches that are dedicated full-time to their teams are your best choice.

This book has everything your coaches need to learn Agile practices, including lots of references to further reading. There’s less about how to coach self-organization and team development; for books about those topics, as well as coaching in general, see the “Investing in Agility Further Reading” section.

4. Create Team Workspaces

Agile teams are highly collaborative and communicate constantly. In order for that communication to be effective, not distracting, they need a team workspace designed for their needs. For most teams, it needs to be a physical work space. For teams that use remote work, it will be virtual. The “Team Room” practice has the details.

For in-person teams, creating a physical workspace is one of the most expensive investments you’ll make. It’s also one of the most valuable; as the “Team Room” practice discusses, physical team rooms act as productivity multipliers.

When your teams are just getting started, though, you may not yet know what sort of team rooms they need, or even if Agile is a good choice long-term. Your teams probably won’t either. Teams new to Agile underestimate how much they’ll enjoy collaborating and overestimate their desire for privacy.

So it’s okay to hedge your bets on physical workspaces. Set aside the budget for it—you’ll need good team rooms eventually, if you stick with Agile—but in the short term, you can commandeer a large conference room or part of an open floorplan for each team. If you set up any of your teams in an open floorplan, be aware that Agile teams have a lot of conversations and can be exuberant about successes. This could disturb their neighbors.

Whatever you decide to do, start working on it now. Physical team spaces take a long time to arrange.

If you can’t colocate your teams...

Agile works fine with fully remote teams. I address how to make Agile practices work for remote teams throughout this book. However, I do assume that your company and teams already know how to support remote work. Doing remote work well takes dedicated effort and additional organizational investment that’s beyond the scope of this book. REMOTE: Office Not Required [Fried and Hansson 2013] is a good resource to learn more.

What doesn’t work is partially-remote teams. The people off-site will miss out on the ad-hoc conversations that take place in the office. They won’t be able to keep up. It’s okay for people to work from home once in a while, but it doesn’t work to have a few people who are in a different location entirely. Everybody needs to be together, or everybody needs to be remote.

If you have a partially-remote team, you can work around the issue by requiring that the people in the office act as if they are remote, too. That means that all conversations need to happen in the team’s virtual team room (their online tools), even if they’d be easier and faster face-to-face. Otherwise, it’s too easy to leave out the people who are remote.

It also doesn’t work to have people with wildly different work hours. Everyone on a team should have at least a five or six hour overlap in their core hours. If there are people on your teams who can’t do that—for example, if they’re in very different time zones—either rearrange your teams or choose different teams to be Agile.

5. Establish a Learning-Friendly Purpose for Each Team

Every team has a purpose: their place in the organization’s big-picture strategy. Most software teams’ purpose involves building a product, or part of a large product, or serving a specific market segment. Sometimes a team’s purpose will be to promote some organizational initiative, such as moving software to the cloud, or improving uptime.

Teams’ purposes change over time. When a team is learning Agile for the first time, it’s best to choose a purpose that will help them learn. Practically speaking, this means three things:

  • A purpose that’s valuable, but not time-sensitive. If their purpose isn’t valuable, the team will have trouble engaging stakeholders. If the team’s under a lot of time pressure, they’ll have trouble learning. They’ll default to what’s worked for them in the past rather than taking time to learn new ideas.

  • A purpose that’s self-contained. The more the team depends on other teams, the more planning and scheduling challenges they’ll face.

  • A green-field (brand-new) codebase. This is only necessary for teams learning Delivering practices. Delivering teams do a lot to make their code easy to modify and maintain, and it’s more difficult to learn how to do that when working with existing code.

If there’s an important deadline...

Each team needs plenty of time to learn. If the deadline leaves lots of room to maneuver, you’re okay. If not, it’s usually better to delay trying Agile until after the deadline is met, or to choose different teams.

If there’s no green-field work to do...

Fluent Delivering teams can work on pre-existing code, of course, but it requires advanced techniques. Teams learning Delivering practices for the first time are likely to have difficulty with pre-existing code. Expect a longer productivity dip, more time needed to reach fluency, and more frustration from programmers on the team.

You can reduce (but not eliminate) these added costs by hiring a coach that has deep experience using Delivering practices with existing code. In particular, they need experience with test-driven development, refactoring, and evolutionary design. (For details about these practices, see Part III.)

6. Delegate Authority and Responsibility to Teams

Respect for people’s ability is central to the Agile philosophy, and nowhere is this more apparent than in Agile’s approach to authority and responsibility.

Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work... When equipped with necessary expertise and guided by a leader, they will make better technical decisions and better process decisions than anyone can make for them. [Poppendieck and Poppendieck 2003]

Mary and Tom Poppendieck

As organizations become more Agile, they move more and more decisions to cross-functional teams. You can see it in the fluency zones:

  • Focusing teams take responsibility for their process and task planning.

  • Delivering teams take responsibility for testing, deployment, and operations.

  • Optimizing teams take responsibility for product planning and business results.

From an organizational investment perspective, this means:

  • Work is assigned to teams, not individuals. Teams decide for themselves how to break their work down into tasks, and who on the team will perform those tasks. You may need to change ticketing systems and other workflow processes to fit this approach. Doing so has implications for performance evaluations, which ties into the “Change Harmful HR Policies” section.

  • Teams decide their own processes. In particular, teams should be free to use their own approach to day-to-day planning and task tracking rather being tied to a corporate tool. Management can put constraints on teams’ processes, but make sure that there’s a thoughtful reason for those mandates, not just foolish consistency.5

  • Focusing teams work with stakeholders to understand business needs and priorities. The organization needs to make sure teams have easy access to stakeholders or their representatives.

  • Delivering teams control their development, build, test, and release processes. Again, management can put constraints on those processes, such as mandating the use of a corporate release pipeline, but make sure teams have the ability to develop and release on their own without waiting for other teams.

  • Optimizing teams control their own budget and product plans. Management defines each team’s purpose, determines overall strategy, and defines the teams’ budgets. They also provide oversight in the form of reviewing business indicators. Within that framework, the organization needs to allow individual teams to decide for themselves how to achieve their purpose and spend their budget.

5Ralph Waldo Emerson: “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines... Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict everything you said to-day.”

If work must be assigned to individuals...

If your organization isn’t comfortable with teams making their own task assignment decisions, your organization lacks the trust that Agile requires. You might be able to convince people to change their thinking by demonstrating success with a pilot Agile team, but proceed with caution. Command-and-control management styles are generally incompatible with Agile.

If it’s not a widespread issue, but just a few individual managers that have trouble letting go, see the “Change Team Management Style” section.

If tools don’t support team-based work...

If your company has existing work assignment systems that are difficult to change, a short-term solution is to create a “phantom” person for each team who receives the team assignments. Alternatively, team members can choose to treat individual assignments as team assignments.

Long term, it’s better to fix the tools.

If teams have to use a corporate tracking tool...

One of Agile teams’ biggest sources of leverage is the ability to improve and streamline their process. Corporate tracking tools, including so-called “Agile Lifecycle Management” tools, limit teams’ leverage. Like so many of the products jostling for space on the Agile bandwagon, these tools tend to miss the point of Agile so badly that they actually decrease teams’ agility.

Forcing Agile teams to use a corporate tracking tool for their daily work will decrease their performance. A common solution is to maintain two tracking systems: a lightweight Agile approach, and the corporate tool. Every day, somebody on the team updates the corporate tool from the lightweight tracker.

You can reduce these costs by decreasing the amount of detail in the corporate tool. Ask if the tool really needs to be updated every day and for every task. Instead, see if teams can update it weekly or semi-monthly, and find out the smallest item that managers really need to track. Minimum marketable features are a good choice. If that’s not enough detail, user stories also work. (See the “Planning” chapter for more about these terms.) Further detail is counterproductive.

If teams don’t have access to stakeholders...

Unlike waterfall processes, which use an up-front requirements and business analysis phase, Agile teams work with stakeholders throughout development to refine plans and gather feedback. Without access to stakeholders, they won’t build the right thing.

If a team can’t work with one or more stakeholder groups, make sure the team has access to someone who represents those groups’ interests. Choose this person carefully: the quality of the team’s product will depend on that person’s availability and ability to accurately represent stakeholders’ needs.

If Delivering teams don’t have control over their release processes...

You won’t see the full benefit of Delivering fluency until your teams have control over their release processors. That said, there’s enough value to Delivering practices that the zone is still worth pursuing. You can chip away at the problem over time.

If Optimizing teams don’t have control over their product plans and spending...

Optimizing teams need the ability to conduct experiments and adapt their plans, and that requires them to control their plans and spending. Without it, you won’t see the benefits of Optimizing fluency.

7. Change Team Management Style

With teams deciding their own process, making their own task assignments, and coordinating with stakeholders, team-level managers could think there’s no place for them in Agile. But that’s not remotely true. The job of the Agile team manager changes, but it’s no less important than in a pre-Agile team.

Agile team managers manage the work system rather than individual work.6 Their job is to guide their team’s context so that the team makes correct choices without explicit management involvement.

6Thanks to Diana Larsen for her contributions to this section.

In practice, this means team managers:

  • Make sure the right people are on the team, so that the team has all the skills needed for its work. This includes coordinating hiring and promotions.

  • Make sure the team includes the coaches it needs, and act as a backup coach, particularly around interpersonal issues.

  • Mediate interpersonal conflicts, help team members navigate the chaos of change, and help team members jell as a team.

  • Help individual team members develop their careers. Mentor individuals to become future leaders and encourage team members to cross-train so that the team is resilient to the loss of any one person.

  • Monitor the team’s progress towards fluency—the beginnings of Parts II-IV describe how—and coordinate with the team’s coaches to procure training and other resources the team needs to reach fluency.

  • Procure the tools, equipment, and other resources the team needs to be productive.

  • Ensure that the team understands how their work fits into to big picture of the organization, that they have a charter (the Purpose, Context, and Alignment practices in the “Teamwork” chapter), and that the charter is updated regularly.

  • Provide insights about how well the team is fulfilling their charter and how their work is perceived by stakeholders, particularly management and business stakeholders.

  • Maintain awareness of the relationships between the team and its stakeholders. Help the team understand when and why those relationships aren’t working well.

  • Advocate for the team within the rest of the organization, and coordinate with peer managers to advocate for each others’ teams. Help the team navigate organizational bureaucracy and remove impediments to their success.

Managers’ managers also need to change their expectations to match.

If managers have trouble letting go...

Micromanagement is annoying, but isn’t a deal-breaker in the short term. Managers often micromanage when they don’t what else to do, or when they fear that there won’t be a place for them in an Agile environment. Reassure managers that they still have a role by showing them what that role looks like. Training or a good Agile coach can help.

8. Replace Waterfall Governance Assumptions

Governance is the way work is approved, tracked, and managed. Not using waterfall governance for Agile teams may seem obvious, but waterfall assumptions can be subtle and widespread. They often stem from outdated views of software development.

Early software development revolved around projects, which had clear start and end dates. When the software shipped, the project was over. When more work was needed, a new project would be started.

Modern software development doesn’t work that way, of course. Software today involves ongoing development, maintenance, and operations. Software is a product, not a project, and some level of ongoing work is required until the product is retired. But many organizations still fund software development on a project-by-project basis.

Project-based accounting results in a whole series of complications. Projects typically require a fixed budget to be approved in advance. But if you need a budget in advance, you need to commit to a plan in advance. To commit to a plan in advance, you need to know your requirements in advance. To ensure you don’t exceed your budget, you need a way of monitoring conformance to the plan. In other words, you need a predictive process. And, oops, Agile is adaptive, not predictive.

Agile governance is simpler. Fund products on an ongoing “business as usual” basis. Your biggest expense will be people (usually), so budget for a team of X people, where the cost of X is less than the product’s value. Track progress by expecting the team to ship early and often. Look for a steady stream of value, whether that’s revenue or something else. Manage the team at a strategic level: monitor the value they create and adjust their purpose, budget, and team size accordingly. When the product stops providing enough value, shut it down, or put it on the back burner, and give the team a new product to work on.

This is simplified, but the point holds: for Agile teams, allocate an ongoing budget based on your estimate of value, not cost. Expect your Agile teams to deliver value early and often, measure the actual value they create relative to your estimates, and adjust your plans and costs to match.

If waterfall governance is required...

You can adhere to waterfall governance policies if you need to. It’s okay for a few pilot teams, but it’s wasteful, so switch to Agile governance before spreading Agile more widely. Even for a pilot team, waterfall governance is like sand in the gears: a little bit is wasteful and annoying, and a lot will grind you to a halt.

The most common governance demand is to produce a fixed plan and budget in advance. The simplest way to meet this demand is to use whatever approach you use now, then start the Agile part of the process after you’ve gone through project approval. Alternatively, for teams that have both Focusing and Delivering fluency, you can allocate one or two months for “planning,” conduct 4-8 real development iterations, and use the practices in the “Planning” chapter and the “Forecasting” chapter to dial in a high-quality roadmap.

Other up-front documentation, such as a requirements analysis document or design document, can also be done using existing approaches prior to starting the Agile part of your work. Remaining compliance work can usually be scheduled alongside your Agile work, with user stories (see the “Stories” practice), like any other request.

Waterfall governance is incompatible with Optimizing fluency, which relies on a flexible product-based approach. If you’re required to adhere to a waterfall governance policy, limit your aspirations to the Focusing and Delivering zones.

If you’re a software development provider...

If you provide outsourced software services, or other sorts of contract-based software development, you can still be Agile. Your approach will depend on the type of software contract you use.

Time and materials (T&M) contracts are the most compatible with Agile. In a T&M contract, the client simply pays the provider for work performed. It’s similar to the "business as usual" funding Agile teams prefer.

Predictive T&M contracts put all the risk of incorrect predictions on the client, because if the work takes longer than expected, the client has to keep paying or be left with nothing. Agile T&M contracts can mitigate these risks by specifying regular demonstrations of work in progress, at least once per month delivery of working software, and the opportunity to change or cancel the work after every delivery. This allows the client to use Agile governance of the style described above.

Fixed-price contracts, in contrast, puts the risk of incorrect predictions on the provider. In a fixed-price contract, the project requirements are defined in advance. The provider quotes a price based on those requirements, and if development takes longer than predicted, the provider eats the extra cost. Providers typically mitigate this risk by charging high change fees. They’ll often quote a low price in order to win the bid, then make their profit from the inevitable change requests.

Given the inevitability of changes in software development, fixed-price software contracts create an adversarial relationship between client and provider that’s at odds with Agile’s philosophy of customer collaboration and responsiveness to change. That said, Agile teams can perform fixed-price work. Start with whatever estimating and bidding process you use currently, then use your Agile teams for the development and delivery portion of the work.

Cost-plus contracts inhabit a middle ground between T&M contracts and fixed-price contracts. Risk is shared between client and provider. They’re still based on an up-front definition of requirements, though, so the Agile approach is the same as for fixed-price contracts.

Contracts that depend on up-front requirements are incompatible with Optimizing fluency, but they’re fine for the Focusing and Delivering zones.

9. Change Harmful HR Policies

Agile is a team sport, and despite paying lip service to teamwork, many companies have policies that unintentionally discourage it. Any policy that puts people in competition with each other is going to make Agile more difficult. A particularly destructive example is stack ranking, in which people are evaluated relative to each other, with the top of the stack getting promotions and the bottom getting fired, regardless of their actual performance.

A related issue is managers that only value tangible output. On an Agile team, there are many ways to contribute to success, such as the person who doesn’t write a lot of code, but spends a lot of time reproducing bugs, or the person who works in the background to smooth over interpersonal conflicts.

Rewarding individuals instead of teams makes this worse. It sends a message that assisting others is less important than pursuing your own goals. At its worst, emphasis on individual work turns into hero culture, where talented individuals are rewarded for working long hours in isolation, often to the detriment of overall team performance.

Organizations can also develop blame culture, which responds to mistakes by punishing culprits. The Agile mind-set, in contrast, treats mistakes as a learning opportunity. For example, a non-Agile organization might fire a programmer for accidentally deleting a crucial production database. An Agile organization would instead ask, “what checks and balances can we put in place to prevent accidental database deletion, and how can we make it easier to recover from these sorts of mistakes?”

It takes time to change HR policies, so start on them early. You’re likely to need the backing of senior management. It helps to look for creative ways to apply existing policies, rather than removing policies altogether, which can be more difficult. Remember, too, that managers often have discretion in how they apply policies, so if you hear that something “can’t be done,” it may be a manager that you need to convince, not HR.

If your organization has a cultural problem, there’s probably not much you can do about it in the short term. That’s okay. Focus on changing the way managers treat your Agile teams rather than trying to change the whole organization.

If HR policies are set in stone...

Individual managers can often work around or mitigate harmful HR policies, so bad policies aren’t a deal breaker, so long as your teams’ managers are on board with Agile and are savvy about navigating corporate bureaucracy.

If you have a lot of Agile teams, you won’t be able to get a savvy manager for every team, so you’ll need to change the policies first. If you can’t change HR policies, limit your Agile aspirations to a few pilot teams—with sharp managers—and use their experiences to motivate the changes you need.

10. Address Security Concerns

This investment only applies to colocated Delivering teams, which use techniques such as the “Pair Programming” practice or the “Mob Programming” practice to work together at the same computer. This can be worrying from a security perspective, because the person who logged in to the computer might not be the one who is actively using the computer. In fact, the person who logged in might even step away to go to the bathroom or have a side conversation. Because people switch who is at the computer frequently—as often as every few minutes—logging out and back in again every time a new person is at the keyboard isn’t feasible.

Work with your company’s security team to resolve their concerns. You can usually find a creative way to support Agile work while also remaining secure. One common approach is to create a locked-down shared development account. Some companies combine this with dedicated development workstations or shared server-based VMs. Email and other individual work takes place on individually-assigned laptops.

A related issue is traceability. Some companies require that every commit be traceable to its original authors. You can meet this requirement by adding the authors’ initials or emails to the commit comment. Git has a convention of adding Co-authored-by lines to the end of the commit.7

7Documented at Thanks to Jay Bazuzi for bringing this to my attention.

Some companies require that all code be reviewed prior to release. Pairing and mobbing meet this requirement, but you may need to modify tooling to allow code to be released without a separate review phase. If removing the requirement entirely isn’t an option, you might be able to modify the tool to skip commits that have co-authors.

If there’s no flexibility around security requirements...

You can require that the person who logged in stays at their computer. If they need to step away for a moment, either they switch logins, or work stops until they’re back. This introduces more friction than you might expect, so prefer solutions that allow work to continue.

Teams can also use tools designed for collaborative remote work rather than working at the same computer. This introduces a lot more friction than the other options, even when team members are sitting side-by-side, so I don’t recommend it unless your team is already remote.

If you’re required to have a separate code review step...

Code written by a pair or mob has already been peer reviewed, so teams can rubber-stamp reviews of that code. It adds friction, though, so it’s best to remove this requirement prior to spreading Agile widely.

11. Go Shopping

Whether they’re in-person or remote, your teams will need equipment, tools, and supplies to make collaboration more effective.

For colocated teams, provide following equipment and supplies. Although some of these can be replaced with electronic tools, invest in the physical equipment. It’s not very expensive and it will allow your team to take advantage of the strengths of face-to-face collaboration. The “Ownership” chapter has more details.

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

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

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

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

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

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

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

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

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

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

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

8Technically, a “magnetic whiteboard” isn’t actually magnetic, but has a steel backing so that magnets stick to it.

9One out of eight men have some form of color-blindness.

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

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

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

  • One development-grade computer at each pairing station.

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

  • At least two monitors.

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

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

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

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

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

Remote teams need an electronic version of the team workspace:

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

  • Messaging software, such as Slack, for asynchronous conversation.

  • Collaborative workspace software, such as Miro or Mural, for free-form collaboration.

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

  • For Delivering teams, collaborative programming tools that support pairing or mobbing (see the “Pair Programming” practice and the “Mob Programming” practice for details).

In all cases, avoid purchasing new licenses for Agile Lifecycle Management software or other tracking software unless the team explicitly requests it. Even then, wait until the team has tried the lightweight planning practices described in Part II.

Further Reading


Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Chapter 3: How to Be Agile

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

How to Be Agile

What does it mean to “be Agile?”

As we’ve seen in the previous chapters, Agile is a philosophy: a way of thinking about software development. To be Agile, you need to put the Agile philosophy into practice. Paying lip service to Agile ideas doesn’t get you anything. It’s action that matters.

Practicing Agile

Every team has a way of working—a process, or method—that they follow, even if it isn’t formally written down. It’s rarely articulated, and isn’t necessarily self-consistent, but that method reflects an underlying development philosophy.

For a team to be Agile, they need to change their method to reflect the Agile philosophy. This is both easier and harder than it sounds. It’s easy because, in most cases, they can start with one of the many off-the-shelf Agile methods, like the one in this book. It’s hard because they need to change their way of working, and that involves changing a lot of habits.

Methods consist of individual elements the Agile community calls practices. These are things like using version control, having automated builds, and giving demos to stakeholders. Most practices have been around for decades. Agile methods combine them in unique ways, accentuating those parts that support the Agile philosophy, discarding the rest, and mixing in a few new ideas. The result is a lean, powerful, self-reinforcing package.

It’s tempting to choose practices that are similar to what you’re already doing and ignore practices that are different. Avoid this temptation! The practices that are the least familiar are often the ones that involve the biggest change in philosophy. They’re the ones that your teams need the most, if they’re really going to be Agile.

In addition, Agile practices often perform double- and triple-duty, solving multiple software development problems simultaneously and supporting each other in clever and surprising ways. You won’t truly understand how it all works until you’ve seen it in action for a while.

So, although it’s tempting to customize your Agile method from the beginning, it’s best to start out with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about how to improve, observe what happens, and repeat.

The Road to Success

The majority of this book—parts two through four—is dedicated to a curated set of Agile practices that have been proven in practice.1 To succeed with Agile, follow these steps:

1The method in this book is primarily based on Extreme Programming, but it also draws inspiration from Scrum, Kanban, Lean Software Development, the DevOps movement, and Lean Startup.

  1. Choose the zones that your organization both needs and is willing to pay for, as described in the “Choose Your Zones” section at the end of the previous chapter.

  2. Figure out which investments your organization needs to make (see the “Investing in Agility” chapter), and get your managers, teams, and stakeholders on board with making those investments, as described below.

  3. Help your teams to apply all your chosen zones’ practices together, as much as they can. The practices are self-reinforcing, so they work best when you use them all together. Parts II-IV of this book describe the practices for each zone.

  4. Follow the practices rigorously and consistently. If a practice doesn’t work, try following this book’s approach more closely. Teams new to Agile often under-apply the practices. Depending on which zones you choose, expect each team to take up to four months for the practices to start feeling comfortable and another two to six months for them to become second nature.

  5. As your teams become confident they’re applying the practices correctly—again, give it several months—they can start experimenting with changes that aren’t by the book. Each practice in this book includes a discussion of why the practice works and how it can be changed. Each time a team makes a change, they should critique what happens and make further improvements. (The team retrospective is a good place for this—see the “Retrospectives” practice.) Each team will have its own challenges and should make its own changes. Every team will end up with its own custom process.

  6. There is no last step. Agile software development is an ongoing process of learning and improvement. Never stop practicing, experimenting, and evolving.

Kaizen and Kaikaku

Kaizen (rhymes with “I win”) is a common term in the Agile community. It’s a Japanese word meaning “improvement.” In the West, it’s come to mean a process of continuous gradual improvement: constantly reviewing and improving your practices at all levels of the organization.

Continuous improvement is an integral part of being Agile, so shouldn’t you kaizen your way to Agile in the first place? Counterintuively... probably not. Kaizen is for improving your existing ways of working. If you have a document-oriented culture, kaizen will help you streamline your documents. If you have a blame-oriented culture, it will help you place blame more accurately. But it won’t help you make the leap from either to Agile.

To jump from one way of working to another, you need a different Japanese word: kaikaku (rhymes with “I rock you“). Kaikaku means “radical change.” Instead of incrementally improving your existing way of working, as kaizen does, kaikaku fundamentally changes your underlying approach.

The great Agile teams I know all started with kaikaku. They figured out what they wanted from Agile, how they were going to invest in getting those results, and went all in. This can still be done incrementally—you can change one team at a time, or one division at a time—but for any given team, the change to Agile is all-in. It’s a disruptive change, but the disruption is relatively brief: less than half a year.2

2If you have many teams, the overall time frame will be longer.

I see many more companies with mediocre Agile teams than great Agile teams. One thing the mediocre teams have in common is that they didn’t go all in. They tried to kaizen their way to Agile. It seems to work at first, but invariably stalls out. People burn out on the mismatch between Agile ideas and company values. They get tired of absorbing big new ideas. Change fatigue sets in and progress stutters to a halt after several years of effort. Ironically, the disruption from approaching Agile this way lasts much longer than the disruption from kaikaku.

If your company is new to Agile ideas, regardless of whether they already use the name, use kaikaku. It’s faster and safer. If radical change is a scary proposition, reduce risk by starting with a pilot. Choose just one team, and maybe just the Focusing fluency zone. You can use that experience to guide bigger changes in the future.

Teams that are already Agile can kaizen their way to better results within their current fluency zones. See the “Improvement” chapter for details. To move to new zones—for example, if a team is fluent in the Focusing zone, and wants to add Delivering or Optimizing fluency—kaikaku is still the best approach. New zones require new investments and major changes, and that’s best done all at once.

Successful kaikaku requires discipline and care. And it starts with...

Get Management Buy-In

If you want to be Agile, you need management support. Without it, the mismatch between your teams’ Agile practices and your organization’s non-Agile culture will cause constant friction. If you’re a manager yourself, you still need your manager to be on board, and it’s best if your peers support you, too.

1. Start with a conversation

It begins with a conversation. This is often easiest one-on-one, and you’ll be most successful if your conversations are in-person, or at least over video. Start with an influential manager you trust and recruit them as an ally. They’ll help you understand who else you need to talk to and how best to approach them.

In your conversations, starting with that first manager, talk about the challenges your organization faces with software development. Based on the benefits described in the “Choose Your Agility” chapter, talk about how you think software development could be better in your company. Don’t monopolize the conversation, though; engage your audience. Briefly share the benefits of each zone and ask which zones they think are important. Ask them why. Spend more time listening than talking.

Above all, focus on what they can get and what inaction could cause them to lose rather than pushing Agile for the sake of Agile. In fact, given the extent of misunderstandings about what Agile is, you might be better off not even mentioning the word “Agile.”

2. Get the economic buyer’s approval

Your ultimate goal is to speak to the person who has the authority to make the investments your teams need, or to have a trusted manager speak on your behalf. In sales, this person is called the “economic buyer.”

Economic buyers are often surrounded by gatekeepers who see their job as protecting the economic buyer. They’ll ask you to make your pitch to them, so they can present it to the buyer. They’re not trying to steal your idea; they’re trying to save the buyer time. Sometimes they’ll assure you that they’re the real buyer, even if they don’t actually have the authority needed.

Don’t be fooled. Although it’s helpful to get gatekeepers on your side, and often necessary, it’s not enough. Gatekeepers can’t approve the investments you need. You need to talk to the real economic buyer.

Prior to talking to the economic buyer, focus your conversations on the benefits of Agile: what’s at stake. The investments are likely to be a distraction, or even a source of concern, because the people you’re talking to won’t have the authority to make those investments.

When you finally talk to the economic buyer, your goal is to get them to agree in principle to investing in Agile. You probably won’t have a lot of time, so stay focused on the big picture. It’s also often best if you approach your meeting as a conversation, rather than a presentation with slides, but your allies will know the best approach for your specific situation.

In your conversation with the economic buyer, talk to them about what they want from their organization and how Agile will help. This works even better if a manager they trust speaks informally on your behalf.

Once the buyer is on board with Agile’s benefits, talk about the investments. Summarize the investments needed for each zone (see the “Summary of Investments” sidebar), along with how those zones map to what they want, and ask the economic buyer which of those investment/benefit tradeoffs seems most appropriate. Giving them a choice of several options, rather asking for a yes/no decision, reduces the chance that they’ll reject you outright.

Assuming the economic buyer agrees to investing in Agile in principle, or at least is worth considering further, ask for permission to create a concrete proposal. Ask what they need to see in the proposal, in general, for them to approve it. Ask for them to recommend a sponsor for you to work with, provide a date when you’ll have the proposal to them—within a day or two is best, so it’s a good idea to have a rough draft done already—and ask when you should expect to hear back.

Finally, ask for permission to follow up with them. They probably won’t get back to you when they said they would, so it’s good to be able to say, “I’m following up as you requested.”

3. Make a formal proposal

If you got this far, congratulations! You’ve passed your most important hurdle. Now you need to follow through with a proposal.

The formality of your proposal will depend on your organization. Your sponsor and other allies will help you understand how to format your proposal, help you refine it, and promote it to the economic buyer. Be prompt, polite, and persistent.

In your proposal, describe the benefits your that organization can expect to see and the investments it needs to make. Be concrete. The “Choose Your Agility” chapter describes Agile’s benefits in general; translate those benefits to your actual situation, the investments the economic buyer is willing to make, and what that realistically means for your organization.

For the investments part of your proposal, read the “Investing in Agility” chapter and translate each step into concrete requests. You may have to compromise on some investments. That chapter explains how. But avoid compromising too much. The investments are ultimately what make Agile’s benefits possible.

If this sounds like too much work...

This careful buy-in process is for when support is uncertain: when you’re working with multiple teams, asking for big investments, or working in a bureaucratic organization that’s uncomfortable about Agile ideas (even if they use the name a lot).

But sometimes, that’s not the case. Sometimes you’re just helping one small team become more Agile. If you and your manager already have the power to make the investments you need, do it!

If management thinks they’re already Agile...

Some organizations—these days, a lot of organizations—think they’re already Agile. One company told me, “We’re post-Agile!” Or you might hear, “we’re little-a agile, not big-A Agile!” But when you compare the philosophy in the “What Is Agile” chapter to how the organization acts, and the benefits in the “Choose Your Agility” chapter to what they get, you see that they’re nowhere close.

There’s nothing to be gained from arguing about terminology. If they want to say they’re agile, or post-agile, or extra-super-duper agile, let them. Instead, stay focused on the situation at hand: the challenges your teams are facing. The benefits the organization could get. The investments needed to get those benefits.

If management isn’t supportive...

If you can’t get traction with managers at first, don’t give up. Put yourself in their shoes. What does organizational success mean to them? What about personal success? How can Agile help them get what they want? If the answer is “it can’t,” then maybe Agile isn’t a good fit. Choose another approach to software development, one that properly fits your organization’s culture. Waterfall is a fine choice! Keep your documentation lightweight, your approach flexible, and your delivery horizons down to 3-6 months—shorter is better—and you’ll avoid its most common failure modes.

If you have a trusted manager you can turn to, ask for help and advice. If not, try conducting an informational interview with a manager at a company who’s been through it before. (They may try to recruit you. Win/win!) The “Change Your Organization” sidebar has more ideas.

In the early days of Agile, when it was a grass-roots movement, many teams adopted Extreme Programming (a popular Agile method) on their own, with little to no permission or support. You could try that. But I don’t recommend it. In the experience reports from teams who tried it, somebody—often the project manager—ended up having to bridge the gap between company culture and Agile philosophy. It was a thankless job and burned them out.

Some people use the Kanban method to motivate organizational change.3 Kanban wraps around existing ways of working to highlight work-in-process bottlenecks and the cost of delay. It’s easy to put in place and can motivate a more Agile approach to your work.

3Note that the Kanban method is much more than just the Kanban board some teams use for planning.

Kanban is a kaizen approach to change, so it’s slow and can only go so far, but it’s very effective and can lead to permission for kaikaku. See XXX for more information.

If nothing you do makes a difference, take a hard look at what you need for personal success. Assume the status quo won’t change, because it probably won’t. Either that’s good enough for you—and it often is—or it’s time to move to a company that better fits your needs.

Get Team Buy-In

Agile puts people first, so it shouldn’t be a surprise that you need your prospective Agile teams to agree to it as well. It is possible to force people to nod agreement with gritted teeth, but—and I speak from hard-won experience, here—that road involves a lot of employee turnover. Or fails, with a passive-aggressive whimper.

When I’m asked to help teams become Agile, I always speak to each team on their own, without managers present. (I used to include managers. No longer. That’s the “hard-won experience” part.) In your case, if you’re in a position of authority, have the teams’ coaches speak to them without you.

First, though, you’ll need to choose your prospective teams. Review the next chapter’s material about choosing teams and selecting coaches. Select a few extra candidates, just in case, because the secret to team buy-in is giving them the opportunity to refuse.

When you or the coach talk to each team, explain that their team has been chosen as a possible candidate to try Agile. I explain why their managers are interested in Agile, what benefits it will bring to the organization, and how it will affect them personally. I also explain that changing work habits can be stressful, and that they should expect a period of chaos—typically, up to three months—as everyone figures out how to make Agile work for them.

The Satir Change Model is one way of explaining how teams react to change. Steven Smith has a good article on the Satir model at that includes tips for helping team members through each stage.

“If you agree,” I tell them, “I’ll ask you to follow a by-the-book approach to Agile for three months. At that point, we’ll evaluate what’s working, what’s not, and make improvements.4 After six months, you’ll have the final say on whether you continue with Agile or go back to what you have now.”

4This is a little white lie. Agile involves constant improvement, so we evaluate what’s working and what’s not within a few weeks. But we do pause for a bigger evaluation at the three month mark.

Then I open the floor for questions. Teams typically a lot of questions about the process, but invariably, one of the questions is, “What happens if we say no?” My answer is always the same: “Then it doesn’t happen.” This is important! The veto must be real. If you don’t give people the option of saying, “no,” their “yes” doesn’t mean anything. By giving people a real chance to refuse now, and a concrete opportunity to change their minds later, you make it safe to try something new.

Make sure you allow plenty of time to answer everybody’s questions. The meeting usually takes about an hour, but sometimes it goes longer. After everyone’s questions have been addressed, ask for a vote. Remind everyone that there’s no consequence for voting against Agile. Mean it. Then ask the team to vote.

If team members are skeptical...

Skepticism is normal, and you should expect it. Be straight with your teams: change is disruptive, but the results are rewarding. Be clear about the practices that you think people might find frustrating or unusual at first, such as pair programming. That will help disarm skepticism and also make it easier to introduce those practices in the future.

It helps to emphasize that this is an experiment, and that the team has the final say over whether they stick with Agile or not. I often ask the team to schedule the three-month and six-month evaluation meetings on the spot. That makes them real.

If a few team members refuse...

If a few people disagree, ask them to explain why, and see if their objections can be resolved. If they can’t, ask if they’d be willing to reserve judgement and go along with the rest of the group for six months.

If they still don’t agree, ask if they’d be okay moving to another team, subject to management approval. If that’s not okay, or if the dissenters won’t speak up (in the case of an anonymous vote), then this team isn’t a good candidate.

If the majority of the team refuses...

If the team doesn’t agree, then you’ll have to choose another team. I’ve only had this happen once, but it does happen. In my case, it was because the team didn’t trust their organization to give them the time they needed to learn. In retrospect, they were correct, and it’s a good thing we didn’t go through with the change.

If people lie about their acceptance...

Sometimes, people will vote for Agile while secretly opposing the changes. Other than making sure people don’t feel coerced, there’s nothing you can do about it. It’s not productive to second-guess people’s votes.

Even if nobody lies, the nature of change is that everyone will have second thoughts once in a while. You’ll need to work through those objections as they arise. When they do, it helps to be able to remind people that they to agreed to stick with the experiment for six months, but there is a clear end date, and if it still isn’t working by then, they’ll be able to change their mind. Be compassionate and respectful; changing habits is takes time, and people can feel like the norms they rely on have been set adrift.

In my experience, by the time the six month date rolls around, the chaos of change will be past and people will be happy with their Agile method. That’s been true for every team I’ve worked with.

If you’re introducing Agile to a lot of teams...

Changes that affect a lot of people are much more disruptive than changes that only affect a few teams. The disruption is multiplicative. Rumors start flying, people start worrying about their jobs, and the upcoming changes become part of every conversation.

Large changes—those that directly impact more than 30-70 people—require professional change management. Depending on the size of your organization, your HR department may have change management experts on staff who can help. If not, you can hire consultants. Some Agile consultants have change management experience and can guide both aspects of your Agile adoption. For very large changes, you’ll need dedicated change management experts to work alongside your Agile guides.

Organizational leaders often underestimate the importance of expert change management. This is a grave mistake! To put it in terms of the Satir Change Model, everybody goes through a period of resistance and chaos when they learn about a change. But everybody goes through it at their own pace, and leaders typically go through it first. Not because they’re better or more resilient, but because they know about it first.

By the time the rest of the organization learns about the change, organizational leaders have already experienced the “transforming idea” that resolves their feelings of resistance and chaos. To the leaders, the change now seems obvious and necessary. Why would anybody disagree?

Then they introduce the change and experience massive amounts of pushback and disruption from people going through their own resistance and chaos stages. It can kill the change entirely.

Proper change management can’t prevent all disruption, but it can reduce it. Don’t skimp. If you’re not prepared to get expert help, limit your Agile changes to a few teams at a time.

Get Stakeholder Buy-In

Your teams’ stakeholders are everyone who is affected by, or has an influence over, their work. For you and your Agile improvement efforts, your stakeholders also include anybody else who has influence over the changes you want to make.

You don’t need every stakeholder to buy in to your Agile intentions. You do need the ones with a lot of political influence to do so. If they don’t, they could quietly sabotage your efforts, pulling the rug out from under you in six months to a year, even if—or especially if—Agile is succeeding.5

5Alistair Cockburn calls this “organizational antibodies.” The more successful a change initiative is, the more people worry that it will affect them, and the more they fight against it.

The stakeholders who are most likely to resist are your teams’ business partners: product management, marketing, and sales. Agile represents a major shift in how teams interact with these groups. They’re used to a predictive approach, with a focus on commitments and deadlines. Their interactions with development teams are typically focused on documents, progress reports, and sign-offs.

Agile teams focus on feedback, frequent delivery of value, and adapting their plans. They constantly ask their stakeholders for feedback, then change their plans based on what they learn. Because their plans are always changing, they don’t make detailed release commitments. Some teams do provide release forecasts, but even then, those forecasts aren’t commitments, and they change frequently.

Some stakeholders love it. Finally, they know what’s really going on, and they have the ability to influence the outcome. Others, particularly those who have been burned by missed commitments in the past, see Agile as a political maneuver: a complicated way for teams to avoid making promises. They fight Agile tooth and nail.

Talk to your teams’ key stakeholders about Agile. This is often best done one-on-one. The topic is politically fraught, so make sure you plan your strategy with your management allies. You might not be the best person to have the conversations—a manager or person your stakeholders trust might be a better choice.

When you (or your proxy) talk to stakeholders about Agile planning, be sure to put yourself in their shoes. Demonstrate that you know what’s important to them. Perhaps they need to make marketing plans, or talk to sales prospects about competitive new features, or coordinate delivery with a third party. You want to make a connection: to dispel their preconceptions that you’re just another arrogant engineer here to tell them they can’t have what they need.

Talk about what you’re going to do better. The “Planning” chapter describes how it works. Don’t sugar-coat or over-promise. Instead, say something along the lines of, “We want to do better. We’ve found that, when we fix our plans in advance, we end up disappointing customers with delays or half-baked results. That’s not good for you or our reputation as a company. Instead of making a fixed plan and surprising you with delays, we’re going to give you more visibility and control, so you can see problems early, and we’ll adjust our plans as we go to get better results.” For many stakeholders, it’s not missed deadlines that are the biggest problem; it’s being blindsided by them.

Throughout each conversation, treat your stakeholders as trusted partners. You want them to be successful. You’ve got to balance multiple interests, and Agile teams don’t use predictive planning, but you’re there to help. You’re going to do everything you can to make their job easier and more successful.

If concrete commitments are required...

The Agile way is adaptive planning: changing your plans as you go to achieve the best possible results. That’s incompatible with making precise commitments in advance. You can commit to a specific date and steer your plans to meet that date, but you can’t predict exactly which features will be done on that date.

If that’s not good enough, fluent Delivering teams have the ability to make reliable forecasts, although it takes 4-8 weeks of development to dial them in. This allows you to predict when a particular set of features will be done. You can combine that with long planning horizons and inflexible plans to make fixed-scope, fixed-date commitments.

If your teams aren’t fluent in the Delivering zone, or if you need to make predictions before development begins, you can keep using whatever big-picture planning technique you’re using today. Agile won’t make it worse, and as development proceeds, it will give you visibility into how things are really working out. Predictive plans aren’t the Agile way, but there’s more to Agile than adaptive planning, and you can work your way up to true agility over time.

That said, predictive planning is incompatible with the Optimizing zone, which is based around taking advantage of your ability to change your plans. If you have to make commitments in advance, limit your aspirations to the Focusing and Delivering zones.

Do be careful. Some people like finding scapegoats, and some companies have a culture of assigning blame. Fixed scope, fixed date commitments are notoriously unreliable. Even if Agile doesn’t make anything worse, it might be convenient to blame Agile—and you personally—for the same deadlines that would have been missed before Agile. If that’s the case at your company, introducing Agile could be a mistake.

If stakeholders don’t buy in...

Some software teams have a contentious relationship with their stakeholders, particularly those in product management and sales. It can get pretty acrimonious. In some cases, bad blood and a lack of trust might lead stakeholders to flat out refuse to support an Agile process. They might also object to the initial slow-down involved with learning Agile (see the “Account for Learning” section in the next chapter).

If only a few stakeholders object, you can choose teams that they’re not involved with. If a lot of stakeholders object, or if their high-level leadership objects, you might be able to convince them to try out a pilot with a single team. If you can, choose a team whose stakeholders are both influential and eager to try out new ideas. It might take a while—even a year or two—but they’ll come to like the visibility and control Agile gives them, and they’ll convince their colleagues to give Agile a chance.

Sometimes software organizations try to force Agile on their stakeholders. They can even succeed, if they have enough political power, but it leads to long-term blowback. If you face widespread, active opposition, to the point that even a pilot team isn’t acceptable, Agile isn’t a good fit for your organization.

Further Reading

Once you have the buy-in you need, it’s time to make your investments. We’ll talk about that in the next chapter.

XXX Reading recommendations TBD.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

AoAD2 Chapter 2: Choose Your Agility

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

Choose Your Agility

Real talk: There’s no point in Agile for the sake of Agile. The only reason to be Agile is to improve your results. So, what results will you get?

Let’s Talk Success

When I was a kid, I was happy to just play around with computers. I loved the challenge of programming. When I got a program to work, it was a major victory. Back then, even a program that didn’t work was a success of some sort, so long as I had fun writing it. My definition of success centered on personal rewards.

As I gained experience, my software became more complicated. I often lost track of how my programs worked, and I had to abandon some programs before they were finished. I began to believe that maintainability was the key to success—an idea that was confirmed as I entered the workforce and began working with teams of other programmers. I prided myself on producing elegant, maintainable code. Success meant technical excellence.

Despite good code, some products flopped. Even impeccably executed code could elicit yawns. I came to realize that my teams were part of a larger ecosystem involving dozens, hundreds, or even thousands of people. My software needed to satisfy those people... particularly the ones signing my paycheck. In fact, for the people funding the work, the value of the software had to exceed its cost. Success meant delivering value to the organization.

At each step along my journey, my understanding of the world expanded. For a while, I found myself perplexed by the companies that achieved massive organizational success despite creating technical messes and treating their people terribly. Now I've come to realize that my previous conclusions weren’t wrong. They were just incomplete.

  • Organizational success makes a company;

  • Lack of technical success breaks a company;

  • And personal success glues it together.

You need all three types of success to get the best results.

A Venn diagram showing three circles, marked “Organizational Success,” “Technical Success,” and “Personal Success.” There’s a star in the center where all the circles intersect.

Figure 1. Types of success

The Importance of Organizational Success

Organizational success is often neglected by software teams. They assume that, if they just do what they’re told, they’ll be successful.

Rest assured, however, that even if your teams aren’t taking responsibilty for success, the broader organization is judging them at this level. For senior management, it’s not enough for your software to be elegant, maintainable, or even beloved by its users. These are just means to an end. They care about results: the return on investment your teams produce. If your teams don’t achieve this sort of success, management will take steps to ensure that they do.

Unfortunately, senior managers don’t usually have the time or perspective to apply a nuanced solution to each team. They wield swords, not scalpels. They rightly expect their product teams to take care of fine details.

When senior management is unhappy with teams’ results, the swords come out. Costs are the most obvious target. There are two easy ways to cut them: set aggressive deadlines to reduce development time, or ship the work to a country with a lower cost of labor. Or both.

These are clumsy techniques. Aggressive deadlines end up increasing schedules rather than reducing them [McConnell 1999] (p.220), and offshoring has hidden costs of its own [Overby 2003].

Do aggressive deadlines and the threat of offshoring sound familiar? If so, it’s time for your teams to take back responsibility for success: not just personal or technical success, but organizational success as well.

Enter Agility

Will Agile help your teams be more successful? That depends on how much your company embraces its ideas. Agile development focuses on achieving personal, technical, and organizational successes. If you’re having trouble with any of these areas, Agile might help.

Organizational Success

Organizational success is crucial. Without it, the money will eventually run out. Organizational success doesn’t just mean dollars and cents, though; see the “What Organizations Value” sidebar.

Agile teams achieve organizational success by focusing on delivering value and decreasing costs. This directly translates to increased return on investment (ROI). Agile teams also validate expectations early, so if an idea won’t provide good ROI, you’ll find out early enough to stop working on it before your organization has spent much money.

Specifically, Agile teams increase value by seeking out business expertise, getting frequent user and customer feedback, and focusing development on the core value that their products provide. Agile teams release their most valuable features first and release updates frequently. When business needs change, Agile teams change direction to match. The best Agile teams actively seek out opportunities to adapt their plans.

Agile teams decrease costs as well. They do this partly via technical success; the best Agile teams generate only a few bugs per month. They also eliminate waste by cancelling bad products early and replacing expensive development practices with simpler ones. Agile teams communicate quickly and accurately, and they’re not bottlenecked by the work of a single team member. They regularly improve their process and code, making their software easier to maintain and enhance over time.

Technical Success

Technical success grants teams the ability to cost-effectively enhance and maintain their software. Without technical success, costs rise and your teams’ ability to make changes plummets. Eventually, they have to throw their software away and rewrite it. It can take years for the replacement to achieve feature parity with the old code. Meanwhile, they’re spending buckets of money just to catch up with where they used to be, all while their customers become increasingly frustrated with their lack of progress.

I highlight two Agile approaches to technical success in this book. The first is Extreme Programming (XP), an Agile method that’s particularly adept at technical successes. In XP, programmers work closely together, which helps them keep track of the nitpicky details necessary for great work. Programmers continuously integrate their code, which enables the team to release their software whenever it makes the most business sense. The whole team focuses on finishing each feature completely before starting the next, which prevents unexpected delays and allows the team to change direction at will.

In addition to the structure of development, XP includes advanced technical practices that lead to excellence. The most well-known practice is test-driven development, which helps programmers write code that does exactly what they intend. XP teams also create simple, ever-evolving designs that are easy to modify when plans change.

I also include techniques from the DevOps movement2, which brings XP’s ideas into the modern era of cloud-based software. Agile teams using XP and DevOps techniques create high-quality, low-defect software that’s easy to modify, maintain, and operate.

2Not to be confused with DevOps tools, which dominate much of the discussion around DevOps.

Personal Success

Personal success is, well, personal. Most people need more than a paycheck to feel satisfied, and they don’t always complain when they’re unhappy. In the best case, they find a new job, taking their accumulated organizational knowledge with them. In the worst case, they’ll quietly sabotage the company’s efforts as they agitate for work that’s more satisfying.

Agile development won’t satisfy everyone’s needs, and it’s different enough that it can be uncomfortable at first. However, once people get used to it, they find a lot to like about Agile:

Executives and senior management
People focused on the bottom line appreciate Agile teams’ emphasis on providing visibility, a solid return on investment, and long-lived code.
Users, stakeholders, domain experts, and product managers
People who care about what the software can do appreciate their ability to influence the direction of development; teams’ focus on delivering useful and valuable software; and increased delivery frequency.
Product and project managers
People interested in delivering a valuable product appreciate their ability to change direction as business needs change; teams’ reliability; and improved stakeholder satisfaction.
UX and graphic designers
People obsessed with user experience appreciate their ability to influence development plans; teams’ willingness to iterate on ideas; and faster, more accurate implementation of design ideas.
People who write code appreciate the improved quality of life that results from technical excellence; their improved influence over forecasts and schedules; and their autonomy.
People who focus on quality appreciate being integrated with the rest of the development team; their ability to influence quality at all stages of development; and more challenging, less repetitive work.
People who keep software running in production appreciate being included in development decisions; having operational requirements included in development plans; programmers’ focus on providing actionable telemetry and logging; and teams taking responsibility for post-release quality and up-time.

Working on Agile teams has provided some of the most enjoyable moments in my career. Imagine the camaraderie of a team that works together to identify and deliver products of lasting value, with each team member enthusiastically contributing to a smooth-running whole. Imagine how it feels to take responsibility for your areas of expertise, whether technical, business, or management, with the rest of the team trusting your professional judgment and ability. Imagine how pleasant it is to address the frustrations of your work and see quality improve over time.

Agile development changes the game. Developing and delivering software in a new way takes a lot of work and thought. Yet if you do it consistently and rigorously, you’ll experience amazing things: you’ll ship truly valuable software on a regular basis. You’ll demonstrate progress multiple times per month. You’ll have the most fun you’ve ever had in software development.

The Agile Fluency® Model

I’ve painted a rosy picture of Agile. Is it too good to be true? That’s up to your company.

In 2014, I partnered with Diana Larsen to analyze why companies see such different results from their Agile teams. We’ve both worked with Agile teams from the beginning, and, over the years, we noticed that Agile teams tend to cluster in different “zones” of capability. We captured these observations in the Agile Fluency3 Model [Shore and Larsen 2018].

3“Agile Fluency” is a registered trademark of Agile Fluency Project LLC, founded by Diana Larsen and James Shore.

A picture of the Agile Fluency Model. It shows a path from “Pre-Agile” through a shift in team culture to “Focusing,” followed by a shift in team skills to “Delivering,” then a shift in organizational structure to “Optimizing,” and finally a shift in organizational culture to “Strengthening.” The path continues and fades away, as if there are additional zones yet to be discovered.

Figure 2. The Agile Fluency Model

Although the “Agile Fluency Model” figure shows a clear path from one zone to the next, reality is messier: each zone actually consists of multiple skills, all of which develop in parallel. A team has proficiency in a zone when they’re able to apply all of its skills. They have fluency when they can do so with effortless grace, even under pressure. Teams can develop fluency in any order, although the progression shown in the figure is most common.

The zones correspond to how companies invest in Agile ideas. In other words, the fluency your teams achieve—and the results your company gets—depends on how much it buys in to the Agile philosophy. Not just lip service, but actual, meaningful changes that cost time, money, and political capital.

Each zone has its own set of investments, and you probably won’t be able to convince your company to invest in every zone. That’s okay. Each zone also has its own set of benefits, and as long as your company fully invests in at least one zone, you’re likely to see improvements.

Which zones should you choose? It’s a matter of picking the right cost/benefit tradeoffs.

Focusing Zone

The Focusing zone corresponds to the fundamentals of Agile. For your teams to reap the benefits of Focusing fluency, your organization needs to buy in to the core Agile philosophy.

What is that core philosophy? As we saw in the “Essence of Agile” section: Agile is adaptive rather than predictive, and people-oriented rather than process-oriented.

In practice, this means that Focusing teams regularly review and change their plans. They work as a tightly-knit team to define their own work processes and self-organize around completing the work. All the while, they’re Focusing on the next piece of value for their organization.

For most teams and organizations, this requires a shift in how they think about teams. Pre-Agile organizations make plans in advance, ask teams for estimates, and expect reports about how work is progressing relative to those estimates. Focusing teams revise their plans frequently—at least every month—and demonstrate progress by showing what they’ve completed.

Pre-Agile organizations break their plans into tasks, assign those tasks to individuals on the team, and judge individuals based on how well they complete their tasks. Focusing teams do their own task breakdown, decide for themselves who will work on each task, and expect to be judged on their ability to create value as a team.

Can your organization buy into this core Agile philosophy? Again, lip service isn’t enough. They’ll need to make concrete investments in the form of changes to team structure, management, and work environment. (See the “Investing in Agility” chapter for details.) It’s a “good news, bad news” situation: The bad news is that, when the rubber meets the road, some organizations won’t be willing to invest. The good news is that, if they refuse, you’ve discovered early that they’re not really on board with the Agile philosophy. You just saved yourself years of frustration and heartache chasing Cargo Cult Agile.

If you are able to get buy-in, Focusing fluency will take each team about 2-6 months of dedicated practice to develop, with benefits appearing within 1-4 months. Part II shows how. In exchange, expect to see the improvements in value described in the “Organizational Success” section. Some aspects of personal success described in the “Personal Success” section will also improve. Specifically, people with a business and user focus will like their improved visibility into the team’s work and their ability to influence teams’ plans.

You aren’t likely to see the improved technical success described in the “Technical Success” section, though, or the organizational cost savings that come with it. In fact, technical quality could get worse. Traditional approaches to design rely on careful up-front work based on firm plans. That doesn’t mesh well with Agile’s emphasis on flexible, frequently changing plans. As a result, Focusing teams often end up with an ad-hoc approach to design, which isn’t sustainable.

Poor technical quality can be frustrating for team members, lowering their feelings of personal success. It usually prevents the team from making reliable forecasts and commitments, which can be frustrating for stakeholders.

To improve technical success and make useful forecasts, you’ll also need fluency in the Delivering zone.

Delivering Zone

Companies who invest in the Focusing zone have taken an important first step: they’ve aligned themselves with the core Agile philosophy. This is critical! It’s the secret to Agile success.

But it’s not enough for long-term success. Although organizational success makes a company, and Focusing fluency will help you get it, lack of technical success breaks a company. Software built by Focusing teams becomes unmaintainable over time. Over the course of several years, costs will rise. The team will eventually lose their ability to make cost-effective changes. They’ll tell you they need to throw away the software and rewrite. That can kill a product.

Delivering teams prevent this problem by investing in technical success. They design their code so that it can absorb frequent changes. They keep code quality high, so they don’t waste time hunting bugs. They refine their production lifecycle so releases are painless and operations are manageable. They’re capable of Delivering reliable, low-defect software whenever it makes the most business sense.

This requires a shift in team members’ skills, which requires a substantial investment in learning and code quality, as well as structural changes to integrate technical disciplines such as Testing and Ops into each team. (See the “Investing in Agility” chapter for details.)

If your company makes these investments, Delivering fluency will take each team 3-24 months to develop, in addition to the time needed for Focusing fluency, although you’ll see benefits within 2-6 months. Part III has the techniques. The exact amount of time each team will need depends on the quality of their existing code and how much coaching they receive.

In exchange, expect to see the technical success factors described in the “Technical Success” section, the cost reductions described in the “Organizational Success” section, and the team member success factors described in the “Personal Success” section. Combined with Focusing fluency, that’s all the success factors described at the beginning of this chapter.

Optimizing Zone

The vast majority of companies would be satisfied with Focusing and Delivering fluency. But Agile imagines more. In its full glory, Agile is a world in which teams twirl and dance in response to changing market conditions. They experiment and learn; develop new markets; outmaneuver the competition.

Optimizing teams achieve this level of agility. They understand what their market wants, what your business needs, and how to bridge the two. Or, as in a startup environment, they know what they need to learn and how to go about learning it. They’re constantly Optimizing their product plans to achieve the most value possible.

This requires a shift in organizational structure. Creating optimal plans requires constant attention by people with deep business and product expertise, and that means having product and market experts join development teams full-time. It also means giving those teams full responsibility for their product budgets and plans.

These structural changes require high-level permission in the organization. It can be difficult to obtain. It typically takes teams at least a year of building trust via Delivering fluency before they get permission for these investments. Once that happens, Optimizing fluency takes another 3-9 months to develop, although benefits appear within 1-3 months. That said, Optimizing is a never-ending process of experimentation, learning, and discovery. Part IV describes how to begin.

Strengthening Zone

There’s one final zone in the Agile Fluency Model. It’s largely speculative: a possible future for Agile. It’s also only appropriate for organizations on the bleeding edge of management theory and practice. That puts it out of scope for this book. Briefly, the Strengthening zone involves distilling teams’ collective insights and channeling them into organizational improvements. If you’d like to learn more, start with [Shore and Larsen 2018].

Choose Your Zones

Will Agile get you better results than you’re seeing now? It depends on which zones your organization can support. In a vacuum, the first three zones together provide the best results and the purest realization of Agile ideas. But that also takes the most investment. Investing in more than you need could incur backlash. Only invest in the zones that will be a big benefit for your organization.

Once you’ve chosen a zone, though, invest fully in it. Without sufficient investment in a zone, the skills teams need to become fluent in that zone will develop slowly, if at all, and full fluency will probably be out of reach. You’ll incur the costs of learning without getting all the benefits, and you might even see worse results than now if teams don’t have the support they need.

In other words, choose the zones that your company both needs and is willing to pay for.

So, which zones should you choose? As you’ll see in the next chapter, it starts with a conversation with management. But here’s a handy guide.

  • Every Agile team needs Focusing fluency. It’s fundamental. If your company can’t at least invest in Focusing fluency, Agile isn’t a good fit. You don’t need perfect support, as the “Investing in Agility” chapter describes, but if you can’t at least get the minimum, you’ll need a different approach.

  • Delivering fluency decreases costs and increases development speed. It takes time to learn, but you’ll see benefits within 2-6 months, and it will pay for itself within a year. Without it, your code will eventually succumb to technical debt. That makes the Delivering zone a no-brainer for most teams. That said, some organizations aren’t ready to make the big investments in learning and code quality that the Delivering zone requires. It’s okay to start with Focusing fluency first, demonstrate success, and then use that to make further investment.

  • Optimizing fluency is where Agile shines brightest. It’s also a lot to ask. For most organizations, it’s best to build trust by demonstrating fluency in the Delivering zone first, then gradually take on more responsibility. But if your organization already has a culture of delegating decision-making authority to cross-functional teams, as is often seen in startups, Optimizing fluency will give you great results.

Whichever zones you choose, invest in learning all of them simultaneously. It’s fastest and easiest to learn Agile ideas if you practice everything together, because the techniques in the later zones make the earlier zones work better. If you can’t get all the investments you want, though, that’s okay. It takes longer, but as long as you can at least invest in Focusing, you can build up to the later zones over time.

Once you’ve chosen your zones, you’re ready to get started. That’s the topic of our next chapter.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

Complete “TDD Lunch & Learn” Series Available

Screenshot showing a slide labelled “Overlapping Sociable Tests.”

The “Testing Without Mocks” episode.

My full “TDD Lunch & Learn” series is now available! This weekly livestream series, which ran from May to September 2020, uses test-driven development (TDD) to develop a microservice and accompanying command-line application from scratch. Each episode focuses on a new challenge.

The series emphasizes real-world TDD, with a strong focus on “hard” problems such as networking, logging, and testing without mocks. If you’ve learned the basics of TDD and want to see how it works in the real world, this series is the perfect next step.

Start Here.

Microservice Architecture Without Microservice Overhead

Every week in my Tuesday Lunch & Learn livestream, we choose a useful software development skill, define a challenge related to that skill, and solve the challenge live. This week, we’re looking at microservice architecture.

Microservice architecture is a great way to partition code so that teams can work independently. It’s effective at preventing the “big ball of mud” problem that can plague large monolithic codebases.

But microservice architecture comes at a high cost. Because all communication happens via network calls, microservice architecture introduces a lot of complexity in the form of error handling and distributed transactions.

What if there was a way to get the advantages of microservice architecture without all the added complexity? In this episode, we look at “microliths,” a way to reduce overhead while still retaining the benefits of a microservice-based design. We cut the size of our codebase in half and increase performance across the board.

To follow along, download the code from GitHub and check out the 2020-09-29 tag. To see the final result, check out the 2020-09-29-end tag or view it on GitHub.

Visit the Lunch & Learn archive for more.

AoAD2 Chapter 1: What is Agile?

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 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.

What Is Agile?

Agile is everywhere. And, paradoxically, nowhere.

In the 20 years after the Agile freight train roared into software developers’ conscious, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much. “Agile,” the easily-repeated name, is enormously successful. The ideas behind Agile—well, most of them are ignored.

Let’s fix that.

Agile’s Genesis

In the 1990s, software development was believed to be in crisis. They actually called it that: “The Software Crisis.” Software projects were over-budget, late, didn’t meet requirements, and—according to the oft-quoted and ominously named “CHAOS Report”—nearly a third of them were cancelled outright [Standish 1994].

Agile wasn’t a response to this crisis. Far from it. Agile was a response to the response.

To bring software development under control, big organizations created highly detailed processes that defined exactly how software was to be created. Everything was tightly controlled so that no mistakes could be made. (In theory, anyway.)

First, business analysts would interview stakeholders and document the system requirements. Next, software architects would read the requirements documents and create detailed design documents specifying every component of the system and how they related to each other. Then programmers would convert the design documents to code. In some organizations, this was considered low-skill work—just a mechanical translation exercise.1 Meanwhile, test leads would use the same documents to generate test plans, and when coding was done, armies of QA personnel would manually follow those test plans and report variances as defects. After each phase, everything would be carefully documented, reviewed, and signed off.

1In fact, programming was considered such a mechanical activity that, for a while, there was a movement called CASE—Computer Aided Software Engineering—to automatically convert architectural diagrams into code.

This approach was called “waterfall development” or “phase-gate development.” If it sounds like a ridiculous straw-man, well, consider yourself fortunate. Not every company used a heavyweight process in the ’90s, but it was widely recognized as a logical and sensible way to work. Of course you needed to define requirements, then design, then implement, then test. Of course you needed to document every phase. This was discipline. This was engineering. How else could you possibly succeed?

Born Out of Crisis

Big companies defined their processes in excruciating detail. Roles, responsibilities, document templates, change control boards... every aspect of development was defined and controlled. If a project didn’t succeed—and according to the CHAOS Report, less than a sixth of them did—it was because the process needed more detail, more documents, more sign-offs. It resulted in a massive amount of documentation. Martin Fowler called it “The Almighty Thud.” [Fowler 1997]

This wasn’t a great way to work. It was bureaucratic and dehumanizing. Skill didn’t seem to matter as much as adherence to process. Programmers felt they were interchangeable cogs in an impersonal machine. It didn’t even work all that well.

So several people independently developed simpler, slimmer, and less prescriptive methods for developing software. They were called “lightweight methods” in contrast to the heavyweight methods used by big companies. These new methods had names like “Adaptive Software Development,” “Crystal,” “Feature-Driven Development,” “Dynamic Systems Development Method,” “Extreme Programming,” and “Scrum.”

By the late ’90s, these methods were attracting serious attention. Extreme Programming, in particular, saw an explosion of grass-roots interest among programmers. In 2001, 17 of the lightweight methodology proponents met at a ski resort in Utah to discuss unifying their efforts.

The Agile Manifesto

“I personally didn’t expect this particular group of [people] to ever agree on anything substantive,” Alistair Cockburn said later.

And, in fact, after two days, they only accomplished two things: the name “Agile,” and a statement of four values (see the “Agile Values” figure). Over the following months, over email, they hashed out twelve accompanying principles (see the “Agile Principles” figure).

This was the Agile Manifesto. It changed the world. So, as Alistair went on to say, they did agree on something substantive after all.2

2Alistair Cockburn, quoted by Jim Highsmith in [Highsmith 2001]. The full quote is, “I personally didn’t expect that this particular group of agilites to ever agree on anything substantive... Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive.”

Agile Values

Figure 1. Agile Values

Agile Principles

Figure 2. Agile Principles

But there was no unified Agile method. There never has been, and never will be. Agile is three things: the name, the values, and the principles. That’s it. It’s not something you can do. It’s a philosophy. A way of thinking about software development. You can’t “use” Agile or “do” Agile... you can only be Agile. Or not. If your teams embody the Agile philosophy, then they’re Agile. If they don’t, they’re not.

The Essence of Agile

Martin Fowler has made a career out of turning complicated software topics into well-considered, even-handed explanations. His explanation of “The Essence of Agile Software Development” is one of the best:

Agile Development is adaptive rather than predictive; people-oriented rather than process-oriented.3

3Fowler has expressed this idea in many ways over the years. It originated in [Fowler 2000]. As of October 2020, his most up-to-date overview could be found at

Martin Fowler

Adaptive rather than predictive

Remember the CHAOS Report, which said that only one-sixth of software projects were successful? It had a very specific definition of success:

Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as originally specified.

Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.

Resolution Type 3, or project impaired: The project is canceled at some point during the development cycle.

These definitions illustrate the predictive mindset perfectly. They’re all about conformance to plan. If you did what you said you were going to do, you were successful. If you didn’t, you weren’t! Easy.

It makes sense at first. But look closer. There’s something missing. As Ryan Nelson wrote in CIO Magazine [Nelson 2006]:

Projects that were found to meet all of the traditional criteria for success—time, budget, and specifications—may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business.

... Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value. For example, at a financial services company, a new system... was six months late and cost more than twice the original estimate (final cost was $5.7 million). But the project ultimately created a more adaptive organization (after 13 months) and was judged to be a great success—the company had a $33 million reduction in write-off accounts, and the reduced time-to-value and increased capacity resulted in a 50 percent increase in the number of concurrent collection strategy tests in production.

Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams actively look for opportunities to increase value by changing their plans.

Take a second look at the Manifesto (see the “Agile Values” figure and the “Agile Principles” figure). “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” How many of its values and principles relate to delivering valuable software and adapting to feedback?

People-oriented rather than process-oriented

Heavyweight processes tried to prevent errors by carefully defining every aspect of software development. By putting the “smarts” in the process, individual skill became less important. In theory, you could apply the same process over and over, with different people, and get the same results. (Come to think of it, they kind of did. Just not the results they wanted.)

Agile says people are the most important factor in software development success. Not just their skills, but all aspects of their humanity. How well team members work together. How many distractions they encounter. How safe they feel. Whether they’re comfortable voicing dissent, and whether they feel motivated by their work.

Agile teams have a process—every team does, even if it’s implicit—but the process is in service of the humans, not the other way around. And Agile teams are in charge of their own process. When they think of a better way of working, they change it.

Look at the Manifesto again (see the “Agile Values” figure and the “Agile Principles” figure). “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Which other values and principles relate to putting people first?

Why Agile Won

In the first ten years after the Manifesto, Agile faced enormous criticism. It was “undisciplined,” critics said. “It could never work.” Another ten years after that, the critics were silent. Agile was everywhere, at least in name. Heavyweight waterfall methods were effectively dead. Some younger programmers had trouble believing anybody ever could have worked that way.

There’s actually nothing inherently wrong with the basic waterfall process. If you keep it slim and operate in a well-understood domain, waterfall can work well. The problem was the heavyweight processes big companies used. Ironically, the processes designed to prevent problems actually caused many of the problems organizations were seeing.

With software, it’s very difficult to imagine how it will work before you actually use it, and it’s even harder to think of absolutely everything your software needs to do. This is doubly true for people who aren’t actively involved with software development. As a result, it’s critically important to get working software in front of people as soon as possible. You need to get feedback about what’s missing or wrong, then change your plans based on what you learn. As the Manifesto says, “working software is the primary measure of progress.” Learning and responding to change are at the heart of what Agile is all about.

Those heavyweight processes put so much emphasis on process controls and documentation and sign-offs that they incurred a huge amount of delay and overhead. They took years to produce working software, and they had nothing concrete to show until near the end. Instead of welcoming change, they actively worked to prevent change. They actually had a dedicated part of the process, the Change Control Board, whose primary purpose was to say “no” to change requests. (Or, more accurately, “yes, but it will cost you.”)

All of this added up to projects that spent years in development before they had anything to show. When they did, it was too late and too expensive to make changes. They ultimately shipped software that didn’t do what customers needed.

Although there are a variety of approaches to Agile—and some of them are more about co-opting a popular name than following the actual philosophy—one thing they all have in common is a focus on making progress visible and allowing stakeholders to make course corrections as they go. This seems like a small thing, but it’s incredibly powerful. It’s why we no longer hear about a Software Crisis. Software is still late. It’s still over budget. But Agile teams don’t spend years building failures. And that’s huge.

There’s more to Agile than just providing visibility. But this one thing? This was enough. It’s why everybody wanted Agile.

Why Agile Lost

At first, Agile was a grassroots movement. It was largely driven by programmers seeking better results and better quality of life. As it became more successful, Agile’s momentum shifted from the underlying ideas to hype. Rather than saying, “let’s get better results by adapting our plans and putting people first,” organization leaders started saying, “Everybody’s talking about Agile. Get me some Agile.”

The thing is, there is no “Agile” to go get. It’s just a set of values and principles. There are specific Agile approaches, such as Extreme Programming and Scrum, that will tell you how to be Agile, but you still have to be on board with the underlying philosophy.

And for a lot of organizations, that underlying philosophy—adapting plans and putting people first—is really, really foreign.

The tragedy of the cargo cult is its adherence to the superficial, outward signs of some idea combined with ignorance of how that idea actually works. In the story, the islanders replicated all the elements of cargo drops—the airstrip, the tower, the headphones—but didn’t understand the vast infrastructure that enabled airplanes to arrive.

The same tragedy occurs with Agile. People want Agile’s Cargo: better results, more visibility, fewer business failures. But they don’t understand the underlying philosophy, and often wouldn’t agree with it even if they did. They want to buy Agile, but you can’t buy an idea.

What they can buy is the outward signs of Agile. Stand-up meetings! User stories! Tools! Certifications! There’s lots of stuff labelled Agile, and plenty of people eager to sell it to you. It’s often sold as “enterprise-grade,” which is a way of saying “don’t worry, you won’t have to change.” Uncomfortable ideas like “adaptive planning” and “people-centric” are ignored.

And that’s how you get a cargo cult. All the activity; none of the results. The Agile part is missing.

“At my old company they wasted a huge number of man hours in meetings.”

“[Agile] cost an entire team (30+) people their jobs as they produced almost nothing for almost a year.”

“All [Agile] means is developers get shafted when the project changes... the day before delivery.”

“It‘s because of Agile there are sh—ty developers and sh—ty products being shipped.”

“I can’t take this Agile crap any more. It’s lunacy.”

comments about Agile from around the Web

The name Agile is everywhere. The ideas of Agile aren’t. It’s become self-perpetuating: for many, the only Agile they know is Cargo Cult Agile.

Icon of person in a suit wearing coconut headphones

Cargo Cult Agile

It’s time to fix that. In the rest of this book, I’ll show you how to apply Agile ideas for real. Keep an eye out for the Cargo Cult Agilists shown in the margin. They’ll show you what not to do.

Ready? Let’s go.

What Next?

If you’re trying to help your organization become more Agile, continue with the next chapter. If you’re on an Agile team and want to understand how Agile works in practice, skip ahead to Part II.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

Art of Agile Development, Second Edition: Open Review!

The open review for The Art of Agile Development, Second Edition has begun! As we finish sections of the book, I’ll publish them on the Second Edition home page.

We want your feedback! Join the AoAD2 open review mailing list to be informed when new sections are released and to share your thoughts.

Sign up here.