How Lean Six Sigma affirms agile programming practices

Joe Goss examines how the Define Measure Analyze Improve Control and agile software development methodologies address the eight areas of waste defined by Lean Six Sigma.

At the University of Wisconsin-Madison where I work as a senior business analyst, we recently completed a third year of using Lean Six Sigma (LSS) to improve administrative processes. (LSS is a combination of Six Sigma ideas with lean manufacturing.) By using the LSS methodology, we were able to reduce wasted effort, minimize wait times, and improve overall process outcomes. Independent of that effort, we began slowly implementing agile programming practices and now recognize the improvements it offers within the context of software development. In this column, I'll explore the similarities between the effect of LSS on a process and the effect of agile programming practices on software development.

Note: This blog post is also available as a PDF download. If we think of software development as a process, then LSS could be used to improve the waterfall software development life cycle. For this purpose, it is useful to think of processes in the context of its component pieces; LSS identifies five component pieces: suppliers, inputs, process, outputs, and customers. To help you translate a manufacturing process into a software development process, it will be useful to review Table A. Table A

Suppliers Inputs Process Outputs Customers
Manufacturing Vendors Raw materials Assembly Product Consumers
Software development Stakeholders Requirements Development Software application Users

The Agile Manifesto is an excellent starting point for understanding agile core principles. The Wikipedia entry for Agile Software Development provides basic information about the history, practice, and suitability of this software development discipline.

LSS defines two overall methodologies: one for developing a new project or process design and one for improving an existing process. Since the focus of this column is on improving a process, I'll cover the latter of these two methods.

The Define Measure Analyze Improve Control (DMAIC) methodology is commonly used to identify problems in a process, measure key data attributes of concern, analyze the resulting data, improve the process, and control the future state process to reduce defects.

One of the standard tasks in this methodology is the assessment of process waste. Since waste reduction is also a core principle of agile software development, let's examine how the two methodologies (i.e., DMAIC and agile software development) address the eight areas of waste defined by LSS. Table B compares a poor manufacturing process to some of the failings of traditional waterfall software development. Table B

DMAIC-identified waste category Waste category definition Wasteful manufacturing processes addressed by LSS Wasteful software processes
Transportation Unneeded movement of materials supplied as input to a process Raw materials travel a great distance from the supplier to the manufacturing site. Project team and customer fail to communicate directly with one another about business requirements.
Inventory Materials queued waiting to be processed Excess stores of raw material may cause some loss or decay of inventory. Comprehensive waterfall software requirements specification document is produced for an evolving business.
Motion Unnecessary movement of people and equipment in the production process Worker routinely steps away from the production line to retrieve raw materials. Members of the development team are not located in a shared physical work space.
Wait time Nonproductive time waiting for a production step to resume because of shortages or downtime Worker must wait for a previous step in production to be completed. Developer fails to ask peers for help in addressing a thorny, critical path development issue.
Overproduction Producing more output than is required (e.g., just in case it is needed) Worker creates more output than the next step in the production line can handle as input. Developer adds extraneous features to the software, thinking the customer might like the additional features.
Overprocessing Excessive work to produce a product Worker adds excessive refinement to the output. Developer needs to rework portions of the software.
Defects Return of output to correct flaws in the product Customer receives a defective product. Customer identifies defects in the production software.
Skills Underutilized skilled staff or inadequate staff skills Inadequately trained production workers cause safety concerns or slow the rate of production. Inadequately trained staff slow software development.

Table C describes how even agile "light" helps eliminate waste in the development process. Table C

LSS waste category How agile "light" reduces waste

  • Synchronous, on-demand communication among developers and customers
  • Customers work face-to-face with developers in a common development work space.


  • Requirements and software specifications are provided to developers as needed, allowing the team to more readily adapt to changing or evolving business requirements.


  • A common work area is provided for developers.
  • Daily "stand-up" meetings reduce the need to visit each developer's office.

Wait time

  • Common development area reduces need for asynchronous communication through phone tag or e-mail.
  • Short, overlapping cycles of analysis, development, testing, implementation, and customer feedback minimize wait time.


  • Daily "stand-up" meetings expose extraneous development effort.
  • Maximizing the amount of work not done reduces developers' incentive to "gold plate."


  • Daily "stand-up" meetings identify difficult development problems and coordinate resources to resolve them.


  • Requirements-driven testing by developers reduces the incidence of defects and downstream effect.
  • Paired programming reduces incidence of defects.
  • Integrated testing and frequent software builds increase the probability that defects will be found early.


  • Tight integration of development team promotes sharing of skill sets.
  • Adequate training reduces the need for heroic effort to save the project.
  • Periodic self-evaluation by the development team identifies the need for additional training or support.


In identifying and eliminating waste in a process, the disciplines of LSS DMAIC and agile development share many attributes. While agile practices focus narrowly on improving the software development process, the broad discipline of LSS DMAIC is often used to improve manufacturing and business processes. By highlighting these similarities, it may help you to bring agile development to your organization, particularly if LSS is well established in your organization.

Related TechRepublic resources

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

To all of the Six Sigma devotees: Please tell me how to determine standard deviation for producing a software product. You may define the software product any way you choose. This is at the core of the Six Sigma methodolgy. I am dedicated to improving the process by eliminating errors and risk. Process is similar from one software project to another though it is not identical. There are definitely methodologies that can be applied and, if allowed, will help, but Six Sigma is not one of them. All of the attempts to make Six Sigma fit software development stretch the concepts beyond belief or pick and choose the parts that are applied to suit the outcome.


Six Sigma is a methodology for identifying errors in a repetitive process. Six sigma is a statistical measure of the number of pieces that are out of spec versus the total number produced. Each piece is identical and in agreement with a specification. The goal is achieve that measure by reducing the number of bad pieces. I can never seem to understand how Six Sigma can be applied to software development. If you are producing the same software over and over, the problem should be evident.


Yes the methodology is called Six-Sigma (or Lean Six-Sigma), but don't confuse this with the statistical term relating to the defect levels. What is being discussed is a process, and I agree fully with colinwpa and wel6, that this is exactly what software development is. It is all about reducing input variability and defects, and not just on repetitive processes. The key is to determine the right measures for your process. If you don't have any measures, then you're going to have problems improving. Possible measures for SD could be #errors within code (syntax, semantics etc.), #failed boundary conditions during test, etc. It doesn't just have to be error in code. The Lean aspect targets wasteful parts of the development process, and if anyone can honestly say there's no wasteful processes in SD, then its time for us all to go home...


While Six Sigma reduces variation (defects) in the output (product) it stresses that the output is a function of its inputs and is produced by the process. Therefore the methodology really focuses on improving the inputs (the requirements when we're talking about software development), and on improving the process to reduce the possibility of error. So yes, it is very applicable. When you add Lean methods to reduce the other sources of waste the fit with Agile methods should be obvious, as described in this article.


At the outset the article makes clear we are talking about "process" not "product". In this sense the SDLC is nothing if not a process and hence LSS can be applied to improve the process used in generating software. Obviously we don't generate the same software over and over, but we do try to reuse and improve the process so we can do it better next time.


There are indeed many metrics one can and should use for measuring how good our SD process is, not the least of which is "days late" or "milestones missed", and no doubt many more will come to mind. Agile depends on metrics, it's how the process monitors progress. The point is though that the SDLC is nothing without metrics to see how good we're doing it. At the end of the day its how our customers evaluate and judge us in meeting their expectations.


I agree with colinwpda. Software development is a process and the article is focusing on that process. Sig Sigma does focus on reducing the number of errors, but to do that the software development process must be improved. The real question is, since the end product (A software application) is new each time, how do you measure improvements made to the process. Customer satisfaction is somewhat subjective. The number of bugs depends a lot on the complexity of the application. Numerically comparing each software development project may be challenging, but the basic principles of improving the process and reducing waste as described in the article still make sense.

Editor's Picks