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, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.


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.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.