The Importance of Working Agreements in Agility

The basic building block in the agile world — including organizations themselves — is the team. For Scrum, for example, the Scrum Team is the fundamental unit , and for the Scaled Agile Framework, it’s the Agile Teams . But what does it take to build a solid agile team? Without a doubt, the first step is establishing solid working agreements.

What Are Working Agreements?

At its core, a working agreement is a list of rules or qualities defined collaboratively and participatively among all the members of an agile team. This list can include, among other things, activities, values, or even rules that guide or shape the behavior of every single member of an agile team.

These documents — and I say documents because they need to be written down somewhere visible or accessible to team members at all times — help avoid the tacit commitments and informal rules that come with working alongside other people.

Example of a Tacit or Implicit Agreement

To help understand what these agreements are about, let’s look at a simple example.

At this organization, every meeting always starts late. We’re all used to them running longer than scheduled, so we don’t feel any urgency to show up on time, since we’re not going to leave on time anyway. It’s a vicious cycle.

This situation is typical in a lot of organizations. And let’s not forget that, especially now with virtual work and the new normal, it’s common for meetings to not start on time, and of course, not end on time either. But is this actually a formal rule? If it holds true always, or almost always, does that mean it’s our way of working?

While it’s hard to pin down the cause of this common organizational habit, the real question is: what can we do as a team to fix it?

Explicit Agreement

Teams can define a rule explicitly. Agreeing on rules together and discussing them openly promotes good communication and empowers the team.

In our example, the team could agree on rules that favor punctuality and focused, on-time meetings, like this:

As a team, we value focused meetings that start and end on time. We always hold meetings with a clear goal, communicated ahead of time.

Why Working Agreements Matter

Working agreements are a core part of a team’s identity — who we are, what we do, and how we do it. Every team starts out with some uncertainty. Team members don’t know each other yet, meaning the rules of the game aren’t clear: how we’re going to organize ourselves to get the work done, whether we’re going to use a top-down model where tasks are assigned by someone else, or a self-management model.

That’s exactly why the sooner you define your agreements with your team, the sooner you’ll get through that stage of uncertainty — known as Storming — and the sooner you’ll be able to build a safe space for debate, communication, and experimentation.

How many times have you joined a team and had no idea what your job was, or how you were supposed to contribute to the team’s goal? You might have a clear sense of your own tasks, or know what you’re good at, but how we’re going to work together as a team isn’t something you can anticipate, and getting everyone on the same page isn’t easy either.

How Working Agreements Relate to Agile Teams

Working agreements aren’t exclusive to agile teams. But an agile mindset is centered on people and how they interact with each other, which makes it a lot easier to see the value of using working agreements. Some traits of agile teams that align well with team agreements are:

Team Size

Agile teams are small groups of people. That means participatory democracy is possible, and easy to put into practice. You can fit the whole team in a meeting room and work collaboratively to define the team’s agreements.

That’s not so easy with large groups of people. It’ll likely be a more impersonal process, and therefore feel distant to a lot of people. That lack of involvement in creating the agreements turns them, for many, into just another set of rules handed down from above.

Structure and Hierarchy

Agile teams, for the most part, lack full hierarchies or deep political structures. That makes the team more participatory and more willing to take risks — thinking of risk here as the uncertainty of taking on new challenges or adopting new practices.

Working agreements help teams with a simple, flat structure take “accountability” for certain behaviors or processes within their own way of working.

Autonomy

Another trait of agile teams is the autonomy to define “the rules of the game.” While agile teams shouldn’t go against established norms, they can “bend” the limits a bit by setting their own rules.

Done well, autonomy can become a booster for productivity and trust within the team. That’s key to unlocking the team’s potential through what’s known as “psychological safety.”

How Do You Define Agile Working Agreements?

The first and most important thing is to be clear that the word agreement involves multiple parties, which means the process has to be collaborative. Defining the working agreement is a joint effort of every team member, not a task you delegate to the project manager or the Scrum Master.

If you want to facilitate the process of building a working agreement within your team, I’d recommend:

1. Know the team’s purpose. What’s the team’s raison d’être?
2. Identify the people on the team, their roles, and the reason they’re part of the team.
3. Send out the invite for the session — in person or virtual.

Once the day and time are set, don’t forget to:

1. Define which tool you’ll use. If it’s an in-person session, don’t forget to book the space — a meeting room or auditorium — and prepare the materials you’ll need for the activities you’re facilitating. If it’s a virtual session, you can lean on a tool like Miro or Mural.
2. Set up a base structure for the discussion. Facilitating isn’t the same as directing, but setting a contextual framework to shape the discussion and reach a baseline agreement is key. You can do this using the Team Canvas or a Team Charter.
3. Picture the flow of the session. How much time does each activity you’re planning need? That way you can set timeboxes for each activity. Remember, if activities don’t have a time limit, participants tend to drift or fail to land on concrete ideas or proposals.
4. If it’s the team’s first time meeting, or you’re not sure everyone knows how to use the selected tool, run a small icebreaker or support exercise so everyone’s clear on the group dynamic, time management, and how to use the tool.
5. Let the team work. The team needs to work on its own, without your constant intervention. Still, keep checking that everyone’s participating, and try to prevent one person from doing all the work.
6. When each activity wraps up, set aside time for the team to present its conclusions or findings. Prepare a few key critical questions to check that people understand the impact of each proposal — how does the team benefit? What impact does it have on others, inside and outside the team? When and how are we going to implement it?

Every agreement and every conclusion needs to be discussed and formally documented. And documenting doesn’t mean producing a thousand-page document — it can be something as simple and light as a small poster or infographic. What matters is that it isn’t just words in the air. Let the team review the outcome of its work and put together its own final version of the working agreement.

What Are the Most Popular Types of Agreement in Agile Teams?

Well, agile teams have all kinds of agreements and tacit and explicit rules. But the most popular — or most commonly used — are:

Team Charter

This document is a document or graphic representation — like a poster — of the team’s values, goals, and the guidelines or rules the team has defined for itself.

This charter is created by the team members themselves and can’t be imposed. As the saying goes, “authority can be delegated, but responsibility can’t” — because responsibility can only be “accepted.” In other words, we want teams to be accountable for, and feel ownership over, their own rules.

Typically, this kind of team working agreement includes:

1. The team’s mission and goals — why and what for we’re together as a team.
2. The context and resources we need to have in order to do our work and reach our goals.
3. In many cases, in organizations with more conservative values (compared to an agile mindset), clear roles and responsibilities are included — since the spirit of “shared accountability” or “shared ownership” over achievements and challenges isn’t there yet.
4. Processes, procedures, and techniques to use. How do we commit to doing or guiding our work? Discussing quality, and good ways of doing our work, with commitment from every team member, is key. Otherwise it’s just another document full of rules everyone ignores.

Definition of Done

I’ll go ahead and say this is the most popular, and most misunderstood, tool of them all. According to the Scrum Guide, the Definition of Done is a formal description of the state of a deliverable or increment in Scrum when it meets the established quality requirements. When we talk about the concept of quality, that conceptually includes both assurance and control. But what does meeting the quality requirements actually mean?

Definition of Done vs. Acceptance Criteria

The Definition of Done refers to the general criteria tied to the production process for requirements — or backlog items, if you’re in an agile context. Acceptance criteria, on the other hand, are specific to a given requirement. To understand this better, let’s look at an example:

A team whose job is producing informational content for a travel website has agreed on the following Definition of Done for every article: (1) it follows the style guide; (2) it has no spelling errors; (3) a teammate has done a review read and any comments have been addressed.

This week, one of the people writing an article is covering Spain as a travel destination. The acceptance criteria include covering the country’s capital, and discussing, within the article, the impact of the Arab periods on Spanish territory and how that shows up in certain cities, in their architecture, and in their cuisine.

This example is very simple, and it shows both concepts clearly. The Definition of Done is a shared team agreement that promotes the quality of the deliverable. In that sense, it can include steps to “avoid making mistakes” — quality assurance — and steps or checks to catch defects or mistakes early — quality control.

Common Mistakes When Writing a Definition of Done

Some of the most common mistakes when creating a definition of done include:

1. Building an extensive list that tries to cover every scenario — the list needs to be practical and applicable across all requirements, never an attempt to handle every special case.
2. Confusing acceptance criteria and folding specific, one-off requests into the definition.
3. Not formally communicating the definition, or not publishing it clearly somewhere — printed on-screen or in a collaborative work platform.

Definition of Ready

This is a somewhat less popular tool, but no less valuable for it. If you think of the Definition of Done as an exit checklist (for delivery), the definition of ready would be like an entry checklist.

When should you use a definition of ready? Here’s when:

1. Do you struggle to finish features or requirements that were never clearly defined? This tool can help you agree on certain intake criteria.
2. Does your team not know when a requirement should be considered ready to work on? This artifact promotes clarity and avoids arguments about what to do and what not to do.

Just like with the Definition of Done, you need to avoid going overboard with detail. It’s about setting clear rules for the level of detail required, and what needs to be true before something gets accepted into a plan — a Sprint in Scrum, for example.

5 Keys to Building Good Working Agreements in Agile Teams

Here are a few useful tips for building better team working agreements.

Cover Both Technical and Personal Aspects

Teams have a focus, or a goal. That focus is often limited to technical or work-related activities, not personal ones. But high-performing teams don’t limit their commitments to the work itself — they recognize the importance of the other person too. This includes, among other things, cultural expressions, behaviors, or even attitudes — for example: how to greet each other, how to approach topics like politics or religion, attitudes toward feedback, or how to handle problems and conflict.

Keep the Agreement Simple

Agreements need to be easy to remember and easy to follow. An agreement shouldn’t be a lengthy contract — it should be a clear way for each team member to commit to their teammates. Agreements don’t replace a values framework, and a group agreement doesn’t need to live in a single document, so keep it simple.

Update Agreements Regularly

While an agreement is meant to be followed, it’s also important to understand that context evolves, and sometimes it’s smart to revisit our agreements and give them an update. Sometimes this happens naturally as the team evolves, or it can happen the moment a new member joins.

Speak Up When the Agreement Isn’t Being Kept

This case gets considered far too rarely. Who creates an agreement just to break it? But the reality is that, while creating the agreement, the team needs to discuss the mechanism or channel for flagging or reporting what’s considered a violation of the agreement. It doesn’t have to be anything complex, but it needs to be clear to every team member how to raise what they consider a violation of the agreement. Likewise, discuss with team members how that report or violation will be handled. This should be settled early, to avoid headaches down the road.

Tie Agreements to the Organization’s Value System

Unless you work at a truly terrible organization, working agreements should always connect back to the organization’s context and values. That doesn’t mean copying the values word for word, but finding an anchor point will definitely help your agreement stay consistent with the organization. Your team might not be part of a larger organization, or this might simply not apply — in that case, set up a small value system of your own, the way Scrum or XP do.