Readers – today I’m happy to introduce our first guest blogger in a while, Leon Tranter. Leon is an agilist and blogger from Sydney, South New Wales. You can follow him on Twitter at: @LeonTranterEU. Welcome Leon!
Moving from Retrospectives to Continuous Improvement
Retrospectives are one of the core ceremonies in Scrum, and considered an essential part of Agile software development. They are even called out specifically in the Agile Manifesto: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This regular “pause and reflect” activity seems to connect the Lean Manufacturing idea of Kaizen or Continuous Improvement to the short time-frame iterative nature of Agile software development.
Many people conclude from this that by performing Retrospectives, a team is thereby doing Continuous Improvement. However, I would argue that this is not the case, and that Retrospectives are in some way a move away from the Lean concept of Kaizen.
The main problem with Sprint Retrospectives is that they are by their nature done every sprint (which is usually a two week iteration). This means that issues that come up during the sprint have to wait up to two weeks before they are brought up at a retrospective. This can make it hard for people to accurately remember the details of the issues, since they are now dislocated from that incident spatially and temporally.
This also means that problems can go uninvestigated or unresolved for one or two weeks during a sprint, further eroding the team’s effectiveness. A once per sprint event is not “continuous”, it is in fact discrete – the opposite of continuous!
The true spirit of Continuous Improvement, from Lean Manufacturing, is that improvement is something that is the responsibility of everyone in the company – not just software developers – everybody, from accountants all the way to the CEO. It is also something that happens all the time – continuously.
When a problem happens, or someone notices a tool or process that is inefficient or not fit for purpose, they must stop what they are doing and call attention to it. And the organisation must treat this seriously and resolve to fix it, ideally then and there.
As an example, Toyota car factories have something called “Andon Cords”, which are cables hung from the ceiling over an assembly line. If a worker notices a problem, they pull the cord – the entire manufacturing line comes to a halt and those in the area huddle around to investigate and resolve the issue.
This behaviour is a true reflection of the meaning of Continuous Improvement, an idea some call “Stop and Fix It”. This requires a significant change in the mindset and behaviour of the organisation, which is usually focused on day to day operations, and deferring non-urgent problems for another day. Retrospectives were designed with good intentions but fit too easily into this mold. Moving to a true Kaizen organisation is a larger shift but with potentially huge payoffs for those that can make the transition.
Leon writes about Agile and Lean at his blog www.extremeuncertainty.com. Why don’t you check it out right now?
Like this blog? Forward to your nearest Agile Leader!
This post first appeared on “Ask the CMMI Appraiser”.