Or “Why should we set up working agreements for my (Agile-, Program-, Leadership-, etc.) Team?”

Agile approaches often talk about “working agreements” for Teams especially, but for any group of folks getting together. In case you think this type of discussion sounds a bit “touchy / feely” there are a number of benefits to discussing and establishing working agreements early in the Team’s life:

• You will have them implicitly. For example, by observing some organizations I can see that they have a working agreement that “it is OK to start a meeting 5-10 minutes after the scheduled time.”. Most of the time this is not stated, but never-the-less that is what people accept.
• It is better to control the process of creating working agreements so that we produce the results we desire – “ready, aim, fire” rather than “ready, fire, aim”.
• By being proactive we can set ourselves up to deal with team issues in a calm way, before we find ourselves in a situation where we cannot, for example, control our emotions.
• The process of creating working agreements helps develop Team cohesiveness and so helps with creating a high-performance Team.
• By having the discussion on working agreements, it helps the Team understand that this is a subject that we can and should talk about.

Our aim is to create high-performing Teams (or groups). Working agreements are a positive productive process that help establish a “one-Team” mindset needed for high-performance. "The Five Dysfunctions of a Team" by Patrick Lencioni tells us that we want a Team where Team members:

1. Trust one another.
2. Engage in unfiltered conflict around ideas.
3. Commit to decisions and plans of actions.
4. Hold one another accountable for delivering against those plans.
5. Focus on the achievement of collective results.

Building trust is the hard part. To create an environment where trust is possible you need to have transparency between Team members and have the Team members make and meet commitments to each other. A step in the right direction is to establish some working agreements.

What kind of things should be covered in your working agreements? Basically you are answering the “who”, “what” and “why” question as it relates to the Team:

• Why are we here, what do we want to achieve together, what is our core, our strongest beliefs and our purpose? Why do we exist as a team? What core value do we all share?
• How can we make this happen? What principles (benefits, qualities) support this?
• What exactly will we do (and what will we not tolerate) to support each of the key principles we’ve agreed upon that contribute to our purpose? What are desired behaviors for the team? What are our team norms?

The best time to start the discussion of working agreements is early in a Team's life. This is not to say it cannot be done at any time, but if you get into the habit early adjustments can be more easily done as you learn how to become more effective. For Agile teams, an obvious place to inspect and update is during a Retrospective but the reality is that any time it makes sense to discuss this, that is the right time.

Deb Korbe sent me an (excellent) template she has used in the past to help teams come up with the working arrangement. This is really just to give you a flavor of some of the things you might want to talk about. You’ll notice there are placeholders for some items, and items are greyed out. There is nothing in this template that is fixed – its just there to help guide the discussion.

In addition to the agreements about time / place etc. a good starting point for discussion is to have the team brainstorm (by themselves) things:

• That “bother them” or they “expect will bother them” and for which they’d like to establish an agreement, and then facilitate a discussion.
• Working agreements or values that they have thought worked well when they were on other high performance Teams (sports teams, work teams, etc.).
• A discussion about what the Team will value. A good starting point for this discussion is the Values and Principles from the various flavors of agile (Scrum, XP, Kanban, SAFe, DevOps, etc).

Sometimes the mere act of talking about a potential agreement is enough, and no documentation or enforcement is required. One Team I work with had a problem early in their life in that Team members would feel they had the right to interrupt other Team members any time they had an issue. This meant that Team members that were “deep in thought” were disrupted and had a problem restarting again. The discussion came up at a Retrospective and it was agreed that a flag system would be put in place to signal whether the person was open for discussion (green - no problem, yellow - if important, red - don't). Flags were bought and placed in work areas. And then they were never used. The reality was that because the discussion was had, people were aware of the issue and were much more careful about observing whether a person was open for interruption.

This idea leads to another concept; working agreements can be “deleted” if you are documenting them. If everyone knows the behavior and it just happens (in other words, its become part of the team culture and is a habit) then there is no need to keep that agreement around. Perhaps a new agreement should be put in place to help the team become more effective. Or perhaps not.

One thing that many ask is “who is responsible for making sure agreements are met.” The answer is “the people that made the agreement.” On a Team it is up to the individual Team members to hold each other accountable for behaviors the Team has agreed to. So while agreements can be a tool to allow a Scrum Master, for example, resolve issues, but the main idea is that Team uses it to hold each other accountable for behavior.

The idea of working agreements can be applied to any meeting, any group of people, with the aim of improving the effectiveness of the group. As said before, you will have agreements whether you are explicit about them or not, so you might as well leverage the idea to become more effective.

And finally from What Google Learned From Its Quest To Build The Perfect Team we learn that we want to encourage a couple of team behaviors to have a good team:

1. Members spoke in roughly the same proportion, a phenomenon the researchers referred to as “equality in distribution of conversational turn-taking.”
2. Members high “average social sensitivity”, a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues (a trait that can be developed)

By understanding these characteristics, perhaps you (the Team) can mould the working agreements to increase the chance of these behaviors.

Many people think that “We don't need to do this. After all, aren't we all adults? Aren't we all professionals?” The reality is that in the normal course of events these things will seem self evident and so of course we adult and professional. But this is not about the normal course of events. Working agreements are a tool for the team to work issues when people are not working well with others, for whatever reason. They are particularly useful when there is a lot of emotion around an issue and when working an issue starts to degenerate into a discussion about the people involved and their motivations, rather than the issue itself. Working agreement are an acknowledgement that we are all human and so do not always respond in a rational, professional and adult way to situations.

A foundation piece to this is talk about our team purpose, our values (statements of what is important), and establish some working agreements and rules.

Some examples of values:

• SAFe values: alignment, built-in quality, transparency, program execution
• Scrum values: focus, courage, openness, commitment, respect
• XP values: simplicity, communication, feedback, respect, courage

Some examples of working agreements are:

• Show respect
• Don’t interrupt or let someone finish what they have to say before you start
• When working in co-located space, if you do not want to be disturbed, put this red flag on the monitor
• It’s OK to disagree with each-other. Debate the merit of idea. Don’t attack the person presenting the ideas
• There is no such thing as a bad idea, bad question, etc.
• Everyone has an equal voice
• Everyone is expected to make an equal contribution
• For meetings, be on time and end on time.
• If we exceed the time-box ask ourselves whether additional time is required before continuing
• Meetings should have an agenda
• Our core working hours are from 9-11 and 1-4 and we will schedule team meetings during core hours
• Be transparent – no hidden agendas
• We will give / receive (and act on) feedback
• We make commitments as a team
• We will aggressively work on blockers as a Team
• We've work our Stories to our Definition of Ready (DoR)? before accepting them into an Iteration
• If the blocker cannot be address by the team, then the scrum master will drive it to resolution
• When we estimate, we will go three rounds of planning poker, and then if unable to make progress we will pick high estimate

Some examples of working agreements when the Team is distributed:

• Turn video on if possible
• Remain focused on this meeting
• Team members should review the Team Slack (where key decisions are a made) as they start work in their timezone

And additional information:

• Agile Development Team Charter - expands the idea of working agreement to a more formal charter. Also has some interesting examples and ideas of what could be in a set of agreements.
• "The Five Dysfunctions of a Team" - Patrick Lencioni