Using Six Sigma Tools in an Agile Software Project

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Doing Some Software Six Sigma and Agile ‘Mythbusting’ Software Development Convergence: Six Sigma-Lean-Agile Exploring Defect Containment Metrics in Agile
	Discussion Forum "....We have an 'Agile' process for software development which integrates into a set of engineering processes. How does Six Sigma relate to Agile software development? Doesn't it add significant extra process into the development cycle?" Contribute to this Discussion

Download Products Design For Six Sigma (DFSS) E-Book or Print Business Process Management Power Tools Project Selection Process Pack

By Yousuf Ahmed

It may be counter-intuitive to consider using Six Sigma tools in an Agile software project. Six Sigma's genesis was in the manufacturing world where one of its primary goals has been to reduce process variation. On the other hand, Agile software development is built on the premise that complex software projects, unlike manufacturing, cannot be successful in an environment using defined process control. Instead, Agile development supports empirical process control that relies on continuous inspection and adaptation of the process used.

Six Sigma offers a groundbreaking way of reducing defects in the end product – something that any software project can definitely use. Hence, it makes a lot of sense to at least evaluate the possibilities of integrating both processes.

Agile software methodologies, based on the principles of the Agile Manifesto, are typically adaptive processes that provide a process framework. This framework guides a development team to build software using a process adapted to suit the domain of the project. This approach actually opens up possibilities of using appropriate tools, including tools of Six Sigma, that can help improve the quality of the product.

There are many areas of software development that can benefit from Six Sigma. The fact is, there is a low-barrier approach to deriving benefits of Six Sigma, in a controlled way, while following an Agile software development methodology.

Before going any further, it is important to acknowledge that Six Sigma is a major initiative usually involving the entire organization. The scope of a Six Sigma project often is much wider than a single software project. Therefore, this discussion will be limited to only certain aspects of Six Sigma that can be implemented relatively easily and provide maximum return on investment.

Requirements Management and Six Sigma

Not understanding customers' real needs is probably the single most common reason for failure of a software project. Requirements errors also are the most expensive to fix – these errors can easily consume 25 percent to 40 percent of a project budget, according to Dean Leffingwell and Don Widrig in their book Managing Software Requirements: A Unified Approach.

Agile methodologies address the problem by using an iterative and incremental approach. The Agile approach has made it possible to work closely with the customer, understand the requirements and implement the functionality progressively and in collaboration with all the stakeholders.
At the same time, one of the primary objectives of Six Sigma is to align business goals with the requirements of customers. The DMAIC (Define, Measure, Analyze, Improve, Control) phases are focused toward the expectations of the customer and provide valuable tools to address these.

This leads to the conclusion that Six Sigma tools and techniques, if used in conjunction with the Agile process, can enhance the effectiveness of gleaning the real needs out of customers. Here is a look into some tools of Six Sigma and how they can be used in Agile software projects. Two popular Agile methodologies, Scrum and Extreme Programming, are used in the examples.

Using Voice of the Customer

The voice of the customer (VOC) technique is used in Six Sigma projects to understand customer needs. The technique guides the project team to identify the customers and collect data from them both reactively and proactively.

In an Agile software project, the problem of being disconnected from the customer is largely removed by having a customer representative present at team meetings. However, in a complex project in a large organization, it is possible to have many direct and indirect customers, making it impractical to get everyone in a room for the sprint review meeting (in the Scrum methodology) – or the release planning meeting (in Extreme Programming).

Using VOC ahead of time to prepare for the sprint review meeting will help make the meeting much more effective. The sprint review meeting in Scrum is a meeting that includes the primary customer – known as the product owner – and the development team. The goal is to review and prioritize the functionality to be developed in the next 30-day iteration – known as a sprint. The table below shows how the product owners can get critical information to help them prepare for the sprint review, so they can help effectively guide the development team in building the right product.

Steps for Collecting VOC Prior to Scrum Sprint Review
Step	What Needs to Be Done	Who does it	When
1	Identify all direct and indirect customers affected by the upcoming sprint	Product owner	A week before sprint review
2	Prepare targeted questionnaires for each customer group	Product owner, Scrum master	A week before sprint review
3	Collect answers for the questions through direct conversation, email, etc.	Product owner	Two to three days before sprint review
4	Review any existing forms, issue log, etc. to identify customer pain points	Product owner, Scrum master	Two to three days before sprint review
5	Prepare for the sprint review meeting with additional knowledge of all customer needs	Product owner	One day before sprint review

Building a Critical-to-Quality Tree

Creating a critical-to-quality (CTQ) tree helps in translating customer requirements into measurable characteristics needed in the final product. The development team needs to translate the data gathered from customers into specific features in the product that meet those needs.

Using the example of the Scrum project workflow above, the team works with the product owner in the sprint review meeting to draw out the CTQ tree. A CTQ tree takes customer requirements expressed in non-product terms and extrapolates specific features that can be developed. This can be a useful exercise in a sprint review meeting. It allows the team, along with the product owner, to brainstorm a solution from a requirement often expressed in a generalized way.

Critical-to-Quality Tree for a Customer Need

Failure Mode and Effects Analysis for Design

Failure mode and effects analysis (FMEA) can be a difficult tool to implement in an Agile project; nonetheless, it can be extremely effective in certain cases. While there are many types of FMEA, considered here is a simplified design FMEA that keeps the visibility on potential design failures as new requirements are elicited with the progress of the project from iteration to iteration.

Agile projects are fundamentally iterative projects that focus on building incremental code complete in all respects in every iteration. A design decision made in one iteration – based on the requirements as understood up to that point – may become a risk for a subsequent iteration as new requirements are gathered. By maintaining a FMEA for design and evaluating it at each iteration, the development team will be able to ensure that many potential failure points are analyzed ahead of time. For every major design decision (e.g., extent of normalization of a database), the team can evaluate the potential failure mode (the defect), the potential failure effect (impact on the project), the possibility of occurrence and the risk. This can lead to a cost-benefit discussion with the customer and potentially avoid costly implementations with little value.

Obviously, not all failure points will be foreseen. But the team will be consciously evaluating the risk and possibly be able to reduce re-factoring time considerably.

About the Author: Yousuf Ahmed is employed by Valtech Technologies as an engagement manager handling major client engagements. During his more than 16 years in software development, he has played a multitude of roles, both in product development and consulting. He can be reached at yousuf.ahmed@valtech.com.

BEST SELLING PRODUCTS (iSixSigma Publications) Six Sigma Black Belt (DMAIC) Training Slides - 2009 Version! The 2009 Six Sigma Black Belt course includes over 40 more slides than the 2008 version. Contents include: 1,220 PowerPo... Certified Lean Six Sigma Black Belt Assessment Exam Interested in assessing your knowledge of Lean Six Sigma? Preparing for certifications? Testing your students and traine... Certified Lean Six Sigma Green Belt Assessment Exam This assessment exam is useful for students interested in assessing their knowledge of Lean Six Sigma on the Green Belt ... Certified Lean Six Sigma Black Belt E-book In 670 pages learn everything within the Lean Six Sigma DMAIC body of knowledge to successfully achieve Black Belt certi... Kaizen Workshop E-book This 150+ page ebook teaches key tools and techniques of Kaizen, as well as real application to enhance learning. Kaizen... Six Sigma Yellow Belt Training Slides - 2009 Version The 2009 Six Sigma Yellow Belt course is comprised of: 503 slidesInstructor notesSlide explanations15 data sets19 suppo... Design For Six Sigma (DFSS) E-Book or Print Need an "encyclopedia" consisting of many of the tools you’ll study? Need a helpful refresher to apply the DFSS process?... Sell Your Products