Scrum by Example – Team Friction Inspires Working Agreements

Working Agreements are a simple, powerful way of creating explicit guidelines for what kind of work culture you want for your Team. They are a reminder for everyone about how they can commit to respectful behaviour and communication. In this post we’ll help you understand why these agreements are useful, and how you can help your Team create their own.

Dramatis Personae

• Steve – a ScrumMaster and the hero of our story
• Paula – the Product Owner of Steve’s Team
• Kirby – one of the Team’s software developers
• Tonia – the Team’s Quality Assurance specialist
• Doug – another of the Team’s software developers
• Ian – the Team’s Business Logic programming specialist

In the past few Sprints, there have been moments of social friction noticed by both Steve and the rest of the Team. They included:

• Kirby was blunt when discussing a defect with both Tonia and Ian.
• Some discussions with the whole Team became so heated that the quieter team members stopped speaking up for several days.
• Doug was late for Daily Scrum on several days.
• On multiple occasions, Team members needed to ask Paula some questions, but she wasn’t available by email, and they often didn’t know how to find her.

None of these individual issues was truly bad, however, taken together and left unchecked, they harm the Team’s cohesion. When that happens, people opt to stay silent when there is an opportunity to share an opinion, and events like Daily Scrum becomes less useful when Team members signal their disrespect by frequently being late.

During the next Retrospective, Steve mentions a few of these issues and says that he wants to talk about making their environment better. Tonia shares that she knows another one of their peer teams has created their own Working Agreement to reduce some of the friction and improve respect.

What is a Working Agreement?

A Working Agreement is a short set of guidelines created by the Team, for the Team, that establishes what the expectations of the Team are for one another. A well-written Agreement should help establish, as well as reinforce, a clear, shared understanding between all Team members about what they acknowledge is good behaviour and communication. It is usually referred to as a single “Working Agreement”, but in reality, it’s comprised of many individual agreements for each topic or issue.

Characteristics of an Effective Working Agreement

• Public and Visible – preferably written in a large font and posted in a prominent space
• Collaborative – created by all, not imposed by others
• Short – a small list of agreements that are easily remembered and lived up to trumps a big list that overwhelms people and gets forgotten
• Updated Frequently – Taiichi Ohno once said: “If the kanbans do not change for one month, you are salary thieves”
• Consequential – when the agreements are violated, Team members call out the violation

What Goes Into a Working Agreement

Your Team will create its own Working Agreement based on the context of its work. Elements of an Agreement might include:

• Core hours – times during the day that all Team members agree to be present and available for collaboration.
• Daily Standup – the time that it happens and what to do if you realize that you can’t make it that day.
• Cell phones – if or when it is appropriate to use them during Team events.
• Headphones – when it is fine to use headphones, versus when Team members will not use them so they’re available to communicate and collaborate with others.
• Product Owner – availability and contact information.
• Definition of ‘Done’.
• How the Team limits Work In Progress (i.e. the Kanban Concept).
• How the Team ensures everyone has an equal voice and feels respected.
• Decision-making policies.
• If you miss a meeting or event then you agree to support decisions made in your absence.
• If you can’t attend a Team event you will let the Team know in advance.
• During each Sprint, at least one Team Member will work on growing a skill outside of their core strengths.
• In the case of software development, every Sprint the Team will make an effort to improve some part of their codebase.

As part of coming up with this list, it is worth considering the Scrum Values as a source of guidance:

Focus: Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.

Courage: Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.

Openness: As we work together, we practice expressing how we’re doing, and what’s in our way. We learn that it is good to express concerns so that they can be addressed.

Commitment: Because we have great control over our own destiny, we become more committed to success.

Respect: As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Teams normally create a Working Agreement before their first Sprint by setting aside an hour or two beforehand. In the case of our World’s Smallest Online Bookstore (WSOB) Team, they haven’t yet. No time like the present!

How To Build a Working Agreement – How Can a ScrumMaster Help?

Sensing the atmosphere of the Team, Steve starts by helping them learn about Working Agreements. He first ensures that the Team understands what Working Agreements are, and how they will personally benefit from having them.

Mark’s note: Spending some time on a good setup will reduce cynicism among Team members. Giving people some categories or areas in which Working Agreements will help, gives them a framework. For instance, in our workshops, categories are cell phones, laptops, break times, and punctuality. In the context of a Team, you might use some of the areas mentioned above, and perhaps draw on the Scrum Values, but ultimately the Team chooses what works best for them.

Steve then facilitates a Retrospective to help the Team and Product Owner come together to sort out some of their problems. During the process, they discuss the friction they have felt over the previous few Sprints. They agree to create a Working Agreement and, since it will likely take over an hour, they elect to make it an action item for the next Sprint Retrospective.

There isn’t an official or correct way to create Working Agreements, so Steve uses the approach that I share in my workshops. As usual for a ScrumMaster, good preparation pays dividends. Consider canvassing the Team beforehand about categories/areas for agreement.

After talking to Team members, Steve selects “Daily Scrum Start Time,” “Respect,” “Phone usage in Team Events,” and “How to give everyone equal voice for discussion.” He explains that if there are other categories that they would like to consider including in the Working Agreement, they’re welcome to add them as they go.

Given the previous friction between some Team members, he opts for a 1-2-4 model^[3] for discussing possible agreements. This model is designed to ensure that everyone has a voice in the process:

• Each Team member (1) takes a few minutes to share to the whole group their ideas for potential agreements in each category.
• They then work in pairs (2) to record the best ideas from each person. As facilitator, Steve is paying attention to the conversations and outcomes. It should be a red flag if one person is dominating their partner during this step.
• Next, they move to groups of four (4) to further consolidate their ideas and present them to the group for discussion. In the case of Steve’s Team, there are only six people, so they skip this step and move straight to final group consensus.

Steve starts asking for proposed agreements in their first area of focus: Daily Scrum Start Time. After each potential working agreement, he uses the Decider Protocol^[2] to check for consensus rapidly. When there isn’t immediate consensus, the person who said ‘no’ to an idea suggests what they think is a better one. If multiple people have an issue, then each is expected to offer a better idea. If too many people say no, then the proposer should consider withdrawing the proposal. In the case of Steve’s Team, after 20 minutes, the team have their first set of Working Agreements:

– Respect – when another Team member is talking, don’t interrupt. When they’ve finished, pause, reflect, and share back your understanding of their idea.^[4]

– Make sure everyone has a voice – more vocal Team members volunteer to speak last to give quieter Team members an opportunity to speak up.

– Daily Scrum is 9:20 am, allowing all Team members to get their kids to school before coming in to work.

– Cellphones in Team Events – they stay outside the room.

– To improve the quality of all ideas, we encourage respectful dissent. At least one Team member volunteers to be the dissenter. Even if they think the original idea is good, they’re expected to find criticisms of the idea with the goal of making it stronger.^[5]

– Focus – during the Sprint, the Team is focused on the Sprint Goal. If something comes up that doesn’t fit the goal, Team Members are expected to say no.

Notice that the last two items weren’t among those previously suggested by Steve, instead, they appeared organically.

Steve then offers a suggestion of his own: “If you miss a meeting/event it is expected that you will support the decisions made there.” Kirby, who has previous experience facilitating, reminded Steve that if he truly is playing the role of facilitator as part of his ScrumMaster duties, then he is expected to remain neutral and not inject his own ideas.

The Team compiles all the individual agreements in the Working Agreement and posts it on the Team room wall. In the months afterwards, Team members slowly get used to the idea of reminding their peers of behaviours that don’t honour the Agreement. Every few Sprints, Steve asks in a Retrospective “Is this still our Working Agreement? Is there anything you would like to change?” The list evolves as Team members find more areas where they see benefits. After six months, they find themselves much better able to deal with tense problems within the Team, or when the outside pressure increases on them.

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.