How LSS 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
Transportation	Synchronous, on-demand communication among developers and customers Customers work face-to-face with developers in a common development work space.
Inventory	Requirements and software specifications are provided to developers as needed, allowing the team to more readily adapt to changing or evolving business requirements.
Motion	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.
Overproduction	Daily "stand-up" meetings expose extraneous development effort. Maximizing the amount of work not done reduces developers' incentive to "gold plate".
Overprocessing	Daily "stand-up" meetings identify difficult development problems and coordinate resources to resolve them.
Defects	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.
Skills	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.

Conclusion
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.