Scrum, day 24: working agreements

Today's objective: turn a recurring disagreement into a working agreement that people can observe, use, and revise.

Read alongside: Mastering Professional Scrum, chapter 2, focusing on working agreements. Look for a situation in which good intentions still leave people expecting different behavior. Allow roughly five minutes for this companion, plus the book section.

The disagreement behind “communicate better”

A Developer on the fictional ShiftSwap team changes how an older cancelled request is displayed. They mention the decision in a chat conversation with one colleague. Another Developer continues work using the previous behavior and discovers the difference during verification.

Both people believe they communicated reasonably. One assumes a message in the team channel is enough. The other expects consequential behavior changes to be recorded alongside the work. Telling both of them to “communicate better” leaves that mismatch intact.

The team needs an agreement about this recognizable situation. It should describe what people can expect from one another when a decision changes the behavior they are building together.

Start with the consequence everyone recognizes

The first discussion is about what happened, without deciding immediately who was careless. The message was visible in chat, but the change was absent from the item used during implementation. A colleague who had been away for a few hours had no reliable way to distinguish a final decision from an idea still being discussed.

The consequence was avoidable rework and a delay in checking the complete request flow. Naming that consequence helps the team agree on the purpose of a new practice. The purpose is to preserve a usable record of decisions that affect other work.

It is also useful to ask where the current approach works. Quick chat exchanges resolve many small questions effectively. The team does not need to replace every conversation with a form or approval request.

Describe a trigger and an observable response

The team drafts this agreement:

When a decision changes the expected user behavior or an example another Developer is working from, the people making the decision record the new behavior and its reason on the affected item, then directly alert the colleagues whose current work depends on it.

The trigger is more specific than “when anything changes.” The response names both a durable record and a timely conversation. Either alone may be insufficient: a record nobody notices can arrive too late, while a conversation without a record is easy to lose.

The wording does not require a particular person to become the team's permanent secretary. The people involved can decide who updates the item. The agreement concerns a result they can check, not a new administrative role.

Try it against concrete cases

ShiftSwap tests the wording with three examples. A spelling correction does not change expected behavior and needs no special discussion. Changing which cancellation explanation employees see does trigger the agreement. Replacing an internal function while preserving behavior probably does not, unless other Developers depend on its interface.

That third example reveals a gap. Technical interface decisions can affect colleagues even when users see no immediate difference. The team broadens the trigger to include changes to an agreed interface that current work depends on.

Working through examples is more useful than asking everyone whether the sentence “looks fine.” People often agree with an abstract statement while imagining different situations. A disagreement about an example is information that helps improve the agreement before it creates frustration.

Preserve room for urgent action

An urgent correction may need immediate attention. The agreement should not delay a response merely because a particular person is unavailable to update the item. The Developers discuss how to preserve the purpose under that constraint.

They agree that the people handling an urgent problem can coordinate directly and record the decision as soon as the immediate response allows. They still alert affected colleagues promptly. Urgency changes the sequence, while the need for shared understanding remains.

If almost every change is described as urgent, the exception has swallowed the agreement. That would be a reason to investigate incoming work and expectations, rather than repeatedly accuse people of failing to follow the rule.

Make participation real

Radu can facilitate the discussion and help quieter team members contribute. He should not write an ideal set of rules alone and ask everyone to sign it. People who must use an agreement need an opportunity to explain where it would help, where it could obstruct work, and what they can realistically do.

Consider a colleague who spends much of the day pairing and rarely watches chat notifications. Their experience may reveal why a direct alert is necessary. Someone working different hours may explain why a written reason matters more than a bare statement of the new behavior.

The final agreement can accommodate these differences without requiring everyone to maintain the same working rhythm. It should improve coordination around the work rather than standardize every personal preference.

Keep agreements distinct from quality requirements

This decision-recording agreement describes how people collaborate. The Definition of Done describes the quality state required for the product Increment. They serve different purposes, even when a collaboration practice helps the team meet its quality standard.

A team also cannot use a local agreement to remove a Scrum accountability or ignore a genuine organizational requirement. “The Scrum Master assigns all tasks” would require examining how that practice affects the Developers' ability to manage their work, rather than treating unanimous approval as sufficient justification.

Working agreements are a supporting technique. Their value lies in making useful expectations explicit and revisable. Their existence alone does not prove that the team collaborates effectively.

Review the agreement through use

After a Sprint, ShiftSwap examines a few relevant decisions. Did affected colleagues notice the changes in time? Could someone joining later understand the reason? Did the record become burdensome for small changes? Were there disagreements about when the agreement applied?

If people repeatedly overlook it, investigate why. The wording might be vague, the information might live in an inconvenient place, or the expected response might be unrealistic. A respectful reminder can help, but repeating the same reminder indefinitely is not evidence that the agreement is well designed.

The team can simplify, amend, or retire an agreement when its circumstances change. A long list nobody uses is less helpful than a few expectations people can explain and apply.

Rewrite one vague rule

Choose a phrase such as “be responsive,” “help each other,” or “keep the board updated.” Describe the recurring situation that prompted it, the consequence you want to avoid, and the observable response people could reasonably expect.

Test your draft against an ordinary case, an ambiguous case, and an urgent case. Set a review point and decide what evidence would show that the agreement helps.

Reflection: could two colleagues independently recognize when this agreement was followed? If not, which word or missing condition leaves too much to interpretation?

Next, day 25 examines who should make the decisions these agreements support.