malvasia bianca

(Mostly an e-mail to the leandevelopment group, but I figured I might as well stick it here, too.)

I just finished reading The Toyota Way, by Jeffrey Liker. Which I highly recommend: it may actually now be my favorite (non-software-specific) lean book. A clear presentation of a good set of principles; I saw a lot that was new to me, still more that would have been new to me half a year ago (or a year ago or two years ago), I’m sure that I’ll get a lot out of it the next time I read it.

One thing that struck me in the software development context is its principle 13: “Make Decisions Slowly by Consensus, Thoroughly Considering All Options; Implement Rapidly”. It seems to me that there’s a pretty big tension between a naive application of that rule and agile: it sounds to me a lot more like BDUF than traditional agile.

Now, I don’t really believe that that’s true, partly for ideological reasons and partly because I’m sure that most people doing BDUF would do it in a way that is far away from the spirit of that principle. But maybe there’s something to be learned (in both directions?) from Toyota’s slowly building a consensus before deciding as compared to Agile’s quick iterations on development?

Part of the bridge seems to be set-based development. (Which is one concept in the Poppendiecks’ books that I haven’t seen in many (any?) other agile books.) Are there other Toyota techniques in this area that we should take to heart? The chapter talks about A3 reports; I’d been thinking that they might be a good fit to some gaps at work; does anybody have experience using them in software development? (Hmm, the Poppendiecks talk about those, too, don’t they? My copies of their books are at work, so I can’t check.)

One thing about agile that I don’t want to give up is that we’ve got some good techniques for evolving well-designed software. (E.g. Kent Beck’s four rules. Which I wish I could find a good URL for; this is the best I’ve come up with.) Are they in tension with the Toyota principle? Or are they each applicable in different domains?

How do I tell on a software project when we should be spending more time thinking before making a decision and when we should be getting our hands dirty and checking in production code? (With, of course, the expectation that the code will change as our understanding and the requirements change.)

Here’s the book’s description of the principle (emphasis in the original):

The Principle: Thorough Consideration in Decision Making

Many employees outside Japan who have joined Toyota after working for another company have had to face the challenge of learning the Toyota approach to problem solving and decision making. Because Toyota’s process of consensus decision making deviates so dramatically from the way most other firms operate, it is a major reeducation process. New employees wonder how an efficient company like Toyota can use such a detailed, slow, cumbersome, and time-consuming decision-making process. But all the people I have met who have worked for or with Toyota for a few years are believers in the process and have been greatly enriched by it—even in their personal lives.

For Toyota, how you arrive at the decision is just as important as the quality of the decision. Taking the time and effort to do it right is mandatory. In fact, management will forgive a decision that does not work out as expected, if the process used was the right one. A decision that by chance works out well, but was based on a shortcut process, is more likely to lead to a reprimand from the boss. As Warren explained in this chapter’s opening quote, Toyota’s secret to smooth and often flawless implementation of new initiatives is careful, upfront planning. Underlying the entire process of planning, problem solving, and decision making is careful attention to every detail. This behavior is associated with many of the best Japanese firms and Toyota is a master at it. No stone is left unturned. In fact, every stone is inspected under a microscope.

…

Thorough consideration in decision making includes five major elements:

• Finding out what is really going on, including genchi gembutsu.
• Understanding underlying causes that explain surface appearances—asking “Why?” five times.
• Broadly considering alternative solutions and developing a detailed rationale for the preferred solution.
• Building consensus within the team, including Toyota employees and outside partners.
• Using very efficient communication vehicles to do one through four, preferably one side of one sheet of paper.

(Liker, The Toyota Way, pp. 238–9)