Retrospectives and Post-Mortems
A high-performing team has to be a learning team. In a learning team, not only is the team performing as a unit, but they are also working together to become better every day. They question each new status quo and make hypotheses about how they can be more effective. I believe in this type of team the stages look more like this.
A learning team (or maybe I should call it a Lean team, as it closely resembles the continuous improvement of Lean Manufacturing and the learning cycle of Lean Startup) shares a commitment to progress. Knowledge is shared out as soon as it’s acquired, and the team is continually developing new hypotheses to be tested.
There are two key rituals I’d like to call out, both from Agile15, that support learning. One is the Post-Mortem and the other is the Retrospective. There is a LOT written on the internets about both, so I’ll keep this section short.
The Retrospective happens every week. The team quickly notes what worked last week and what sort of things they’d like to try next week. Different teams use a lot of formats. I’m a fan of two columns: keeps and changes.
The keeps + and changes Δ columns used on retrospective.
It’s good to go with an approach that matches your team culture. Personally, I prefer the very simple one, because I think it’s more important to do regular, small, fast check-ins than make a production out of it. If every week you just improve one to three things, that adds up very quickly to a great team. A lightweight ritual is less likely to be skipped because you are low on time. It can take just ten minutes, tacked on the end of another meeting.
The team’s leader can make a big difference in how willing the team is to admit mistakes and learn from them. From Edmondson, The Fearless Organization
“To create psychological safety, team leaders also can demonstrate tolerance of failure, such as by acknowledging one’s own fallibility, taking interpersonal risks, and religiously avoiding punishing others for well-intentioned risks that backfire. Self-disclosure by team leaders is one way to do this (Gabarro, 1987).
For example, one surgeon team leader repeatedly told his team: “I need to hear from you because I’m likely to miss things.”
“The repetition of this phrase was as important as its meaning: People tend not to hear or not to believe a message that contradicts old norms when they hear it only once. Soliciting feedback suggests to others that their opinion is respected; it may also contribute to establishing a norm of active participation.”
In early retrospectives, expect to go first, admitting a mistake of your own. You can also “seed” the retrospective by keeping an ear to the ground for good items for reflection, and say things like, “You folks really figured it out. I hope you’ll mention it Friday at retro so others can learn from it.” Or “You really struggled with that. Would you mind bringing it up Friday so we can figure out how it doesn’t happen again?” But nothing beats being willing to go first.
Your reception to mistakes will make a huge difference to the team’s psychological safety. Treat them as failed experiments that reveal new potential solutions. You don’t have to condone incompetence, but a well-intentioned, well-researched, well-executed failure that did nothing wrong but be unable to predict the future? If you punish good people doing their best for not succeeding, you’ll soon have a group that doesn’t want to take any risks.
The motto of product-design firm IDEO is, “Fail often, so you’ll succeed sooner.” Innovation is hard, and if you really want it you’ll have to make a safe place for risk taking.
Post-mortems are more formal retrospectives held at the end of a project. They don’t fit the set-check-correct model as closely, as they can be held anywhere in the quarterly cycle.
A learning team creates a rhythm of introspection and evaluation. Some do it at the end of each project, some will make a simple “keeps” and “changes” tally each week. What matters is the learning cycle. (I recommend both, by the way.)
15 Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It has a number of best practices (rituals) for delivering software iteratively, and both my OKR and team methodologies borrow from the practices I’ve seen succeed.