Become More Effective

“At regular intervals, the team reflects on how to become more effective, then tunes and adjust its behaviour accordingly.” 

– Manifesto For Agile Software Development – Principles

Pausing regularly to do this is 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 our project work and meeting a deadline. There was rarely time to pause, reflect and plan improvements to processes and working methods.

Where time was set aside for this, it was always at the end of the project once we were live and we had some “downtime”. But this fabled “downtime” never came. Projects always overran, 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 significant than short-term project delivery, so it rarely received 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 then 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 improve. When a project ended, I was often tasked with creating a lessons-learned report. The purpose was to reflect on the project and determine 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 critical 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, 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 remember him discussing the importance of the Sprint Retrospective. He spoke at some length about how organisations that failed to improve their processes regularly would be moving backwards relative to the competition.

“If you’re not striving to improve, you’ll go backwards.” – (paraphrasing) Ken Schwaber

You may get away with it in the short term, but it is a surefire route to oblivion in the long run. Ken’s recognition of this led to it becoming a rule in Scrum. Scrum wraps the underlying Agile principle in the Sprint Retrospective, which aims 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 takes 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 will 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. Minor regular improvements add up and compound. Motivation levels increase. We can use new tools and practices to save time, money and energy.

Despite the benefits of Sprint Retrospectives being transparent, it cannot be easy 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 for improving.
• 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 a practical Scrum Master with strong facilitation skills is essential 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 most of our issues will be due to the system rather than the individuals. Help foster a culture where the team can discuss complex issues without fear of repercussion.
• All voices heard – There will be louder and quieter people in any team. 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 must narrow our focus to plan and act on something now. Prioritising the matters based on their impact and the Scrum Teams’ ability to work on them is vital. Establishing 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 rather than fixating on the pain caused by the problems themselves. If the event becomes negative, refocus 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! – Many 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 forward. 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 significant long-term difference. Making this transparent and highlighting the successes can help maintain a focus on this incremental improvement.
• Celebrate – Product development is a marathon, not a Sprint (despite what  Scrum suggests). To keep people engaged and motivated, find ways to celebrate progress and success.