Repository navigation
Team Norms
New teams often go through the phases of "forming", "storming" and "norming" before hopefully reaching "performing". One of the problems that can come up, is that individual team members have private expectations of how they expect software should be developed, and how others should behave. When people fail to live up those expectations, tension, conflict and worst of all contempt can arise.
We can avoid this by making those expectations public, and reaching agreement on them in a "Team Norms" or "Ways Of Working" meeting. It is common for norms might state:
- How "done" is defined
- Quality assurance measures (e.g. automated testing, refactoring, pairing)
- The format for specific meetings (planning, stand-ups, retrospectives)
- How to respond to bugs
- How to respond to build failures
- How to manage technical debt
- How to communicate respectfully
- Release protocol
Norms are also best when they are "punchy", e.g.
- We don't track bugs, we fix 'em
- Don't step over poo
- Come prepared, come on-time
Like retrospectives, it is better to have a neutral facilitator chair the meeting. To do otherwise encourages the facilitator having too influential a voice, or being conscious of this and self-censoring.
Prior to holding a team norms meeting, the purpose of the meeting should be explained, and participants given time to prepare suggested norms. Expectations should be set that not all norms will be agreed by the group, and to avoid bikeshedding a time limit should be set to discussing individual items.
It can also be useful to suggest consensus mechanisms, e.g.
Steve: I propose the "....." norm
Peter: I second the norm
Gail: I object since "......". Instead I propose "......"
Chair: All those in favour say Aye
Peter: Aye
Gail: Aye
Chair: All those against say No
Steve: No
Chair: The Ayes have it
If there is a significant dispute, it can help resolve conflict by trialling one of the options for a period of time. At the end of the period, the team should review, and there is still a dispute, trial an alternative. The team norms do not have to be perfect first time around, and should evolve over time.