Lean Software Engineering

Kanban directly addresses the lean values of pull and flow, but only indirectly addresses the values of value and perfection. It would be useful if our workflow directly spoke to those values, so that we might form a complete process that fully embodies lean principles. There is some tension between value and perfection, so we will need some discipline and understanding in order to bring that tension to a harmonious resolution. As it turns out, there is a product development methodology that is deeply concerned with these values: Design for Six Sigma (DFSS).

I think it’s important to remind ourselves from time to time that we’re interested in lean because we’re interested in pull, value, and perfection, and not vice-versa. If you don’t need these things, if “pretty good and pretty soon” are good enough for you, then there’s no need to fuss with all of this lean business, and craft methods will probably suffice. But if you find yourself in a situation where:

• You have direct competition in a market.
• The consequences of operational failure or poor quality are great.
• You have a large user population.

…then you may need a little more than “pretty good and pretty soon.”

What is Six Sigma?

The title question might appear a little opaque at first, but we can break it down. To begin with, what is Six Sigma and why would you want to design for it? Taken literally, Six Sigma refers to a goal of limiting the frequency of production of defects, defined in terms of variation from a product specification. If you take a closer look at the components of Six Sigma and ask what the purposes or consequences of those components are, you might come away with a more practical definition:

A set of principles, practices, and tools for the systematic improvement of business processes.

Putting things in more neutral cause-and-effect terms helps us to reason about them more objectively. Then you can decide how you feel about systematic improvement of business process, independent of any particular terminology. If you decide that process improvement has value to you, then you may look into the matter and discover that Six Sigma offers one point of view on that topic, as do Lean, Theory of Constraints, and others. Further, most of these systems have some shared history within the field of quality and process control. If you view each of them as a collection of ideas, connected by themes, then you may find a particular combination of those ideas that speaks most clearly to your particular situation. In fact, the cross-pollination of these systems has been a hot topic in recent times.

What is Design for Six Sigma?

In its original form, Six Sigma is oriented towards repetitive processes like manufacturing. Further, it’s oriented towards improving processes that already exist. But if the underlying design of a product or its process is sufficiently flawed, then it may not be possible to “improve” our way to quality. It is better to “design quality in”. Perhaps we can design the product in such a way that it does not need so much improvement in production.

To the end of designing-in quality, a companion methodology was developed, called Design for Six Sigma, or DFSS. The goal of DFSS is the economical development of high-value, high-quality product designs. Like its complement, DFSS is a collection of theories and practices that work together in service of that end.

The components of DFSS each have long and illustrious histories in industry in their own right. They include:

• Quality Function Deployment: A theory of customer value. Practices for discovery of customer value, analysis of competition, priority of product features.
• Theory of Inventive Problem Solving (TRIZ): A theory of technology evolution. Practices for the systematic discovery of high-value design problems and their solutions.
• Pugh Concept Methods: We don’t want the first design we think of, we want the best design we think of, and we want options.
• Failure Modeling (FMEA): Practices for discovering what’s likely to happen outside of your carefully controlled development environment.
• Design of Experiment: Design notations like source code describe what we want the system to do. Now what does it really do?
• Taguchi Robust Design: The real world is noisy and unpredictable. Robust systems work well in spite of this.

and perhaps most importantly:

• Axiomatic Design: A rigorous theory of design structure. Practices for evaluating design quality and decomposing design structure.

Some versions of DFSS include Axiomatic Design and some don’t. For those that do, Axiomatic Design is the conceptual glue that binds all of the other pieces together (like the Force). For those that don’t, QFD plays that role.

I wouldn’t be me if I weren’t disdainful of tribes, hype, and comprehensive branded methodology frameworks. Nonetheless, the way that the DFSS practices complement one another is remarkable. Understanding how they complement each other also illuminates how to fit each practice into your own process. Is there any value in “doing DFSS”? No. Is there value in designing robust products? Yes.

How does Design for Six Sigma relate to software development?

DFSS does not have much to say about writing code. Neither does it have much to say about drawing circuit schematics or mechanical drawings. This is because DFSS is about systems engineering and product design, independent of any particular technological domain. Any system that can be decomposed into parts and is subject to economic calculation in its development is within the scope of the methods of DFSS.

This has some interesting consequences, not the least of which is that it puts software development on an equal footing with other engineering disciplines within the context of product development. You do not want to hear: The Boeing 787 is a marvel of modern engineering…except for these 6.5 million lines of code, which were merely ‘developed’. DFSS relates all design decisions to all other design decisions, and holds them all to the same quality criteria, regardless of how they are notated or which mathematics they use.

The questions that DFSS addresses are fundamental to software development: quality, value, reliability, robustness. DFSS, by its nature, offers the best thinking on these subjects. If software developers have not caught up with this yet, it is because currently popular software development methodology is deficient. But this idea is catching on. Jayaswal and Patton’s Design for Trustworthy Software is exactly about DFSS for software development, and I think there will be more books to come on this subject.

How does Design for Six Sigma relate to Lean?

The intersection of Lean and DFSS is the state of the art in product development. Part of the importance of Axiomatic Design to DFSS is exactly that it provides a theory for incremental, iterative, and evolutionary design. Suh’s Independence Axiom shows that the best designs for evolutionary development are simply the best designs. Conversely, any design that would be considered ideal could have been constructed by an evolutionary process. That is, the criteria for design ideality and evolution are one and the same.

Suh’s design axioms apply directly to software systems. They unify all other DFSS methods, and they unite DFSS with lean development and evolutionary design. The intersection of Lean Thinking, DFSS, and Software Engineering is coming, and it is very exciting! Perhaps we might call it Robust Evolutionary Design.