Conflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict. You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement. The following workshop is the one I use with my teams and organizations.
Set up the workshop
Set up a room for a flip chart rotation. For each role you have in your team (or organization) create one flip chart. The top part is reserved for notes that everybody agrees to, the bottom left quadrant is for notes that should apply to everybody, and the bottom right quadrant for notes that need to be discussed. Finally create one chart titled “All” this is the chart for notes that apply to everybody. This one is split in half, where the bottom is for notes that are to be discussed.
The workshop is split into the following parts:
- Gather data – Schedule about 4 minutes per chart, and an extra 5 minutes at the end.
- Break – 10 minutes
- Set Role Expectations – Schedule about 5 minutes per chart and 15 minutes at the end for each team to summarize.
- Break – 10 minutes
- Working agreements – 20 minutes
Gather data
Split the participants up into groups of around 3-6 depending on the size of the team/organization you’re doing this for. Try to mix the groups so that as many roles as possible are represented in each group.
Each group visits each flip chart in turn. They write notes that reflect the expectations they have on that role. If there are disagreements about an expectation, the note should be moved. Either the group will feel that this is an expectation that should apply to everybody, in which case it ends up in “All”, or they disagree with it, and it ends up in the “Discuss” area.
The flow of notes: Notes can go from the accepted role expectation to the “All” area or to the “Discuss” area. Notes can also go from the “All” area to the “discuss” area. However, no notes can go backwards to the accepted role expectation, or from “Discuss” into “All”. If there’s disagreement over where a note is placed, it should be moved to “Discuss”.
Once all the groups have been to each chart, they go back and quickly take a look at notes that were added to charts after they visited them. No new notes are generated in this step, but if the group disagrees with a note it should be moved to the “Discuss” area.
Schedule a break here. While people are on break, you can move all the notes in the “All” areas of the individual roles to the accepted expectation area for on the “All” chart for everybody. Since these stayed in their respective “All” areas it means that the whole team agrees that they should apply to everybody.
Set Role Expectations
After the break, discuss the notes in each “Discuss” area. Go through them one role at a time. Let the person/group who wrote the note explain why they think it applies, and let the person/group who moved it explain why. Facilitate the discussion so the team reaches an agreement on what to do with the note.
Once you’re done discussing all the charts, ask the people in their respective roles to work together to rephrase the notes for their role as a list of 5-10 expectations. The role expectations are now set.
Schedule another break here. The next step is setting up the working agreements.
Set Working Agreements
Ask the participants to group the notes on the “All” chart. Let them dot vote on which areas they think should be part of the working agreements. Include all areas that have more than one vote. Ask the participants to rephrase each area into a couple of short sentences. These formulations can optionally be grouped into the following categories: “who we are” and “how we work”. These are the team’s working agreements.
Outcome
A team that works well together! Disagreements about how to work are easier to address since they’re stated explicitly. Members do not have small lingering annoyances that slowly turn into conflicts, they’re naturally brought up during the work day by anyone as a reminder of how what we agreed to. If someone had a reason for not following the agreements this comes up as well, and the team ends up with a better understanding for each other. As a result of these discussions, the team grows and matures together. New members who join the team also benefit as they don’t need to “guess” what’s expected of them by observing the behavior of others. Finally, this is a great way to develop team culture, as the team grows and changes we run this workshop again, and make adjustments to our role expectations and working agreements, improving them with insights we’ve gained over time, and by taking in new members.
Get in touch via my homepage if you have questions or comments!
I have been looking for ideas for defining “working agreements.” Thank you for this helpful article.
One question. How does this focus on “roles” work with respect to teams of generalists as opposed to specialists and shared responsibility? I’m concerned it could lead to an emphasis on “my work” and “your work” instead of “our work.”
Hi Jeff, glad you found the article useful! We usually pick high level roles. For example in the exercises I’ve facilitated we specify only “developer”, not backend or front end, etc. We decided this as a team when we formed. And we discuss this again when we rerun this exercise as we add new team members and new roles.
Hi Yassal,
thanks for sharing this!
I have some questions for you:
* How do you identify which are the roles in the team? I mean, I could see that there’s a “product manager” role that others in the team would not actually see.
* Should we have a flip-chart even for roles that we have in our team but which are not represented actually because they are not currently available (e.g. the “product manager” is a role in the project but nobody representing this role can be present at this workshop) ?
* You said “If there are disagreements about an expectation, the note should be moved”: should be move where? In the “discuss” area?
* When you say “…ask the people in their respective roles to work together to rephrase the notes”, how do you know which person is in his/her respective role?
Thanks!!
Hi Pietro,
I hope these answers clarify your questions:
Definitely start out by identifying who is a team member and who is not. Is the product manager a team member, or a stakeholder for example? Make sure the rest of the team are on board with the definition. Somebody who is not generally around, or who the team does not see might not be a team member.
I would try to make sure that all the team members are present for this exercise, especially when one of them is the only one who holds a given role. I really wanted to make sure that everybody’s input was taken into account, and that we all had the discussions together.
Yes, the note should be moved to the discuss area.
We definitely have people who sometimes have more than one role in a team. For example when I ran this exercise last time we had a person who was both a developer and a scrum master. That person can decide which group to sit with, or they can split their time. We also kept the roles pretty high level because that’s the way we work in the team. So the roles we’re talking about could look like this: developer, artist, product owner, scrum master, tester. If people don’t know which role they perform for the team I would have a discussion about that before starting the exercise. Make sure the whole team comes up with the roles together, and have them decide on the granularity. Maybe in some teams “developer” isn’t enough, and you would need to be more specific “application developer” and “database developer”. Finally, ask each team member which roles they perform for the team.