Coaches, Whole Team
We agree on how we work together.
What is a “team?” It’s not just a bunch of people who sit in the same room. It’s not even a group that’s been assigned to work on the same thing.
A team is a group of people who depend on one another to accomplish a shared goal. That interdependency is the hallmark of a team. It’s what makes teams so successful…and also what makes them so difficult.
You probably remember working on group assignments in school. They tend to be tolerated at best. We’ve all heard the horror stories about one person who ended up doing all the work while the others mooched off their grade.
But we’ve also heard stories of amazing teams. Maybe you’ve had that experience, too: being part of a great sports team, a band, or a volunteer group. When teams work, they’re electrifying.
What’s the difference between bad teams and good teams? Alignment. Team members in an aligned team not only depend on one another to accomplish a shared goal, they’re in agreement about how they’re going to work together.
Your chartering session is a good time to discuss alignment. (See “PLANNING YOUR CHARTERING SESSION”.) 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.14
Start your alignment discussion by getting to know one another better. “A CONNECTION-BUILDING EXERCISE” can be a good way to break the ice. Then hold a group discussion of the following questions:
Who am I? Say a bit about your background, then share some of your positive personal qualities, such as “detail-oriented,” “patient,” or “friendly.”
What’s something people learn about me once they’ve gotten to know me? Possibilities include a hobby, favored vacation destination, or beloved pet.
Why do I believe this group is well-suited to achieving the team’s purpose?
What’s the most important thing that others need to know about working with me effectively?
What’s in it for me? What do I want to get out of being part of this team and accomplishing our purpose?
Go around the room, one question at a time, and ask each person to answer. People can skip their turn if they need time to think, but come back to them before moving on to the next question.
Having this discussion will help team members start to see one another as whole people, rather than just names, faces, and titles. If you have a remote team, make an extra effort to have this conversation with video on.
Working agreements guide your team’s behavior by describing what you expect from one another. Over time, the agreements will change. As the team matures, some of the working agreements will become second nature and can be taken off the list. Others will be added to take advantage of new ideas.
To create your team’s working agreements, start by sharing stories of other teams you’ve worked with. Describe how they worked together, either good or bad. You can do this in round-robin order, or just randomly, according to who wants to talk next.
Thinking back on your experiences as part of a team (any kind of team, including a sports team, church group, band, or choir), when were you most effective as a team member? Tell us a short story about that time. What workplace conditions fostered effective teamwork?
Reflect on the times and situations in your life when you have collaborated on a team. What do you notice about yourself, or your contribution, that you value? What do you value most about those teams?
What do you consider to be the core factor that creates, nurtures, and sustains effective teams in organizations? What is the core factor that creates, nurtures, and sustains effective teamwork? Is there any difference?
What three wishes would you make to cause your experience on this team to be most worthwhile?
As people share their experiences, pause to make a note of potential working agreements. They can be anything: behavioral standards, such as, “We don’t interrupt when people are talking;” specific practices, such as, “We use pair programming for all production code;” work habits, such as, “When we change tasks, we drop a note in the group chat;” and more. Include anything that will help your team work together better. Don’t critique the suggestions yet; just collect them.
After you share your stories, check whether you’ve covered the following categories. If you haven’t, suggest working agreements for them, too. You won’t have to choose them, but make sure they’re considered.
The practices your team will use. I recommend starting with every practice in your team’s chosen zones.
For remote teams, how you’ll communicate. (See “Designing remote collaboration”.)
How you’ll make decisions.
For in-person teams, how you’ll deal with distracting background noise.
For teams that don’t use pairing or mobbing, how you’ll ask for help without being disruptive. (See “Always ask, always help”.)
The core hours when you can expect people to be available.
After generating ideas, narrow down the list by using dot voting (see “Work simultaneously”) 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”). If you’re unable to get consent for a particular working agreement, just drop it from the list for now. You’ll be able to revisit it later.
Finish off by rephrasing the working agreements and transferring them to a cleaned-up list. Each working agreement should finish the sentence, “We work together best when…” Describe what to do instead of what not to do. In other words, rather than saying, “We don’t interrupt one another,” say, “We let people finish their thought before adding our own.”
Post the final list of agreements prominently in your team room. You can start using them immediately.
Standards are special working agreements that apply to specific types of tasks. Coding standards, UI design guidelines, and operational standards are all examples.
Standards tend to be a source of conflict if they’re not addressed, so it’s good to define them. What’s not as important is their actual content. You’ll amend and improve them over time. Remember, few decisions are irrevocable in Agile. Ward Cunningham put it well:
It was a turning point in my programming career when I realized that I didn’t have to win every argument. I’d be talking about code with someone, and I’d say, “I think the best way to do it is A.” And they’d say, “I think the best way to do it is B.” I’d say, “Well no, it’s really A.” And they’d say, “Well, we want to do B.” It was a turning point when I could say, ”Fine. Do B. It’s not going to hurt us that much if I’m wrong. It’s not going to hurt us that much if I’m right and you do B, because we can correct mistakes. So [let’s] find out if it’s a mistake.”
To that end, use these two guidelines to define your standards:
Create the minimal set of standards you can live with.
Focus on consistency and consensus over perfection.
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”), 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:
Start by consenting to a baseline standard. (Limit to five minutes.)
Brainstorm additions or changes. Group them into categories. Dot vote.
For each category, consent to a specific standard. (Limit to five minutes.)
Limit entire discussion to 45 minutes.
No matter which standards your group chooses, some are likely to feel jarring or grating at first. Over time, you’ll become more comfortable with them. In many ways, standards are an aesthetic choice. One of the marks of a professional is the willingness to put aside personal aesthetics for a team aesthetic.
Your list of working agreements, not including your standards, is for habits you’re actively working on establishing. It’s best to limit this list to about five agreements. When an agreement becomes second nature, take it off the list and make room for a new agreement.
Standards tend to need some time to bake. Schedule a meeting to discuss your standards a few days after you start working together, and another one a few weeks after that. An hour should be enough. This will allow you to put your standards into practice. If there’s disagreement about a standard after that time, agree to experiment with one approach, then the other, then revisit the question.
You can change your working agreements and standards at any time. Just announce your intention to the team, get consent, then change the flip chart or virtual equivalent. Retrospectives are another good time to discuss changes to working agreements.
People make mistakes. Assume your colleagues are professional and well-meaning. If someone isn’t following an agreement, assume there’s a good reason, despite evidence to the contrary. Your challenge is to find that reason and address it. This approach shows respect for others and will improve their respect for you.
Pairing, mobbing, and collective code ownership all help team members catch mistakes and maintain self-discipline. They also provide a way to discuss questions not addressed by your team’s agreements. They’re also an excellent way to improve your standards; it’s much easier to suggest an improvement after you’ve talked it over with someone first.
Automated enforcement of standards tends to be less effective. Some people use automated tools to check their source code for adherance to coding standards, or automatically reformat code upon check-in. Although this can work when the team is in agreement, teams commonly fall into an over-enforcement trap.
Even worse, people often use tools as a bludgeon to enforce their opinion. Although it’s tempting to come up with a technical solution to interpersonal problems, it won’t work. You have to solve the interpersonal issue first. Tools have no nuance. At best, they’ll paper over the disagreement. They won’t solve it; they’ll just shove it out of sight to fester and grow.
Instead, it’s best to start by assuming good faith. Perhaps the other person misunderstood the agreement, or feels it no longer applies, or something in their life is making it difficult for them to comply.
If someone consistently violates the team’s agreements, talk with them alone to see if there’s a disagreement. Take an attitude of collaborative problem solving. Instead of saying, “Why aren’t you handling nulls like we agreed?” ask, “What do you think about the null-handling standard we agreed on? Should we change it?” Give objections full consideration, raise them with the rest of the team, and consider changing the agreement.
If someone is on board with the agreement, but still not following it, it’s possible that the agreement isn’t appropriate in every situation. Ask about specific cases you’ve noticed. Again, be collaborative, not confrontational. Say something like, “I agree with you about how we should handle nulls. In that case, can you explain what’s happening in this function? I don’t understand why this code doesn’t check for nulls.”
During this discussion, you may learn that they don’t understand the agreement. By this time, you should be in a good situation to discuss the agreement and what it means. If they’re a junior team member who needs more help, coordinate with the rest of the team to make sure they get plenty of mentoring from more experienced team members.
There’s another possibility for teams new to Agile. Changing work habits is disruptive and can make people feel like they’ve lost control. Sometimes they react by picking small things that they refuse to change. An obstinate desire to stick with a particular standard or communication style, regardless of the wishes of the rest of the team, might be a symptom of this reaction.
In this case, your best solution may be to let the infractions slide for several months. Over time, as team members become more comfortable with the changes in their environment, they’ll relax and be more willing to compromise.
What if we can’t agree on standards or other working agreements?
It’s possible to pressure people into accepting agreements that they don’t agree with, but it’s not a good idea. The disagreement will just keep coming up in other conversations.
Instead, try to let it go. Is the working agreement really so important? Focus on the things you do agree on. As work progresses, your differences will resolve.
If it’s not something you can safely ignore, your team needs the help of a professional mediator. Talk to your coach or manager about finding someone who can help. Your HR department may have someone on staff. In the worst case, it may turn out that your group isn’t suited to be a team, and you’re better off teaming up with different people.
We have pre-existing work that doesn’t fit our standards. Should we fix it?
It’s expensive and risky to spend a lot of time fixing things that aren’t broken, so if your previous work, well, works, go ahead and leave it alone. Bring each piece up to standard when you need to change it.
Some standards, such as code formatting, can be automated. Don’t spend too much time on this, but if you can do it easily, it’s fine to do so. Be sure to coordinate automated changes with other team members so their work isn’t disrupted, and separate the automated changes from normal changes so your version control history is easy to read.
Team members have to be willing to work as a team before they can create effective working agreements. See Chapter 5 for more about team buy-in.
When your team has effective working agreements:
Your team uses your agreements to prevent and resolve conflicts.
Your standards improve the readability and maintainability of your code and other artifacts.
Your standards allow team members to more easily understand unfamiliar parts of the system.
Some teams work together so well that they don’t need explicit agreements. Their agreements are implicit.
For new teams, though, and even most existing teams, taking the time to explicitly discuss your agreements will help prevent disruptive arguments in the future. The exact format of that discussion isn’t important. The format in this book was chosen because it’s relatively quick and nonconfrontational, but you could use another approach.
Stick with the approach in this book until you’ve had experience with several successful alignment discussions. Alignment can be contentious, particularly when teams get down to concrete agreements such as standards, and that’s why this book emphasizes setting aside divisive agreements.
Once you’ve had that experience, experiment with changes. Would small group discussions or interviews help? Is there any preparation that people could do in advance? Would different exercises be faster or more effective? There’s no limit to what you can try.
14 This agenda is based on [Larsen2016] (ch. 6), with some changes.