Kaizen Sprint Retrospectives
Retrospectives in SCRUM are meetings held after the sprint is finished (after the demo or sprint review and before planning).
The duration of the meeting depends on the duration of the sprint: usually 1 hour per week of sprint.
The team identifies problems, possible measures to solve them, and assesses those habits or ways of working that the team wants to maintain: in the retrospective meeting, the three groups are presented, raised, and reflected upon. Measures or actions necessary to improve in subsequent sprints emerge.
It is about evolving the way of working through continuous improvement towards excellence, progressively increasing productivity. In addition, it fosters team cohesion and trust.
In the meeting, the team answers three questions:
- What has worked well?
- What should we improve?
- What actions do we take?
It is advisable to reflect the answers in a simple Kanban board throughout the meeting:
Firstly, and usually, a balance is made of what has gone well and what needs to be improved, to later take the measures or actions recommended to improve. There are other variants or techniques to reflect the team’s reflections in this meeting: the sailboat technique or the starfish technique:
In this case, there are more sections in which to reflect the opinions of the team or the evolution of these in the course of several sprints.
Having more sections means having more detail of the situation, although it also means investing more time in agreeing on all the possibilities with the team.
In my opinion, it is more accurate to have a simple board that influences the team to be more strict in the synthesis, focusing on what is really important. The actions that are identified as tasks can be included in the Product Backlog of the corresponding project. The rest will be reported on the board.
Kaizen and retrospectives
One of the books I read recently which I recommend: The Kaizen Way, explains all the advantages of applying this philosophy in constant continuous improvement through small cumulative steps.
Retrospectives are the ideal meetings to put it into practice. It is about establishing easily manageable actions that allow us to adopt them without much effort.
Avoid indicating large actions to large problems, trying in any case to break it down by facing a minimum part of it, to be able to combat it more effectively through small actions until it disappears completely. Or, face it in its entirety, but starting and choosing the first minimum step easily manageable to combat it progressively throughout the sprints.
What happens if the actions are not carried out and accumulate?
From my point of view, the main root cause of why they are not fulfilled is the incorrect approach of the actions that are applied to solve the problem: either because they try to solve the entire problem (being a large and complex action), they are too conceptual/abstract or depend on third parties outside the team.
Those that depend on third parties outside the team are candidates to be included in the corresponding Product Backlog.
If a certain action is not carried out in the following sprint, it indicates that the action has a bad approach: we must continue to decrease the size of the action or experiment with other small actions that face the same problem, until it is carried out.
I am in favor of assigning an owner to each action for team monitoring of each agreed action.
Recommended readings