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.
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.
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.
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.
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!
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.
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 f
or 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.
or 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.
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?
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 engineering or software leader!
Jeff Dalton is Chief Evangelist at AgileCxO.org, and a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the Agile and CMMI in all types of organizations. Jeff has taught thousands of students in Scrum Master, Product Owner, and CMMI training classes, and has received an aggregate satisfaction score of 4.97 out of 5 from his students.
Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation, software process improvement and running a successful Agile Transformation or CMMI program.
No comments:
Post a Comment