An agile team working agreement is essentially a document that lists out a team’s norms using statements like “We value long-form asynchronous communication over short, unclear messages.” These documents are a way to take implicit agreements and make them explicit so that the team can remain aligned throughout the duration of a project. This can be a particularly useful tool when a new team is spinning up and norming together.
There are many different articles online about the ‘right’ way to create an agile team working agreement, but I find that it’s best to come up with a process of creation that works well for your team and your culture. Earlier this month, I facilitated a session that worked extremely well for that team, but it’s not to say that way would work for everyone. However, you should be able to take the principles from this post and apply it to your team.
When to Create an Agile Team Working Agreement
The short answer to ‘when should my team create an agile team working agreement’ is now, (if you don’t already have one). However, the best time to create these agreements is at the very beginning phase of a project, especially if it’s a new team. It’s most critical at this time because the team may have preconceived notions of how the team will work. I have found that this is also a great time for a team to begin having some healthy debate. It breaks down that wall early on in the project lifecycle, so that the first issue they disagree on in the project isn’t the first time they’ve had to debate one another.
How to Create an Agile Team Working Agreement
The creation of an agile team working agreement should be a collaborative process. As I’ve mentioned earlier, there are many ways to do this, and I’m simply describing a way that has worked well for our teams. When thinking about the facilitation of this process, ask yourself, ‘what is your team most comfortable with in terms of collaboration?’ At Crema, it’s now a norm that we use a virtual whiteboard (even if no one is joining remotely), called Miro. Using a product like Miro can be helpful because of the wide variety of features such as voting, reacting, timers, etc. However, you could use a collaborative document like Dropbox Paper, regular sticky notes, or even use a physical whiteboard to anchor discussions. It’s really up to you.
The first step in this process is setting the scene for your team. Give them an explanation of why this document can be valuable to them, as well as what the process is going to look like. Then, kickoff the process! Ask the team to answer the following question: What are the decisions that, if made now, could help us in the future when the pressure is on or things haven’t gone our way?
Then, set a timer for about five minutes and ask the team to generate as many ideas for working norms as possible. This is a good time to remind them to think of the agreements as ‘We believe…’ or ‘We value…’ statements to avoid having to clean things up later.
After the time is up, take some time to review all the sticky notes as a team. Ask the team to call out any clarifications that they need to understand what the sticky note means, but not to discuss it yet.
Once the entire team is clear as to what each sticky note means, ask them to rate each norm using the following scale. Thumbs up ( 👍) for full agreement, neutral face ( 😐 ) for questions, or thumbs down ( 👎🏼 ) for disagreement. Here’s the catch with disagreeing though; If anyone disagrees, they have to suggest something better.
Once the team votes, review all the new norms. Anything with all thumbs up immediately becomes a new norm. Anything with a neutral face should be discussed further. Once the team aligns on it (including rewording), then it becomes a norm. Any norm that includes a thumbs down should be discussed and decided if it should be thrown out or revised to work with the team.
If you use the method described above, you will likely end up in a scenario where there are duplicates. Work to consolidate them into common themes and ask the team about suggestions for rewording that align the near-duplicated sticky notes. At this point, you should have a set of new team norms that can be placed into some kind of public document that is referenced on a regular basis. All of our ‘final’ documentation at Crema is placed in Confluence for future reference, but this could be any repository of documents that makes sense in your organization. What’s important is that people know where it lives.
What’s Next?
After you’ve created this agile team working agreement, it’s important that it’s not forgotten about. It should be a topic of conversation on a regular basis. Depending on your process, this could look different, but a bi-weekly retro would be a great time to check in to make sure everyone feels like the norms still represent the team. It’s perfectly okay if the norms need to be adjusted to better fit the team as the project progresses and the team learns how to work well with one another. If the team values constant improvement, there should be no problem discussing changes and/or calling team members out when they’re breaking the agreement, especially since the entire team agreed to this collaboratively.
I hope you’ve found this overview of agile team working agreements helpful. If you have any questions, comments, or even arguments against it, I would love to hear them.
