There’s a lot of literature on Lean Six Sigma (LSS) and Agile separately, but I couldn’t find a good comparison between the two frameworks–possibly because few folks have significant training and experience in both subjects. In my previous post I attempted to define the applicability criteria for LSS and Agile. The goal of this article is to dive deeper into the similarities and differences between the two methodologies.

This post assumes some familiarity with both Lean Six Sigma and Agile. In case you are new to one or both of these frameworks, here are quick summaries:

30 Second Intro of Lean Six Sigma

• Lean eliminates non-value-adding activities (NVA) and shortens the Cycle Time and Lead Time.
• A litmus test for NVA is asking yourself “if your customer knew about the activity, would she pay for it?”
• Cycle time (also called Takt Time, which derives from the German word taktzeit) is a rate at which product or service items are produced.

For example, a Cycle Time of 45 for Toyota means that a new Toyota rolls out of the production line every 45 seconds. Lean processes are typically synchronized to the Takt Time.

• Lead Time is the time to produce a new product from start to finish. You place an order for a new Toyota Prius with customizable features, and it arrives to the dealership near you after X days.
• After Lean has eliminated NVA, Six Sigma cuts down defects of the remaining value-adding activities by systematically reducing the variation of critical to quality processes. It does so through the DMAIC cycle, more on that later in this post.

It’s been said that Lean moves Mean, while Six Sigma reduces Variance. The NVA that Lean eliminates also happen to be significant sources of defects. Thus Lean and Six Sigma work synergistically and are typically applied together.

30 seconds on Agile

Agile delivers a working product in small increments (iterations), while always delivering the most valuable features first. Agile methodologies are an alternative to the traditional (Waterfall) project management cycle. In contrast to the Waterfall phase-gate method, Agile promotes adaptive planning and welcomes changing requirements. Agile teams stay close to the customer and rely on frequent customer feedback. Agile relies on small, co-located, self-organizing cross-functional teams, which are given a high degree of freedom in how the product is developed. There are multiple forms of Agile. Most popular include:

• Scrum
• Extreme Programming (XP)
• Chrystal Methods
• Dynamic systems development method (DSDM)
• Scaled Agile Framework (SAFe)–used for large projects
• Kanban (a Lean tool borrowed by Agile)
• Scrumban (Scrum/Kanban hybrid)

However, all forms of Agile are based on the five-point Agile Manifesto and the twelve Agile Principles. While Agile originated in the software industry, it applies in many other industries and project types. Agile thrives in unique one-off projects with constantly changing requirements.

(I) Similarities between LSS and Agile

Reducing Waste: Lean Way vs. Agile Way

One should not speak of Agile as separate from Lean. Agile is based on Lean. In fact, Lean software development (LSD) and Kanban are often classified under Agile, even though these are purely Lean methods. Among other things, Agile borrows Lean’s idea of eliminating Non-Value Adding activities (NVA) or waste, but it goes about doing so in a slightly different manner.

Lean identifies eight forms of waste, which are easy to remember using a DOWNTIME mnemonic:

• Defects
• Overproduction
• Waiting
• Non-utilized / underutilized talent
• Transportation
• Inventory Work-in-Progress (WIP)
• Motion
• Excessive (over)-processing

Defects and Excessive processing NVA are eliminated through error-proofing (Poka-Yoke) and Kaizen initiatives. Kaizen is also used to reduce the Motion and Transportation waste. Six Sigma reduces the defects even further through identifying and eliminating the root causes of variation. Waiting is reduced by shortening the cycle, while Non/underutilization of talent is reduced by Heijunka (load leveling). To eliminate Overproduction and Inventory WIP, Lean replaces the traditional Push system with a Pull system (Kanban), where the customer pulls an order in for a new product or service item to be produced, which then triggers orders to replenish the parts, etc.,—all the way through the value chain to the suppliers.

One of my favorite videos, explaining Kaizen initiatives in terms of one’s kitchen:

Agile borrows Lean’s idea of eliminating NVA in the environment of rapidly changing customer requirements, which Agile welcomes. According to Agile, the biggest kind of waste is delivering features that the customer does not want—or no longer wants. Agile eliminates such waste through frequent and early iterative delivery and frequent check-ins with the customer, during which the customer determines which features need to be produced next (a Pull system).

Shortening Lead Time and Cycle Time

Lean aims at reducing Lead Time (time to develop a new item, starting from the customer request) and Cycle Time (items / hour).

Similarly, Agile dramatically shortens both the time to deliver a new feature and the product release cycle time. The traditional (Waterfall) software development cycle assumes several stage gates:

1. Requirements gathering
2. Design
3. Code
4. Test: system and user acceptance

With the Waterfall software development, it could take 6-12 months before a customer could see any value. By the time the client sees the finished product, the market and the competitive environment changed to the point that they no longer need many, if not most, of the features. The long cycle represents the single biggest source of waste according to Agile. The widely-quoted Standish Group study of 2002 states that as much as 64% of software features are rarely, if ever used–for this very reason. It turns out that the study was fairly limited in scope, and should be taken with some skepticism. Nevertheless, this form of waste is very prevalent in the Software Industry.

Agile OODA Loop vs. DMAIC

OODA Loop, originally defined by Colonel John Boyd to train other fighter pilots, is widely adopted by the Agilists. Short product development iterations are followed by review, analysis, appropriate action and a feedback loop (Retrospective)
        Observe – collect information from as many sources as practically possible.
        Orient – analyze the information, and use it to update your understanding of reality.
        Decide – determine a course of action.
        Act – follow through on your decision.
DMAIC cycle (Define, Measure, Analyze, Improve Control) is the basis of Six Sigma.
        Define the customer and their key requirements in terms of Critical to Quality Characteristics (CTQCs)
        Measure the performance of the core business processes, which affect CTQCs
        Analyze the data collected in the Measure phase to identify root causes of defects
        Improve the processes by eliminating the root causes of defects
        Control the improvements

One can’t help but notice that DMAIC is a slow (3-6 months) and thorough version of the OODA loop:

OODA	DMAIC
Observe	Define
	Measure
Orient	Analyze
Decide
Act	Improve
←Feedback back to Observe	Control

II) Differences between LLS and Agile

Quality Is Defined Ahead of Time

Lean Six Sigma DMAIC projects have the advantage of being able to define quality ahead of time. This is because DMAIC improves an existing product, and you can simply ask your customers to rate the importance of each quality characteristic. You can the build a House of Quality, which translates Critical to Quality Characteristics (CTQCs) into Critical to Process (CTP) parameters. For example, if you run a coffee shop, you will notice that your customers cluster in two groups:
    1. morning rush hour office workers looking for a quick caffeine fix
    2. afternoon leisure visitors, looking for a great experience.

The morning rush hour customers might tell you that consistent lead time of 2 minutes or less is critical, while an artistic Christmas tree ornament on the latte foam is of tertiary importance. You can then optimize the process to ensure that the most important CTPs are taken care of. For example, you might eliminate complex drinks, which delay the rush hour line, from your morning menu. You might also conclude that you need to acquire an espresso machine with high throughput to eliminate the bottleneck. For the afternoon leisure visitors, you’d optimize towards very different CTQCs.

Agile, which is often used in developing new products and features, cannot afford the luxury of knowing what quality means ahead of time. The CTQs are unclear, and they change rapidly. For new products, which are the domain of Agile, customers often don’t even know what they are going to like until they see it.

Using Inspection/QA to catch bugs? Shame! Shame! Shame!

Agile relies on inspection to catch and resolve defects. For Lean Six Sigma practitioners, relying on inspection is a sign of miserable failure. It means that your process is such that you first produce defects and then spend time fixing them. Shame, shame, shame! W. Edwards Deming, the father of Total Quality Management (TQM), a precursor to both Six Sigma and Lean said: “Quality cannot be inspected into a product or service; it must be built into it.” Every time you perform an inspection or testing to catch bugs, Deming turns in his grave. Bug fixing is one of the forms of waist in Lean. According to both Lean and Six Sigma, the process should be such that you produce near-defect free product right the first time with no inspection required. Realizing this disadvantage, Agile software development attempts to make the inspection cheaper, by relying on automated testing and Test-Driven Development (TDD) as much as possible. Nevertheless, even the most efficient Agile companies spend over 40% of their time on testing and QA.

What Comes First: People or Processes?

The very first tenant of the Agile Manifesto reads:
“We value individuals and interactions over processes and tools.” While this does not mean that processes are unimportant, Agile is not as rigid with its processes as compared to LSS. While Agile recognizes that there are general legal, quality and regulatory “guard rails”, most Agile teams adapt the process according to what works for them. Since I started with LSS before learning Agile, this gave me quite a bit of discomfort. In my opinion, the risk comes from low frequency but high impact defects. Because such defects are extremely rare, a small self-organized team would not have worked enough time to see them happen. Thus, left to its own devices, the team would not build its processes around preventing such defects. For example, while having the pleasure of being a Cleveland Clinic patient, I was amazed how every nurse that worked with me asked me for my name and date of birth before any procedure–even though some of them knew me very well and saw my name and date of birth on my wrist tag. If these were Agile teams, they could have decided this was a useless practice, a waste of time. Failure Modes and Effects Analysis (FMEA) is one of my favorite LSS tools. It prioritizes defect prevention effort based in Frequency, Impact and Discoverability. An act of administering a wrong drug to a patient might be extremely rare, but when it happens, it can kill a patient, and the effect would not be discovered until it was too late. Thus, this defect would get a high FMEA score for the Cleveland Clinic and would be high on their priority list.

LSS declares that a great process is paramount. It even states that people are happier than the process is great. When folks don’t waste time on rework and when they face happy customers instead of dealing with frustrated customers, the work is more enjoyable and satisfying. Fix the process and people will be happier.

This is exactly what happened when Toyota management transformed a dysfunctional General Motors’ Fremont, California plant in 1983. They re-hired and re-trained the same workforce, which was considered to be among GM’s worst. Prior to the takeover, absenteeism had regularly reached 20% or more, but following the Lean transformation, it immediately fell to as low as 2%.

I’ve seen the effect of better processes on job satisfaction and morale when we applied LSS at Manta Advertising Operations. Many of our campaigns did not produce the results that our clients wanted—despite tremendous effort by Campaign Managers, who painstakingly optimized each campaign. After a few weeks of measurement and analysis, we noticed that a major source of variation and defects was upstream, in the proposal creation phase. Because people who created proposals were not the same as people who optimized the campaigns, learning from optimization did not carry into the next proposal. Often, the proposals would include campaign elements, which were proven to be ineffective during the previous round of optimization, and the initial performance upon renewal was mediocre at best. As a result of the LSS project, we ended up marrying the proposal creation and optimization roles. The result? A year later nobody could remember the last client that ever canceled. Instead, many of our advertisers would give us additional budgets, which they’d take away from our competitors. The Campaign Managers became noticeably happier. They could take pride in the results of their work.