This post continues my ongoing series revisiting the principles behind the Agile Manifesto. This time we are focussing on the following Agile principle – “At regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly.”
Pausing regularly to do this seems like common sense. But it was a surprisingly rare practice in most organisations I encountered before Scrum & Agile became more widespread. The focus was always on the project work we were doing and meeting a deadline. There was rarely time to pause, reflect and plan improvements to processes and ways of working.
Where time was set aside for this it was always at the end of the project once we were done and we had some “downtime”. But this fabled “downtime” never came. Projects always overran and so the next project was late in starting. The promised “downtime” disappeared as we shifted focus to the new and already late project. Process improvement was always less important than short-term project delivery and so it rarely received any real attention. As a developer, if you wanted to do it you had to work covertly and build time into your estimates to improve things. It felt wrong at the time and only encouraged bad practices like estimate inflation and hiding certain types of work.
When I became a Project Manager, things changed but didn’t really improve. When a project came to an end, I was often tasked with creating a lessons-learned report. The purpose was to reflect on the project and figure out how to improve moving forward. The problem still was that I was the only person active in this. Everyone else was busy doing other more important work. The output was biased to my observations and resulted in little real change. It was also too little and too late to help with the project that we had just finished. More often than not, the recommendations were filed away never to be seen again.
It was only when I first encountered Scrum that for the first time that it seemed to me like the importance of this activity had finally been recognised. When I first met Ken Schwaber (the co-creator of Scrum and founder of Scrum.org) I can remember him talking about the importance of the Sprint Retrospective. He talked at some length about how organisations that failed to regularly improve their processes would appear to be moving backwards relative to the competition.
“If you’re not striving to improve, you’ll end up going backwards.” – (paraphrasing) Ken Schwaber
You may get away with it in the short term, but in the long run, it is a surefire route to oblivion. Ken’s recognition of this led to it becoming a rule in Scrum. Scrum wraps the underlying agile principle in the Sprint Retrospective, the purpose of which is to plan ways to increase quality and effectiveness for a Scrum Team. Some time would be allocated at least monthly for the whole team to reflect on and plan future improvements to how they work.
If a tool, is no longer fit for purpose, let’s replace it. If testing is taking too long, let’s work out how to automate it. If we are missing a vital skill in the team, let’s figure out how we are going to get it. This is the purpose of the Sprint Retrospective. Rather than forcing people to carry on regardless of how bad the process around them may be, we are now empowering them and requiring them to improve things as they proceed.
Scrum Teams that are empowered to do this, and learn to do it effectively, typically see significant benefits. Small regular improvements add up and compound. Motivation levels increase. We can take advantage of new tools and practices to save time, money and energy.
Despite the benefits of Sprint Retrospectives being clear, it can be surprisingly difficult to make them effective events. Here are some of the more common issues that are felt in Sprint Retrospectives:
- Too many problems – We may identify too many problems and feel overwhelmed.
- The blame game – People start blaming each other for the problems.
- Failure to create an actionable plan – The team gets stuck in the blame game and fails to create a plan of how to improve.
- Lack of action – The plan does not get actioned. What is the point of talking about problems if we never work to address them?
- Lack of engagement – People check out, often due to the lack of action and improvements from earlier Sprint Retrospectives.
This is where an effective Scrum Master with strong facilitation skills is important and has an opportunity to shine. As a Scrum Master, you can ensure that the Sprint Retrospectives your team carry out benefit from the following:
- Safety – Assume the best of people and understand that the majority of the issues we face will be due to the system, rather than the individuals. Help foster a culture where the team feels able to discuss difficult issues without fear of repercussion.
- All voices heard – In any team there will be louder and quieter people. Be conscious of this and facilitate in a way that allows all voices that want to be heard, to be heard. Liberating Structures can help with this.
- Prioritisation – Where there are many issues, we need to narrow our focus to plan and act on something now. Prioritisation of the issues based on their impact and the Scrum Teams’ ability to act on them is vital. Basing some Sprint Retrospectives around a specific theme can help with this.
- Positivity – To prevent a negativity bias from creeping in, focus the event on the positive. We need to understand the issues, but we should move to plan solutions to them rather than fixating on the pain caused by the problems themselves. If the event becomes negative, refocus it on the more positive future and the plan to get there.
- Focus on what you have power over – Some issues will be beyond the influence of the Scrum Team to change. The Scrum Master is expected to take action around these impediments. The rest of the Scrum Team should focus on what it has the power to influence and change. Often there is much more they can do than they realise and the Scrum Master can help make this transparent.
- Make it fun! – Lots of Scrum Masters I have worked with over the years went to great lengths to make the event fun. Theming the sessions to add an element of entertainment and bringing in snacks seem to be the go-to tactics for this.
- Let off steam – Developing products in complex environments is hard! Give people a safe space to let off steam so they can draw a line under an issue and move forwards. Sometimes, just talking about a problem is all it takes to reduce its impact.
- Small improvements add up – Whilst we are in the midst of things it may not feel like it, but this is true nonetheless. Creating a culture of continuous improvement ensures that small, regular changes add up and compound to make a big long-term difference. Making this transparent and highlighting the successes can help maintain a focus on this incremental improvement.
- Celebrate – Developing a product is a marathon, not a Sprint (despite what Scrum suggests). To keep people engaged and motivated, find ways to celebrate progress and success along the way.
Here are some tools and resources related to Sprint Retrospectives that you may find helpful:
- Agile Retrospectives book by Esther Derby & Diana Larsen – This is a little old now, but it’s “the” book on Retrospectives and well worth a read.
- Scrum.org Professional Scrum Facilitation Skills course – Learn how to develop a facilitator’s mindset and learn some effective techniques to help you improve your Scrum Team’s events.
- Retrospective Tools – There are a vast array of tools that can help you facilitate a Sprint Retrospective, especially with remote teams. My preference is to avoid a dedicated tool. I prefer to use an online whiteboarding tool like Mural or Miro. These give you maximum flexibility, and minimal learning curves and can be used for many other things as well.
Finally for the Retrospective on this post – I think it is a little too long. Next time I plan to keep it shorter and stick to 1-3 key points. Please let me know your thoughts via the comments.
--
Hi, my name is Simon Kneafsey and I am a Professional Scrum Trainer with Scrum.org & TheScrumMaster.co.uk. I am on a mission to simplify Scrum for a million people. I have helped over 10,000 people so far and I can help you too.
Learn more at TheScrumMaster.co.uk and signup for our newsletter with 80,000+ practitioners.
