Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

A Working Agreement is a valuable tool to use for establishing a shared understanding, and way of working for teams. Also called a Social Contract, this practice is a great foundation for building high performing teams. Team members themselves set agreements.  The purpose of setting up team norms is to establish a ONE team culture, and it is something to refer back when things get rocky within the team.

How to create a working agreement?

This Working Agreement exercise has been adapted from Esther Derby and Diana Larsen’s 5 step structure from their book Agile Retrospectives. The five steps can be summarized as follows:

  • Set the stage — Goal: Set the tone and direction.

  • Gather data — Goal: Create a shared memory; highlight pertinent information and events

  • Generate insights — Goal: Think creatively; look for patterns, themes and connections

  • Decide what to do — Goal: Generate and prioritize valuable, clear actions

  • Close — Goal: Summarize and end the meeting

That said, in the context of Working Agreements you can run the following:


 1. Set the Stage (3min)

Describe what the purpose of the exercise is. I like to use the following introduction and description of what a working agreement is, and how it can benefit a team:

“Becoming a team involves commitment to working together and supporting each other in our common goals.

This commitment is supported by writing what all team members believe are important protocols for the team to comply with to maximize their capabilities to deliver faster and with higher quality.”

 2. Gather Data (7 mins)

Have each team member write down things that are most important to them to achieve this. Generally this will be done on sticky notes and added to a whiteboard.

For remote teams we’ve used FunRetros with great success (the merge functionality for grouping and voting is really useful) if you want a more “traditional” feel, we’ve also played around with Web Whiteboard (the sticky notes look and feel is quite fun).

Like a retrospective, you can decide to limit focus by having each team member limited to 3 items, or you can gather more data by having no restriction on this. It’s important to encourage at least 2 items from each team member.

You can guide the discussion by suggesting some high level topics such as:

  • Time and location of Daily Scrum

  • Testing strategy (unit, functional, integration, performance, stress, etc…)

  • Build and infrastructure plans (shared responsbilities)

  • Team norms (be on time, respect estimates, help when needed, etc…)

  • How to address bugs/fires during Sprint

  • Product Owner availability (phone, office hours, attendance in Daily Scrum)

  • Expectations of each role and how they will work together at each phase of the SDLC

 3. Generate Insights (15mins)

Discuss each item added by the team members and start grouping items which seem to relate to each other. Do this as part of open discussion on each topic to gather enough context to see if it can be grouped with something similar, or if it’s something different. Make sure to encourage participation from all team members by asking questions like “X, what do you think about this?”, etc.

On FunRetro, you can create a column for Working Agreement Items, then you go through them top down and drag them to a second column, Groups. If an item exists in the Groups column that the team agrees is similar, you can merge the cards by dragging the card from Working Agreement Items to the corresponding card in the Groups column.

In person, you can do this by physically grouping sticky notes.

Optional — if you want to limit the number of groups based on importance to keep focussed on the “most important items”, you can then use voting to determine priority. This is optional because some teams have found value in this, while others have not. Use your team’s discretion on whether there are “too many” items are not. If no such phrases, or comments, are mentioned then the grouping can just be used as is in the next step. Voting is also useful if there are a large number of conflicting views on how to do things. What we want here is consent over consensus, i.e. consent is where no one objects, and consensus is where everyone agrees.

 4. Decide What To Do (15 mins)

For each group, make sure that there are clear actions for each item where applicable. If, for example, a group of items allude to how we deal with external team requests or unplanned issues, it’s useful as a team to agree on how we will respond to this. We can create actions like “Must be discussed with PO”, “Must be groomed according to our story format respecting Definition of Ready” and “PO will update external part with expected delivery based on team capacity and discussion”.

It’s important to remind the team that these actions are not set once off. They can (and should) change as we learn more about working together. Retrospectives are a good time to have an action that changes an existing working agreement if we realize it’s an impediment to working better together.

 5. Close (5 mins)

Summarize and close the meeting. Make sure someone has taken ownership of documenting the Working Agreement and placing it near your Team Board or in your Wiki space.

This is also a good time to gather feedback from the team on the usefulness/effectiveness of this format for future usage. This can be done by fist-to-five voting.

On a count of three every team member holds up their fist displaying a number of 0 (bad) to 5 (great). Ask each person that shows a 0 to 3 what can be improved to get them to a 4 or 5. Use this feedback for future meetings/retrospectives or Working Agreement discussions.

Reference Material

  • No labels