Team Working Agreements

---

Origins

The idea of explicit working agreements has roots in organizational psychology — in particular Edgar Schein's work on group culture and Bruce Tuckman's stages of group formation. In the Agile world, the practice was popularized through Esther Derby and Diana Larsen's Agile Retrospectives¹, Lyssa Adkins' Coaching Agile Teams², and the broader Agile coaching tradition that treats the team as a deliberately-formed unit rather than an accidental grouping of people.

The premise is simple. Every team operates by rules. The only question is whether those rules are inherited, implicit, and inconsistent — or articulated, agreed, and visible. Working agreements make the rules a deliberate artifact rather than a set of habits the team drifted into.

What a Working Agreement Is

A working agreement is a small set of explicit norms the team commits to following. It is short enough to read in a minute, specific enough to be actionable, and broad enough to cover the moments where the team's behavior diverges from its intentions.

Typical agreements cover topics like:

• Meetings: when they start, who attends, what happens if someone is late, what cameras-on means on remote calls.
• Response times: how quickly Slack messages, code reviews, and pull requests are expected to be acknowledged.
• Decision making: which decisions require consensus, which are owned by individuals, when "disagree and commit" applies.
• Disagreement: how the team handles conflict, where pushback belongs, how the team distinguishes between debate and stalemate.
• Done: shared standards for code review, testing, documentation — the team's contribution to its Definition of Done.
• Work hours and availability: core hours, on-call expectations, notice for time off, asynchronous norms.

Why Implicit Doesn't Work

Every team has working agreements. The choice is whether to make them visible. Implicit norms have three predictable problems.

First, they drift. The team that "responds to pull requests promptly" gradually responds slower as the team grows, then suddenly the new hire is waiting two days for review and nobody can agree whether that is acceptable. Norms erode quietly until a friction point forces them into the open.

Second, they exclude new members. Veterans know how the team works because they were there when the norms formed. New people pick up most of it from observation, but they consistently miss the unwritten rules — and the team treats their missteps as character failures rather than knowledge gaps.

Third, they import defaults. People bring expectations from prior teams. Without an explicit agreement, those defaults silently become the team's policy, and the policy is whatever the loudest or most senior person assumes.

How to Run a Working Agreement Session

A first working agreement session typically takes 60–90 minutes. Repeat sessions (revisiting and refining) run shorter.

1. Set the frame (5 min)

Explain what a working agreement is and what it is not. It is not a policy document; it is a small set of behaviors the team commits to. It will be visible, will evolve, and will be revisited.

2. Generate (15 min)

Silent generation. Each person writes one item per sticky note answering prompts like: "What helped our previous team work well?" "What got in our way last sprint?" "What do we want to be true about how we work?"

3. Cluster (10 min)

Group similar items. Common clusters: meetings, communication, decisions, conflict, code/quality, work/life balance.

4. Discuss and refine (20–30 min)

For each cluster, the team discusses the underlying behavior and converges on a specific, observable statement. "We respect each other" becomes "We respond to code reviews within 24 hours during work days."

5. Commit (5 min)

The team confirms the final list. Each member explicitly agrees. Anyone who cannot agree to a specific item flags it for discussion or modification.

6. Publish (5 min)

The agreement goes somewhere visible — team channel pinned message, wiki page, retro tool, physical wall. Out of sight is out of practice.

What Makes a Good Agreement

The difference between a working agreement and a values poster is specificity. Vague aspirations don't change behavior; concrete commitments do.

• Behavioral, not aspirational: "We are transparent" is a value. "We post status updates in the team channel daily before noon" is a working agreement.
• Observable: A teammate should be able to point to a moment and say "that violated our agreement" or "that honored it" without ambiguity.
• Few: Five to ten items is plenty. Long lists go unread; short lists get referenced.
• Written by the team: Agreements imposed from above don't stick. The act of writing them together is half the value.
• Time-bound by review: Commit to revisiting in a month, a quarter, or after a notable team change. Agreements are living.

Maintaining the Agreement

Working agreements that get written, posted, and forgotten produce more cynicism than no agreement at all. Three practices keep them alive.

• Reference them when they apply: In a retro, when discussing a conflict, when onboarding a new member — the agreement is the touchstone, not an abstract value.
• Revisit them on a cadence: At least quarterly, or whenever team composition changes meaningfully. Ask: which items still serve us, which need editing, what is missing.
• Let the team amend them: An agreement that cannot be changed is a constitution, not a working tool. If a norm consistently fails to fit, change the norm.

Common Pitfalls

• Too many items: 30 rules nobody can remember, much less follow. Cap aggressively.
• Vague items: "We collaborate well" goes nowhere. Push for specifics until the agreement is testable.
• One-time event: Agreement created at team kickoff, never referenced again. Schedule the next review before you finish the first session.
• Lopsided participation: Senior or louder members dominate the writing. Use silent generation and explicit go-arounds to balance voice.
• Leader veto: If the leader can override the agreement at will, it is not a real agreement. The team will read that and stop investing.

Coaching Tips

Run It Early

A working agreement session in the first week of a new team is more valuable than a perfect one written three months in. Form the habit early; refine later.

Push for Specifics

When the team proposes a vague item, ask: "What would I see someone doing if they were honoring this?" Don't move on until the answer is concrete.

Use Silent Generation

Solo sticky-note writing before any discussion levels the playing field. The loudest voice doesn't anchor the conversation before quieter members can think.

Make the Leader Sign First

If the leader visibly commits to the agreement — including the items that constrain their own behavior — the team will treat it as real.

Surface Violations Calmly

When an agreement is broken, name it as a system event ("our agreement says X; that didn't happen here") rather than a character flaw.

Retire What Doesn't Fit

If an item consistently fails to be honored, the choice is to recommit or to change it. Don't let dead clauses pile up — they undermine the agreements that still work.

Summary

Team working agreements are one of the lowest-effort, highest-leverage practices a team can invest in. They cost an hour to create, they reduce the friction of countless small decisions, and they give the team a shared reference for moments when behavior drifts. The teams that use them well treat them as a living document, not a one-time artifact: the agreement evolves as the team learns what actually serves it.

The point is not to legislate every interaction. It is to make the invisible visible — to surface the half-dozen norms that matter most, agree on them deliberately, and give the team a way to talk about them when they break.

Back to Team Dynamics, Health & Coaching