What exactly is a retrospective? Following the definition on Wikipedia – it generally means taking a look back at the events that have already taken place. At this point you will probably ask yourself – why do developers have to recollect situations from the past?
Broadly speaking, the aim of a retrospective is “to take a small step back, to then take a big step forward”. What does it mean? During the retrospective you should consider both types of situations – the negative that caused some problems and the positive that we are proud of and satisfied with enough to aim to replicate such results in the future. Each of the reported issues should be discussed in detail during a retrospective.
Each retrospective is finished by drawing common conclusions, which should be written down. It will allow us to refer to them in the future in order to check whether we follow rules as previously decided.
Some time ago I decided to organize a technical retrospective to celebrate the completion of our project. You can read an extensive case study of this project on our blog.
Since I organized this retrospective, I was leading it. During the meeting, I focused mainly on the methods we used to build our application, including adopted rules, libraries, technologies and external services which caused us some trouble.
Each topic we brought up during the meeting formed grounds for an interesting, substantial discussion and everyone was free to contribute. To sum up each part of the conversation, we formed a conclusion and it helped us to formulate a specific goal for our next projects.
I believe each developer team should make a technical retrospective after their project is published. An hour or two spent on talking about the finished project is a time well invested. Your conclusions can help other teams to avoid the problems you have encountered.