Should Scrum integrate with Six Sigma?

 

My recent post in the PMC discussion forum and the excellent replies about the utilization of Earned Value Management and Six Sigma's Statistical Process Control, got me thinking about how this differs from Scrum and its use of Empirical Process Control.  This article from Scrum Alliance seems to advocate that both techniques can co-exist, and my initial thought is that they could.  And since the focus on my blog is “bridge the gap between traditional and agile project management”, I thought I’d write about how they could.

But as I thought it through and reading the replies to the Scrum Alliance article, my feeling is that they should not co-exist.  In fact, the question could be “why would you want them to”?  This reply from a reader expresses the same sentiment:

(Six Sigma) is largely about reducing variation, which is one of the key control methods in (repetitive) production. Product creation, on the other hand, is very much about innovation and generation of understanding in a once-in-a-lifetime environment. I find these two fundamental approaches very much in opposition to each other.

At the core of Six Sigma is the need to reduce variation while simultaneously increasing quality for well defined projects and processes, whereas Scrum is used for ill defined projects or processes that have never been solved before or is heavily dependent on feedback to determine when the problem has been solved correctly 

Projects that require detailed and process oriented planning would be best served with Six Sigma statistical control.  This would especially be the case for projects with good historical artifacts, or projects with very similar scope and requirements, e.g., a project to build an extension to a data center with the requirements that it mirror the existing one.  In this example, I would be confident of being able to establish a firm baseline for scope, cost and schedule.  When the project gets executed, I could use EVM and Six Sigma statistics to reduce variation and increase quality.

But what if my project involves something like creating a new software system or product that will capture untapped market share for my company?  In this instance, you’ll most likely have vague, incomplete or too high level requirements that will have to be prototyped, tested and reworked in short iterative “sprints”.  From this perspective, variations could be a good thing as it could clarify and reveal requirements the customer was not aware of till revealed in demo session of the prototype.  

I was involved in just such a project for a new software application where at each two week demo, the customer would request new features which would be incorporated into the prototype until a fully functional application with all requirements were delivered.  This application was eventually deployed into production with very little changes.

Much as Six Sigma is executed with SPC, Scrum is executed with EPC which advocates obtaining information by means of observation, experience and experimentation.  This is done in a continuous cycle of inspecting the project deliverables with customer feedback to ensure correct operations and results are obtain and adapting and changing the process as needed.

Through Scrum is a light weight project management framework that has a strong Lean process bent to eliminate waste, some have taken that to mean it does not have a rigorous foundation.  EPC if utilized properly can be a very disciplined way to manage uncertainty and complexity for things like the development of new software systems.

In conclusion, given the different approaches and the problems they are trying to solve, I don’t think in this instance you should be integrating Scrum and Six Sigma.  If your project’s parameters and scope are well defined, then it would be a better approach to use Six Sigma to control variation and quality, but if your project is not well defined then use Scrum to control variation and quality with empirically validated feedback from your customers.