Are retrospectives real continuous improvement?
Are retrospectives used for real continuous improvement? Having worked with Scrum for more than 4 years, I’ve seen the benefits of the retrospective. For me, it’s easily the most important meeting.
You identify and discuss what went well, what can be improved and what are the actions that will be carried out to improve those things, whether they be processes, product or something else. It’s not rocket science.
But what happens when a problem comes up in the middle of a sprint that you should fix? Many a time, we made a fix and then waited until the retrospective to thrash out a longer term solution with a root cause analysis or something similar. “Let it not happen again”.
So going over the steps – the team found the problem, we fixed it, then (potentially) 10 days later, we sat down to ensure it does not happen again.
To me, something here is not quite right and it does not sound like kaizen. It is an improvement philosophy and continuous (in terms of every sprint) but shouldn’t we be thinking about these improvements every day?
Kaizen, as Womack and Jones tell us in their 1996 book “Lean Thinking: Banish waste and create wealth in your corporation”, is “continuous incremental improvement”. Do we do that in Scrum retrospectives? Imagine if a sprint is 4 weeks long. It seems a little long and non-continuous to be considered kaizen.
However we should be happy if there are small improvements every sprint and it’s important to celebrate achievements. I’ve also seen teams lose momentum when larger institutional impediments are not cleared. They feel that the retrospective is not worth very much and to repeat the same things to improve again, a waste of time. In this case, any improvement, no matter how small is important.
A slight change to the retrospective
I imagine a stop-the-line mentality for teams. When an important error or problem occurs, we stop, go to the affected area and get to the real cause of the issue. Then we put together a solution to ensure it does not happen again. We don’t wait 10 days for the official retrospective meeting. This is something I have not seen encouraged enough in Scrum.
If we did this, then the retrospective meeting could be used to recap, more like a checkpoint for the continuous improvement in the team.
This way we may begin to see real kaizen in the companies.
