|
Kanban is a mechanism for organizing and operating a process, but it is not the process itself. Kanban must be matched up with a particular value stream or workflow in order to form a complete process. Since we are concerned with the specification and design of new systems, we should evaluate development workflows to find complementary matches.
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:
…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? 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:
and perhaps most importantly:
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. |
{ 2008 01 07 }
Richard Durnall | 08-Jan-08 at 12:49 am | Permalink
Really interesting post. I’ve always found the intersection between 6-Sigma, DFSS, Toyota Production System (TPS) and Toyota Product Development System (TPDS) an interesting one; a Western response to the Japanese threat. I’m lucky that I got to study them in a manufacturing context before I had the opportunity to apply them to software delivery. I find that because they have their roots in PDCA cycles they can all live happily together. The big challenge with DFSS and 6-Sigma I found is that you need a brain the size of a planet to fully understand the stats and this focus on statistical modelling can lead to ‘management by numbers’. Lean offers a broader context and having it’s basis in Training Within Industry (TWI) principles gives it more of a focus on people, teamwork and culture. You’re doing some interesting and valuable work; impressive.
Corey Ladas | 08-Jan-08 at 1:47 am | Permalink
Thank you, Richard. I appreciate the encouragement! I share your concern about statistical excess. My most important statistic is “probability of method being correctly applied,” which would seem to be inversely proportional to the density of numerical methods involved. So I’m always looking out for simple heuristics that give you most of the benefit of the math, without actually having to do the math. TOC, kanban, Axiomatic Design, all have that property of simple rules of thumb with analytical interpretations that you won’t need if you apply them well. I don’t want to spend a lot of time on the math either. I’m just a programmer who gets very irritated with stuff that doesn’t work.
Eric Landes | 08-Jan-08 at 6:34 am | Permalink
Corey, extremely interesting post. While I work in a manufacturing company, I haven’t been exposed to Six Sigma in Practice yet. I’d love to hear how you are implementing these principles within your software projects. Specifically how these principles happen within the project (Silos in Kanban, just part of a Silo named design?). Thanks, keep up the interesting work.
Corey Ladas | 08-Jan-08 at 12:46 pm | Permalink
Thanks Eric
Different parts of DFSS will straddle conventional software stages, some parts go to analysis, some to design, some to test. I dropped a hint about DFSS kanban in this post:
http://leansoftwareengineering.....nban-team/
I promise I’ll revisit the workflow/kanban topic
Rob | 10-Jan-08 at 1:41 am | Permalink
When implementing DFSS it is important to make the distinction between what you are actually designing. Is it a process, a service or a product?
While new process design may involve only a few of the organization’s functions or departments, the design of a new product or a new service has stakeholders throughout the company’s value creation process. Additionally, if errors or omissions in product design data are not addressed early, more costly changes are required later in the product development process.
The difference between product and service development is the level of detail and complexity mainly in the Optimize phase of the DFSS project. In product design projects, the Optimize phase is the phase when the design “becomes real.” First prototypes will be built; data must be collected on tangibles even if simulating the processes.
Advanced DFSS programs include a number of tools for the Optimize phase mainly for product design. Typical Six Sigma tools such as design of experiments may be advanced by robust design principles or mixture design concepts. It is however, critical to choose the right tool at the right time. This becomes especially important if Six Sigma is run in conjunction with Lean as sometimes stakeholders can become confused.
Some organizations consider going for Design for Six Sigma right away and not starting with process improvement (DMAIC). This seems attractive: DMAIC always means searching for problems that can be solved – and a lot of organizations (responsible persons?) do not want to admit to having problems.
Nevertheless, there are a number of good reasons for starting with DMAIC even in a creative or engineering environment: Budget-effective financial savings can be reported within a limited time frame, a number of projects can be executed simultaneously and internal success stories can be created, proving that Six Sigma works here!
Corey Ladas | 10-Jan-08 at 4:23 am | Permalink
Hello Rob,
Thank you for your comment, and welcome!
For the most part, I’m talking about software products and services, and I should emphasize that I’m talking about applying methods that are associated with DFSS in the service of evolutionary design. Meaning that phases like Optimize are overlapping and continuous, prototypes are continuously built in testing and staging environments, and design improvements are continuously released into production as long as it remains profitable to do so.
From my point of view, evolutionary design is the goal, and DFSS provides a useful box of tools in service of that goal. How to manage evolutionary design is what we spend most of our time talking about here
Clint | 04-Aug-10 at 6:05 am | Permalink
Hi Corey,
I found this through a Google search and at first I thought I was on the wrong page and then I though I was going to have something negative to say in response. But then I realised that this was all about software.
My interest in Robust design, DFSS and such is within the context of engineering design (mechanical, civil, electrical etc.). Within that context I have always thought of noise as being things like manufacturing operation randomness, wear, temperature changes and stuff like that. I always thought of software as being more precise. It’s not like the program comes out a little different each time it is copied or the code changes with time. So I am really fascinated by the application of methods that I think of as being probabilistic (robust design especially) in the software area. What is the randomness or uncertainty that you normally need to be robust against when developing software?
Corey | 04-Aug-10 at 2:18 pm | Permalink
Hi Clint,
Complex software is not at all deterministic. The code might not change over time (not always a reasonable assumption), but the execution of code can vary in unpredictable ways. Think of the Mandelbrot Set, generated by the simplest of programs:
Zn+1 = (Zn)^2 + C
Some algorithms and program structures are intrinsically non-deterministic. A goodly chunk of Computer Science has been devoted to distinguishing which ones *are* deterministic. Multi-process programs are especially difficult to design and verify, and the history of software engineering is littered with the corpses of expensive systems brought down by obscure race conditions.
Software always operates as part of a system, and noise can come from the analog part of the system i.e. the physical components that the software depends upon. Noise also comes from the operating environment. Software interacts with the world through inputs and outputs which are subject to the variation of the analog world. Software is designed to act upon data it expects, and can behave badly in response to data it doesn’t expect.
Probabilistic methods have been used in software design and verification since at least the 1960s. Software systems are often designed and tested in controlled environments that do not accurately model the conditions of the real world. Robust design techniques can be used to write more realistic specifications and discover unexpected interactions between the parts of a system.
tl;dr:
* Ideal programs running on ideal computers in an imperfect environment can be nondeterministic.
* Ideal programs running on imperfect computers in an ideal environment can be nondeterministic.
* Ideal programs running on ideal computers in an ideal environment can still be nondeterministic.
Dustin | 17-Apr-11 at 11:14 am | Permalink
Cory,
I am hugely regretful for not running across this sooner! I’m also a software engineer thirsty for a better answer to quality management in software, and too have made connections to the quality management systems employed in automotive and other engineering disciplines. It also annoys me greatly that software development is not ubiquitously observed as an engineering discipline! At any rate, I share and commend your beliefs and ideas.
A couple general ideas though in response to “probability of method being correctly applied”: I think a lot of this is being solved through compiler innovations these days. Think templates in C++ or generics in C#. Also the notion of type inferencing and lambda expressions in both C# and now the C++0x standard, and the notion of co/contra-variance (think interface duality). Stuffing much of this down in the tooling allieviates both the expertise AND burden from the developer masses (if applied). Also, I’ve just as surely you have found patterns and principles to be effective vessels of better quality. The only thing lacking would be proof through numbers. Food for thought. For example, in SOLID principles, low cohesion is observed to improve robustness through a software lifecycle, just no hard data to prove it (yet).
On a more objective thought, the application of DFSS and the dreaded issue of data (or more abstractly, knowledge management) that Richard Durnall pointed out boils down to the tooling, I think. A data warehouse BI/OLAP approach to managing this data is the way to go. Then, you can manage your quality by shaping the grain of your Facts (what you want to measure), and let it continuously “feed” from the tooling output (IDE, compilers, build/test environments, etc). I also believe these “facts” will tie directly into the software methodology (some of which I would consider a component or subset of DFSS). Over time, I beleive the grain of the facts per the methodology will become apparent and just “come” with the tooling out of the box. Perhaps what we are talking about then would be a next-generation ALM system. (Whoever reads this and then builds one sucessfully – I have RIGHTS!)
Lastly, I see existing metrics in software such as in methodologies (e.g. story points), code metrics (maintainability index, cyclomatic complexity, class coupling, depth of inheritence, methods per interface/service, lines of code per method, parameters per method, types per component, etc), TDD (method pass/fail, test methods to product methods ratio) and so on to be actual contributors to DFSS metrics – effectively tying the entire SDLC together.
I’m curious about your thoughts about this and about DFSS for Software Engineering in general these days. Indeed I think the magnitude of this is much larger than most fathom, for software is silently spreading into the outer reaches of the universe – literally! Space craft, robotics, ECUs on cars, aircraft as you mention and perhaps one day nano-devices (which are little bros of classic robotics) – its everywhere.
Dustin | 17-Apr-11 at 12:14 pm | Permalink
EDIT: I meant to say HIGH cohesion in the GRASP software principles. I knew something didn’t sound right about that when I reread!