Designing team culture: How good retros create amazing teams

In an agile software development team, the number one predictor of success is good communication. But culture is a slippery thing. How do you create a culture of open communication, fast feedback and shared ownership?

One tool to do so is ritual and routine, and good retros are invaluable to that. When it comes to normalising the sharing of feelings and helping a team own their process, structure is key.

In this talk you’ll hear advice on how to run effective retros from some of the most experienced facilitators from around the world. You’ll hear how we used opinionated design to create Postfacto, a tool for running effective retros.

And you’ll learn how to run quick and fun retros every week to help your team be better, happier, and more productive, together.

Every couple of months Nicola works with a new set of clients – new people, with new ways of working together. They created PostFacto – a tool for running remote retros. It is now used by around 2000 teams worldwide.

A show of hands shows most people are doing retros… but most have been in one that felt like a waste of time.

Nicola remembers her first retro, after a tough full-day scoping workshop. The clients were arguing amongst themselves, there was one person who clearly wanted to derail the project, a key person kept dropping out to take phone calls. After this day-long workshop from hell, someone said “wow…retro?”

They wrote up the usual went well, went wrong and do differently. The group was able to use this technique to figure out how to improve as a group, without blame or worry. It was a little weird to talk about your feelings at work… but it’s also nice to work with a team that can be open with each other.

The teams that communicate openly are the great teams.

There are lots of variations on the retro. postfacto.io is an opinionated version, with “happy”, “wondering” and “sad” columns. The labels may vary but that’s their purpose.

The key in the end is to do this regularly, but ensure there are actions. Things actually need to change as a result of a retro.

It’s based on research digging into both good and bad retros – lots of 1:1 interviews, observation and dogfooding the product. This showed a common set of pitfalls:

  1. The painful, awful retro. Often solved by having them more often (counter-intuitive, but works). Think of retros as scheduled maintenance for your team. Also set expectations, note the prime directive. Beware voting or skipping items – they had a ‘cheese’ item that looked like an easy-to-skip thing. But when they asked ‘who wrote this one?’, it ultimately showed their habitual retro snack of cheese was making a lactose intolerant team member feel a bit ignored.
  2. People not really sharing the truth. It’s a serious problem when people don’t feel safe to share. things that can help: just invite the direct team; actively work to establish a feeling of safety (be vulnerable, or be the one willing to point out an elephant in the room).
  3. The room is dominated by one or two voices. This needs a strong facilitator, who ensures everyone is heard. Watch for someone who has been talked over or interrupted, particularly if they have since shut down.
  4. Same old problems over and over again. It helps to focus on the action items. Don’t repeatedly discuss a problem without trying solutions. If there are lots of options, do a time-boxed trial. Make sure the items are actually actionable, make sure they are owned by someone specific.

Last tips:

  1. Do retros weekly, don’t skip
  2. Make it a safe space
  3. Have a facilitator
  4. Focus on action items
  5. Be kind