Retrospectives

If you're not improving: you are getting worse. So, you should always strive to improve. That does not mean that you should always change: an improvement can derive from continuing on a path already stricken. I've seen multiple examples of stuff going wrong and people feel an urge to change stuff, just to make themself feel better - at least we're doing something.

But I'm getting off track - I was going to talk retrospectives. Why do you hold retrospectives? Well, to know how to improve you need to know the current status and how people feel and think about that. Hence, end different periods with retrospectives. The periods can be anything from a meeting to a whole project: if you're having a retrospective over a meeting the retrospective should not take too long while the retrospective after completing a whole project should take it's time.

If we turn to the classic sprint retrospective, I've found that a one hour meeting is appropriate. I make a mental note of 1,5 hours if it was a troublesome sprint.

Then I come prepared: Agile Retrospectives is a good cookbook when selecting stuff to do. But selecting tasks can be a hazzle. My rules are: make sure there's a flow. That you use the stuff from one exercise to the next. This rule may not apply to the check-in exercise.

There are a number of exercises published online but I do recommend the complete book: even if you shouldn't change the exercises every time, you need som change too. I have the rule to only change one exercise at the time. This way there is something new but you don't have to explain everything before each exercise. Explaining an exercise takes away from a much needed flow.

I also include exercises where people are up and running: for example placing postits using Timeline or Prioritize with dots.

And finally: use the last exercise for something positive. Appriciations is the best exercise for me. - ending with everyone saying something positive is wonderful. But make sure that there is not apprications for everyone but one (if it is not called for) - being singled out as the only one not appriciated is not the best way to end a project.