design

{ Category Archives }

Representation of structure

Structure in the design of systems is usually represented by some form of schematic or block diagram. Block diagrams describe logical relationships between design elements, without getting hung up on physical detail. UML class diagrams and electronic schematics are examples of such abstract structural models of “things that are made out of things.”

Graph diagrams have one big trick for managing scale by collapsing compositional hierarchy into subdiagrams. Most of the time, I don’t care how an integrated circuit works, I’m only interested in the inputs and outputs. I’d rather treat it as a unified thing, even if the components on the inside of the thing are of the same type as the components I connect to the outside.

If our biggest scaling trick is reserved for object composition, then other hierarchical relationships may be described by color, symbolism, or layout. Color can be tricky because of problems with reproduction and perception (colorblindness is common). Symbolism works well for simple type relationships, but it’s difficult to represent taxonomy with nothing but icons. Edge layout is the first and most expressive tool of block diagramming, but layout quickly runs into problems with scale. Block diagrams are not the panacea of design modeling.

Large diagrams can become incomprehensible as they scale beyond a few 10′s of nodes. Most block-diagram notations allow an ad-hoc layout. Imposing rules upon the layout of the diagram can preserve comprehension and communicate additional information about structure. Resistance to orderly layout is itself useful information about structure.

There are some wonderful algorithmic graph layout tools that we can apply to help us make sense of things, but there are also a few simple manual layout tricks we can apply to finding latent structural patterns. It’s useful to know a few tricks for discovering structure when you are given a set of entities, but you don’t yet understand the relationships between them. It’s even more useful if these tricks can be applied at a whiteboard or in a spreadsheet without the need for expensive and/or complicated software tools.

Radial layouts equalize the significance of nodes and emphasize patterns between edges. They also scale up nicely. These can be very useful for discovering relationship patterns in a system that is new to you. You can make a pretty big circular diagram on a whiteboard with sticky notes for nodes and ink for edges.

Linear layouts are easy to draw.

They scale up decently, equalize nodes, and emphasize patterns between edges. They can optionally encode sequence along the node axis, but they don’t have to, and we’ll see why not encoding sequence is also useful.

Linear layouts are especially useful when we make a rule about the direction of the edges.

Any leftward edge that we can’t remove by reordering the nodes is a dependency cycle. Generally, you want to avoid such cycles in your design structure. A useful consequence of such a linear layout is that it can easily be translated into a matrix of relationships between diagram nodes. The reason becomes more apparent when you orient the graph along a diagonal axis:

The graph

can be represented as the matrix

Such an adjacency matrix can be referred to as a design structure matrix, or dependency structure matrix. The tabular form of a design structure matrix makes it a useful tool for understanding the relationships of large interconnected systems. A block diagram with 26 nodes may be simple, or it may be visually unwieldy. The equivalent DSM always has the same layout:

dsm

With our matrix form, we can apply simple row and column reordering to maximize the number of edges on one side of the diagonal. The dependency matrix of a decoupled design can be made to have all of its edges under the diagonal. Any edges above the diagonal that can’t be removed by row/col reordering are dependency cycles.

In a coming article, we will expand on this matrix technique to further understand and manage the structure of large systems. We may also discover something in the patterns of relationships that will help us to manage the work of building and maintaining such systems.

2009 02 09

My favorite kanban development example

It has been a long time in the works, but Clinton Keith’s article on kanban systems for game development is finally up. It is an excellent description of the why and the how of organizing a process for content-intensive development. Clint has managed to do something which I previously thought improbable: setting a takt time pace for development activities.

2008 11 11

Completion queue as incremental throttle

In the last two posts, we’ve discussed some useful properties of internal workflow queues:

queue states between processes can provide an early warning of process breakdowns
local work-in-process limits serve to slow down a malfunctioning workflow and free up resources to fix it
queues can sometimes be combined to reduce the total work-in-process while still preserving their buffering function

I gave an example of workflow throttling, and suggested there was another configuration of those internal queues that could respond more smoothly and gracefully than the simple, independent queues given in the example.

In order to pull a work item, there has to be a place to pull it from, and there should be some way to distinguish work that is eligible to be pulled from work that is still in process. At the same time, there has to be a place to put completed work when you are done with it. A completion queue serves both these functions.

In this case, we can have up to 3 items in the “specify” state AND we can have up to 3 items waiting for the next state in the workflow. The team can pull new work into “specify” whenever there are fewer than 3 work items in process. If there are already 3 work items in process then the team will have to wait until something is moved into the completion queue. If there is some kind of blockage downstream, first the completion queue will fill up, THEN the specify queue will fill up, THEN the specify process will stall. And when it stalls, it stalls all at once. The flow is either on or off, there’s no middle speed, and it keeps going until it stalls.

In another example, we still have a busy state and a complete state, but the token limit is shared between them. In this case, we can have 4 items in process OR 4 waiting. Or we can have (3 busy + 1 waiting) OR (1 busy + 3 waiting).

In the ideal case of 3 busy and 1 waiting, this queue works just like the first example does. However, if work starts to accumulate in the “complete” state, then the “specify” state will incrementally throttle down. The effective WIP limit for “specify” goes from 4->3->2->1->0 as more items are completed ahead of the rate of downstream intake. So, the process slows before it stops, and it slows much sooner than it would have under the independent queues.

What’s more, even though it operates in the same way in the normal case, it does it with two fewer kanban in the system. Fewer kanban, with gradual throttling and smoother flow, should result in lower lead times.

With this in mind, let’s reconsider our scenario from the previous topic:

	1. Something is going wrong in the design process, but nobody knows it yet.
	2. The specify-complete queue starts to back up, thereby throttling down the WIP limit for specify. A resource is freed as a result, who should now inquire into the cause of the backup, which may only be random variation. The code process continues to complete work and pull from the existing backlog.
	3. Code state begins to starve and specify state throttles down another level. Two more people are released as a result. There’s more than enough free resources now to either fix the problem or shut down the process.
	4. The stall completes by flushing out the specify and code states.

It still takes a while for the system to stall completely. The difference is that it begins stalling immediately, and when it does stall, it stalls with less WIP. For equivalent throughput, this pipeline should operate with fewer kanban and less variation in WIP, and therefore should have smoother flow and shorter lead times. It should respond faster to problems and free up resources earlier to correct those problems.

These shared completion queues might be the most common type of workflow queue. There are a couple of other types that we use, and we’ll take a look at those in a future post.

2008 06 20

What is Design for Six Sigma?

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:

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.

2008 01 07

What is Lean Product Development?

Michael Kennedy did his readers a real service by calling his excellent book Product Development for the Lean Enterprise instead of the more obvious Lean Product Development. In that book, Kennedy describes the set-based principles of the Toyota Development System, and how they may be applied to any product development business. TDS is a fascinating system, equally as innovative and interesting as the Toyota Production System, but also very different in the mechanism of its operation.

On the other hand, my own journey down the road of lean development started with Donald Reinertsen’s Managing the Design Factory. Don’s description of Lean Product Development is more like the application of lean production principles to product development, breaking the work into small pieces, managing capacity, measuring flow, and delivering value incrementally. It is this view of lean that my friend David Anderson expounded upon in his book Agile Management for Software Engineering.

The difference between TDS and TPS creates a lot of confusion in discussions about Lean Product Development. Does LPD mean product development targeted to lean production systems? Or does it mean the principles of lean production applied to product development? These two definitions have very different consequences.

If it wasn’t already clear, I am decidedly in the camp of lean production principles applied to product development workflows. Even though I think TDS is ingenious, and I wholeheartedly endorse set-based thinking, I do not consider TDS to be Lean Product Development. To me, lean development is a means to an end. That end is evolutionary design, and lean production fits that end in a way that set-based development does not. Which is not to say that there is not a strong evolutionary interpretation of SBD, as large-scale open source development is exactly that. But I’m not really speaking to the open source audience here. I expect my readers are largely of the enterprise variety, building products or IT systems to spec and for hire. And evolution with such finite resources means flow.

Observant readers have probably noticed that I don’t talk much about Mary and Tom Poppendieck here. I feel a little bit bad about that, because I think they deserve credit and respect. I think they have done the software profession a tremendous service by popularizing the relevance of lean principles to software development. But they have also done a couple of things that bother me, including blurring the definition between set-based, time-boxed methods like TDS and continuous workflow methods like TPS. The consequence of this is that people can (and do) weasel out of lean principles by hiding behind the weakest interpretation. By conflating these definitions, the Poppendiecks, perhaps unwittingly, encourage their readers to claim to be lean while avoiding actually doing it. One of the greatest offenses I see again and again is the rationalization of “craftsmanship” under the auspices of Lean.

In contrast, Womack and Jones (and Roos) were not at all ambiguous about what is Lean and what is not. Jim Womack, who coined the expression, “lean production,” to describe the principles behind the Toyota Production System, explicitly defined lean production as neither craft production nor mass production. Not craft production is part of the definition of lean, and he dedicates whole chapters in his books to why craft production is inferior:

Our advice to any company practising “craftsmanship” of this sort in any manufacturing activity, automotive or otherwise, is simple and emphatic: Stamp it out.
- The Machine that Changed the World, The Strange Case of the “Craft” Producers

Now, I realize that development is not manufacturing. But using that as an excuse to rationalize craft methods is overwhelmingly contrary to philosophy of lean. I am not saying that you shouldn’t practice craft development if that’s what you want to do. But claiming that it is lean to do so is either ignorant or outrageously dishonest. Standard Work is not an optional practice. Craftsmanship means doing it your way, Standard Work means doing it our way. If you’re not doing Standard Work, you’re not doing Lean. Period.