#82-Lean to Agile

In this episode we wrap up our discussion of Lean by relating it to agile development processes.

Transcript

Lean To Agile

Over the past 7 weeks I have outlined the seven principles of lean, which are Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, and Optimize the Whole. I hope I was able to create some clarity about each of these principles. 

But this podcast is called Agile Tips, and so what I want to do now is show how the foundations of lean led to the creation of the agile mindset. 

Many if not most people would say that the agile movement began with the publication of the Agile Manifesto in 1999. But the thought process behind that manifesto came from lean thinking, which predated it significantly.

The overall emphasis of lean is to maximize the flow of an idea through to a deliverable product with the least amount of waste and the most efficient and smooth process. Demming and Ohno shifted the focus from product to process, improving how we work not just what we make. 

By the time these ideas reached the software development industry it was in a significant amount of turmoil. Most development projects were late, over budget, required significant rework after delivery, and often failed to meet the expectations of the customers they were seeking to serve. 

Like lean, the agile movement focused on the process by which software is created. Up to that point it had been a very heavy, bureaucratic, wasteful process that was based on the misbegotten notion that creating software is similar to building a skyscraper or a bridge across a river. The concept of strict phases of development which were analysis, design, construction, testing, and deployment were never successful when it came to the creation of business automation. Agile said, basically, let's abandon all of that and respond to the true nature of computers and the software they run. 

So, the seven lean principles became influential on what would eventually be the Agile Manifesto. It is interesting to take each of those principles and translate into the world of computer automation.

Eliminating Waste became the focus on delivering working software over extensive documentation. 

Build Quality In became the notion of relentless refactoring and constant integration. Eventually this led to the notion of up-front testing. 

Deliver Fast led to the idea of incremental delivery and frequent validation with stakeholders, allowing the process to adjust itself before misunderstandings led to wasteful development.

Respect People led to the focus on team autonomy, and self-direction. The process known as Scrum was one of the earlier implementations of this idea. 

Optimizing The Whole led to the notion of acceptance testing which focuses on the overall product and its value to its stakeholders over the perfection of any particular feature.

Both lean and agile acknowledge the fact that we are in a constant state of learning and that our understanding of the value that we seek to deliver is always sharper as time goes on. Therefore, the process cannot require a fixed design or a fixed architecture, because we would not be able to respond to what we learned if it was. 

One can take this connection too far because lean is about manufacturing, which is focused on the repeated creation of identical physical products with precision and reliability. Agile is about automation, where each product is a uniquely crafted response to a set of requirements and expectations around a specific business process. 

But the focus on efficiency and value is consistent between them and so if we understand lean then we will better understanding agile. That has been the point of this particular sequence of episodes. 

Next time, I want to focus on how we can best measure the progress of an agile process. An old saying in project management is “you get what you measure”, and so we want to make sure that we are consistently measuring the right things. 

See you then.