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
better.
The event was organized by the Expert Committee “Lean, Agile, Scrum” of SwissICT. Many thanks for educating us in such
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â
Source: wikimedia.org
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
- repetition
- no effect
As time passes, retrospectives often get less interesting (Marc's
slide):
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?
Source: dilbert.com
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)
Purpose
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
trying stuff!'â
But that wasn't what Marc had in mind. He was talking about
old-fashioned experiments (you know, Newton or Tesla and those
guysâŠ):
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
example:
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
client.
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.
More Fun
Now we come to the More Fun element.
There are endless possibilities. Marc presented some pointers to get more fun into
retrospectives:
-
Retrospective Cookies
-
Change the Location
Source: wikimedia.org
and most importantly (in my opinion):
- Metaphors
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
- Fun!
Systems Thinking
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
system.
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
Thinking.
An example to do this is by using a Causal Loop Diagram:
Source: isixsigma.com
In this case we can see how individual aspects influence other aspects
in a wanted or unwanted fashion by having an increasing or decreasing
effect.
I believe we often focus too much on short-term problems and lose the big picture.
Closing
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.