Looks good in Retrospective

There are many possible reasons for us to get stressed at work: we may argue with our pair, disagree with our boss, fight with our customer rep (these fellas seem to think everything is doable whenever they want it), or get mad at a teammate for breaking the build. Stress can also come for reasons only the person feeling it knows: you may be sitting uncomfortably at your desk, you may be frustrated at the way the iteration is going, you may need 2GB more RAM to make Visual Studio performance acceptable, or you may be just having a bad hair day. When this happens, you may get cranky and raise the team’s stress level.

Now, this is not a psychotherapy site, so I’m not going to start a long healing process. I’m also not going to send anyone from my crew off for a doobie and have them get back when they are feeling better. I am also accepting that some stress is a part of working with people, especially with a bright bunch of experienced developers, each with their own opinions. What I am interested in is running a software project effectively, and that means we need to manage stress levels and remove obstacles that create them.

The way we run retrospectives is pretty close to the way it’s laid out in the books (Linda Rising is my guru on the subject). At the end of each iteration, and before we start planning the next one we stop everything for 30 minutes (this is ok for our 2-week iteration; you may need more time for longer iterations). We draw a table on the whiteboard with a plus at one column and a minus for another. Then whoever is leading the retrospective asks the team “what went right?”. Everything goes down in the “plus” column, no matter how small it seems. I start with the positives on purpose as it puts everything in perspective: never is everything about an iteration negative. We can find good things in the worst death-march and these things need to be cherished and nurtured. Then we move on to what went wrong. Again, everything goes on the board; this is not time for judgement, but rather to look back and think. An experienced team rarely goes personal at this point, but calling out someone within acceptable sense is ok. 

After everything is on the board we go over each negative and discuss its root cause and what can be done to avoid it. We write these points on the board and each point that needs further work is assigned an owner. This way we try to avoid making the same mistakes again. We also try to track these points over time to see if something improved or if there’s 

Retrospectives help the software development team keep a healthy pulse; each iteration begins with the best intentions to fix what went wrong and bolster what went right, and each iteration ends by venting excess stress. The very act of talking about things that did not work with a level head feels good. When this is complemented by trying to make things better for the next iteration, and seeing the continuous improvement in play over time, it feels even better. I recommend frequent retrospectives too: the longer things get kept inside they tend to spoil and a justified grievence about something that should have been better is often replaced by a petty grudge.

Give retrospectives a chance – they help make a group of good developers an excellent development team. They help you get things off your chest and in the same time make them better. Do them often and you’ll see its easier to share and improve. Most important of all: don’t forget to say a good word and let the team pat itself on the back when it’s earned it.

Ok, enough for now with methodology, I’m off to plan what I’m going to say in tomorrow’s retrospective. I’ve got quite the little bag of hate to share 🙂