Wasting your time in the Scrum theatre. Part IV: Sprint Retrospective and Conclusion
Executive summary: The Retrospective is an easy way to kill your Scrum if servant leadership is not well understood and enacted within and outside your Scrum Teams.
The Retrospective: Beyond Mea Culpa
The final Event of the Sprint – the second Boundary Event [1] – provides the Scrum Team with the setting for reflecting on how things went during the Sprint – from an emphasizedly non-technical perspective. Looking back at what worked well and what didn’t, what in the ways of working should be kept and strengthened and which should be avoided, what improvement opportunities the team identified, how obstacles faced could be dealt with more effectively; these topics all point in one direction: towards continuous improvement.
Delivering complex products and services is a team sport, but we should not forget that a team consists of players. The Sprint Retrospective offers an opportunity for the players to elaborate on how they feel about their roles, their team, the product/service, and their progress and contribution towards the wider purpose of the organization.
Talking about the issues faced during the Sprint allows team members to let go of some of their frustrations early enough without escalating into a personal blame-game and pointing fingers. It provides the opportunity for everyone to be heard and understood, thus to find solutions together. The Retro is the soul of Scrum, a celebration of the team, where we, intelligent people working together on a great product can discuss how to bring out more of ourselves, our working hours, our professional life and our collaboration. This celebration is guided by the Scrum Master as the servant leader of the team.
A well-spirited team ends the session with a clear list of improvement action items in hand, to be executed during the upcoming Sprint and reviewed at the next Retro. It’s a good practice to identify a single topic of improvement, which is often referred to as the Kaizen (“continuous improvement” in Japanese), as a tribute to Lean, in which Agile is rooted.
When you hear this, be suspicious
“Here’s the list of impediments we’ll have to tackle in the future”
Don’t leave with a long list of disparate action items! Focus is not only valuable when you’re talking about the content of the work, but also for continuous improvement items. Choose the Kaizen, a single improvement item instead, and define actions the team can take towards it during the very next Sprint
“Can’t we do the Retro in just half an hour? Or maybe skip it altogether?”
If the team questions the value of the Retro and wants it to get over with quickly, it’s a sure sign of trouble. Make sure that you leave the Retro with a single Kaizen and clear action(s) around it. No clear actions identified means no actions will be taken. Remind the team to the Kaizen and the actions during the Sprint, thus making sure things move forward. This allows you to review the Kaizen actions in the next Retro, closing a positive feedback loop with the team. Process improvement is their achievement and will be seen as something that serves them. So does the Retro
“There’s nothing new I can tell compared to the last few Retros”
Don’t have the exact same structure for the Retros for months! As the soul of Scrum, it should be fun. Besides avoiding boredom, you want to change now and then because change allows the team to look at their challenges from a different perspective. Making Retros meaningful and versatile is the responsibility of the Scrum Master
“Ummmm… I don’t know if I want to talk about this”
For Retros to work, you need to create a safe, confidential environment. For the sake of open, deep, and meaningful conversations, keep the details confidential – this is not the place for full transparency. It also means that only the members of the Scrum Team are welcome – and all of them needs to be there
“This is painful indeed, but we can’t do anything about it anyway”
Sometimes you’ll find impediments that the team can’t resolve itself. The Scrum Master has to make sure to get external help in resolving these, e.g. by raising such impediments to a higher level of the organization. The SM brings back the results to the team at the next Retro
“Kaizen? It’s still the same thing we’ve raised to management the last Sprint. And the Sprint before”
Retros provide a key feedback loop in Scrum. If impediments raised towards management are not getting resolved, decisions are not made and leadership support is scarce and reluctant, the Retro feeds this back to the team mercilessly. The not-so-hidden “we don’t care how well you’re doing, just put your heads down and keep on working” message is hugely demoralizing. This is the main practical reason why you want to make sure that management is ready for Scrum before you start because unresponsive leaders can break Scrum quite easily
In conclusion
The Scrum Events are designed to give the minimum necessary synchronization opportunity to the Scrum Team to make sure that everybody is rowing in the same direction together, thus no one’s work ends up in the gutter. Have you ever heard a team complaining about the meeting overhead of Scrum? Have you ever seen a team wanting to switch to longer Sprints to reduce the relative overhead of the Events? These are sure signs of Scum Events not delivering results and not serving the Scrum Team. It is the responsibility of the Scrum Master to make sure that everything we do in Scrum serves the Scrum Team, so in return, they can serve the customer the best.
Unfortunately, a common answer of many Scrum Masters to the above symptoms is “Let’s try to make the Events shorter”! This sets you up on a slippery slope. If you couldn’t achieve results let’s say in two hours, why do you think you’ll achieve them in 1.5 hours? And even if you make it only 10 minutes: 10 minutes without results are 10 minutes of waste, while 2 hours with results are 2 hours of investment. So instead of making the Events short, make sure your Events are meaningful, yield results and the team benefits from those results. If it needs more time in the beginning, so be it. Once the team gets used to working together in Scrum, the Events will naturally get shorter, without the need to forcefully keep them in a tight time box.
In the US alone, there are about 11 million meetings held on average every single day, with employees attending about 62 meetings every month. A whopping 37% of these meetings are considered to be adding no value to the organization, hence a waste of time [2]. Keeping the well-defined purpose of the Scrum Events in mind and focusing on achieving them will prevent you from ending up in such statistics.
References:
[1] Check out the Sprint Retrospective in our Scrum events cheat sheets
[2] Martin Luenendonk, How Much Time Do We Spend in Meetings? (Hint: It’s Scary)
No Comments