Agile Process Improvement

One of my favorite sayings is “if you want to learn somethig new, read an old book.” For years now, we have been hearing about this thing called Agile Development. It seems there are numerous definitions of what that is and even more variations of Agile in practical execution. I have seen everything from rigid compliance with modern Agile Development standards such as Agile Unified Process to stumbling through a series of high paced mistakes and calling it an Agile approach. The relevance of an Agile approach to software development in the modern age is clear. Numerous forces have converged to make the case for Agile very compelling: Cloud based systems; rapid technological change; useful standards; platform based development; and a growing knowledge gap between IT experts and business leaders. We have all witnessed or at least heard of high profile software failures using drawn out design engineering and waterfall approaches to software development. Examples include the massive Government HR systems, Global Combat Support Systems, and a countless number of industry ERP systems.

Many Agile Development texts, sites, etc. make the connection between Lean and Agile, recognizing that philosophically, Agile is an attempt to make a modern adaptation of agile process improvement methods developed by the likes of W. Edwards Deming, Walter Shewhart, and Joseph Juran as far back as 60 years. Yep, that`s right, Agile is not new. Oh sure, there’s a bunch of new terms and techniques and an emerging mess of beuracracy the merit of which is debatable, but the core value of Agile is the nested set of Agile experiments executed in concert as a learning system to drive superior outcomes in short order. My first exposure to effective implementation of Agile Software development was from a speaker at a Lean conference in 2011. The CEO of Menlo Innovations, Richard Sheridan gave a fantastic speech on the Lean agility that his company was using to reduce mistakes, meet schedules, improve culture, and drive learning. What they were doing was clearly rooted in Lean principles and concepts such as cellular work, one piece flow, in line quality, and visual management.

Now for the irony, the plethera of so called process improvement experts haunting the halls of our corporations and Government agencies are still stuck in the dogma of highly formal, sluggish methods such as the DMAIC. Our consultants regularly see process improvement efforts that span 12 or even 24 months to implement improvements that were generally conceived at the start of the project. In my role as a Master Black Belt for a client, I recently sat in on a final tollgate review so that I could bless a project and allow a trainee to receive his Lean Six Sigma belt certification. This particular project involved simple change of process and policy in only one region, yet took two years to complete. The team rigorously used analytic tools and went through methodology toll gates. After the presentation was over and I did my obligatory questioning on tools, measurements, and ongoing improvement it was decided the project was compliant and the trainee would be annointed. Afterward I asked the trainee if what they implemented was different than what he expected on day one. His answer, “no, my team new this was how to fix it.” So they took two years to do something that could have been done in one month using a more agile approach. The marginal utility of the extra 23 months was a bit more consensus and more certainty that the changes would work, but that’s about it.

I believe one reason this happens is because we have a massive community of Lean Six Sigma professionals that skipped over the foundational principles of Quality and jumped right into DMAIC centric Lean Six Sigma. To make matters worse, many of these LSS professionals have little to no practical experience in production or management. They have made a career of being an outsider that merely facilitates other people’s improvement efforts. One does not have to think too hard to see the potential conflict of interext. As a leader in the process improvement community, I tell you there must be a change. Process improvement experts must adopt, adapt, and use more agile methods where appropriate and in my experience that is at least 50 percent of all process improvement efforts.

At MSI, we have developed and proven an Agile process improvement approach driving rapid results for numerous clients. Of course, we have seasoned experts with many years of operational process improvement experience so we can see the right path well ahead of LSS belts that simply follow a methodology such as DMAIC without knowing where it is taking them or how long it will take to get there. MSI’s approach can be applied in part to isolated projects or in whole to serious transformation efforts incorporating a portfolio of improvement efforts. Applied in whole to serious efforts, the approach incorporates a rapid goal setting and high level systems thinking design endeavor to paint a clear and quantifiable picture of the enterprise’s future state, we then use simplified matrix management, chartering, and reporting techniques to priorItize, launch, and track the work. The process improvement work itself is predominantly a portfolio of nested PDCA projects taking 30 days or less each. Each project cycle generates common outputs feeding control/measurement, process architecture, training, and policy. Further, each cycle improves upon best practices and informs decision making on future cycles. Hence, the approach is a rapid execution, high functioning system that learns, informs, and improves as it rolls through the enterprise. When appropriate, methods such as DMAIC and DMADV are employed for larger scale or more design oriented efforts, but they are also conducted with an eye toward agility, understanding that time is our enemy and the perfect solution may also be the irrelevent solution if it is a day late.