My brother, who is the smart one in the family, and who is now a lead engineer in a multinational wireless company, recently mentioned that their firm is attempting to implement “yet another useless process improvement methodology, Lean Six Sigma.” Ouch! Having completed Lean Six Sigma Black Belt training, I love the tools, about one hundred or so of them. Lean Six Sigma (LSS) has been compared to turning on the light in a dark room towards the end of a house party. Suddenly you notice that someone passed out on your couch, a pile of empty bottles on the table, wine stain on your new carpet, an overflowing garbage can, and other ugly things you didn’t know you had. In terms of business operations, this means that you are now able to see:
- causes of variation, which result in critical defects
- non-value adding activities (NVA), which result in unnecessary long cycles while also adding to the defects.
So why doesn’t this yet produce results for my brother’s team? No tool applies in all circumstances. If not Lean Six Sigma, then could they, perhaps, try Lean on its own or Agile?
There is a lot of literature on LSS and Agile separately, but after searching for several days, I couldn’t find any clear guidelines on when one framework applies better than the other. So, I have come up with the guidelines.
In a separate post, I will examine the similarities and differences between Lean Six Sigma and Agile. There are a lot of similarities. This has not been explored well in the existing literature either—probably because few people have mastery of both subjects. Meanwhile, a bold statement: having extensively studied both Agile and Lean Six Sigma, I am convinced that Lean Six Sigma is a far superior framework—when it can be applied.
Why do I think so? Among other things, because LSS can establish a near-perfect process when things are done right the first time, with no QA, testing, bug fixing or rework. All at the same time, it can produce as few as 3.4 DPMO (defects per million opportunities)–the 6σ level. Even the best Agile teams spend up to 40%-45% of their time testing their code, writing automated tests and fixing bugs. In Lean terms, QA, and defect resolution are considered to be non-value adding activities a.k.a. “muda” or waste. More on that in my next post. Agilists, before you place me on your shit list, see the following graphic. The good news for you is that in many circumstances LSS won’t work at all, while Agile will be very effective.
Based on my experience, the applicability of Lean Six Sigma vs. Agile depends on two key factors: rate of change and scale.
- Rate of change is an inverse of product life-cycle. It is a measure of how often your product or platform undergo significant changes.
- Scale is measured by the number of identical product or service items that you produce every day, week, or month.
So, here we go:
Out of the two factors, the rate of change has a stronger negative impact on LSS applicability than scale. Thus, LSS won’t apply at very high rate of change, even if the scale is high too.
The rationale is as follows:
1. Rapid Change: The Mortal Enemy of a Well-Optimized Process
A typical Six Sigma DMAIC cycle (Define, Measure, Analyze, Improve, Control) takes 4-6 months. Larger DMAIC projects could take up to a year. If you are releasing a very different product, which requires a completely new process, every four months or faster, you can’t apply DMAIC. Same if your platform dramatically changes every four months or faster. You could apply Six Sigma’s DMADV (Define, Measure, Analyze, Design Verify) cycle for new product launches in 2-4 months, but you will barely be able to complete one DMADV cycle before you have to start over again.
Lean Kaizen events could be a lot shorter, only 1-3 weeks. However, Kaizen events produce incremental improvements. You won’t achieve a perfect “flow” and near-perfect quality with just one Kaizen event. Usually, you will need a series of such events. In the environment of rapid change, by the time you are done with the Kaizen series, you will have a completely different process, so you can start over. Lean’s 5S initiative could still be useful even if your product changes. To remind, 5S are the Japanese words: seiri, seiton, seiso, seiketsu, and shitsuke, which are roughly translated as: sort, set in order, shine/scrub, standardize, and sustain. This could benefit the process even if you have to frequently switch from one product to another. I’d recommend it for Agile teams.
2. Scale. Lean Six Sigma – the Groundhog Day of Agile
Scale means that you are producing thousands, if not millions of identical products or service items. That gives you a tremendous advantage to learn about the potential points of failure / variation and systematically eliminate them. If you are part of an Agile software development team, imagine how easy (but boring) it would be to develop thousands of absolutely identical pieces of work over and over again? As you write your code, you’d know exactly where the future bugs could hide. You’d know exactly which part of code you’d have to later rewrite, so you won’t have to write it in the first place.
In the movie Groundhog Day, Phil, Bill Murray’s character, had a chance to execute the same processes over and over again, observe the failures (Measure), establish the cause-and-effect relationship (Analyze), and Improve his approach until he achieved near perfect execution of his day. Phil didn’t have to apply the Control phase of DMAIC, because there was absolutely no variation to control in his day. By applying DMAIC, Phil ended up living a perfect day. He was at the right place in the right time to perform a Heimlich maneuver to a choking person, then saved the dying homeless man. The day culminated with a perfect and successful date with Rita, Andie McDowel’s character. Phil achieved a six sigma level of 3.4 defects per million opportunities.
This is how easy the LSS people have it! That’s how they get down to 3.4 defects per million opportunities without even having to QA their work. They can do things right the first time, because they have done it over and over again and learned from it. Alas, when you develop software or work in RND, or do anything, which has never been done before, there’s no such thing as learning from past repetitions. LSS won’t apply, but Agile will. Agile welcomes change requirements and achieves success through incremental delivery—even if it means a lot of rework.
Why Agile Originated in Software and LSS in Manufacturing
Software developers never write the same code twice. Every app is unique, and every 2-4 weeks you are writing a new and different part of the app. Software developers operate at the bottom-right corner of the chart: lowest possible scale and the fastest rate of change. Contrast this to an assembly line, which produces millions of copies of the same widget. Here Six Sigma’s DMAIC does miracles, especially in combination with Lean. Manufacturers operate in the top left corner.
To be clear, it would be a gross simplification to say that Agile is only for the Software Industry while LSS is for Manufacturing. LSS works miracles in the Service Industry, including Finance, Healthcare and even Advertising, while Agile delivers excellent results for any projects that produce something new and unique. The industry is not at all important. The rate of change and the scale are.
Now, let’s review my brother’s case to see where it fits on this diagram. His team provides advanced support to wireless data carriers. They are the last point of technical escalation, when the carriers’ teams fail to resolve the issue. The environment changes rapidly, and no two issues are ever the same. How can you measure and control variation when no two things you do are ever the same? Agile it is for my brother’s team.