My chain of thought so far expressed in 4 books

In order of how the logic develops:

Managing the Design Factory, by Don Reinertsen

The Toyota Product Development System, by Morgan & Liker

Lean Software Development, by Mary & Tom Poppendieck

Flexible Product Development, by Preston Smith

Design patterns

Semi-formed thought for the day:  are Design Patterns a useful variation on the Lean theme of ‘low level standardization for high-level freedom”  like Toyota’s use of design standards and tradeoff curves?

More Zen: another go at the “is testing waste” question

Having commented not 5 minutes ago that discussions like this weren’t very useful, I’m going to continue this one.  That’s what happens when your mind is going 20 to the dozen at 3am for no good reason.

I think the is testing waste question, at least for whatever variation of testing you’re thinking of right now, can be answered by this simple question:  What is your instinctive gut reaction to testing?

1. We should do more of it
2. We should do less of it
3. We should do the minimum necessary to serve the purpose.

If (1), it’s value added, if (2) it’s type 2 waste, if (3) it’s type 1 waste.

An alternative viewpoint is from the perspective of “what type of testing are we talking about?”.  As I see it there are basically 3 types of testing:

1. Testing as exploration – “What will happen if I try this?” Or, more commonly “I just tried this.  Lets find out if it worked”
2. Testing as verification – “I did the right thing.  Did I do it right?”
3. Testing  that is vanishingly unlikely to yield useful information – for example testing so someone higher up the food chain can tell someone even higher up the food chain “yes, we did a million miles testing on that”.  Or marketing can tell it to the customer, or whatever.   What we used to call in the auto industry “Miles for Smiles”.

(1) is value added, provided the “this” you just tried is value added.  A known good solution is worth more than a hypothesis.  (2) is type 1 waste (as long as there is a significant possibility that the answer is “no”, otherwise it’s the same as (3)).  You are not increasing customer value, you’re just avoiding reducing it.  (3) is type 2 waste.  Stop doing it.  Or at least be explicitly aware that it’s a marketing exercise (even if it’s your boss selling to his boss) not an engineering one.  Interestingly, the more you do of (1), the more (2) becomes (3).

 Or, like I said in the first place, “It depends”.

Too much Zen? Lean and the 80/20 rule

I’ve commented before that discussions about whether X is waste or value-added in Lean terms are like arguing about how many angels can dance on the head of a pin – entertaining for those philosophically inclined, but not terribly useful.

In practice, I think there’s a lot to be said for just focusing on the easy stuff.  Pick something you think is obviously value-added. Figure out how to do (more of) it.  Pick an obvious item of waste.  Eliminate it.  Repeat.  Then keep repeating.  After a while, look at the “obvious” item you just dealt to, and think about it from the perspective of where you started.  Back then, what’s obvious to you now would have been too subtle for words.  There’s a lot to be said for the learning value of practice and repetition.

Is testing waste?

There’s been a discussion going on on the lean software development forum about whether testing is waste.  Glen Alleman in particular has been getting quite exercised about it.  As far as I can see the only possible answer is “it depends” (which is basically Glen’s point).  The value of testing is context-dependent.

Context, by the way, includes time.  For example, in manufacturing it’s common to put a test after a process step you’re not completely comfortable about when introducing a new product.  After you’ve made a few thousand and the test hasn’t picked up any failures, you can get rid of it.  What’s changed?  Nothing except your confidence level.  But confidence is good;  it has value.  Once the test stops increasing your confidence level, it’s muda.

Which brings me once again to the question of perception & reality.  Your perception, both of your product and the customer’s values, is going to be imperfect.  Value is added both when you make your product closer to the customer’s values and when you improve your perception of either.  Often that’s what testing is about – and it’s certainly what listening to the customer is about: is the latter waste?

 The idealised question of whether something is waste strikes me as something of a meaningless one anyway – it’s like asking how many angels can dance on the head of a pin.  In a perfect world (or one with sufficiently advanced technology) development would be like magic.  We’d know what the customer’s ideal product was, we’d think of it and it would appear.  So in the ideal case, all activities are waste.  The important question then becomes:  “right here, right now, can we eliminate it without eliminating value?”  Or, in lean terms, is it type 2 muda?  If it’s not, whether it’s value added or type 1 muda is totally irrelevant – you can’t get rid of it.  Or at least not today.  But that doesn’t mean you shouldn’t be trying to figure out how you can eliminate it tomorrow.  

Variation

It’s a fairly common perspective that one of the key differences between production and product development is variation. Production seeks to eliminate it, the object being to produce an identical item every time, while PD requires it, as the object is to produce something different every time. Direct expression of this I think originates with Smith & Reinertsen’s Developing Products in Half the Time, but any number of people have reiterated & rephrased it since.

However this expression of differences masks some similarities. Production doesn’t necessarily shun variation – in an ideal lean or flexible manufacturing environment, it should be possible to build every product different from the last one. Even comparing nominally identical products, the object of the exercise isn’t to make them absolutely identical, just functionally identical – that’s the whole point of production tolerances. OK, a process (particularly one operating under six-sigma) may aim to run well inside allowable tolerance limits, but that’s about giving yourself a margin for error: there’s no added value in making products more identical than they need to be.

In product development, the object is to produce something new every time. But how new is new? Obviously, and pretty much by definition, the latest design can’t be identical to the old one. But conversely, it’s almost invariably unnecessary for every single part of it to be new. A resistor is a resistor, and a screw is a screw – if the old one worked, why wouldn’t you specify it again. And if every component on your last design didn’t work, what are you doing in business? In this context, not only is change unnecessary, it’s undesirable. Changing from screw A to screw B costs time and money. The engineer has to specify it, purchasing needs to order it, it needs to be set up in the system, it needs a bin in stores, etc, etc, etc. To justify making the change screw B needs to not only be better, it needs to be better enough to justify the effort.

The same logic applies at a larger scale. If a subsystem can’t be improved enough to justify the cost of improving it – and that cost isn’t just the engineer’s time in doing the new design, it includes all the knock-on effects thoughout the project – it shouldn’t be changed any more than absolutely necessary. Design effort and creativity should be focussed on areas where worthwhile improvements can be made. Even in revolutionary products, that’s not every bit.

The point of all this is that production and PD actually share an attitude to variation: variation can add or remove value. The sort that adds value is good, the sort that reduces it is bad. Where they differ is in the attitude to variation that does neither. In production, if variation doesn’t reduce value, there is no point in eliminating it. In PD, if it doesn’t add value, it should be eliminated. The elimination criteria for PD is actually more aggressive than it is for production.

Where I’m going here is that even though variation, creativity, and newness is what PD is all about, PD needs to put as much or more effort into minimising variation as production does. Designs that can be reused should be. Processes that can be repeated should be. Since it’s impossible to stop designers designing, jobs that don’t need redesigning should be done with minimal human intelligence required, i.e. automated or done with checklists, lookup tables, or standardised processes. Creativity should be focussed on the areas where it can do the most good, and in those areas we should be creative as all heck.

The trick, of course, is to eliminate the undesirable variation without stifling our ability to generate the desirable.

If Agile & Lean are the same….

OK, I’m no expert on either, but I’ve been poking round agile software development for the past few weeks, and it seems that the analogy between agile software development and lean manufacturing (or TPS if you prefer) is very close. Now I know that it’s hardly news that Agile fits pretty well under the larger Lean philosophies umbrella, but from what I can see most of the people making that connection are coming at it from a product development perspective, i.e. equating Agile to the TPDS.

There’s a whole philosophical argument to be had as to whether software development is “product development” or “manufacturing” – but for managerial purposes, creating software of sufficiently simple (or at least emergent) architecture that it can be created without an upfront design strikes me as closer to manufacture than to PD. And certainly it seems to me that the tools and philosophies of lean specifically as applied to manufacturing translate closely to those evolved quasi-independently for agile software.

So my question is, how come there isn’t more crosstalk between the manufacturing and software worlds? If they’ve independently come up with such closely related systems, there must be scope for each to learn from the other. But I can’t see many signs of it happening.

Thoughts on “Lean”

Lean Manufacturing – and by extension “lean” in all business activity – is a management philosophy which focuses on uninterrupted product flow through value-added processes, a pull system that cascades back from customer demand, and a culture of continuous improvement [1]. Although many of the precepts of lean thinking date back to manufacturing theorists and practitioners such as Taylor, Ford and Deming, the complete philosophy was developed largely by Toyota’s Taiichi Ohno. Although first publicly described as early as 1977 [2], it was not widely noted in the West until popularised by Womack in the early 1990s [3, 4]. Since then it has been heavily studied and implemented, to the point where “Any manufacturing manager or production engineer who has not engaged with these principles at some level (even if to reject them) can fairly be called an amateur” [5]. Although TPS remains the benchmark implementation of lean manufacturing, subsequent growth and westernisation of the philosophy, along with “continual improvement” in Toyota’s own interpretation of it, has resulted in popular concepts of lean thinking diverging from Toyota’s implementation of it.

In practice, lean (or TPS) is often viewed as a set of tools for the elimination of waste from production systems, and as an outgrowth of management practices such as TQM and JIT [see, for example, 6]. This approach is criticised by many lean proponents and is in marked contrast to the outlook of Ohno, whose publications on the subject concentrate upon the underlying philosophies, with only superficial attention paid to the tools [7].

Critics have referred to lean techniques as “management by stress” [8], and there is evidence within the writings of both Womack and Ohno to support this view [9]. The principles of kaizen and JIT require repeated stressing of the system (and therefore the people within it) to reveal and therefore eliminate problems. There is an internal inconsistency here in that this stress is itself a source of muri (overburden – pushing workers or machines beyond their capacity). It has also been noted that many lean implementations – including Toyota’s – rely heavily on shojinka (“the adjustment and scheduling of human resources”, exemplified in critics’ view by short-notice and unpaid overtime), which has the effect of providing an externalised labour buffer which makes the elimination of other buffers possible [10]. On the other hand, it can be argued that a “correct” implementation of lean principles results in the creation of labour “slack” through initial improvements, and relies on this to resource ongoing kaizen activities, therefore providing an internal rather than external labour buffer. Further, the principle of heijunka (workload levelling) aims to eliminate the need for both material and labour buffers. The application of lean thinking to NPD has been an area of significant interest in the past decade, although Smith & Reinertsen [11], among others, have previously advocated some of the underlying approaches Recent developments have been driven mainly by the aerospace and construction industries.

Some aspects of lean manufacturing have obvious analogues with NPD. On the whole, these align well with the focus of previous NPDM trends. For example, the principles of flow and transport minimisation which result in “cell” based manufacturing fit the thinking driving the CE staple of co-located cross-functional teams, while elimination of buffer stocks and batch-based operations are key tools of APD.

On the other hand, in other areas the analogy is less obvious. NPD is an information processing operation, and information differs from physical products in important ways:

• It can be in more than one place at a time
• Reprocessing (by iteration) can add value
• Its value is not always immediately visible or easily defined
• It is (by definition) impossible to fully define a process for processing it

These differences lead to difficulties in applying lean to NPD, and in their recent survey of lean NPD literature, Baines, Lightfoot, Williams, & Greenough [12] found that many of the key issues remain unresolved in the literature. Much of the recent work [e.g. 13, 14-16] focuses upon narrow areas such as definitions of value, it being apparent that without a clear understanding of what NPD work is value added, waste may go unnoticed. This is a particular problem in large complex projects, where value is often not readily defined. Of more system-focused work, a majority minimises the difficulties by focusing upon low-innovation environments [e.g. 17], or tools and process issues [e.g. 6, 18], where the lessons of lean manufacturing are more transferable. There appears to be no work to date focusing upon small-business applications of lean NPD.

It is notable that Toyota’s own NPD system, the Toyota Product Development System (TPDS), does not follow many of the precepts which western academics and practitioners espouse, and at first glance appears to conflict with lean first principles in several areas. The system, which has been described extensively by Liker [1, 7, 19, 20] among others, is based upon “set-based” design (i.e. pursuing multiple options simultaneously). This approach inherently produces a lot of “wasted” design work, although the value of having available options can be such as to make this economical [21]. TPDS is heavily functionally oriented, and does not cross-train engineers, which contrasts with principles of flexibility and cell-based operations (i.e. cross-functional project teams). The company also make limited use of value analysis tools, and have unremarkable CAE capability [14]. For all that, Toyota continues to move towards a dominant position in their industry: clearly they are doing something right.