Understanding the Magic of Lean Product Development

Lead in Quote: Arthur C. Clarke said, “Any sufficiently advanced technology is indistinguishable from magic.”

Presentation slides here. 

Main Lean Product Development (LPD) problem: People consider LPD to be magical rather than technological.

• Why not move a domain X best practice (ex: Toyota Manufacturing) into another domain (ex: software product development)? Improved performance might transfer from a domain to another one... or not. For example, if we apply Toyota's approach to a hospital emergency room, arriving patients would be processed with a FIFO queue, and admissions would be accepted until a preset FIFO limit is reached... not necessarily a good idea, right? So such a good practice in a domain might be bad into a different domain.
• This presentation is mainly about analyzing what could/should be transferred from Lean Manufacturing to Software Product Development (SPD)

Speaker's suggested approach is based on this:

1. Toyota developed their way by focusing way more on actual practices and their measured implementations than on theoretical analysis (TBD, add Taiichi Ohno related links)
2. How to turn Magic into Technology: By Using some ideas and Lean Manufacturing & Add concepts and Science from other Domains (ex: the queuing theory, traffic flow theory, computer OS design concepts, need to add non-repetitive tasks aspects, high variability aspects and non-homogeneous flows, The "hooda loop" (TBD) from the maneuver warfare (accelerate decision making process)

So here are some ideas the speaker considered good enough to be imported from Lean Manufacturing to Software Product Development domain:

1. queuing theory: queues sizes vs resources capacities is not linear, but exponential... the more you utilize the capacity, the more the queue size explodes (ex: traffic at rush hour: reducing capacity by one lane out of 4 at rush hour will cause more than 25% delay in the queue time)... To produce an economic output, we should take great care at selecting the right amount of capacity and use the economics of queues; we should measure queues sizes in our product development cycle and search for $ vs excess product development resources with 3 curves, a-total cost, b-cost of excess capacity and c-cost of delay. Why it works so naturally for manufacturing? Because queues are physically visible. In Software Product Development, they are invisible... however, it is really useful to know how much delaying a certain software release actually costs globally.
2. Batch size is an very important aspect as well (ex: coffee break with 100 person at the same time vs 5 cofee breaks with 20 persons for each one) - see the economic lot size equation reference (created in 1930s). To select the right batch size, you need to measure. There are huge benefits in small batch testing for example (less debug complexity therefore cheaper debug, less open bugs, therefor cheaper testing, faster cycle time, early feedback therefore lower cost changes, ... in the end, better economics). TBD: a link here with CI small increment theory
3. WIP (Work In Process) constraints: very powerful to deal with accumulation in states (ex: maximum 10 items in Coding, ready to test and testing states); See Little's formula that says that waiting time in the queue is function of number of items in the queue and departure rate of the items. A useful tool for this one is the visual WIP boards - those boards makes non physical/invisible items as physical tokens on the boards - the horizontal axis changes from the traditional time axis to an axis on the software state. Another useful tool is a Cumulative Flow Diagram (showing Cumulative quantity vs time). It permits to see arrivals vs departure times in the queues, therefore, both at the same time the queue sizes (by taking on the x slices) and quantities in queues (by taking y axis slices).
4. Synchronized cadence: it makes wait time predictable (ex: dedicated support time on each day vs a % of the time of support at an unknown time); Cadence sets an upper bound for wait time and favor less context switching costs.

And now, the ideas considered toxics by the speakerthat should probably not be imported from Lean Manufacturing to Software Product Development domain:

1. Variability: as opposed to Manufacturing, we cannot eliminate variability in Software Development (concept equivalent to the finance volatility); in fact variability leads to the very options concept presenting higher value possibilities; removing this variability from Software Product Development is equivalent to killing ideas and potential values.
2. Queuing disciplines: many queuing strategies exists and not only the Manufacturing FIFO. See high cost of delay first (HCDF) minimum slack time first (MSTF), weighted shortest job first (WSJF), etc. we can see Computer OS techniques. The idea is to take the right one depending on context.
3. Fast feedback: extremely important in software development (in fact, one of the main reason for small batch sizes and shorter cycle time) - the main idea is that we can quit unproductive paths quicker and save the associated resources (ex: SCRUM daily meetings vs weekly meetings, or a 2 digits lottery (ref needed) ).

Conclusion

1. The importance of Math: The underlying mechanisms behind lean methods can be used in Software Product Development; these methods affect more than one measure of performance so trade-offs are necessary; An economic model gives comparable measures with common units. (See Life Cycle profit impact (ex: one month delay can cost 500K$)).
2. We need to calculate more economically and less with intuition! The speaker measured scientifically that any analysis (even poor ones), beats intuition in software development!

Going further references:

Book 1: Developing Product in half the time

Book2: Managing the design factory (a little outdated possibly)

Book 3: The principles of Product Development Flow (second generation LPD) - excellent!