Skip to content 
Retrospectives, also known as post mortems or project histories are commonly performed after the conclusion of a release. Typically, they involve a subset of the team with a project manager or process manager facilitating a gripe session.
These meetings start with a token effort to brainstorm what went well (to placate the team members) and then finish with a longer session where the losses are written on a flip chart. In the more enlightened companies, there is an effort to suggest some solutions to the bigger losses not to be repeated again (ever). Again, in the more forward thinking companies, these flip charts are written up in Microsoft Word document and sent to the team with a cc to some managers.
The team members & managers get the email and either file them or delete them. And life goes on. Does this sound typical? Retrospectives performed at this level are less beneficial than a celebration dinner. Setting aside the cost, a celebration dinner would have made a bigger impact as a way to both praise efforts and provide a needed catharsis. So why not just have a celebration dinner, and skip the retrospective? I’d recommend doing that unless you construct a way to get lasting value and make a difference in the next development effort.
In the example in the first paragraph, there were no facts collected, nor data for that matter let alone any quantified information. The output was not widely communicated outside the team member, and follow up actions were not completed.
There is a better way.
Why you shouldn’t do Retrospective?
First, preparation is key for a winning retrospective. The most important goal in most programs is time to market, a winning feature set, and quality. We’ve found that collecting the events that impacted the project using a timeline technique to be the best method to quantitatively preserve the planned (and unplanned) events that impacted quality, features or schedule. Besides a simple event timeline, there are additional metrics that can be captured such as find versus fix rate for software defects, cargo dropped as a function of time, and person level over time (by function).
If these artifacts are brought to the retrospective meeting, the quality of the output is dramatically improved. Furthermore if the unplanned events are highlighted for magnitude of impact, and then a root cause analysis is performed on the biggest events, you will now be driving conclusions from data. And then if you take those biggest root causes and derive steps to eliminate them from reoccurrence the team has really completed a service to the product creation organization – a deliverable that can provide an impact, depending… …depending on if it is communicated!
Key to making an impact is the second step, which is to get this information into the right hands. More effort should be invested in communication the results, and remediation than in the retrospective itself. Much more. For example, these should be kept in a repository so they can be used to look at trends and provide evidence of improvement over time.
The results of the retrospective format, and the resulting recommendations should be discussed at the staff of the cross functional executive that oversees the bulk of the functions, as many of the remedies will require action at that level. Also, every and I mean EVERY project kick off meeting should have a presentation of the most recent retrospective. Finally, all agile teams should take a part of their normal working sessions to hear a presentation regarding the retrospective – and then to agree on what is relevant for the team, and what actions they will take to avoid repetition of the mistakes.
Sprint retrospective ideas are not a waste of time if done correctly and communicated. If not, then I’d recommend a celebration dinner. It’s more fun.