Lean Software Engineering

JD Meier has written a nice post on the value of capturing “lessons learned”. In the projects I’ve been on, having an open, honest, and well-run lessons learned session (aka retrospective or postmortem) at regular intervals during the project has been one of the most valuable uses of the team’s time, but also a big source of missed opportunities.

Four top barriers to successful lessons learned:

1. We don’t look back until the very end of the project.
2. We don’t set a tone of open and honest feedback.
3. We don’t look at the whole picture of product and process.
4. We don’t actually follow through on the feedback.

Nothing is more important than this kind of feedback from your team. So how can improve our approach?

• Don’t rush the project so that there’s no time for ongoing improvement or reflection. The projects that end most disastrously are those where everyone is sucking wind so much that there’s no air left in the room for calm and honest reflection and discussion of what’s going well, what’s going poorly, and how we can improve.
• Make reflection part of the cadence of your project. Whether it’s with a methodology like Scrum (which encourages daily small-scale reflection and monthly large-scale reflection), or scheduled feedback sessions called Kaizen Events which encourage analysis of the “big picture” of your processes, or systematic continuous feedback (a Kaizen culture — the Toyota way). Whatever cadence you choose, keep it up. When the project needs honest feedback the most, is when people will be most tempted to sacrifice the time spent on improvement or just keep their mouths shut to not put themselves at risk. I was on several projects where we went a year or more between opportunities for large-scale feedback (and these are projects that did not go as well as the could have). That timescale is simply far too long!
• Anticipate the barriers to honest feedback, and remove them. Structure the feedback so everyone has their turn. Sometimes intra-team conflict means it’s best to get a 3rd party facilitator for the retrospective. Sometimes a level-headed team member should start the feedback with a balanced analysis to start the discussion. Sometimes it’s essential to give an opportunity for anonymous feedback (a suggestion box) that will be read through at the meeting. With all these tips and others — keep in mind that if you fear the feedback process, it will become a self-fulfilling prophecy. Err on the side of being as relaxed about the process as the team will allow.
• Put the “lessons learned” front-and-center. Far too often great feedback is collected and good decisions are made to improve — but then the natural inertia of the team causes it all to be forgotten once the project gets busy again. Don’t let your “lessons learned” be forgotten. Capture your processes, and note lessons learned beside them. Email out your lessons learned. Put them on the team’s web page or wiki. Encourage management to refer back to them. Lessons learned do have a half-life — as the nature of your team and project change, older lessons learned may no longer be relevant. And they’re not always relevant across teams. But by encouraging focus on recent lessons and making available the older ones, you build a stronger corporate memory for reacting to the problems that may be common on your project — and what solutions worked well or didn’t.

What are your “lessons learned” about retrospection? What opportunities to do better were missed here?