What is a Retrospective?
Retrospective, in a general sense, means looking back on or directed to the past or past events, according to Collins English Dictionary. But, when talking about product development, it refers to a specific meeting that takes place at the end of a project or iteration, with the goal of identifying how to improve process and team cohesion.
The use of the term “retrospective” to describe this meeting is credited to Norm Kerth, the author of the 2001 book Project Retrospectives. This type of session had been done for several years before that book was published, however. Alistair Cockburn described projects dating back to 1993 that involved them in the 1998 book, Surviving Object-oriented Projects.
This practice is known under a variety of names, including “post-mortem,” “debriefing,” and “sprint retrospective.” Cockburn’s “reflection workshop” is less popular, even though it seems to have influenced the practice’s description in the Agile Manifesto.
How is Retrospective Beneficial?
The past should ideally influence our future actions. Failure to learn anything from it means something similar to or worse than that which had occurred could happen in the future. A retrospective can facilitate better iterations. It improves the effectiveness of iterative development. These sessions allow you to assess and improve the performance of teams throughout a project. A retrospective can also promote a sense of responsibility and a common understanding. A thorough examination of the different aspects of a project can enable everyone to see the reasons for certain decisions.
Retrospective Meetings in Agile
In companies using Agile methodologies, the focus is usually on shipping quick releases and iterating. The benefits of this are well-known. However, the speed at which things are done may not allow enough time to review what has been done. That’s why this session is important, to set aside time for these important discussions, and to allow the team to iteratively improve their own process, not just the product they’re iteratively building.
It is helpful to do some preparation in advance. Get a whiteboard ready. You may also want to bring in a neutral party to facilitate the retrospective. Participants may hold back useful opinions if the facilitator is a manager or someone high up in the company hierarchy. Parties that directly participated in the project should all be represented. The retro meeting needs to be a ‘safe space’ so participants feel they can speak freely, to encourage and open and fruitful discussion.
An examination of both the failures and successes can enable an Agile team to do better in successive iterations. There should an attempt to understand why things happened the way they did. This will enable you to know what you can do to replicate successes and avoid flaws in your future work.
Ideal Frequency of Retrospectives
You should aim to have a retrospective session as soon as possible at the end of a project or iteration. Experts advise that you should have one in no later than one week after shipping a release. This guards against the possible danger of forgetting what was learned when you took your time before having the meeting.
Retrospectives should be a regular part of process, and conducted at the end of every product or featre release; not just when things didn’t turn out as expected. Frequent retrospectives may make team members more likely to be honest with their feedback.
