Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called “post mortem” analysis (so the RIP reference is not far) or “retrospective” in the agile approach. If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in the last Agile survey published by Version One, where a large majority of respondents are using an agile approach, only 39% of the participants are using this practice. Why?
The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project’s completion to think about what went wrong. Are you not supposed to do things right in the first time?
Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some “post mortem” reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not…
There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:
* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)
* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)
* Plan of Action by Bas Vodde (HTML)
* Project “Post Mortem” Review Questions by Michael Greer (HTML)
* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)
* Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen and Ken Schwaber (Book)