How to run a productive retrospective session

The Japanese have in their dialect a strange word, Kaizen.

It simply means “To change for the better”.

Now scrum is an iterative process. That simply means that you don’t just do everything in a linear fashion. Rather you do the best you can in the first round, review it and then do it again with the lessons learnt, rinse and repeat. This is our Kaizen.

Yet of all scrum practices, retrospectives happens to be the least likely to get done and if done likely to be the least effective.

A retrospective is simply the act of reflecting on the work that has been done during the sprint and seeing how it could have been done better.

In my opinion, the dismal effect of retrospectives arises from the fact that when improvement is brought up, the mind immediately assumes that something was being done wrong in the first place and now we are “improving” it.

This view could not be further from the truth. You see Kaizen philosophy is all about accepting change and making it work for us. This has nothing to do with being wrong or right. We could have done the best work but Kaizen tells us that there is still something that we can improve.

A good retrospective shines, it is the only way that a team can be truly agile.

You can tell you are running an effective retrospective when:

  1. The entire team is engaged
  2. Problems identified are depersonalised
  3. The team, rather than individuals feel responsible
  4. Each iteration, your process improves

So how do you steer your team towards more productive sessions?

Do it for the right reason

Don’t use this meeting as an opportunity to evaluate individual developers. In fact, don’t even use it to evaluate the entire team. The only purpose that you should have for this session is to identify valuable lessons from the just elapsed sprint that you can apply to future sprints.

Discussions on individual developer performance should be done in private.

Encourage open communication

Tell the team you encourage everyone to be open and that there will not be punished it. Here is the important part mean it!

Show genuine appreciation for all input that team members give. You don’t even need to agree with it, acknowledgement is usually enough.

Come up with an action plan

I am surprised at how many meetings I attend that leave without any actionable.

The team must identify.

  • Things that were done well that they should continue doing
  • New practises that could be incorporated into their software development process
  • Practises that are not beneficial and need to be stopped

The team must then commit to making the changes that they have identified.

Fun but no personal jokes

No matter your culture, do not allow anyone to make jokes targeted at any one individual. It is hard to know how the butt of the joke will receive it. Being an already difficult meeting you don’t want to make it any harder.

Don’t shy from hard conversations

As humans, we naturally avoid anything that can hurt us. Conversations on what went wrong have the capacity to hurt us because:

  • Stakes are high. The client paid you and messed it up
  • Emotions are high. No one wants to be blamed for the issues on the board
  • Opinions vary. There is almost certainly going to be different takes on the events that passed during the sprint

The only way you can improve thou is by having this crucial conversation.

See the book Crucial Conversations for more insight.

How do you ensure your retrospectives are productive? Talk to me on my twitter @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer