Continuous improvement is the one consistent message in all organizational transformation philosophy. In the manufacturing world, it began with “Just-in-time” and Total Quality Movement (TQM) and eventually becoming Lean from the Toyota production system and Goldratt’s Theory of Constraints. The IT world has adopted these philosophies in the form of Agile software development and DevOps. These principles and practices have to lead to many transformation efforts across manufacturing and the IT world.
All of these principle/practice systems are built on the idea of Continuous improvement. Continuous improvement is usually described as iterative changes or a behavior or a “mindset”. I believe that all of the Agile, DevOps, Lean, and like belief systems are extensions of Continuous improvement. Continuous improvement breaks down to Edward Deming’s PDSA (Plan, Do, Study/Check, Adjust/Act wheel) https://en.wikipedia.org/wiki/PDCA. Let’s take Agile for example. In an Agile Scrum process, we have a Scrum and assign story points (Plan), run through our sprint (Do), have a retrospective (Study/Check), then learn from the results and decide where to go next (Adjust/Act).
Lean and DevOps use pretty much same thing with, some variation, of this PDSA approach as well. Mike Rother in the Toyota Kata talks of the “Improvement Kata” that establishes current condition, set the next target condition, execute, and repeat. DevOps has feedback loops at as many places in the pipeline as possible to see the effects of every decision through automation, which is like PDSA loops on crack.
This appearance of PDSA loops and emphasis on Continuous improvement makes me want to abandon all of the Agile, DevOps, and Lean buzzwords. Paraphrasing Goldratt in his Audio series Beyond the Goal, “TQM and “Just-in-time” were replaced by Lean because these words had become lip service.” In today’s world, Agile and DevOps and Lean are not far off at this point either in my opinion (Maybe it’s because every vendor email in my inbox has one of these buzzwords in the title). It’s hard to even get a real definition of any of these ideas anymore. Questions often here in my office is “What is DevOps”, “is it any different from Agile?”, and “what does Lean have to do with IT?” When we can’t define terms that have been around for decades, are they really making an impact?
I come to the belief that we aren’t doing anything unique, special, or even transformational by adopting Lean, Agile, or DevOps, we’re either doing PDSA or we’re not. Everything after PDSA is helping optimize the process. Without the Continuous Improvement and PDSA mindset first, all of the optimizations and efforts are just new faces to the same problems.
Without a thorough and honest evaluation of reality through experimentation against the plans and beliefs we create and hold to, we will miss the mark more often than not. It is by PDSA, which is just the scientific method, that find successful Agile, DevOps, and lean efforts. By working on PDSA I think that our beliefs be more accurate, our assumptions minimized, and our execution more effective.
Continuous improvement, in my beliefs, is synonymous with accurate adjustment. As the world changes around us, we change with it. We make decision based on facts, not beliefs alone nor “gut-feeling”. By frequently and rigorously experimenting we find out what works, what doesn’t, and the right questions that lead to the right answers.
Randomness, divergence, and stubbornness is the enemy of PDSA and any transformation (This applies to new people and older people, no exceptions) will fail unless these internal issues are resolved. If we can learn to let go of our beliefs of reality and embrace reality for what it is, I believe, we will find the answers we are looking for.