Working Agreements Everywhere

The concept of working agreements is as old as the need to cooperate. Inside the agile community, they are used to set the teams norms. They set the agreed upon cultural rules. Working agreements are enforceable within the team because it is a collective agreement. Typically, the people affected by them create them. Working agreements are an effective method of ensuring everyone is on the same page. They help lay the foundation for a high performing team.

When To Establish Working Agreements

It is an easy answer – let’s just say in the beginning. Otherwise, at the point where you recognize the need for some ground rules. Remember high performing teams are self-organizing with vastly different, cross-functional skillsets. Working Agreements help them identify common ground, align, empower, and create shared expectations. Yet, Each agreement is a collaborative work of art that will change and evolve. Every team will have subtle differences like the spots on a leopard.

Everyone supports and empowers the team to develop their own standards. Other teams may need an unbiased facilitator to help with their creation. It is a typical scenario for new teams. It is not a management tool or management-driven initiative. Furthermore, the intentions and culture limit the boundaries of the agreement. It means if a company has a variety of teams, each team will have their own set of agreements.

Building True Teams

Have you ever watched a team create innovative products and works together as one? Even with multiple personalities and skillsets are at odds are some working agreements in place. Whether they are written or informal, they provide basic ground rules. Hence, they go above and beyond the work assigned and encompass a shared set of expectations. To create working agreements, consider factors such as:

  • How we resolve disputes
  • What’s our communication preference
  • How we respond to broken agreements
  • The best way to evaluate the quality
  • How we demonstrate trust and value
  • Managing roadblocks
  • How we demonstrate respect and empathy
  • Handling and assigning activities
  • How to assess agreements

When to change the agreements

The team as a whole determines and manages their working agreement. The creation of positive principles and values is the goal. It is a simple system for internal assessment and accountability. This list should consist of 5 to 7 items—no more than 10. The working agreements are not a to-do list, but a system of values. If one member falls short in anyway, the entire team is responsible. However, as a cross-functional team—it is likely that team members can help pick up the slack. It takes accountability to a whole new level.

Working Agreements Further Simplify The Complex

One of the principles of the Agile Manifesto states that simplicity is essential. One of the most common sources of stress at work is an unclear understanding of expectations. In any organization, this is often an ever-moving target. Or, feeling consumed and overwhelmed by an unrealistic volume of work. In additional, the ability to deliver early and often allows us to break big things into bite-sized chunks. Yet, working agreements go further by allowing to team to create supportive behaviors. These behaviors counteract stress by creating a happier and more productive work environment.

These self-driven agreements support transparency and innovation. They are not mandated by management. Sometimes well-intentioned dictated agreements restrict or complicate the situation in some way. That being said, it is not uncommon to turn to company principles of values as inspiration. However, as a self-organized team, it is best to align from within.

Let’s about Talk Scrum’s Product Owner

The Scrum Team is the Development Team, Product Owner, and Scrum Master. These are three distinctive roles, but one team. So, people believe that working agreements are solely for the Development Team. Wrong! They think that a few agreements should be made for the Product Owner. Wrong, again! The Product Owner is part of the Scrum Team, not the sole external member of the Scrum Team. Don’t treat the Product Owner like an outsider that disrupts the flow.

Creating working agreements with only the Product Owner does not make sense. It is like having a unique set of rules to make sure someone does their job. It is an attempt to make individuals commit to Scrum and minimize disruptions. Therefore, working agreements do not function as the Scrum Police or a form for CYA (aka Cover Your Arse =) ). Solving the problem will help you maintain balance and respect. Focusing agreements on individuals will create a cavern in the team. Instead, use working agreements to build a system of support.

Who takes leads

In a perfect world, a high performing team has no leaders. But, there is always someone that takes point based on the situation. It assumes that someone takes the first and most exposed position. For example, an underwater demolition specialist may take the lead when needed. It will put them in the most physical or political danger. The alternating nature of leadership helps the teams learn and grow as a unit. Therefore, the situations are ripe for opportunities to make subtle adjustments or complete overhauls. It is imperative to have a period of reflection from time to time for improvement.

Holding The Team Accountable

Contrary to this sub-title, the team holds itself accountable. Yes, a Scrum Master is a servant servant-leader. Also, a project manager can help clear the path. Finally, management puts us in the best position to be successful. They all inspect for gaps in transparency and barriers to communication. However, the team is tasked with holding one another—and themselves, accountable.

Allow the team as a whole to determine consequences when agreements are broken. Most of the time, any infractions are minor and will not need much attention. To be clear, this doesn’t mean that the team has the power to make anyone do anything. Hence, this solution is to coach teams to work within 70% to 80% of the rules being followed. Yet, this flexibility is essential to keep the team from becoming a Police State.

Revising Working Agreements

A fundamental tenet of Agile is to respond to change, so if something is not working— change it. Furthermore, this includes revising or eliminating Working Agreements that aren’t working. It can be anything as simple as communication. Other times it is the dreaded personality conflicts. If an agreement or any system set up by the team is not working, individual team members are empowered to speak up. Odds are, they aren’t the only one feeling same way. If someone is the only one feeling that way, a healthy team will listen. Hence, they will be receptive to innovative alternatives. At the very least, experiment with a subtle change or new agreement.

New Team = New Agreements

Create new working agreements even if team members have worked together in the past. Don’t forget that every team is unique. Even simple agreements help to maintain transparency and empower innovation. Hence, the simple act of adding one new team member could lead to evaluating agreements. Rolled over working agreements get revised at some point along the way.


Working agreements are not required. Yet, utilizing these supportive strategies is always helpful for any work effort. In particular, Working agreements create a foundation to achieve any goal. They are not necessarily quantifiable beyond a binary, yes or no. Hence, this best practice will help any team, especially new ones.

In conclusion, understanding the sum of all parts creates a greater team. Hence, working Agreements are an excellent way to support any endeavor. It is yet another time-saving means of simplifying the otherwise complex. Whether informal or formal, you will find working agreements everywhere.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.