Skip to content

Scrum Master TIP #6 – Retrospectives (2)

August 7, 2012

Hi there :)!

Back in February I wrote this post about Retrospectives, giving hints on whom, when, why and  how to do it, plus some references for you to learn more about it.

The thing is: I may not have focused something really really important:

People HATE retrospectives, your job is to make them have FUN.

there’s a reason:  Teams are the most unfortunated and unhappy beings at the face of earth. Let me just explain  you some of the hidden rules and harsh conditions teams are obliged to follow when they are formed. Let’s make it more educated and call it Rules and Principles of Team Behavior.

Principles of  Team Behavior:

1. You shall feel  pressure all the time from everywhere.

(Even and specially from people you’ve never seen and which no one really knows what’s their role, contribution, in the organization).

2. You have to talk to people.

(Even when you dont speak the same language or have anything to say, keep training on every opportunity)

3. You shall use words during communication with other beings.

(Numbers are valid if spoken or cardinal form used)

4. You shall always smile

(Always, no matter what, Be Chucky!)

5. You shall always be friendly to others (including when they bring you bugs, specially when they think they are bringing you bugs)

(Always treat others as if you are dating then, relation improves a lot. Don’t cross over to commitment, else relation declines. Keep yourself and your relations  in sweet promise land)

6. You shall  always be happy for helping others

(Always, no matter what, even when asked to perform euthanasia)

… which lives in perfect harmony with….

Rules of Team Behavior:

1. You must deliver on time, preferably 1 week before

(Weekdays)

2. You must refactor, not using project timeframe

(Unless you work in Recycling Business)

3. You must automated tests

(Even exploratory )

4. You must write documentation

(in several formats and media, so it reaches bigger audience)

5. You must help other teams and still do all you promised (and deliver 1 week before)

(Collaboration is the sweet perfume of a lovely team, be lovely)

6. You must  help all bugs perish in peace

(Every Bug, because it is your baby, must be treated gently and it shall always be remembered in  the sweet valleys of  Automation)

The  point here is that teams feel pressure to deliver functional interesting stuff (which is ok, else they wouldn’t be hired right? ).

The catch is that they are requested also to work as a team, requested to do their own predictions (also known as estimations) and to decide on how to implement stuff. The truth is, be prepared: most people are not used to do this. Most people need time to learn how to estimate, predict, plan, postpone, take decisions, define precedence… all those crapy things that make Management and Planning a real graduation in University. Plus, they are asked to do some real work. (I mean: work that you can sell to others, considering you are not a Management Consultancy Company

And from here comes: People HATE retrospectives, your job is to make them have FUN.

In retros you ask them mainly to talk about human relations and to talk and define action plans to deal with “not so successful things that happened last sprint”. And here I mean FAILURE.

Lets call it what it is: Failure. Every time you miss the deadline or the scope,or you deliver bugs rather than software, rather its other’s or your own perception: it tastes like pure, smelly  Failure.

Obviously that teams work their.. buttock..  out every single day, so most probably they hate to see things havent worked out for the best. AS such do you think its easy or pleasant  to talk about it ? and as C. Avery taught us : its always a long way up for humans in the responsibility ladder!

So make your retrospectives fun. Less embarrassing, less formal, less painful. Make it easy for them to talk about failure. Make it easier for them to have fun and grow together.

That’s all you have to do: make good vibes bigger than bad vibes.

Carpe Diem!

Catia

About these ads

From → Agile, People, Scrum, Tips

5 Comments
  1. When your team hates retrospectives, there is a more fundamental problem… Or even many. You identified some of the most common causes here, thanks!
    People under pressure can not improve, and they cannot solve problems with good solutions, as they always feel inclined to choose the first (most obvious, cheapest) one…
    Which leads me to the one question I have: making the retrospectives fun is surely motivating the team to do them at all (assuming here that the alternative would be that they skipped them under pressure). On the other hand, how does that help the team create the time they need to actually do their job well, and have fun doing it? So that they have fun all week, not only in the retrospective…
    :-)
    take care
    Olaf

  2. Good point Olaf :) So, we do retros to deal with failure and move towards success (product success and people success – as in feeling you get the best of both), as I’m a believer that people work in places and products they love (else we would be falling into bigger questions as : how can a human, knowing his life has an expiring date, decides to spend more than half of his useful day doing things he doesn’t like?)… I would dare to say it doesn’t need much for people to have fun at office daily if they do what they love and still they feel they have succeed by talking and acting on failure, towards success.

  3. A great contradiction in human behaviour (one of many… that’s what makes humans so complex and interesting beings…) is that humans have, to a greater or lesser degree, a fundamental fear of change. That’s not our fault… evolution programmed our brains that way. When going in to a retrospective, talking about all the things that didn’t work last sprint leads to… change. “Let’s try something different next sprint” or “let’s update the way we work”.

    The contradiction is: that all humans, I believe, fundamentally love to _learn_. To improve; to better one’s self.

    The trick, then, is to disguise change as _learning_. This is the greatest opportunity of the retrospective format, when failures can be discussed in terms of the learning they allowed (and not in terms of the direct “result” or effect of the failure).

  4. Change is a difficult process, even physically. According to Neuroscience (not me :)!) it demands that your brain deletes some synapses and creates new ones. Change is hardworking for all it’s aspects, and most often than not, people only change when the pain of not changing is greater than the pain of changing.

Trackbacks & Pingbacks

  1. INSPECT&ADAPT » Mit Spaß haben Ernst machen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 873 other followers

%d bloggers like this: