by marc

September 5, 2012

Last week I talked about „Spicing up you retrospective“ at the ALE2012. I did a similar talk in June at the ACE!Conference in Krakow. But after the talk in Krakow, I had a chat with Bob Marshall and he pointed out that fun isn’t the (only) answer to make retrospectives better. He also pointed me to a blog post where he wrote about these issues. So, the following article is mainly based on his ideas.

Retrospective Challenges

For me, there are two main retrospective challenges:

  • Create a motivating environment and keep the people them engaged
  • Work on the identified items

On first sight it seems that these two challenges may be caused by:

  • Repetition –> Boring Retros
  • Same problems –> No effect
  • No responsibility
  • Tasks are not visible
  • Tasks are too big

But these are only the things you see on the surface, if you dig deeper you’ll find the real root causes.

Inject Purpose

IMHO, the root cause is a missing purpose. 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. But how can you inject purpose into your retrospectives? The answer is: by using hypotheses. To do so, I adapted the original retrospective flow by Diana Larsen and Esther Derby the following way: Alternative retrospective flow The first two steps didn’t change. But instead of directly generating insight you check the hypotheses from the 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. Instead 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. Now you can enter the step „Generate Insight“ and check what went wrong. This approach helps you to iterate on your tasks until you can fulfill your hypotheses. But it could also be, that you find out that a hypothesis was complete nonsense. This is also fine. Another change to the standard flow is the adaption of the step „Decide What To Do.“ 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. The closing step is the same as in the normal retrospective flow.


I was asked at ALE2012 to give some examples: – Task: Collocate the team with the PO –> Hypothesis: The response time to questions to the PO will drop.   – Task: Introduce a Definition of Ready (DoR) –> Hypothesis: Better prepared User Stories, and we can keep the time-box of the Sprint Planning. – Task: Stand-up in front of the task board –> Hypothesis: More focused stand-up (keep the time-box). Keep in mind that this is only examples to give you an idea how this could possibly work. I know that it is difficult to measure „more focused stand-up,“ but I’m sure you’ll find a way 😉 In the next blog post I’ll write about some ideas how to shape such retrospectives by using metaphors.

About the author 


Marc Löffler ist selbständiger Agile Coach, Autor und Keynote-Speaker. Er befasst sich leidenschaftlich mit agilen Managementmethoden. Bevor er mit agilen Methoden in Berührung gekommen ist, hat er als zertifizierter Projektmanager bei Firmen wie Volkswagen, Siemens und EADS gearbeitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und zu leben. Er liebt es, neue Einsichten zu generieren, und unterstützt Teams dabei, Probleme aus anderen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley.

Leave a Reply

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. It’s really great how you described it!
    I’ve been using a very similar approach for a long time, but didn’t manage to conceptualize I was actually adding new phases to the approach suggested by „Agile retrospectives“ book. And wouldn’t have been able to put it so nicely as well :o)
    However I think I’m doing also something more: besides checking if the action we tried was effective and actually satified the hypothesis, we also check whether the action was only a „one shot“ action or we need to systemize something in our process, so that a sustained benefit is achieved.

    1. Thanks for your comment. I like the idea of checking if it was only a „one-shot“ or if the team needs to do more. IMHO you always have to look if you’re only working on the symptoms instead of the real root cause.

  2. Pingback: Nataly
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir das kostenlose Poster

Lerne die Voraussetzungen für echtes, agiles Arbeiten kennen!