#78-Lean Principle: Deferring Commitment

Waiting until the "last responsible moment" to make critical decisions is important both in physical manufacturing and the creation of business automation.  This week, I'll outline the concept and the differences that exist when applying to these processes.

Transcript

Lean Principal: Defer Commitment 

Way back in agile tips episode 4 I made a joke. I said that your mother probably told you “Never put off until tomorrow that which you can do today”. In other words, don't procrastinate. The joke was that Martin Fowler says you should ignore your mother, that you should put off everything you can because tomorrow you will be smarter. 

I do sometimes think about making a t-shirt with that joke on it. 

However, there is a critical part of Fowler's statement that will apply to what I want to discuss today when outlining the lean principle of deferring commitment. Fowler says to put off everything you can, which implies of course that there are things that should not be put off because you can't. 

In manufacturing this is particularly important because misjudging what can be deferred and what cannot can have huge financial consequences. 

Remember that lean began in automobile manufacture, and so we can use that as an example of identifying decisions that can be delayed. When you buy a car, there are often a number of options for you to select from regarding the trim of the vehicle, the color of the paint, the wheel style, floor mats, and other elements of finishing the product. But these customer decisions require a customer, which you may not have yet when you are building the automobile. So, in the Toyota Production System those decisions are left open, the cars are unpainted and lack trim details, because those are easy things to do once the customer has made their selection, and in waiting we avoid the possibility of, say, creating too many red cars for the marketplace. 

When building physical objects, the cost of change can increase rapidly because of the waste that is incurred when those changes have to be made.

Let's contrast that with business automation, especially software.  Changing the design of a car after you’ve started manufacturing it is enormously wasteful and expensive. Software is different. It is soft. So, it is possible to make changes to a software-based system without incurring extensive cost if your process is designed to allow for that. 

In the early days of software development, the assumption was made that the creation of software is very much like civil engineering projects: building bridges, skyscrapers, and other complex, one-off structures. This assumption suggested that we should make software the way we make those things, but if we do that then we give up the advantage of software being inherently more flexible since it is virtual.

Agile software development, which is influenced by lean manufacturing, suggests that we should delay architectural and product decisions until the last responsible moment. My first book was titled “Emergent Design” because I believe this is possible in software if certain key qualities, principles, and practices are adhered to. If you are familiar with the concept of design patterns, one thing that they share in common is that they are all examples of adhering to these very critical things that allow software to be changeable without waste and delays. 

Because of this the cost of change in software can be much lower than it is in manufacturing. That said, Fowler was right: we will always know more tomorrow than we do today and so if we can delay our decisions and the commitments we make to them the better those decisions will be.

Virtually everything that I teach in my technical courses, which includes design patterns, test-driven development, and emergent design are focused on the skills that developers need to be able to accomplish a high degree of flexibility without over-design. 

Next week I will examine another lean principle, namely “deliver fast.” As with all of these principles there are interesting differences between how it can be applied in physical construction versus the creation of virtual behavior.