Working Agreements

Purpose

Working Agreements give a team explicit, self-chosen norms that replace assumptions with shared expectations. By co-creating rules together, every member gains ownership and accountability for how the group collaborates, communicates, and resolves tension.

At a glance

How to run

1. Set the frame (5 min): Explain the purpose — the team will create a living set of agreements that guide daily collaboration. Stress that agreements are revisable, not permanent.
2. Silent brainstorm (7 min): Each person writes behaviours they consider essential for effective teamwork — one idea per sticky note.
3. Share & cluster (10 min): Go round-robin. Each person reads one sticky at a time. The facilitator clusters similar ideas on a wall or whiteboard.
4. Discuss & refine (15 min): For each cluster, the group crafts a single, concise agreement sentence. Push for specificity: "We start meetings on time" beats "Be punctual".
5. Consent round (5 min): Read the full list aloud. For each agreement ask: "Can everyone live with this?" Modify until consent is reached.
6. Make it visible (3 min): Photograph or digitise the list and post it where the team can see it daily.

Materials needed

• Sticky notes and markers (or a virtual whiteboard such as Miro / Mural)
• A visible wall or digital canvas
• Timer

Pitfalls & common mistakes

• Too many agreements: More than 7–9 rules become unmanageable. Merge or prioritise.
• Vague language: "Respect each other" is hard to act on. Translate values into observable behaviours.
• Set-and-forget: Agreements lose power if never revisited. Schedule a review every 4–6 weeks.
• Loudest voice wins: Use silent brainstorming before discussion to surface quieter perspectives.

Inclusion & accessibility

• Provide sticky notes in advance so non-native speakers can prepare.
• Use a digital board so remote participants contribute equally.
• Read all agreements aloud for participants with visual impairments.
• Allow anonymous submissions if psychological safety is low.

Variations

• Remote-first version: Use a shared document with comment threads; vote asynchronously.
• Retrospective add-on: Derive one new agreement from each retrospective’s biggest pain point.
• Role-specific agreements: Create separate sets for pair programming, code review, or on-call rotation.

When NOT to use this

• When team membership is entirely fluid (e.g., open-source contributors with no recurring core). Agreements need stable membership to stick.
• When organisational policies already dictate the same rules — duplicating them can feel bureaucratic.

Source & further reading

• Lyssa Adkins, *Coaching Agile Teams* (Addison-Wesley, 2010)
• Practice library of agile leadership practices — Working Agreements
• Esther Derby & Diana Larsen, *Agile Retrospectives* (Pragmatic Bookshelf, 2006)