Moving from Retrospectives to Continuous Improvement

[Readers - we've been writing about the new version of CMMI lately, but 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 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.

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 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.

Why CMMI?

Hey CMMI Appraiser, I found your blog via a Google search for “Maryland CMMI.” We are a Maryland manufacturing company that uses both Waterfall and agile methods. Quick question: Why CMMI? ~ Todd L.

Hey, Todd - Why CMMI? Well, let me ask YOU quick question … Why dance?

The point is that, like dancing, adopting the CMMI can be a liberating experience. I find it fascinating that the misperception continues, even among CMMI appraisers today, that the CMMI is this heavy, command and control, document-centric cauldron of hard, dreary work and pure nonsense.

CMMI has none of that. It doesn’t tell you how to do anything. It doesn’t “require” anything. The CMMI says, “Here’s what great companies do.” That’s all it essentially says.

Let’s break it down a little more. Here’s what the CMMI is and does:

• The CMMI is a tool to help solve business problems.
• The CMMI helps you change and improve requirements churn and volatility, so that you can spend less time and money on requirements.
• The CMMI helps you be on-time and on-budget.
• The CMMI helps you motivate your staff, and make them better at what they do.
• The CMMI helps you understand and deal with risk, before it hurts you
• The CMMI helps you avoid having too many meetings, unhappy customers and unpredictable projects.

And the CMMI can do this whether you choose agile, waterfall, and any other set of methods.

Why CMMI?  Back to you, Todd: Why not?

Like this blog? Forward to your nearest engineering or software exec! 

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.