Almost every process or best practice in software development advocates the use of a post mortem or a retrospective to take a look back at how things went. It’s a valuable tool to use, discussing what went well, what did not and how could things improve for the future.
It’s a tool that we should use more during the requirements elicitation process. So often, retrospectives (I prefer this term over “post-mortems”, since it sounds much more positive), are only done at the end of a project, or perhaps at the end of a sprint if you are following an agile process properly. Rarely is a retrospective done at the end of a requirements phase. Why not?
As product managers or business analysts, a lot can be learned from doing retrospectives once we have finished eliciting the majority of the requirements for a project. We can review what seemed to work well. Why did it work well? Were there characteristics of group that you work working with that helped things go well? And while it is always easy to look at what went wrong, looking at what went right is equally important. I always prefer to start off on a positive note; after all, something had to have gone right!
Looking at what did not go so well, is always the easier part of the retrospective process, but it is difficult to analyze what did not go well and really understand why it did not go well. An attempt needs to be made to get to the root cause, why did a model or activity not go well. Was it the particular model? The wrong model for the particular group? Be sure to explore all options.
One of the most difficult things to do with the information collected during the retrospective is to make improvements. Asking the team what should change for next time is important. Ensuring those changes get implemented is even more important. It’s far too easy to talk about what should be done, much more difficult to put those into action. One suggestion is to assign owners for each action item. Make someone responsible for implementing the change, or at least working on the next step of that change. Set a due date for each action as well. Be sure to include how the team will follow up…in what way will the owners of the action items communicate to the team their progress?
Then…implement! Take the ideas and suggestions and put them into practice. Follow up as agreed. Be sure to do another retrospective after your next requirements phase. Look at the items you implemented…how did they work? Better? Worse? What needs to be tweaked? And go through the same questions as before: what went well? What did not? What needs to change for next time?
A continuous improving process is the goal, and retrospectives most certainly help you improve. Do them!
