It’s a scenario we’ve all been a part of before. To shake things up, your Agile teams are being restructured. After the initial shuffle, the team gets together for a first meeting to figure out how it is going to work. Introductions are made, experiences are shared. Maybe a team lead is named. It’s a heady time full of expectations. Following the cycle of Forming-Storming-Norming-Performing, phase one is off to a good start.
At the first team retro, a better understanding of what everyone brings to the team starts to take shape. Relationships and communications within the team, as well as other players within the organization, take root. The team also starts to get a sense of where there are some gaps. Maybe it’s a misunderstanding of how code reviews work, or how cards are pointed. Storming has happened, and the team is ready to begin the transition to the Norming phase.
I’d suggest that team norms, which tend to be prescriptive in nature, falls short of what the stakeholders are hoping it will. Instead, I’d suggest that a social contract is a better concept to work towards.
A social contract is a team-designed agreement for an aspirational set of values, behaviors and social norms. They not only set expectations but responsibilities. Instead of being focused on how individual team members should approach the work of the team and organization, it lays out the responsibilities of the team members to each other. It also lays out the responsibilities and expectations between the team and the organization.
What would this type of contract look like? It should call out both sides of a relationship. An example of part of a social contract may look like this:
In the spirit of the social contract, this should be discussed and brainstormed with open minds and constructive dialog with both sides of the social equation. In truly Agile fashion, it should also be considered an iterative process, and reviewed from time to time to ensure the social contract itself is providing value.