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.