_ Sprint Retrospective – 10x awesome learner?

Adrian Sita

Agile Software Development
—
December 18, 2019

3min

What is an Agile retrospective?

Agile or Sprint retrospective is the same… but what is this ceremony? Could it be of any help for the Agile teams? Is it important?

Agile Manifesto is describing it like this:

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

What about Inspect and Adapt? Is it fundamental for every practice under the Agile umbrella?

I’ll refer to the Agile Retrospective as Sprint Retrospective because SCRUM (the most well-known framework in Agile) works with Sprints. A retrospective is a ceremony in Sprint – and this why I like to call the sprint a “container” – because it is a placeholder for all the ceremonies.

Many agile team members make confusion between Sprint Review and Sprint Retrospective. Actually, the fundamental similarity is that both ceremonies happen at the end of each Sprint (or at least this is how it should be).

In very simple words, which are the purposes of these ceremonies?

Sprint Review: it helps the team asses the incremental work of the product/project that the team has done;
Sprint Retrospective: it seeks for the improvements of the process that have the team applied during the Sprint.

A Sprint Retrospective is a placeholder for inspecting and adapting the framework rules by the team – as a formal ceremony. Nothing can stop the team from making process improvements all the time, but the best practice is to use this ceremony for seeing a complete picture of the entire process.

The ‘Agile tunning brain’ (as I like to call it) – the person responsible to coach the team to apply an agile mindset – usually is the role that sets the stage for the ceremony to happen… and the main property should be to have a safe environment. Why ‘safe’? Because should be very easy for each team member to speak freely to the rest of the team, even if the words are wrong and could embarrass that person.

Which are the major improvements which come because of applying Kanban framework as a strategy?

Setting the WIP limits and policies for transitions in the process workflow.

Using information radiators assure that the team immediately see the bottlenecks or the improvements that may happen.

Agile - Sprint Retrospective - cases

Situation

Diagrams used in SCRUM framework cannot expose one of the main issues that may appear in a flow like forgetting about unique starter items:

burn-down/up chart: it does not “show” the problem – the rate of completion does not distinguish between items that have a different start time;
cumulative flow diagram: it can give an insight into the average cycle time.

Solution

To calculate the cost of impeded flow, you need to follow these steps:

calculate the age of each item;
use the input below to get the average cycle time;
in a cumulative diagram confront every throughput with the previous step;
work items that influence the flow negatively can optimize the flow.

Even if a very well know anti-pattern is to skip this ceremony – this is one of the biggest mistakes that a team can do. Therefore, the velocity/improvement overtime of an established team is insignificant.

Every Sprint retrospective must end with listed items – known as actions list – in order for the team to put in practice what they discover or learned during the sprint duration even if they didn’t make it consciousness they have this opportunity into this ceremony!

Some (final) thoughts

Kanban framework uses the same terms for Sprint Retrospective (other explanations you can find here as described by Mike from Mountain Goat Software) or Sprint Review as the other known frameworks used in Agile. The Sprint Review and Sprint Retrospective are different ceremonies focusing on process and on product/project increment.

This is the major opportunity to learn and become greater at developing business products that create a footprint in the Agile Software Development world.

Kanban framework as a strategy – implemented by a team – brings more focus towards the flow rather than towards the delivery of particular features.

This article is part of a bigger topic called: Agile Software Development