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.

Alignment

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

Interdependency is the hallmark of a team.

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

Allies
Purpose
Context

Your chartering session is a good time to discuss alignment. (See “Planning Your Chartering Session” on p.XX.) 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.

If you haven’t created a skills inventory yet, you can do so when people answer the first question in this activity.

This activity requires a bit of advance preparation. First, post the team’s purpose and skills inventory in a prominent location. 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? 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 whiteboard with three columns. Label the first two “Same” and “Different.” Then ask the group to use simultaneous brainstorming (see “Work Simultaneously” on p.XX) 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 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.

Diversity of experience leads to diversity of ideas.

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 chapter “How to Be Agile”.)

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

  • How you’ll make decisions (see “Work Simultaneously” on p.XX, “Seek Consent” on p.XX, and “Agree to Experiment” on p.XX)

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

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

  • The core hours when you can expect people to be available (see “Team Room Prequisites” on p.XX).

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

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

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

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

Allies
Team Room

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

Define standards

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

Standards tend to be a source of conflict if they’re not addressed, so it’s good to create them. What’s not as important is their actual content. Over time, you’ll amend and improve them.

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

2Quoted at https://en.wikiquote.org/wiki/Ward_Cunningham

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.

Allies
Done Done

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

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

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

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

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

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

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

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

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

  4. Limit entire discussion to 45 minutes.

No matter which standards your group chooses, some are likely to feel jarring or grating at first. Over time, 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 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.

Allies
Team Room
Retrospectives

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 team agreements (the first list, not the standards) is for habits 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

Assume your colleagues are professional and well-meaning.

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.

Allies
Pair Programming
Mob Programming
Collective Code Ownership

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

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

I’m reminded of a time when my team added an automated style checking tool. It blew out our build times and kept throwing false positives. We spent more time on the tool that it ever saved.

Technical tools can’t solve interpersonal problems.

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

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

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

If 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 doesn’t check for nulls.”

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 needs more help, coordinate with the rest of the team to make sure they get plenty of mentoring from more experienced team members.

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

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

Questions

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, it’s fine to do so. Be sure to coordinate automated changes with other team members so their work isn’t disrupted, and separate the automated changes from normal changes so your version control history is easy to read.

Prerequisites

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

Indicators

When your team has effective working agreements:

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

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

  • Your 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 disruptive arguments in the future. The exact format of that discussion isn’t important. The format in this book was chosen because it’s relatively quick and non-confrontational, but you could use another approach.

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

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