PoleThe working agreement is perhaps the most important output of a self-organizing team. It defines how we operate as a well-functioning unit, and gives us permission to hold ourselves accountable to the pursuit of excellence.

At the risk of sounding like Sheldon Cooper, a working agreement is in some respects like a roommate agreement. It defines how we keep the place clean, stop the refrigerator from smelling, and provides a clear mechanism to hold each other accountable to the objectives. Of course, a dysfunctional team doesn’t use the agreement like a club the way Sheldon is prone to. Rather, it’s a positive signpost that each member of the team can look at to help keep us on the path we know is right.

When a working agreement is done well, all the members of the team have “bought into it.” They’ve reached a common understanding of what excellence means within the context of their work and their focus. All have given it a thumbs up. 

The agreement lets everyone know what is expected of one another. In the software context, it means such things as waiting to merge code until it’s been reviewed at least twice. It can specify what sort of notification is necessary when planning time off. Whatever it takes to keep the team running smoothly, effectively, and all of the members working in concert with one another. When the team holds members accountable to the agreement, it’s not punitive. It’s a reminder of what we all agreed to.

Beware The Pitfalls

But there are pitfalls with the working agreement. I’ve facilitated several working agreement sessions now, and I’ve rarely been satisfied with them. Not that the team did anything wrong, but I had a vague sense that, as a facilitator, I could have done a better job. I’ve learned to take that as a cue to re-examine my approach.

Here are some things I would change about past working agreement sessions I’ve been a part of:

  • When you have a diverse team, you have diverse ideas of a working agreement. Generally the team works this out in the normal course of discussion, but there have been times when I wasn’t aware of instances where the working agreements were not entirely in alignment. I should have been more “in the moment” and called those out, because they lead to difficulties later.
  • KISS – Yes: keep it simple, stupid. There’s a tendency, in the spirit of “letting every voice be heard” to allow all ideas have equal weight. This leads to a working agreement as complex as Sheldon’s roommate agreement, and many of the details tend to get forgotten. This in turn can lead to a general disregard of the working agreement entirely. If it’s too complex for the team to manage, it will be discarded intentionally or unintentionally. I’m not suggesting that as a facilitator we should be an editor; far from it. But the facilitator should challenge the team to ask themselves whether they are up to implementing the agreement as written.
  • Make sure the items are specific. Vague statements lead to vague implementation of them. If the team gives itself wiggle room on a given agreement, they are likely to let accountability slide, if they bother to enforce it at all. If the team isn’t in perfect agreement on what a statement means, they won’t know how to hold each other accountable to it.
  • Make sure accountability is part of the agreement. How we agree to hold each other accountable is as important as what we are holding each other accountable to. Make sure the team agrees on methods that are positive and constructive, not hurtful.
  • If there is a change of even one member, revisit the working agreement. This one I can’t stress enough, because it’s the one I overlooked the most. Scrum teams tend to be from 3 to 8 people. A change of even one person represents a huge percentages in the makeup of the team. Make the effort to look at the working agreement again. Make absolutely certain everyone is still in alignment with it.

Scaling The Working Agreement

At a scaled level, working agreements are even more interesting. How to craft a workable agreement amongst several teams? I won’t claim to have all the answers on this one yet. But I do know this much. The KISS principle is even more important. A cross-team working agreement that is more than half a dozen items is not likely to be adhered to. Think of it this way: If your large project averages 5 members per team, and has 7 teams, then you need to develop a working agreement that 35 people all have a common understanding of. I’ve seen working agreement boards with over 30 items on them, and expecting that to work at a scaled level seems unrealistic.

At scale, what is the absolute minimum that is necessary to keep many teams in alignment and functioning smoothly? It is the facilitator’s responsibility to understand this, and make sure the team of teams isn’t crafting something impossible for a scaled environment to live up to.

The signpost needs to point to a clear objective, and offer clear, easy-to-remember directions to the destination.

Does your team have a working agreement?  What have you learned while crafting one with your team? Join in the conversation below or Contact Us.

Anthony Bopp, Scaled Scrum Facilitator
Latest posts by Anthony Bopp, Scaled Scrum Facilitator (see all)