Reinforcement for running retrospectives

Retrospectives are a common, regularly practiced ceremony on projects managed using an agile delivery method.

But why stop there?

There’s no reason that retrospectives couldn’t be applied to traditional projects too, it’s just that some improvement ideas might not be immediately applicable in a non-iterative lifecycle.

But won’t it cost a lot more effort to conduct regular retrospectives rather than waiting till we get to the end of our projects? To defuse that concern, here are some reasons why retrospectives are superior to traditional lessons learned approaches.

We all want to help our company but charity begins at home! Why wait till the end of a project where the only beneficiaries of learnings will be teams on future projects if there is an opportunity to reinforce good practices and course correct on others to the benefit of your project?

Sharing knowledge is a good first step, but actually applying that knowledge is when we now whether the lessons are valid or not. Consider our projects as labs where we conduct experiments. If the team comes up with a proposed change to existing practices, it might sound good in theory, but until we try it for real we’ll never know. Regular retrospectives support the scientific method of formulating a hypothesis, testing that hypothesis via an experiment and then adjusting it based on the results.

Dollar-cost averaging is better than trying to time the market. Conducting lessons learned at the very end of a project or even at the end of a major phase is similar to timing the market. Key stakeholders will need some time to de-stress and gain perspective hence emotions can get in the way of identifying quality learnings. If the project or phase ended very well there might be reluctance to challenge practices while if things went poorly there’s a good chance that patterns which should be recognized and reinforced will get ignored. By conducting retrospectives regularly, unless the team is on a death march, there is less likelihood of an emotional rollercoaster derailing knowledge capture.

One approach to categorizing lessons is to classify them as true knowledge, reminders or blockers. The normal methods of handling reminders when they have been identified at the end of a project are to send out some reinforcement communication or to look at adding them into onboarding and other training collateral. While this has some value, it pales in comparison to the influence which a self-organized, self-disciplined team can use on a team member who chronically ignores or forgets a good practice. With blockers, there is value in communicating those post-project to leadership teams in the hopes that they can be eliminated to protect future projects. But when those same blockers are escalated on a project where they are impacting a looming milestone, there may be faster response.

Increased agility and sustained learning comes from being able to identify and apply lessons in close to real time. Regular retrospectives help us avoid Aldous Huxley’s warning “That men do not learn very much from the lessons of history is the most important of all the lessons of history.”