Login / Registre-se Account

In my job as a Consulting Architect working with Red Hat’s Open Innovation Labs, I am in a very fortunate position where I get to help kick start new product teams. We use a range of open practices to help bootstrap these teams and get them off to the best start. One practice, in particular, I’ve come to realise is foundational for getting the team off to a great start: Social Contracts

A Social Contract is not some big consulting engagement, but it is rather a simple set of rules and behaviors put forward by a team for how they would like to interact with one another. It promotes autonomy and self-governance within a team.

 

An example Social Contract from recent work with a geospatial company.

 

Do I need one? If so, how do I build one?

In modern software development, we’re all about tearing down walls. The wall between Development and Operations was only the beginning! Open organisations want their teams to act with more autonomy, so we need to give them a shared purpose around their products.

 

Often teams react to this by trying to embody the “You build it, you own it, you run it” mantra. How can we kick start this change in people’s behaviour? How can we accelerate our teams to be high performing? Especially when starting with a new team who knows nothing about each other… This is where our friendly Social Contract comes into play.

 

When I am kicking off work with a new team, I first get them to come up with a name. Team identity is fundamental in setting up the ownership part of a high performing team’s culture. The next step is simple: get the group to spend a few minutes thinking about the best teams they’ve worked with previously or the best products they’ve been a part of creating. With this in mind, think of all the amazing characteristics and behaviours of these working groups and capture them on sticky notes. Conversely, think of all the terrible projects and what things created the toxic environment the team operated in. With some ideas of behaviours we want to adhere to, the group will discuss these further to get a shared understanding and hone in on the specific language to use.

 

A good social contract will contain concrete, actionable items and not fluffy statements. To tease these out, lead by giving examples of how someone would embody the statements they’ve come up with, and try to capture that. For example, “be open” could be a good seed for an item in a social contract, but I think it lacks specificity. I would explore this more by getting examples of where we are, or are not, adhering to it. Teams may then come up with ideas like “Everyone’s opinion and contribution is valuable,” “Give space to the quiet person,” and “Actively listen to others the same way you want to be heard.” With some items in the contract, the group signs the contract and hangs it high and visible. It is now the responsibility of the team to abide by it and call out when others do not.

An example Social Contract from a recent engagement with a cybersecurity company.

 

The example above is from a cybersecurity firm I worked with recently. Their team had a mix of Developers, Designers, and SREs. Some of the things they included in their Social Contract were:

 

Core Hours (10.00 to 16.00) - This is the team’s agreed collaboration time. This is not the hours that teams spend working, but the time in which they will have sync ups, meetings, or do pairings. In this engagement, one of the team members wanted to miss the early morning traffic, so if he came in a tiny bit later it would take him a lot less time to commute. Also, another member of the team had child care responsibilities so getting out at a reasonable hour would make his life easier.

 

Mob to Learn  / Pair to Build  - This is a simple mantra that describes how the team wanted to interact when writing code, tests, or even documentation. If there were new things to be tackled, such as a scary new microservice in a language or framework that’s unfamiliar, then do it as a full team. Get everyone on the same page from the beginning and ensure we’re not creating individual heroes with all the knowledge in the team. Pair up on implementing features to raise the skill set across the board. You can read more about pairing and mobbing in a previous blog I wrote here.

 

Have a Weekly Social - Celebrating success is an important event for lots of teams. Taking the time as a group to get away from our desks, socialise together, and eat together, helps build positive relationships. These events can lead to improving team morale and creating a positive culture around the people working on the product.

 

Blending the practice with other ones

 

Sailboat retrospective used by a previous team.

 

The Social Contract, when it is first created, represents a snapshot in time. It showcases a best guess of how a team should interact, often when we know the least about each other or our habits. It is a useful tool to accelerate a team to a comfortable position built on trust and psychological safety. It is not, however, a fixed or static thing! Items could be invalid or possibly missing. A great thing for a scrum master or agile coach to do would be to bring the social contract to the team’s Retrospective. This provides an opportunity for the group to inspect and adapt, possibly updating the contract with new things.

 

When working with the cybersecurity company from the example above, we found a great opportunity to update our social contract. In this scenario, there were two developers on that team that were quite hot-headed, and both liked to be right. Often they could not agree on the approach to take for any given solution, which had created a toxic environment within the team, and reduced morale. Through a retrospective, the team identified this issue. After some discussion, and getting the issue out into the open, we updated our social contract with one simple phrase: “It’s OK to be wrong.”

 

This change had a profound effect on the team going forward. The competition within the team had started to evaporate as we could focus less on “who was right”, and more on “does the solution work for our end users.” We looked for opportunities for both developers to have their voices heard by trying more than one implementation of a feature, building both solutions, and evaluating each. The two developers then started to pair on building out each other’s solution, thus creating a better bond between themselves and others. This had a net benefit of creating a better solution by combining and building upon ideas from both individuals.

 

Social contracts are powerful and easy to implement as a practice - they promote team autonomy, self-governance, and psychological safety. If your teams are not using them, it’s not too late to build one. Most importantly, keep it visible on the wall by the team, and don’t forget to revisit it when needed.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn


About the author

Em destaque

Notícia do seu interesse em destaque

Próximo evento

Webinar relacionado