Tag Archives: Agile and Six Sigma

Are Agile and Six Sigma Complementary to Each Other?

I recently responded to a question on an online discussion that asked “Are there companies that use Agile and Six Sigma?”.  This raises an interesting question of “Are Agile and Six Sigma really complementary to each other?”. How would you go about blending the two approaches?

Are Agile and Six Sigma Really Complementary to Each Other?

Potentially Conflicting Approaches

There are numerous approaches that might conflict with each other such as:

  • Agile and Six SIgma,
  • Lean and Agile, and
  • Agile and Waterfall

Those approaches have different objectives. If you pursued these approaches individually and independently of each other, the objectives of each approach might be somewhat contradictory. However, if you do it intelligently, it is very possible to blend these approaches in the right proportions.  

  • That requires a lot more skill and
  • It requires a different kind of thinking to see them as complementary rather than competitive approaches

The Fundamental Problem

There is a significant fundamental problem that must be overcome to see all of these approaches in a different perspective:

  1. Companies and individuals get enamored with a methodology like Agile or Six Sigma and see it as a “silver bullet” solution to any problem that they might have
  2. They attempt to mechanically force-fit their business to one of those methodologies without fully understanding the principles behind it

An Example With Six Sigma

When I published my first book in 2003, Six Sigma was very hot and everyone wanted to “jump on the Six Sigma bandwagon”.  At that time, I researched a number of companies that were doing Six Sigma and other process improvement methodologies. What I saw was this:

Successful Companies

In companies that seemed to do Six Sigma successfully:

  • It wasn’t even obvious that it was Six Sigma and they might not have even called it “Six Sigma”,
    • The implementation wasn’t limited to Six Sigma
    • They understood the principles behind Six Sigma, and
    • Might have blended Six Sigma with other process improvement methodologies, and
  • It was very well-integrated with their business.
    • It was just a tool that was part of their business
    • Rather than a program that was superimposed on their business

Less-Successful Companies

In other companies, I saw a much more superficial implementation of Six Sigma that didn’t last in many cases:

  • There was a lot of emphasis on the “mechanics” of doing Six Sigma,
  • There was a lot of “hoopla” about the ceremonies associated with Six Sigma. (green belts, black belts, etc.), and
  • They openly advertised that they were using Six Sigma to promote themselves

Does that sound familiar?  I think a similar thing is going on with Agile today.

The Key Factor for Success

What I learned from that some of the key factor for success are:

  • Don’t get overly enamored with any methodology (Six Sigma or anything else):
    • Don’t think of it as a “silver bullet” for any problem you might have.  
    • Be objective and recognize that any methodology has advantages and limitations depending on the problem you’re trying to solve,
  • Adapt the methodology to fit the problem and the business environment rather than force-fitting your business to some predefined methodology, and
  • Go beyond simply doing a mechanical implementation of any methodology (Agile or Six Sigma) and understand the principles behind it at a deeper level

Are Agile and Six Sigma Really Complementary To Each Other?

On the surface, Six Sigma and Agile would tend to pull you in different directions:

  • Agile emphasizes creativity and innovation as well as flexibility and adaptivity to maximize the business value of the solution
  • Six Sigma emphasizes process standardization and control of a process to minimize process variation

The key to seeing these approaches as complementary rather than competitive is to understand the fundamental principles behind the approach at a deeper level rather than getting lost in the “mechanics” of the approach.

The essence of Six Sigma is attempting to standardize processes and reduce variation in processes.  If you became obsessive about pursuing that goal, it would also not be very consistent with being Agile. However, there is absolutely nothing wrong with attempting to standardize processes to some extent as long as it is also done intelligently and in balance with other objectives.

The importance of “Systems Thinking”

A fundamental skill for doing this successfully is “Systems Thinking”.
Systems thinking is essential for seeing these seemingly contradictory approaches in a much broader context. It enables you to see how these objectives can interact in complementary ways rather than being competitive. Here’s an article with more detail on “Systems Thinking”:

Overall Summary

It is very possible to blend together different approaches that are seemingly in conflict with each other as long as it is done intelligently. It requires:

  • Understanding the fundamental principles behind each approach rather than getting lost in the mechanics,
  • Using a systems thinking” approach to see these seemingly contradictory approaches in a different perspective. Systems thinking enables you to see how they might actually be complementary to each other rather than competitive, and
  • Learning to fit the methodology to the problem rather than force-fitting a problem to any given methodology

This is exactly the approach behind the Agile Project Management online training courses I’ve developed.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

A “Business Centric” Approach to Agile

Many Agile coaching and consulting companies take what I would call a “developer-centric” approach to Agile. It is heavily focused on team-level capabilities and is primarily oriented around improving the development process. There’s nothing wrong with that, in itself; however, people often make the mistake of assuming that whatever is good for the development process must be good for the business as a whole and that is not necessarily the case. I think that a “business centric” approach to Agile is needed.

Frequent Mistakes

What I’ve seen frequently is that

  • People have the belief that any kind of traditional management approach is bad, Agile is good, and there is a binary and mutually-exclusive choice between “Agile” and what’s commonly called “Waterfall”.
  • That over-simplifies what I believe is a much more complicated decision and the result of that is that people often try to force-fit a company’s business into an Agile approach.
  • The right solution, in my opinion, is to go in the other direction and fit the approach to the company’s business and sometimes that may require blending an Agile approach with a more traditional management approach in the right proportions to fit the company’s business rather than force-fitting the whole company to an Agile approach.

How Do You Determine the Right Approach?

Becoming agile for the sake of becoming agile may not be an appropriate goal for all companies. You have to ask “what problem will it solve?” and “how will it really benefit the company?” and the answer to those questions may be very different depending on the nature of the company’s business.

  • Product-oriented Companies – A pure Agile approach is best suited for a company that is in the business of producing some kind of software product (an example would be Intuit and TurboTax or Quicken) or where the software plays a very direct role in leveraging the company’s primary business (an example would be Amazon.com).
  • Project-oriented Companies – Where that is not the case and the company’s business is only indirectly leveraged by the Agile development process (an example would be an internal IT application development project), it can be a lot more difficult to implement an Agile development process because more adaptation may be required to fit the Agile development process to the company’s business environment.

What’s the Key Difference?

Here’s the key difference –

  • In the product development company, the company typically budgets a fixed amount of development effort to produce and sustain the product and the business decision is primarily about prioritizing how that money is spent on creating new features for the product to get the most business impact.
  • That kind of business decision fits very nicely with an Agile development process approach and it’s relatively easy to implement an Agile development approach in that kind of environment.

How Do You Develop a “Business-centric” Approach?

The key to developing a more business-centric approach is that you have to recognize that at an enterprise level, the overall approach must be designed to satisfy the critical success factors of the company’s business.

  • A good model to look at to understand this better is the idea of “value disciplines”. Check out my article on “Agile and Corporate Culture” for more on that.
  • For example, if a company like Walmart is in a business that demands “operational excellence” as the primary value discipline, one of the most important critical success factors in their business is going to be reducing costs to be most competitive.
  • How does an Agile development approach contribute to achieving that objective? The answer isn’t necessarily obvious.

What Is Needed?

What’s needed in this situation in many cases is more of a “top-down” business analysis to identify potential areas for process improvement so that those initiatives are really well-aligned with the critical success factors that are most important to the company’s business.

  • That should be one of the first steps in an Agile transformation for this kind of company.
  • Before you jump to the conclusion that Agile is a good solution to any problem they might have and start working on making them more agile, you have to figure out how its really going to benefit the company and make the company more competitive in the business that they’re in.

It also doesn’t necessarily require throwing out any existing management processes that they may have and making the whole company more Agile. There may be a legitimate reason for some of those management processes that are already aligned with the critical success factors in their business and it may require some compromise to adapt an Agile development approach to that environment.

The “Program du Jour” Approach

In the 1990’s and early 2000’s, I did a lot of work with companies on large-scale process improvement and business process reengineering initiatives and even though that effort had nothing to do with Agile at the time, the methodology you would use to do a business-centric Agile transformation would be very similar.

This is a great example of what I call the “Program du Jour”.

  • When a new management approach like Agile comes along, we often “throw the baby out with the bath water” and consider anything that came before it as obsolete and passé.
  • I saw a similar thing when Six Sigma was hot in the early 2000’s.
    • Everyone wanted to jump on the Six Sigma bandwagon,
    • there was a lot of hoopla about it (like green belts and black belts, etc.), any other process improvement methodology that came before it was considered out-of-date,
    • and people got lost in the mechanics of Six Sigma without understanding how it really helped their business.

I published my first book at that time in 2003 and did quite a bit of research before writing my book. What I found was that:

  • The companies I considered most successful in implementing Six Sigma had so thoroughly integrated it into the way they did business that it might not have been easily identifiable as Six Sigma and they may not have even called it “Six Sigma”.
  • I think a similar thing is needed with Agile today…companies need to go beyond the mechanics of simply implementing “Agile” and figure out how to really integrate it into the way they do business and there isn’t just one canned way to do that.
  • The approach for doing that may be very different depending on the nature of the company’s business.

Blending a Top-Down Approach with a Bottom-Up Approach

To do this, requires a broader approach for implementing an enterprise-level Agile transformation that blends a top-down business-centric approach with a bottom-up developer-centric approach in the right proportions.

The basic approach for doing that top-down “business-centric” approach to identify areas of process improvement for the business might not be a lot different from what we did 10 years ago for some of the business process improvement initiatives and business process reengineering initiatives I was involved in at that time that had absolutely nothing to do with Agile. Check out this article for more on that:

Business Process Reengineering and Agile Transformation

Overall Summary

The key message is that you have to consider an Agile development process in the context of the business it operates in and many times you need to adapt an Agile development process to fit the business environment.

  • Within the development process itself, the process may be largely the same – the differences may come into play at a higher-level such as the project portfolio management layer that wraps around the project.
  • Those higher-level layers could also be Agile (Dean Leffingwell’s Scaled Agile Framework is an example), but that kind of complete, top-to-bottom Agile transformation just doesn’t work in all business environments.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.