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.

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.

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.