One of the big benefits of Six Sigma is the discipline it brings to the use of facts and measures to guide significant and predictable results. At first glance, that discipline might seem to fly in the face of the flexibility and creativity that also are very important in development and problem-solving. One potential collision of approaches might be Design for Six Sigma (DFSS) moving into a software organization with an Agile development orientation. Without some reaching for understanding, groups on each side of this could become adversaries. However, it is clear that with some flexibility in the way DFSS is viewed, the two approaches share enough to be worth at least looking for synergy and common ground.
DFSS Not a Development Life Cycle
A good starting point would be to clarify the way DFSS relates to software development life cycles (SDLC). While DFSS aligns with the sequence of events in many development life cycles, from requirements through design and delivery, it lives at a broader scope, as a bridge and information pipe between business and development. An SDLC addresses lower-level software-specific things, like configuration management, that are not part of DFSS. In turn, DFSS drives measurement, forecasting, realization and downstream control of business results, which are connected with, but outside the scope of, most SDLCs.
Thus, rather than competing with an SDLC, DFSS actually supports any life cycle by bringing useful facts and data to it, facilitating effective decisions and adjustments to manage risk and value. From that perspective, Agile, like many life cycle approaches, stands to be helped by the tool kit and organizational capabilities DFSS provides.
DFSS Has Always Lived with Agility and Iteration
New product and service development has always been to some degree iterative. For the purposes of learning, a DFSS roadmap is laid out as a linear path. Most projects do not just drive through this, like a car wash, but they learn things along the way, loop back, revisit prior decisions and generally make progress that includes some loops before they are done. Agile, of course, proposes to plan for this rather than just letting it happen.
The figure below loops a DFSS roadmap around on itself, focusing on the activities at each stage that can be built on iteratively. Define, Measure, Analyze, Design/Build, Verify is used here, but any DFSS map could likely be aligned.
Agile-with-DFSS Quick Tour
Define – Seeks to understand the target environment, users, stated and latent requirements, and important results measures. In an Agile world, DFSS would drive for the best global understanding of those things as possible on the first iteration, but could gracefully deal with learning what is possible on one iteration while building on that learning next time around. One aspect of most Six Sigma tools, highly supportive of iteration, is the way they capture, distill, and store data, making it easy for a team to revisit and build on its thinking during a subsequent cycle.
Measure – Includes tools for prioritizing requirements which can help focus effort on the ones most suitable for an iteration. Six Sigma guidance around understanding results measures (Ys) and identifying potential drivers (x’s) can help any software team pay attention to what matters most to customers and the business. That is in line with Agile principles and not necessarily an earmark of behemoth process.
Analyze – Looks at solution choices at the appropriate level(s). DFSS would underline the importance of having an overall architecture and implementation plan as a backdrop and rudder for iterations. This is advocated in the Agile community as well – where DFSS tools for quickly appraising iteration-level learning about the architecture, design/feature set, or implementation could support Agile’s quick but informed thinking. Predicting cost, schedule and performance, even for an iteration, is an important part of the DFSS-driven dialogue with the business. Teams that iterate get lots of practice forecasting and comparing predictions with actuals. For the same reason that geneticists like fruit flies (many quick cycles stack up more learning), DFSS forecasters should like Agile loops.
Design/Build – Constructs the capabilities appropriate for the current iteration. What is meant by “tracking product and process performance” can be auto-sized based on the risk and opportunity at hand for an iteration. At any level of scope or scale, DFSS still offers efficient approaches and tools for managing those aspects of a team’s progress during this stage.
Verify – Checks product and development process performance as appropriate. DFSS drives a dual view of performance – overall and this iteration – providing some effective tools for testing and measuring technical and business results. As an incremental delivery is made at this stage, the target environment is changed – now it includes the cumulative incremental deliveries. The Define phase for the next iteration, still interested in understanding how things work/could work/should work, is informed by the new user and technical interactions with the latest delivery. New learning in that next Define phase can drive the next iteration, with each DFSS stage posing and answering questions using the data and scope appropriate for that cycle.
Checking DFSS Against Agile’s 12 Principles
Tables 1 and 2 separate the Agile founders’ 12 principles into two groups. The first group are the principles that are, a priori, in alignment with Six Sigma tenets. The second group are the principles that initially seem to be at odds with Six Sigma. In each table, the column on the right outlines a few points that characterize DFSS alignment with each principle. Note in Table 2, many of the principles that seem in conflict on the surface are more in alignment when they are understood in the way that the Agile community has followed them in practice and clarified them in discussion.
| Table 1: Agile Principles That Readily Align with DFSS | |
| Agile Manifesto Principles | DFSS Alignment/Support |
| “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” | Strong tools for eliciting stated and latent requirements and connecting them to measurable customer and company value. |
| “Business people and developers must work together daily throughout the project.” | Six Sigma makes requirements and design data more visible – facilitating shared understanding early and often between business and development. |
| “Continuous attention to technical excellence and good design enhances agility.” | Comparing and selecting among design choices based on performance to technical and business measures drives this kind of continuous attention. |
| “Simplicity – the art of maximizing the amount of work not done – is essential.” | Six Sigma focus on what’s important can clarify what not to do – streamlining project effort and schedule. |
| “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.” | Done correctly, Six Sigma projects “auto-size” to cover the risk and value-capture needs of a project or project stage. This helps level out and sustain the long term pace a team can manage. |
| “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” | DFSS also subscribes to this – facilitating face-to-face conversations with facts and measures that keep them crisp and value-added. |
| “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” | As long as this does not mean operating without some bigger picture architecture and plan, Six Sigma also leans away from big-bang delivery. |
| Table 2: Agile Principles That Initially Seem at Odds with DFSS | |
|
Agile Manifesto Principles |
DFSS Challenges |
| “Working software is the primary measure of progress.” | If this meant a “haste makes waste” rush to coding, it would be in strong conflict with Six Sigma. The Agile intent, though, is more to eschew plans and meetings as signs of progress in absence of code. |
| “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” | Closed loop learning is good – and in line with Six Sigma. Taken too literally – with reflection, ungrounded in facts, driving changes – this could induce unwanted variation, with a team yanking itself around. |
| “The best architectures, requirements and designs emerge from self-organizing teams.” | Six Sigma has no problem with the spirit of this – that dynamic and aware teams do a lot better than bureaucracies – but would be in conflict if the statement were applied in a cavalier way, without proper regard for balanced and deep-enough team representation. |
| “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” | Six Sigma might say, “Trust, but verify.” Forecasting and tracking progress – as possible and appropriate for each iteration – are important DFSS tenets. |
| “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” | Six Sigma accepts the need to be robust and responsive regarding changing requirements, but would pay special attention to uncovering and understanding requirements clues early enough to reduce the incidence of requirements surprises downstream. |
This is a very brief touch on a broad and deep topic. And it is an optimistic position, based on experience, that DFSS and Agile have more in common than meets the eye.
