How well are Agile retrospectives serving you?
We assume you follow the Agile retrospective agenda by starting with setting the stage, then gathering data, followed by generating insights before you decide on actions and close the retrospectives. We furthermore hope that at your next retrospective, you look back to your earlier decisions in order to evaluate if you managed to implement these actions and if they made any difference.
However, how do you know it was those actions that made a difference? Further, if they did make a difference, what kind of difference did they make?
What you need to be able to answer these questions is a more scientific approach for your retrospectives.
This means that for every action (or experiment) under consideration, you need to explore your hypothesis — what do you assume will happen by taking that action? And moreover, how can you later tell if this hypothesis was validated or not?
It’s all about the logical process you follow. If you look at all the facts and decide to act on what seems like the best solution, you are being a good detective. You are using what is called abductive logic. That can lead to effective improvements, and yet it can also lead to a good deal of flailing around: the same problem occurring again or resurfacing in a different form — in any case it’s not solved. Another approach is to become a good scientist — to use inductive logic.
Inductive logic means that when a team during a retrospective thinks of an action to address a problem, it pauses to ask, “What is our hypothesis?” An hypothesis says, “Given this background and based on this general theory or accepted approach, if we do x, y, z, we expect to see the following outcome, which we shall measure by the following. Furthermore, we predict that the measurements will be l, m, n. This hypothesis forms the basis of an experiment.
Measurement is critical.
You need first to know what your measurements are before you start your experiment so that you have something to compare to your later results! If you are uncertain about “how to measure anything”, we highly recommend the book with that title by Douglas W. Hubbard. The measurements can be objective or subjective. Even better, you can look for ways to have a “control group.” For example, some people on your team try a new method and another team member keeps doing it the old way. Or, you might be able to compare between teams.
Only with a hypothesis and an experimental plan with adequate measurements will you be able to tell if you might need a different action or if you have to rethink your hypothesis. In our book on company-wide Agility, we call this process “probing” and this helps you not only improve continuously but also innovate sustainably.
There is one more aspect to probes: the possibility of publication. “What happens in a retrospective stays in the retrospective” is a familiar mantra and must, of course, be respected. However, if you discover a process or procedure that seems to make a big difference, you may wish, with everyone’s consent, to tell others about your findings. Publication, in ways that respect the privacy of the retrospective, could be very important because the act of publishing your results asks others to try to replicate what you think you have learned. You will learn from their experiences and validate that what you have uncovered is truly a new discovery.
So consider developing probes in your retrospectives, becoming more like scientists and less like detectives.
Let us know how it goes!
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
