ScrumBut – Part 5 – Retrospective after every sprint

When you think about the hardest part of Scrum, it isn’t the daily stand-ups. Nor the sprint backlog. Not even the demos at the end. The hardest part – and the oft missed part – is “Inspect and Adapt”. Inspecting and Adapting is at the heart of Jurgen’s ScrumBut post. One tool that teams have for this inspection is retrospectives. Not that this is new – there are lots of tools and names similar efforts go by – After Action Review/Report, Hotwash, and the ever popular, “What the hell is wrong with you people?”

To help counter this, Henrik’s Scrum Checklist helpfully includes three subelements to think about for retrospectives:

• Results in Concrete improvement proposals
• Some proposals actually get implemented
• Whole team and PO participates

This also can be tied back to developing SMART results – Specific, Measurable, Attainable, Relevant and Time-bound. And a sixth element – assignable. Someone should take responsibility for implementing or leading the implementation of the solution – and that person shouldn’t be the manager or ScrumMaster.

But is the end of a sprint the only time we can learn from what has happened? Of course not. In fact, we often laud performance review processes for that reason – they aren’t done until the end of the reporting period, and by that point the learning opportunities may have already been lost. Obviously with shorter iterations the mean time to inspection is lower, but it doesn’t mean we can’t become more lean in our approaches to introspection.

Short, yet oh so sweet

The first thing is to try having them every week if your iteration length is greater than a week. You may have to change the format up some, but the shorter cycle times may allow things to be caught much earlier. Like standups, you can try them at the end of the week, or kick off the week with a retrospective. Or, if things are being tied too heavily, put it in the middle. Adjust and tweak to find what works well for you.

One of the more interesting approaches I heard was from someone at KaizenConf last year. They don’t have scheduled retrospectives. What they do is have a spot on their big, visible wall for items that need to be brought up to the team. When it hits a certain limit (1 or 2 usually) they have a retrospective – on the spot. I like that because if people aren’t feeling comfortable calling something out, they can still post it on the wall, and effect the discussion through that means.

Out of sight, out of mind

Yet, even with all of these, I still find it important to have slightly more formal retrospectives on a regular basis with teams. After all, part of the exercise of retrospectives is discovering something that everyone only had a small piece of. And these little pieces can grow and become infected if left completely unchecked.

But yet, even with all of the acknowledged benefits, teams end up not checking this item on the list. Why is that?

1. Haven’t cleared the 5 dysfunctions hurdle – Retrospectives require a high level of trust and a culture of openness. For many teams, that just isn’t the case.
2. You have a poor facilitator – Effective retrospectives require a strong facilitator. There are lots of antipatterns when it comes to facilitation, and any of us who have ever been in that role can probably relate to one of the antipatterns on that list.
3. The team isn’t empowered to make the necessary changes – This can be heartbreaking when the team identifies the very things keeping them from doing a great job – and can’t fix it. In some ways it’s horrendous – they now very much understand what is causing them pain, and know the fix, but can’t apply it

Luckily there are steps. Esther Derby and Diana Larsen have written a great book called Agile Retrospectives which covers a variety of games and skills one can use for holding effective retrospectives.

It’s still smelly

Perhaps the most interesting argument against scheduled retrospectives is on Doc List’s blog post Are retrospectives an antipattern?. In one of the comments, Scott Bellware says:

Scheduled retrospectives are a strong indicator that a team’s management isn’t sufficiently perceptive enough to know exactly when actions like facilitation, drawing out information, deciding how to move forward are needed based on observable phenomena.

And there’s the crux. For high-performing teams, who are adept at inspecting and adapting, modifying retrospectives to be part of a larger value stream becomes second nature, especially when they have a management team highly tuned into the team. But without that, teams need the ability to build those skills in inspecting and adapting, and thus scheduling retrospectives is important.

So if you are a team who is struggling with your retrospectives and want to modify them, ask yourself if you could put a place on your wall for post-its, and then hold meetings as needed. If so, then tweak away. If not, reach out and find someone who can help you facilitate your retrospectives. And begin to build the insights you need to move away from schedules and rigor towards a culture of learning, insight and reflection.