Regularly doing agile retrospectives helps teams to learn and improve themselves. You can make retrospectives more effective by adding purposes and by validating if your retrospective actions are leading to improvement with the usage of hypotheses.
Lack of follow through is one of the main reasons why retrospectives sometimes fail to deliver improvements, as Thomas Cagley describes in retrospective obstacles:
The worst mistake any team can make is to perform a retrospective then do nothing with the results. While the discussion itself may have been invigorating or cathartic, in the end the team wasted its time.
To assure that actions are taken, Thomas suggests making the needed improvement explicit and visible:
Every retrospective should identify at least one goal or idea for improvement. That goal should be added to the sprint backlog and addressed just any other piece of work that the team has committed to deliver.
In the blog post retrospectives that rock, Dave Sharrock explains how you can make retrospectives effective by giving purpose to the meeting:
(…) the simplest way to inject another level of energy into the retrospective is simply to provide intent by setting a clear question at the beginning around which to retrospect.
To be valuable, the intent should be clear to all, relevant and definitely not self-serving. These could be focussed on uncovering specific issues tangential to the success of the sprint itself (e.g. what would have to change for the team to deliver twice as many stories in the same amount of time?) or targeted on organizational issues being ignored by the team (e.g. how can we reduce or eliminate the wait for regulatory compliance sign-offs for new features?)
Bob Marshall explains in retrospectives – wronger and righter why he considers the PDCA cycle, which starts with a hypothesis, as one of the roots of retrospectives:
How to turn the ordinary retrospective into something extra-ordinary? Go back to its roots. Specifically, PDCA (the Shewhart Cycle). Many folks see the word “Plan” in the simple context of e.g. Sprint Planning and Release Planning (Scrum). But in PDCA proper, derived as it is from Francis Bacon’s original “Scientific Method”, “Plan” means hypothesise:
- “hypothesis” – plan
- “experiment” – do
- “evaluation” – check
- (Control – a later addition) – act
In this scheme of things, any retrospective is pointless unless it’s answering the question “did what we expect to happen – our hypothesis – actually happen?”. If so, why so. And if not, why not? Absent an initial hypothesis, we can never ask ourselves this question.
Marc Löffler wrote a blog post inject purpose into retrospectives where he explains that missing purpose is the root cause that should be addressed to do better retrospectives:
Any retrospective without a purpose is a complete waste of time. (the same applies for any other meeting). It doesn’t make sense to change your retrospectives regularly and introduce new ideas as long as there is no purpose behind.
He adapted the retrospective flow from the Agile Retrospectives book by Diana Larsen and Esther Derby by using hypothesizes in a similar way as they are used in the Lean Startup. Marc extending the “decide what to do” step with “add hypothesis” and introducing a step “check hypothesis” after gathering data:
(…) instead of directly generating insight you check the hypotheses from last retrospective. This is really powerful, as it offers you the possibility to check if the tasks from your last retrospectives had the effect you expected (your hypothesis). In most cases you’ll find out that your hypotheses were wrong. In lieu of simply checking if you worked on all of the tasks you identified the last time, you additionally check if they were helpful and had a positive effect. If your hypotheses were wrong this gives you the opportunity to check why they didn’t have the expected outcome.
Adding hypothesizes and checking them in the next retrospective gives purpose to your retrospectives according to Marc. And it helps to check if your retrospective actions are being valuable:
You have to add a hypothesis to any task you identify, otherwise you won’t be able to check if the task helped. Make sure that your hypothesis is testable as described in the scientific method. If your hypothesis is not testable it doesn’t make sense.
Bob Boyd provides an 8 steps process to do retrospectives with scientific validation. Following lean startup concepts these steps help you to validate if actions from a retrospectives have made the hoped for improvement:
1. Clearly state the exact problem the improvement will solve
2. Clearly state what the results will be with the improvement in place
3. Develop the falsifiable* hypothesis for the improvement (this is the experiment summary)
4. Identify the metrics and measures to collect
5. Identify how the metric data are collected
6. Identify how the collected data is presented
7. Identify how the team will know the hypothesis is proven true beyond a reasonable doubt
8. Identify how the team will know the hypothesis is proven false beyond a reasonable doubt