Upgrade from Retrospectives to Prospectives!

Have you ever felt that you are not getting as much out of your retrospectives as you should? Perhaps the problem is already in the term “retrospective”. What is our main goal in an inspect&adapt cycle? Is it the “inspect” part: looking back and analyzing problems? Or is our main goal the “adapt” part: generating creative ideas and building an action plan for improvements in the future? I believe it is the latter. So why do we call the event a “retrospective” and not a “prospective”?

Looking back at what problems we have been facing (the “inspect” part) is necessary to build a platform for further discussion. The big question is how far we want to go in analyzing the past problems. A deep analysis would be especially useful in a complicated, engineering-focused environment, where a “Good Practice” can be applied to a recurring problem, because we know that if a solution (would have) worked in the past, it will work in the future. In complex environments, we cannot be so certain. And most of the time, we deal with complex problems in our retrospectives.

Look at the “5 Whys” method for example. That is a great method for quickly finding an underlying cause for a problem. So let’s play through a common example:

Problem: We couldn’t deploy anything in the last Sprint, so nothing got “Done”.

Why?
Cause 1: The toolchain was completely broken. Nothing worked.

Why?
Cause 2: We only have one person working on the toolchain.

Why?
Cause 3: Because we don’t have a budget for a second person to work on the toolchain.

Well, that looks good so far. But from here on out, the Whys become increasingly pointless:

Why?
Cause 4: Because we did not plan for a bigger budget in the initial planning.

Why?
Cause 5: Because the project manager doesn’t have sufficient experience with large-scale projects like ours.

So what have we achieved with the last two “Whys”? We have found somone to blame (the project manager), and we know that if we had a time machine, we could go back in time and plan a bigger budget. That leads nowhere. Have you ever been in a retrospective where you found out who to blame and that having a time machine would be really great? Did you find these insights to be particularly useful?

Well, the exercise was not completely pointless. At least it looks like we have one important insight: The budget is too low. So now the common approach is to climb back up the “chain of causes”: Get a bigger budget -> Hire an additional person to work on the toolchain -> Fix the toolchain -> Get stuff “done”. Simple enough. But what if we find out that we will not get more money?

In my opinion, we could have stopped after the first “Why”. We know why we couldn’t get anything “Done”. Getting more people to work on the toolchain is an obvious fix. Climbing down a ladder of causes is pointless and only limits us to the solution of “We need more money”. What if there are other solutions? Can team members help out with fixing the toolchain for a few days? Can we reuse something from another project instead of maintaining our own toolchain? Is it time to rethink the toolchain and for example throw out steps or quality gates that nobody actually needs?

I am not saying that these other solutions are better. But working in a wider solution space is definitely better. Drilling down into the problem space unnecessarily can keep us from looking at the wider solution space though. That can lead to discussions like: “Why use up precious developer resources to help with fixing the toolchain if we know that it’s all the project managers fault?” Have you ever been in a situation where you got stuck in that kind of thinking? Well, that’s what you get for wasting most of your retrospective drilling into the problem space.

Even the most common retrospective structure (from the book “Agile Retrospectives” by Esther Derby and Diana Larsen) leads you down that path. After setting the stage, you gather data, and then you generate insights, and these are not insights about what to do better in the future, but about why things went wrong. The “5 Whys” are actually one method for gathering insights proposed in that book. And the authors actually discourage you from looking at solutions too quickly, but they prefer thinking about causes analytically. This obviously caters to an engineering mindset, but we are usually not dealing with engineering problems but with complex problems in a complex adaptive environment. In one model for a two hour retrospective in the “Agile Retrospectives” book, 50-80% of the time are assigned to talk about the past in “Gather data” and “Generate insights” and only 15-20% of the time are assigned to talking about the future in the “Decide what to do” segment.

Doesn’t that strike anyone as completely bizarre?

What kind of creative ideas are we going to come up with in 20 minutes?

I propose to turn this around: We should spend 20% of the time to build our platform – to figure out what went wrong and  to determine the basic root causes. And then we should spend 80% of the time on talking about what we can do better in the future: Action plans, creative ideas, outside-of-the-box thinking, experiments. We don’t need to spend 80% of the time on becoming “problem experts”. We should spend 80% of the time on becoming “solution experts”.

This kind of event would not be a forum for crying over spilled milk, for nostalgically dreaming about water that was already under the bridge two weeks ago, for assigning blame or for discussing about how to build a time machine to fix past mistakes. Instead, it would be a generator of ideas, a catalyst for change, a foreward-looking creative workshop. The key question of the event would not be “What went wrong?” but “What are we going to do better?”.

And this event would no longer be a retrospective but a prospective.