What does flying helicopters have to do with running an engineering team?

I may not be a Scrum Master, but as the leader of an engineering team, I know nothing is more important for the success of my team than an effective debriefing process. Today, I use sprint retrospective meetings to get the job done. But when I first realized how important it was to give the team an opportunity to face their mistakes, address challenges, and improve, I was a flight cadet in the Israeli Air Force. 

I didn’t immediately fall in love with the idea of having debriefings after exercises. As a cadet it was hard for me to understand why we were spending less time flying than we were on the ground talking about our work. A number of years went by and I graduated from being a cadet, became a helicopter pilot, and eventually became a flight instructor in flight academy. During all those years, debriefings were part of my daily routine, and I did 2-3 of them every single day. 

As a flight instructor, I realized my cadets had the same reservations about debriefings that I once had. At that point however, the importance and value of these meetings had become crystal clear to me. So, I started to educate the next generation about how to run effective debriefings, how to address mistakes honestly, and how to optimize their performance. 

This is exactly what Engineering Leaders need to do with their development teams, and that prior experience before was instrumental in helping me establish similar debriefing processes in my current position. Like I said before, now we call them sprint retrospectives and sprint reviews, but below I’ve listed a number of reason why I think these retrospective meetings are almost identical to debriefings for helicopter pilots, and why both of these practices are so incredibly important. 

‍

Cost Effectiveness

Flight time is expensive, like very expensive. Every minute spent flying trying to get better costs us so much, that getting to the bottom of what happened, why it happened and how we can improve next time while debriefing on the ground is both cost-saving, and critical. Well guess what – engineering time is also super expensive. If we waste our coding time making the same mistakes over and over again, the team is doomed to fail. Retrospectives are an amazing opportunity to save that time, get to the bottom of what happened, and see how we can improve.

Incremental improvements

One of the guidelines in every flight debriefing is that you can only choose one thing to improve or change at a time. It is very tempting to “jump” on 3 different issues and solve them all at once, but in most cases we won’t be able to solve any of them. You can call it a cognitive limitation, a concurrency impact, whatever,  it’s been proven that it doesn’t work over and over again. Engineering is a complex thing as well, and while there are so many things we can do better, trying to do them all at once is a surefire way to fail. Picking one thing to handle at a time is the key to a successful process of continuous improvement. Talk about everything, deep dive into a few issues, and then pick one and kill it. Make it a “no matter what we don’t want to talk about this one again” type of issue, and only when that’s done should you move on to the next one. 

What-Why-How

For every incident or issue we debrief, we must define a way to improve it or fix it. It is very easy (and natural) to stay at the “what”, it is one of the most common mistakes new cadets make - tell you the story of what happened - “I tried to do a loop and in the middle we went out of balance and the result was a broken loop.” Ok, but, why did this happen? How can you improve it next time? This is one of the reasons we use the what-why-how technique. This way, every issue we describe must be carefully defined not only by what happened, but also by why it happened, and how we improve next time. Lets try this again - what happened? I could not complete the loop. Why did this happen? Because my eyes got stuck on the speedometer instead of moving my sight continuously through the balance of the wings, speedometer and altitude. How are we going to improve it next time? I’m going to force myself to say out loud what I am looking at, which will remind me to check all the required parameters.

This technique informs almost everything flight cadets too, and also plays a huge part in development team retrospectives.

Use Data

One way to debrief is to rely on our memories and subjective feelings, don’t get me wrong here, subjective opinion is super important as well, but keeping the whole debrief there will necessarily cause us to miss many important points and insights. In flight debriefing we use flight recordings, and go back to the drills and points to look at them again, this is gold, I can’t think of one time that looking at the actual flight data didn’t help us to get to the root cause of what happened. Retrospectives are no different, sitting in a room and concluding a meeting without checking what the data looks like is a great way to miss the most important points, and of course data can also help us avoid the common arguments we use to see when opinions are on the table.

The 5 Whys

Sometimes just asking “Why” an issue happened is not sufficient. If similar issues continue to pop up, perhaps you need to ask the question a few more times. In a complex environment like flight, or engineering, then a very good way to get to the bottom of the issue is to ask “Why” 5 times, going further into the problem each time. Let’s try an example: 

What happened? We didn’t meet the sprint goal.

1. Why #1? Because we had 13 unplanned issues we had to complete.
2. Why #2? Because we had to add more frontend and API tasks that were not planned at the beginning of the sprint.
3. Why #3? Because the product requirements changed 2 days before the sprint started and the technical design was already completed and didn’t take into account some of the changes.
4. Why #4? Because after the tech design was updated (according to the new requirements), it was not reviewed.
5. Why #5? Because we don’t have a process in place to run a review on the tech design for every update.

As you can see, without asking these sprint retrospective questions, the team may miss their next sprint goal as well thanks to another issue with tech design review. After this meeting, the team can think about how to implement a standard procedure that will stop this from happening in the future. 

Talking about your mistakes isn’t natural for anyone. You may worry that it will present you in a bad light in front of teammates, or put a spotlight on work you’re not so proud of. But, without honestly looking in the mirror and facing those mistakes, our abilities to improve– as individuals, and as a team– are greatly diminished. 

Scrum Masters, team leaders and product managers need to establish effective communication with their teams, and practices for retrospectives that will foster growth. Discussing the previous sprint should not be a source of frustration or pain, but an eye-opening opportunity for teammates to learn from each other, how the next sprint can go even more smoothly, easily, productively and fun than the previous. 

This was a lesson I learned over years of experience as a helicopter pilot, and now, I’d like to think my engineering team is benefitting from it as well.