Reinforcement for running retrospectives

StartStopRetrospectives 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.



Categories: Agile, Project Management | Tags: , , | 1 Comment

Post navigation

One thought on “Reinforcement for running retrospectives

  1. Pingback: Reinforcement for running retrospectives – Better Time Management

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at

%d bloggers like this: