In aviation, especially flight training, it is important to debrief after a flight is complete. The debriefing is an opportunity to talk about the things that went wrong and ways to make the next flight go more smoothly. When I am teaching people to fly, I often notice mistakes or think of advice that the student should hear. Sometimes the situation is too busy for me to talk about it, so I make a note and talk it over during the debriefing. Think of the debriefing as an opportunity to solidify the learning that took place during the actual flight.
Like aviation, there is always something to learn when writing software. During the development of a feature, it is important to be focused on the code and not on the lessons to be learned.
What is a debriefing?
A debriefing is a chance to relive the development process and soak in any lessons to be learned along the way. Ask yourself some of the following questions:
-
o
- Did the feature work the way I originally thought it would?
- Did I finish the feature within the timeframe that I estimated? If not, why not?
- Was the code written in an elegant and maintainable way? How could it be improved next time?
- Was there a better way to build this feature?
- Were there any outside pressures on me during the build? How did I handle them?
- Did my software process go smoothly? Is there any way I can improve it?
o
o
o
o
o
If you have an idea for a thoughtful debriefing question, put it in the comments and I will add it to this list.
Some debriefing rules
The debriefing is reserved until after the flight. It should not be done until the code is released and the feature is running smoothly. It is not part of the testing process or even part of the release process. Just like in aviation, you need to do it after all of the excitement and stress is over. However, don’t wait too long to debrief. Everything that happened during development must be fresh in your mind, so think of it as your first task after the feature is complete.
A debriefing doesn’t need to take long. Depending on the size of the feature, a normal debriefing might be 5 – 10 minutes. If you work in a team, expect it to take longer. If the feature is a large project it is worth taking the time to really dig into how it all went.
If you work on a team you should debrief together, but you should also debrief by yourself. In a team environment, ask the above questions of the team as a whole. Before you meet to debrief you should take a minute to debrief yourself personally as well. There are often lessons for you to learn personally that don’t apply to the team as a whole. The opposite is also true.
A debriefing is typically not formal. The flight school that I work for uses a great curriculum so we have a list of goals and standards for every flight, and this helps to guide the debriefing. I personally do not consider it part of the debriefing, but rather it is more like the specification for a software project. At the end we are looking over the specification to decide if we did everything to the standard or if we need to redo this flight and revisit some of the material. The actual debriefing may include topics from the specification, but it should generally be loosely structured. If your debriefing is too formal and you are filling out paperwork, I would argue that you are not benefiting from it. Try to stick to a simple question-and-answer format or something similar.
Every team is different and every developer is unique so these rules are flexible and should be tuned for maximum effectiveness.