People fall asleep in retrospectives or have bad temper? They do not like to share their thoughts – if they have any?
Maybe you are trapped in repetitive rituals and would like to do something about it? Last Wednesday I had been attending the Agile Breakfast in Zurich
titled “Organizing Retrospectives Effectively” with fellow-Liiper Christoph Meier.
Marc Löffler was going to address how we can make our retrospectives
a splendid way!
Marc started with a slide that said:
Your Retrospective Sucks!
I was suprised – and not quite sure how to deal with what I had
read. Then I had to laugh. It's good not to lose one's sense of humor.
The slide's subtitle read: “…and what you can do about it”.
By the way, Marc's slides are available on slideshare.net if you care
to have a look.
For this blog post I was looking for some images of meetings. I
stumbled on this one: “The Indians giving a talk to Colonel Bouquet”
Doesn't that meeting look interesting? Nobody is falling asleep.
Wouldn't we want to have more retrospectives like that? I mean,
we're not fighting wars like the proponents on the image did. But we'd
like to have purpose, and engagement, and …
What can we do?
Marc gave three reasons why retrospectives suck:
- too much and unfocused talking
- no effect
As time passes, retrospectives often get less interesting (Marc's
Source: slideshare.net (slide by Marc Löffler)
We all like to pick the low hanging fruit first. Are we prepared for what comes after that?
The worst retrospectives are those that show no effect. Nobody looks
forward to such meetings.
Marc was going to cover three elements to address this:
- Purpose (know)
- More Fun (enjoy)
- Systems Thinking (understand)
To get the purpose back into the retrospective, Marc wants us to
experiment. Your first reaction to that might be like mine: “Yeah
sure, that's going to ruin it totally. No structure ‘n all. Just
But that wasn't what Marc had in mind. He was talking about
old-fashioned experiments (you know, Newton or Tesla and those
An experiment is an orderly procedure carried out with the goal of
verifying, refuting, or establishing the validity of a hypothesis.
So in the 1st retrospective we would start with a hypothesis , for
If we go to work on-site with the client we can have a better common
understanding and therefore we will have less disagreements with the
Time passes and we have the 2nd retrospective where we do a
reality-check: could we verify our hypothesis? Did things turn out
like we thought they would?
No, we had even more disagreements with the client!
What we assumed turned out to be completely wrong.
But that's fine. That's the agile way. We learn. Remember: “Inspect
and adapt”. We refuted the validity Hypothesis Nr. 1. We then form a
new hypothesis. We will verify that one in the 3rd retrospective.
So that's Marc's way to bring back the purpose: through experiments we
approach our issues with methodology and our retrospectives should
become more effective.
We shouldn't be thinking in terms where we already expect the “solution” to work.
Now we come to the More Fun element.
There are endless possibilities. Marc presented some pointers to get more fun into
Change the Location
and most importantly (in my opinion):
To do this we set the stage by choosing a metaphor we'd like to
use. When Marc asked us for ideas, Christoph Meier suggested
to make a Construction Site Retrospective .
When your metaphor-based retrospective starts, you collect terms that
belong to the metaphor. Everyone should try to stick to these terms
when talking events that took place.
So for example, if the hosting provider for you new website was late
with giving you access you would say:
“We couldn't get to the construction site for four days because it was
locked and the owner was on holidays. We are running late now. We
should have completed the basement last week.”
Or if the requirements for a feature were not clear enough:
“The architect said that the wall should be 10 feet and I made it
so. But now the whole building is too wide!”
The benefits of such metaphors are (quoting Marc):
- Thinking outside the box
- New, creative ideas
- “Distance” to real events
Last but not least: we should be trying to understand the system we
are dealing with. We need to know which buttons to push. We don't want
to press the wrong buttons! Teams are not endpoints but nodes in a
Assuming someone is sick, the doctor analyzes the given symptoms to
find the cause. If only the symptoms are treated, the patient cannot
get truly healthy. That's why the doctor looks at the whole organism
so he is able to identify the root cause, which might not be directly
related to the observed symptoms.
In our environment, we want to know how the different factors (like
the client, the team's morale, the budget etc.) influence each other.
If we forget to consider important factors, we can probably not solve
the issues at hand very well.
The approach suggested by Marc to understand the “system” is Systems
An example to do this is by using a Causal Loop Diagram:
In this case we can see how individual aspects influence other aspects
in a wanted or unwanted fashion by having an increasing or decreasing
I believe we often focus too much on short-term problems and lose the big picture.
It was inspiring for me to hear about these options. I would like to
add that Marc has written a book on the subject called
Retrospektiven in der Praxis: Veränderungsprozesse in IT-Unternehmen
effektiv begleiten (in German only). I will hopefully read it soon.
Please contact me or Christoph Meier if you would like to share your
experience, have questions or corrections to make.
On the 26th of June we will be celebrating the grand opening of our
new office in Zurich. There will be an agile session “Agile – to be,
or not to be” in the afternoon where you can even meet me in person.
See the announcement for further details (and to register for sessions).
So long, see you later!
… and thanks to Christoph for helping me with this text.