Entry 13, Day 37
That was a long break, huh. But I’m back here and now. Let’s talk about the Sprint Retrospective. Time to stop running, look back and think about stuff we have just done. As The Scrum Guide says: the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Inspect and adapt in a never-ending cycle of project lifetime.
Retrospective unleashes hidden demons so that they can be ceremonially butchered for the greater good of Scrum Team. And in turn – the Product.
Dr Who
Retrospective is for the Scrum Team (Dev Team + Product Owner). PO should take part, but if the dev team feels that some issues should be discussed without PO, they can ask him/her nicely to leave for some part of the Retro. Scrum Master may also be asked to leave, but this is not recommended as the SM has the power of insight “out of the box” not being the part of the dev team. Of course it might happen that the SM is the problem, that needs to be addressed, in which case, we have some kind of deep pathology anyway.
Any Scrum meeting is open by default for external observers unless the Scrum Team says otherwise, but in case of retrospective it’s often better not to let external spectators in, since it may cause team members to feel threatened and restrain from sincere feedback. This means, that if there is a manager who is not part of Scrum Team, he can be kicked out if the Scrum team says so. (I’m, not talking about who has authority over who as defined in the labour code, I’m talking about rules of Scrum here).
Who should lead the Retro? The common misconception is that it should be always the Scrum Master. Actually much better idea is if each time different person takes the lead. Everyone has a different style of mastering the ceremony, and variety is the key to unleashing creativity. Of course, if the team is new and unfamiliar with Scrum, the SM should take first few Retros to give them any clue how it can be done. And provide support later anyway.
Dr When
After each sprint. On occasion, you may perform Retros covering longer period, like half a year. Perhaps a specific period like first half year after product initial release or something like that. As any Scrum meeting it should be held at stable time – perhaps Friday afternoon, last day of the sprint is best. Don’t skip it till Monday since people will forget some stuff during weekend (and this is the purpose of a weekend)
Dr Why
Simply to improve. While learning any skill if you don’t stop and think what you blew up recently, your progress will be slower. Same is true for software development, and I don’t mean just coding or technical stuff. I mean the entire process from the bird’s-eye view, coding, testing, deployment, interactions inside and outside team, soft skills usage, corporate politics etc.
Dr Where
That’s actually an interesting question. You could do the meeting in the same place every time, but the point of Retrospective is to get the most creativity, memories and insight out of people. One trick to do that, is to perform it in some different environment, even unconventional. Think about going out, sit on a grass in nearby park, or in a pub, or even in a moving tram or boat. Seems silly, but…
Dr How
The biggest doctor. There is a myriad of possibilities when it gets to organizing the Retrospective. Sure, there are teams that for five consecutive years only do the red cards and green cards each time. Probably they should get a new Scum Master. If you stick with one routine way to do the meeting, people will be bored and you won’t get much out of them. Retrospective should be interesting and fun! There are plenty tricks, exercises or games to get people attention, some of them might be quite unorthodox.
Dr Five Stages
You can follow the Five Stages Model, as described in “Agile Retrospectives: Making Good Teams Great”, a must read by the way. So:
Set the stage – get people’s attention, spin cogwheels of their minds and set some theme for the meeting. And make them feel safe in order to get sincere output. Example: ask them to describe the sprint in one word (and hope it’s not “disaster”) or one emoticon. Throw stuffed toys at them, tell some fun story.
Gather data – get people to create a raw output. Classic way is to have green (good things) and red (bad things) sticky notes, give people 10-15 minutes to prepare a few and put them on a table. You can add third column like “ideas”. You can further divide the table into senses – related areas “I saw”, “I heard”, “I feel”. It will boost people memory. Moving motivators is nice idea and works well.
Generate insights – get people to crunch through what they gather, analyze, discuss, think, try to find the patterns. Talk about sticky note, elaborate, group them together. Encourage everyone to speak up.
Decide what to do – get people to figure out how to improve things. Generate some to-do list, decide what’s most annoying, what should be fixed first, what can be done inside the team and what requires external actions. You can maintain a so-called Impediment Backlog to help manage that kind of stuff.
Close the Retrospective – provide some kind of summary, make people feel good about what has been done during the meeting.
An interesting idea is Retr-o-Mat. It’s a simple page that lets you generate randomly the five stage scenario for retrospective from predefined activities. For now there is over million combinations, and that number is growing.
And what are your ideas for retrospective?
How To Train Your Java 