3 tips for debriefs on your team

RAF Pilot Walking Away from Hawk Aircraft in Silhouette

My sister’s partner, Adam, recently shared the original Top Gun article that inspired the movie with me. It reminded me of my father. My father was a RIO in the F-14 in the seventies and eighties, and later taught at Top Gun. He passed a few years ago. I think about his life, his service to his country, and what, if anything, I can apply to my life. Despite being around him, visiting his office, going on “tiger cruises”, he didn’t talk much about how he went about his work.

The article mentions the debrief after the “bad hop”. I coach teams and leaders to build better software, and, I’m always on the lookout to borrow (OK, steal) metaphors that can give us more of an edge. Project, sprint, iteration retrospectives are often the highest leverage catalysts for change. However, I wondered if I could take some lessons from a pilot’s debriefing for this.

A 2015 HBR article by Doug Sundheim lays out the simple format of these reviews. https://hbr.org/2015/07/debriefing-a-simple-tool-to-help-your-team-tackle-tough-problems

There are four key questions:
1. What were we trying to accomplish? Start by restating the objectives you were trying to hit.
2. Where did we hit (or miss) our objectives? Review your results, and ensure the group is aligned.
3. What caused our results? This should go deeper than obvious, first-level answers.
4. What should we start, stop, or continue doing? Given the root causes uncovered, what should we do next, now that we know what we know?
[1]

The three things that really help me with these are:

1. Start with Objectives

The key part of this that is different from how I usually run sprint, kaizen, project retrospectives is starting with the objectives over starting with question 4. In Scrum, we start with the “sprint goal” so this is built in. If using a flow based model, the objective is something you need to be explicit about adding into your system. OKR’s can work, or a milestone, or an operations review. The key bit is starting with what you ALREADY agreed was the goal so that things don’t drift off into discussions on the meaning of life.

I’ve seen this often where we argue about what to change, and it’s only until we bubble up one level to discuss what we’re trying to achieve, that we realize where the alignment problem is. Is it Predictability or Innovation we’re after? If you don’t know, you’re not likely to solve it at the “Keep, Stop, Continue” level. If we can start from common objectives, we have greater chance of finding tactics to achieve.

2. Make it routine

The current program I’m leading, we stopped the cadence of the overall (cross team) retrospective. We experimented with doing them after standup, when there was time. Individual teams do it after planning, usually. However, we never ended up doing them. Now that we’re operating in a flow based model using a Kanban system, we identify tickets (features) that are challenged. The question is when to set aside time for debrief.

For pilots, briefing occurs 90 minutes before a flight. Debrief within 30 minutes after. Using the analogy of a post flight debrief, we could set a rule that whenever a feature is moved from “to verify” to “done”, we schedule a retrospective within one day. Or after the feature is live with data, we review.

On the other hand, as Don Reinertsen says, cadence helps lower transaction cost [2] making small batches economically feasible. So, if we schedule each debrief on demand, the cost of getting everyone aligned is higher.

So, now we are experimenting with retrospectives on a biweekly cadence with debriefs and post-mortems on demand. Stories are queued up for discussion, in advance (flowing off our kanban board to another board where we will have improvement meetings). I’m looking forward to what we learn from this. I expect we’ll have better attendance, however I also worry we won’t talk about the “good hops” that happened and why.

3 Make it safe

In the Sundheim article, he explains how the Army teaches you to “leave your stripes at the door”. Bourke in a similar article discusses how fighter pilots will leave off their name tags and rank insignia during debriefs. Why all this attention on safety? Not only is it good for morale, it’s essential to create a learning environment. In an environment where you are fighting for self preservation for your ideas, hide mistakes, and point the finger on blame, you won’t learn. Your lizard brain will take over. As the two year project Aristotle showed at Google, creating psychological safety also correlates strongly with the highest performing teams at Google.

So, in the valley where your boss is already wearing flip flops to work? One thing I do is to borrow a trick from Henrik Kniberg from Lean from the Trenches. He moved his retrospectives to a room where there were only chairs and a whiteboard, no conference room table. [4] It’s strange but it seems to help reduce the finger pointing. The second thing I do is to remind people at the beginning of the meeting that it’s about the process, not the people.

If the folks are new to this, an explicit exercise might be in order. I’ve run secret straw polls ala Ester Derby and discussed Norm Kerth’s Retrospective Prime Directive in pairs. You need to be aware of how much safety is in the room, how much power distance exists and adjust your approach accordingly.

So how do you do debriefs?

[1] https://hbr.org/tip/2015/10/the-4-questions-to-ask-when-you-debrief-on-a-project

[2] Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 10). Celeritas Publishing. Kindle Edition.
[3]By DefenseImages, CC 2.0 on Flickr.[4]Henrik Kniberg. Lean from the Trenches (Edward Kraay) (Kindle Locations 747-748). The Pragmatic Bookshelf (358158).

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply