#79-Lean Principle: Deliver Fast

The idea of delivering fast has a very different meaning when you compare the manufacture of physical products to the process of developing a system to meet a business need.  This episode will delve into those differences.

Transcript

Lean Principle: Deliver Fast

“Deliver fast” is a principle that has significant differences when one compares it to what it means in a manufacturing environment and what it means when delivering an automated solution to a business.

Generally speaking, manufacturing is a process where the same thing is made repeatedly with an assurance of consistency in the product. Although products may have various options that customers can choose from, the bulk of the product is the same under all circumstances. If I buy a Prius and you buy a Prius, we have essentially purchased the same thing although I might have picked a different color scheme or different entertainment system, etc. 

In my podcast on the principal of deferring commitment, I pointed out that a manufacturer of, say, automobiles does not want to have a large number of unsold units that has to be stored and tended to. Inventory in traditional business was thought of as an asset. In lean it is thought of as a liability. That said it's also important to reduce the time between the customer’s decision to buy and the moment that they receive the product. 

The Toyota Way leans on techniques that allow for this balance. Products are partially built ahead of time but finished just in time, which yields short production cycles and reduces the time that a customer has to wait. It also means that the flow of material through the production facility becomes very smooth and predictable. But the main focus is to reduce the lead time needed to be able to deliver a product to a paying customer. 

When we create a system to automate a business process, we rarely do the same thing more than once. Generally speaking, each software product and the hardware that it runs on is a unique configuration responding to the requirements of a particular set of stakeholders. 

But because requirements can be misleading, incomplete, misinterpreted, miscommunicated, or simply wrong, it is critical that we have an opportunity to validate the product constantly throughout its creation.  The word “deliver” in this case does not mean delivering a completed product, it means delivering an element of the product that can be validated. We want this to happen as quickly as possible, so that if it is determined that the work is not correct, we can take the steps needed to bring it in alignment with business value without creating a tremendous amount of wasted time and effort.

So, deliver fast in software translates into validate early and quickly, which is an agile principle that grew out of the lean point of view. 

The need to do this has driven several changes to the way software is created. Rather than conducting development in large discrete chunks, we instead want to develop it in short iterations that contain every aspect of software development from analysis through design and implementation with testing happening up front, rather than after the fact.

Also, it is crucial that testing be as automated as can be made workable, that integration and delivery is also continuous and automated, and that we identify and prioritize incremental value that can be delivered long before the product is considered to be complete. 

The main concern of early and constant validation is to avoid building the wrong product, which is a problem that was once very common in systems development.

Another way to say this is that delivering fast in a manufacturing environment means to be able to finish a product quickly. In software development it is all about increasing the velocity of the learning process that the team must engage in in order to build the most valuable product. 

Next week the focus of this podcast will be on a lean principle that I personally find to be extremely important, which is respect people. There are obviously ethical reasons for this but also there are practical concerns that need to be acknowledged.

Stay tuned!