What You Ought to Know About Investing in Retrospectives

Waste of Time
Retrospectives – A Waste of Time? Nope!

Retrospectives – a waste of time in meetings? Too much investment of time with too little valuable outcome? A little thought experiment shows clearly that it’s worth investing in retrospectives.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
— one of the principles of the Agile Manifesto

“This sucks big time! It’s a waste of time for me and the whole team. I don’t see the value of attending this meeting!”
— frustrated team member during a retrospective

Regularly improving the way an Agile team works is one of the most important principles of the Agile community. Retrospectives are considered to be the most valuable instrument to follow this principle. And yet, for some, it can be challenging to see the benefit of doing retrospectives in order to regularly improve.

I’m not writing about dysfunctional retrospectives here, such as retro’s done without a facilitator, not done regularly, with not enough or way too much time, without attendee’s buy-in (prisoners!), mechanical instead of engaging, without actions as a retro’s outcome that actually change the process, etc. There’s lots of knowledge about that in the Agile community, so no need to go down this road here.

I’m addressing the challenge of seeing the benefit of retrospectives even if they are done as retrospectives were meant to be. The logic goes somewhat like this:

“I’m spending an hour and a half with the whole team every two weeks to find at least one action that changes a fraction of our current process. That’s clearly not worth the investment, right?

I agree with the assumptions, but not with the conclusion.

The assumptions:

  • an hour and a half for a retro in a two-week sprint: Of course, the length of both, retrospective and iteration, can vary within certain boundaries. Iterations of two weeks are very common, and a retrospective of 90 minutes per iteration is appropriate for iterations of a length of two weeks.
  • changing a fraction of the process: On average, actions to improve the team’s process are small adjustments within the team’s ecosystem. While actions are sometimes causing lots of change, there are other times when there are no actions (team couldn’t find an action in time during the retro) or flawed actions (team did not make the actions SMART enough) or failed actions (action turned out to not improve the process).

My conclusion differs, though: retrospective’s are worth the investment.

To confirm this conclusion, I did some calculations. In order to do so, I needed some numbers regarding how much a single retrospective might improve a team’s performance. I can’t measure performance, but I can express my gut feeling about how much a team’s performance increases on average within each iteration through retrospectives. My own gut feeling lies somewhere between 1 % and 5 %. Your mileage may vary.

Once I completed my calculations (you can find the spreadsheet with my calculations here), I had a couple of conversations with people around me. All of them were rather surprised in the end. The conversations were similar to this one here:

  • Me: “By how much, on average, will a team’s performance be improved in each iteration by a retrospective? I’m interested in your gut feeling. Something like tiny improvements (1-2 %), medium steps (5 %), or large steps (10 %)?”
  • Her: (thinking about this for a long time) “About 2 %.”
  • Me: “After you hear the following question, I don’t want you to calculate the answer in your head. Just spill out right away what you think about it. Ready? Here we go: Given an iteration length of 2 weeks and a retrospective length of 90 minutes, how long do you think it will take this team to double their performance?
  • Her: (a bit under pressure) “Uh, ah, about 10 weeks?”
  • Me: “Let me check if I understand you: You think it will take a team about 5 iterations to double their performance?“
  • Her: “Yeah, that seems about right to me.”

When you read her estimate, are you laughing or rolling your eyes because she’s off by that much? Don’t judge her. People are bad at estimating effects like this. Most people I talked to are way off. Most people are bad statisticians.

  • Me: “Not even close. It’s actually 37 sprints that the team needs to double their performance. That’s about 1.5 years.”
  • Her: “What?!? Wow! That’s a very long time. That disappoints me.”
  • Me: “Why does it disappoint you?”
  • Her: “Because, clearly, it’s not worth it. The return on time invested is bad. There must be better ways to double the performance.”
  • Me: “What if I told you that you only have to invest 56 team hours to double the team’s performance? That’s only about 1.5 weeks of combined effort for the team. Would you invest 1.5 weeks of the team’s time to double the team’s performance?
  • Her: “Of course I would!”

Everyone I had this conversation with was astonished by this last number representing the combined investment of time via retrospectives. And it doesn’t matter what percentage of increase of performance per iteration you put into the equation from the beginning, whether it’s 1 %, 2 %, 5 %, 10 %, or more. The result is always in favour of the time invested:

  • Improvement per retro of 10 %: Investment of 13.5 team hours within 0.4 years to double a team’s performance.
  • Improvement per retro of 5 %: Investment of 24 team hours within 0.7 years to double a team’s performance.
  • Improvement per retro of 2 %: Investment of 55.5 team hours within 1.5 years to double a team’s performance.
  • Improvement per retro of 1 %: Investment of 106.5 team hours within 2.8 years to double a team’s performance.

Long story short: Yes, it’s worth having retrospectives.

Further thoughts: The idea of putting a percentage number as a measure of increase of performance is off-putting to some people. I used it in this example as theoretical data to show that team’s should indeed invest in retrospectives because the time invested generates a huge return. Again, as stated above, you cannot measure productivity, and it follows that you cannot measure the difference between two states of productivity. Hence, this idea of calculating the return on time invested is a mere thought experiment. However, I find the results valuable, since they have helped me to engage people more to invest in retrospectives.

Another flaw of this thought experiment might be its oversimplification. Retros are often not the way process change is actually done. They are merely the trigger of change, and the actual work happens outside of a retrospective. My calculations do not take this time outside of a retrospective into account. To change, one needs to take into account both, the initiation of change and then following through with it. If either one of these components is missing, there will be no change. The above calculations would be more precise if I summed up both, the amount of time of all the retrospectives and the amount of time needed to follow through with these retrospective’s actions.
There is a clear sequence here, though: Without initiating change, there will be no following through with anything. Meaning, without retros triggering change through actions, there’s generally no or not much change happening. If there is change happening, it will be incorporated into the team’s work during the iterations, and so the actual investment to create change will eventually originate within retrospectives. This is the reason why I didn’t take into account in my calculations the amount of time to follow through with change.

This entry was posted in General and tagged , , . Bookmark the permalink.

About Bernd Schiffer

Bernd Schiffer is consultant, trainer and coach for Agile Software Development in Melbourne, Australia. Learn more about him on his personal homepage, have a look at his company Bold Mover, or contact him on Twitter, Google+, Facebook, XING or LinkedIn.

One Response to What You Ought to Know About Investing in Retrospectives

  1. Bradley Worsfold says:

    Sometimes I think productivity improvements slow down over the life of the project. So, while there are benefits to be gained, they may not be as great as when discussing them at the beginning of the project. Sometimes the benefit reduction is due to constraints outside of the project teams control.

    My 2 cents. Thanks for putting in the time to write about agile.

Leave a Reply

Your email address will not be published. Required fields are marked *