Social Contracts and the Agile Team – Part 2

In part 1, we discussed how a new team could help lay out the foundation of a social contract between itself and the larger organization.  While that works at the macro level, what about the micro, day-to-day interactions within a team?  The focus on a social contract can be a powerful tool in helping a team to perform at its peak.  At its core, this commitment between team members strengthens trust, set expectations, and lets the team push beyond a previously understood comfort level.  Both sides of an interaction must be dedicated to fulfilling their part of the equation.

What are some way this could look like on a day to day basis?

Take the simple act of a code review.  At a surface level, the developer running the review would go over a high level overview of the card being worked.  They would walk through the basic coding that was done, and do a brief demo of the new functionality.  The reviewer nods along, perhaps pointing out an item or two regarding coding standards, and moves along without a deeper probing of the work done.  In a scenario with a strong social contract defined, this would be seen as falling well short of what is expected of both team members.  The developer running the review would do a fuller explanation of the goal of the card, and tie it into the larger picture of the application or the organization’s goals.  The reviewer would ask more intensive questions, including, for example, how test-driven development concepts were used to work the card.  The demo of the new functionality would not only show the happy path, but push at the edge cases that were considered.  The reviewer would prod on the design and maintainability of the code.  The goal of the exercise would be understood to not just check a box, but to provide value to each member of the team, and to the overall team itself.  There would be increased confidence in the quality of the code and the product.  There would be increased knowledge-sharing amongst the team leading to less stove piping of expertise.  Lastly, team members would be building trust between each other so that they could feel more comfortable communicating questions or out-of-the-box ideas.

The same idea can be applied to team-wide activities.  Does your team do a daily stand-up and regular retrospectives?  This is an area where muscle memory can set in, and team members can start to just go with the flow.  If they follow the concepts of the social contract, team members know that they are responsible to make sure the team is generating value from these.  Put down the phone during the meeting.  Make eye contact when addressing the team.  Commit to putting into action the steps generated to make the team work better.

The big picture with the social contract is to ensure team members are fully engaging in the tasks of the team.  Confidence and respect, a sense of responsibility to each other and the larger team builds organically over time.  Only then can teams truly hit the “perform” staging of “Form-Storm-Norm-Perform”, and deliver the full value to the organization and its customers.

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:

• The Team promises to place value through deliverable software as the highest goal to the organization, as defined by the Product Owner
• The Team promises to raise any obstacles preventing them from delivering value immediately
• The Organization promises to address and remove obstacles in a timely manner to the best of their ability
• The Organization promises to maintain reasonable stability of the team so that it has the opportunity to mature and reach its highest potential

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.