Don't be the Working Agreements Police
Article content
Article sections
Some years ago I was coaching a developer team that had agreed on eight working agreements during a facilitated session in their first week as a team. Posted them on the wall, photographed them, dropped the picture into Slack, did all the right things. Three weeks later I walked past their bullpen and overheard one of the senior engineers gently remind a teammate that they had a team agreement about not editing pushed commits without a heads-up. The teammate apologised, fixed it, and went on with the day. Nobody escalated. Nobody pulled me in. The Scrum Master was nowhere in the room.
That moment was the first time I really understood what working agreements are supposed to do, and what they are not supposed to do. They are not your rules to enforce. They are the team's rules to enforce on each other, and the only sustainable way to get there is to never become the person who polices them.
If you ever catch yourself walking into a team room with a copy of the agreements in hand to remind people that they were supposed to do X, you have crossed a line. Don't be the Working Agreements Police. The job of a Scrum Master is to make the agreements visible, name friction when it shows up, and make the agreements self-reinforcing so that the team starts to hold each other accountable instead of looking to you for enforcement. That last shift, the one from the SM enforces to the team enforces, is where the entire value of having a working agreement actually lives.
Why policing kills the relationship
The argument against policing is sometimes presented as a soft skills point, as if the only reason to avoid it is to stay liked. That is true and it is also the smallest part of the reason. The bigger part is mechanical. The instant you become the enforcer of an agreement the team made, the team stops feeling like the agreement belongs to them and starts experiencing it as one more rule someone imposed. They will comply when you are watching and slip back the moment you are not, because the locus of control has moved from the team to you. The agreement still exists on the wall, but the muscle that the agreement was supposed to be building, the muscle of a team holding itself to its own commitments, never gets a workout.
There is a quieter cost as well. Once a Scrum Master takes on the policing role, every conversation with the team starts to carry a small administrative shadow. Are they bringing this to me because they want help thinking it through, or because they want me to enforce it on someone? Am I in this retro to help them improve their craft, or to remind them that they agreed to be on time? The role drift is gradual and almost always invisible to the SM themselves; the team feels it long before the SM does, and what the team usually does in response is stop bringing the harder conversations into the room.
Across the dozens of teams I have coached through this in our CSP-SM programme, the pattern is the same. The teams that hit a steady state of holding themselves to their own agreements are the teams whose Scrum Masters figured out, fairly early, how to set the conditions for that and then step back. The teams that never get there are the ones with an SM who has internalised the idea that the working agreements are part of their job description to defend.
The four principles, in the order they actually have to land
The alternative to policing is not laissez-faire. It is a small set of practices, applied in a specific order, that move the locus of enforcement from the SM to the team. There are four of them, and they only work in sequence; skipping the first one undermines the third, skipping the second turns the fourth into theatre.
Make them visible
Working agreements that can't be remembered can't be followed. The first thing that has to happen is that the agreements have to live somewhere the team sees them, every day, without going looking. A printed poster in the team room. A pinned Slack message in the team channel. The first slide of every retro. The opening minute of every sprint review. Pick whichever venue your team's eyes actually land on and put the list there, and review it briefly at every retro.
The thing to balance here is accessibility versus confidentiality. Some teams need agreements that say something a stakeholder shouldn't read, like "we don't take new scope from product owners outside refinement." Post those in a place the team sees and a stakeholder doesn't. That is a real constraint, not an excuse to bury the agreements; if you find yourself burying them, the agreements themselves are probably the thing that needs work, not the visibility.
Call out friction
The second move is the one most SMs find hardest, because it requires you to name what is happening in the room without naming anyone in particular. When you notice friction (someone is irritated, the meeting is dragging, a decision keeps getting unmade), call it out. Not the person, the friction. "I'm noticing this is the third time we have come back to the same trade-off in this retro." Then ask the diagnostic question that does most of the work: does any of our existing agreements speak to this situation?
If the answer is yes, the team usually finds their own way back to the agreement without anyone having to police it. If the answer is no, the team has just discovered a new agreement they need to make, and the conversation pivots from "who is doing the wrong thing" to "what do we want to do about this." That second conversation is generative; the first one is policing.
Make them self-reinforcing
If you find yourself reminding the team of an agreement more than once or twice, the agreement is broken at the design level. The fix is not more reminders. The fix is to redesign the agreement so it enforces itself, or close enough that the team almost never has to think about it.
Three flavours of self-reinforcement, in order of how often they work. Automate where you can. A pre-commit hook for the "no edits to pushed commits" agreement; a calendar reminder for the standup time; a CI rule for the test-coverage minimum. Ask the team to make the rule design easier on themselves. If three people keep missing the standup at 9am, ask if 9:15am would be more honest. Create positive moments around the agreement. A team I worked with celebrated their "we ship every Friday" agreement with a Slack thread of pictures of what got shipped that week; nobody had to police the Friday-ship rule after the second month because everyone wanted to be in the thread.
Update them often
The last principle is the one most teams forget once they have set up the first three. Working agreements are not commitments etched in stone; they are a living artefact of how a team has chosen to work together this quarter, and "this quarter" changes. Update them when the team forms, when people join or leave, when the team starts a new initiative, and at the latest every six months even if nothing else changed. Set a recurring slot for it; about ten minutes at the start of the retro every other sprint is usually enough.
The simple update prompt I use with our teams is two questions. Which of our current agreements are we honouring without thinking about it, and could probably be retired? Which behaviours have we noticed in the last sprint that should probably become an agreement? The first question keeps the list short; the second keeps it current. A team's list of working agreements should rarely be more than seven or eight items long, and the average lifespan of any individual agreement should be measured in months, not years.
What changes when the team starts to self-enforce
The first sign that the locus of accountability has moved back to the team is small. You will overhear a teammate gently remind another teammate of an agreement in a tone that is neither parental nor punitive, and the other teammate will fix the thing without an argument. The first time it happens it is easy to miss; the second time it happens you will notice that you were not the one who called it out, and that is the moment to know the practice has taken root.
The second sign is more about you than the team. You will start to be invited into different conversations. Instead of being asked to weigh in on whether someone is meeting the agreement, you will be asked to help the team think through whether the agreement itself is still right. The conversation level shifts from compliance to design, and the work you do as a Scrum Master becomes the work the role is supposed to be doing. That is also when the team is closest to operating as a genuinely high-performing team rather than a compliant one.
One last note. The move from policing to self-enforcement is the same move Brock writes about in the coaching mindset and the same move I described in the five-stance map. Stop adding from outside; start asking what the team would do without you. Working agreements are the small daily proving ground for that practice. If you can get the locus to shift on something as low-stakes as the standup time, the locus on the high-stakes things tends to follow.
What to do this week
Pick the working agreement your team is most often slipping on right now. Do not write a reminder for the next retro. Instead, run the diagnostic on it. Is it visible? Is anyone other than you ever the one who calls out friction against it? Is it designed to enforce itself, or is it relying on reminders? And how long has it been since the team updated it? Whichever of those four questions you have the worst answer to is the one to fix this week.
If you want to go deeper on the canvas itself, the original Working Agreements Canvas for High-Performing Teams post has the nine-question canvas we use to facilitate the initial session. The free Scrum Alliance courses Working Agreements That Work and Working Agreements That Evolve, which we built in partnership with Scrum Alliance, walk through the facilitation moves in more depth and are free for Scrum Alliance members. And if your team is currently treating its working agreements as a polarity problem (rules vs. flexibility, enforcement vs. trust), the Integrated Agile Manifesto piece Brock wrote on polarity management is probably the angle you want.
Write back when the welcome email lands if you would like a second pair of eyes on the agreement your team is currently slipping on. Most of what surfaces in those conversations is the agreement itself needing redesign, not the team needing more enforcement. The replies reach Brock and me directly.