Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
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.
Image Removed
Download Working Agreement Canvas
WHERE TO START AND END
When chartering a new team, I would suggest starting with parts 3, 4, & 5: the team mission, roles & responsibilities, and metrics.
This encapsulates the idea of, “starting with why” – a common theme in the Agile landscape. I would end with the top sections 1 & 2, choosing a team name and motto. For an already existing team that is going through changes, like absorbing new members, starting with the top sections is fine.
THINK THROUGH THE MIDDLE
The middle sections of 6, 7, & 8 are meant to be self-reflective. We need to know how we see ourselves and be as radically honest as possible. It’s commonly said at Scrum Inc. that doing Scrum won’t make you agile, but it will surely show you where you are not. These sections are designed to help facilitate that discussion, as well how we want to celebrate and improve.
THE VALUES SECTIONS
The final sections, 9 & 10, are of particular importance as we want to create a values-driven culture. The Scrum Values anchor our culture, but we need to expand our minds to include those of our company and our team. For example, Honesty, while essential for Scrum to succeed, is not a core value. I have not often seen it in corporate value statements either, but I have worked with many teams that want to explicitly include it in their working agreements.
Section 10 is what we commonly associate with working agreements. Here is where we summarize and list what norms and behaviors we want to encourage. We suggest writing them as individuals and then discussing them as a group, ending with voting by “fist of five” for no more than ten at a time to be included in this Working Agreement.
THE EVENTS
Section 11 is our final one where we list our Event details. This includes the time and place, as well as any other important people who need to be present that are external to the team. For example, in Scrum we always want a representation of the customer at the Sprint Review so we can get direct feedback on the product increment the team has created, so here is where we would list stakeholder and customer names.
This agreement can be revisited during a team’s Sprint Retrospective and modified as needed. In particular, if a team has mastered one of the agreements in section 11, it can be removed and another one voted up into its place. I hope you find this helpful and feel free to provide any feedback to make it better.
How Working Agreements Help
Working agreements:
Develop a sense of shared responsibility
Increase members’ awareness of their own behavior
Empower the facilitator to lead the group according to the agreements.
Enhance the quality of the group process.
These agreements are created by teams and the ScrumMaster facilitates the meeting, and they are preferably, created/reviewed during the Sprint 0 of every release.
Agreements work well when:
They are important to the team
They are limited in number
They are fully supported by each member
The members are reminded of agreements during process checks
The members are reminded of agreements when they are broken
Examples of Team Working Agreements
Some Examples of Working Agreement Guidelines are:
Show respect. Don’t interrupt; let people finish what they’re saying. It’s OK to disagree with each other. No personal attacks, attack issues, we debate the merit of ideas, not people.
Contribution. Everyone has equal voice and valuable contribution.
Meeting. Be on time, end on time, have an agenda
Be transparent. No hidden agendas. We will give feedback, we will receive feedback, and we will act on feedback.
Impediments. Solve roadblocks within the team. If the impediment cant be solved within the team, give it to the Scrum master.
We make commitments as a team. We will be held accountable to our commitments. – we work as a team to make a commitment and deliver on it.
Incomplete stories are not good – it is better to help get an existing story to “done” than to start another story that can’t be finished in the current sprint.
How to Respond When Working Agreements are Broken
The Scrum Master is the custodian of the working agreements, but the whole team has the responsibility to question when someone is breaking the agreement. Since the working agreements were agreed upon by the team, it removes the perception of personal attacks and confrontation. In the spirit of transparency and continuous improvement, team members should revisit the working agreements from time to time and ask, “Should these be updated?”
Iframe | ||||||||
---|---|---|---|---|---|---|---|---|
|
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:
Expand | ||
---|---|---|
| ||
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.” |
Expand | ||
---|---|---|
| ||
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:
|
Expand | ||
---|---|---|
| ||
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 focused 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. |
Expand | ||
---|---|---|
| ||
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. |
Expand | ||
---|---|---|
| ||
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. |
Sample Team Working Agreement
Be respectful of others. Give each other the benefit of the doubt
Notify team of any impediments promptly
Attend all required meetings
Stick to the purpose, time and agenda of each meeting
Send update or delegate if unable to attend required meeting
Team will collaborate and support each other to achieve goals
Keep JIRA and Confluence updated
Ask questions and accept decisions adopted by the team
Avoid lunch meetings and Friday meetings after lunch as much as possible
Reference Material