Add some PDCA-Spice to your “Inspect and Adapt”

My beef with “inspect and adapt”

According to legend agile software development almost would have been called “adaptive“ software development. And for a big part that is what agile approaches are about.
It is all about adapting the process, the tools, the interactions to the situation at hand. And most approaches out there have very well defined ways to handle such changes.
But – and it is a huge but – nowadays some people justify everything they would like to change by just invoking “inspect and adapt.” But in some cases (and those are the cases I'm so agitated about) it is only adapt. Or not. Actually sometimes it is only change. But without inspecting first, there is nothing to adapt towards!

What adaptation is, ...

... is for example put nicely by wikipedia:

Adaptation, in biology, is the process whereby a population becomes better suited to its habitat. (emphasis added)

It is not some random change. It is based upon circumstances. Actual facts and requirements. And if one aspires to adapt to something intentionally that just is not possible without knowing those circumstances. In other words: it is necessary to inspect the circumstances.

If you gotta do it, do it right

So yes, you should follow “inspect and adapt” – just don‘t call it a method or try to imply that every time you change some aspect of your process you‘re following the ideas of “inspect and adapt.” If you want to change the ways you work for the better, try employing some formal approaches.

Take some advice from the Lean and Kanban community and follow the so-called scientific method, which – [according to the university of Riverside, CA] – consists of the following steps

1. Observe some aspect of the universe.
2. Invent a tentative description, called a hypothesis, that is consistent with what you have observed.
3. Use the hypothesis to make predictions.
4. Test those predictions by experiments or further observations and modify the hypothesis in the light of your results.
5. Repeat steps 3 and 4 until there are no discrepancies between theory and experiment and/or observation.

One of the approaches that has the thinking behind this ingrained in its DNA is the Deming cycle, often called the PDCA cycle.
The four steps P lan, D o, C heck and A ct actually implement the scientific method for the context of process improvement.

Some things about the PDCA-Cycle come up in conjunction with Toyota’s implementation that seem noteworthy:

• Plan
  build a model of the expected changes to the process – a model also specifying the expected outcomes of the changes
• Do
  try the proposed changes on a small scale, if necessary with extra effort (that can be accounted for in the check step)
• Check
  Verify that the process changes deliver the expected outcomes
• Act
  Roll out the changes to a broader audience, including the automation of labor-intensive tasks or roll back the changes and go to square one (e.g. Plan)

(The rinse-repeat of the whole cycle is somewhat implied by the name cycle, and thus the fifth step – start again with the next idea – is not made explicit)

One more thing... in fact, PDCA is not the Deming cycle – PDSA is

At least according to a guy called W. Edwards Deming this cycle is called the PDSA cycle – and he really should know it...

Be that how it may – the question remains: will you just randomly change things and justify those changes by citing “inspect and adapt” or will you inspect and adapt by following a scheme like PDCA and “install” or “back out” changes based upon feedback collected on some experiment that provided you with real data?

till next time
  Michael Mahlberg