In 30 seconds
- Short, specific rules the team sets for itself.
- Cover meetings, communication, code review, availability.
- Reviewed and updated in retrospectives.
Examples
- Core hours for collaboration: 10:00 to 16:00
- Code reviews within one working day
- Cameras on for planning and retrospectives
- No meetings on Wednesday afternoons
- A failing build is fixed before new work starts
Creating them
- Ask: what helps us work well together? What gets in the way?
- Turn the themes into short, specific statements.
- Agree each one; anyone can object.
- Post them where the team works.
Keeping them useful
Check them in retrospectives: drop ones nobody follows, add ones the team needs. They often form part of a team charter.
Myth vs reality
Myth · Working agreements are rules imposed by management.
Reality · The team creates and owns them.
Myth · More agreements are better.
Reality · A handful of meaningful ones beats a long list.
Myth · They're permanent.
Reality · They should evolve with the team.
FAQ
Who enforces working agreements?
The team, by gently reminding each other.
How many should we have?
Usually five to ten.
Do new members get a say?
Yes; revisit agreements when the team changes.