January 2008

Personal heijunka board

Since departing Corbis, I’ve had so many small tasks and projects going on that I’ve been struggling to keep track of everything. The usual strategy of keeping to-do lists on the whiteboard just hasn’t been cutting it. So, I’ve put up a small personal heijunka board, complete with kanban limits to manage things.

my_heijunka_board.jpg

The green tickets represent outcomes (goals or tasks, aka requirements). Most goals can be broken up into a number of smaller tasks, and those are the yellow tickets. As usual, the red tickets are problems i.e. andon lights.

Since the task types are heterogeneous, there’s no use for any detailed workflow, so I simply have an In-WIP-Out sequence for each level of task decomposition.

On the left, I have three levels of backlog, by priority. Backlog size decreases as priority increases. P1 are things that need to be done ASAP. P2 are important things that are not time-sensitive yet. P3 is stuff I know I need to do, but not right away. Any more stuff than that is too much to manage. If the board is full, and a new goal is not more important than something already up there, it just falls out of consideration. I figure that I can reasonably manage two goals at a time. If I get tired of working on one thing, or I get blocked (waiting for an event, retail hours, etc.), I can work on the other. More than two would just accumulate inventory, and that’s what the P1 queue is for.

Comments (8)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Hundreds of people can’t check directly into main every day

This is part 5 of 10 Pitfalls of Agility on Large Projects. In part 4, we talked about how the customer doesn’t want a release every month, and what to do about it.

Chris Seiwald and Laura Wingerd have had a great paper that’s been out for almost a decade which describe best practices for branching on large projects.

Here’s a similar (but ugly, hand-drawn) take on the key diagram in that article which shows the key criteria for branching and checkins — creating separate branches whenever the risks or goals of a set of checkins deviate significantly from the standards of the current main codeline.

Branching Model

The model requires a source code control system with good branch/merge support. Chris’ Perforce has been the best commercial choice for some time (because of its simplicity and scalability), but open source alternatives have been getting better. Subversion is a great open source choice, but has had subpar merging. This is slated to get better in upcoming version 1.5. And the whole Distributed SCM family of tools (git) makes this their forte.

In a future continuation of this post, we’ll look at tying branching best practices into the larger picture of robust continuous integration.

Comments (1)

Print This Post Print This Post

Email This Post Email This Post

Permalink

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.

Comments (10)

Print This Post Print This Post

Email This Post Email This Post

Permalink

The customer doesn’t want a release every month

This is part 4 of 10 Pitfalls of Agility on Large Projects. In part 3, we talked about how we can’t afford to trust everyone on large teams, and what to do about it.

Frequent releases, which are central to both agile and lean methods, sometimes draw a visceral reaction because people fear we can’t keep the product that close to release quality at all times, while still delivering as much innovation.

That is a real challenge of agile/lean methods. But making this argument against short cycles is difficult, so the most common argument ends up being “the customer doesn’t want a release every month (or every 6 months, or every year …) anyway.”

Unfortunately on any project with many customers, while no customer wants a release every month, there is always one wanting a release right now.

We can deal with that to some extent by having tiers of releases: the single-customer quick fix, the multi-customer patch, the service release, and maybe minor and major releases. But each of these tiers involves extraordinary cost and waste from duplicate efforts — waste that can often be avoided if the main release cycle is short enough that customers can get their needs met.

It’s better to embrace the challenge and compelling benefits of feedback on short cycles. Here’s a rough diagram of a typical three-tier set of daily, weekly, and monthly release cycles.

Release Early and Often

The heart of it is a per-change or, at worst, a daily build (continuous integration). This build is picked up only by people who are in close contact with the project. This discipline keeps everyone in sync, and keeps the project from wandering into a broken state.

The weekly build (or some equivalent) is important whether at a large organization (where many remote teams share dependencies) or at a smaller startup (where the salespeople and management interact with the product daily). Tightening up the feedback loop of these internal customer proxies creates transparency, builds trust, and keeps the product from evolving off-track feature-wise.

Releasing something to customers every month can seem daunting in some large organizations. The biggest of the software beasts (Microsoft) has had challenges but also great benefits in doing so. And if you think you have a great plan set in stone (a very detailed set of requirements), all the feedback these releases will generate would seem to be just a source of endless distraction.

Don’t be foolish. Unless you’re delivering a 1-1 functional replacement for some existing product (and how often do we do that?), you desperately need that feedback. It keeps the team connected with the customer, motivated by the customer, doing right by the customer. Concerned about opening your kimono to competitors? Limit your audience to a trusted subset, like Apple’s AppleSeed program and most others do.

Once the team gets used to a cadence of regular releases, the practice becomes the heartbeat of the organization, keeping everyone on track, in touch with reality, and constantly learning.

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Close
E-mail It
Socialized through Gregarious 42