{{announcement.body}}
{{announcement.title}}

Scrum and Micro-Retrospectives

DZone 's Guide to

Scrum and Micro-Retrospectives

How to achieve continual improvement — high-performing teams will find multiple ways to incorporate effective continual improvement.

· Agile Zone ·
Free Resource

person looking through microscope

One of the twelve principles behind the Agile Manifesto says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Agile is all about adjustments here and there, learning, fine-tuning and responding to change. 

It’s really hard to adjust and fine-tune effectively if we don’t pause to find out where adjustments are needed. The Sprint Retrospective is the mechanism that Scrum teams usually use to fulfill this principle of inspection and adaptation. Unfortunately, the retrospective is often treated like an add-on or a luxury and performed only “if there’s time”.

You may also like: Agile Retrospective: The What, Why, and How (Quick Guide)

But the purpose of this blog is not to convince you of the benefits or necessity of retrospectives – there are hundreds of articles that satisfy that purpose. An implied purpose of the principle above is to achieve continual improvement. High-performing teams will find multiple ways to incorporate effective continual improvement.

A team that comes to my mind when I think of continual improvement was already doing retrospectives really well. They were militant about making sure the retrospective occurred after every sprint, the whole team participated in lively discussion, and the outcomes were insightful and actionable. Then, one day after a Daily Stand-up, a team member said she had an idea for improvement that she would share at the next retrospective (which was still five days away).

The whole team was still standing together, so I suggested they take two minutes right then to hear her idea. She explained an easier way for Testers to notify off-shore Developers of bugs found during a sprint that could potentially cut hours off of the bug find-to-fix cycle. The team decided to implement her suggestion starting immediately. Making that change right then saved the team a dozen hours of wasted time during the rest of that sprint, and saved hundreds of hours over the course of the next several releases.

The team then started to have these “micro-retros” at the end of each Daily Stand-up. While the team was still together, the Scrum Master would ask if anyone had a quick idea to share. More often than not there was nothing to share, but if someone did have an idea, it was heard and the team determined whether it could be implemented quickly, or needed further discussion.

Those needing further vetting would usually wait until the end-of-sprint retrospective. They continued to conduct an end-of-sprint retrospective but now had a more frequent improvement cycle. Improvement ideas don’t just come to us every two weeks during the retrospective. They happen “continually” – they happen when they happen. Agility is about responding quickly when needed. When you find a good idea, don’t put it off – take action now.

Continual improvement can only be attained when we pause to reflect on what’s working well, what’s not working well, and make conscious decisions to adjust our practices. These pauses can occur every couple of weeks during a Sprint Retrospective, during mid-sprint checkpoints, or during micro-retros.

Sometimes small tweaks can mean the difference between success and failure. Whatever frequency your team chooses to pause and reflect, with regular retrospection, continual improvement is never far away.


Further Reading

Scrum Retrospective 1: Setting The Stage

The Four Questions of a Retrospective and Why They Work

Sprint Retrospectives With Kanban

Topics:
agile retrospective ,development ,devops ,kanban ,leadership ,lean ,project management ,scrum ,scrum master ,testing

Published at DZone with permission of Dwight Kingdon . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}