Home > Agile stuff, Lean, Scrum > The essence of Lean development

The essence of Lean development

I was hired once to help out in adopting Lean thinking. Before I started I had an interview and talked to a top level manager on Lean and how I could help the organization in their journey.
In my naivety I actually assumed that we had a similar understanding about Lean. After a few weeks I heard the man say something that rattled my brain.

”….. yes yes we are going to be Lean and Mean”…..

I thought… hmmm what does Mean has to do with Lean!!
I realized that we could have completely different definition of Lean….. unfortunately we had!

The Lean paradigm differs form Mass paradigm in interesting ways.
Lets look at some examples

Efficiency v.s. Flow

“Yes… we are going to make a year plan and allocate our engineers in such a way that all of them are utilized for 100% in all our projects. Yes…. we are going to make them work in multiple projects at the same time, Yes…we need to start all these projects otherwise they do not get done Yes…”

In mass paradigm management people are seen as resources. And these resources need to be utilized to the maximum because obviously this results in higher efficiency. So people need to be kept busy all the time operating under full load! The best way ofcourse to achieve this is to have division of work or specialization. Yes this is good…. now the testers can test all the time and the developers can develop all the time and the requirements engineer can analyse requirements all the time… very good everybody is fully utilized, very efficient indeed!! The ‘production line’ has to be busy at all times because production costs drop with volume.
But….. the problem here is that thinking in terms of resource utilization makes it more difficult to keep the true purpose of the business in mind! How does resource utilization contribute to customer satisfaction? What has resource utilization to do with the purpose of the business? how does resource utilization provide value?
You know you are working in this management style when there never seems to be time to stop the ‘line’ and fix the root cause of a problem. But there is always seems to be enough time to do things over and over again with lots of ‘workarounds’.

In Lean we do not focus on resource utilization or ‘ass to chair time’. We focus on optimizing the total time it takes for work to get done. This often means that people are not fully utilized! And this is good because in development people need to think! And if we satisfy our customer with short lead times they will be happy and that’s actually good also!! We are also happy because we get things done earlier giving a higher ROI. We then also have room to absorb variation in demand, again keeping the lead times low. In full utilization there is no room for variation in demand and the slightest variation in demand results in huge queueing of work which leads to high increase of lead time and lots of WASTE!!!!!!

People v.s. System

In Lean thinking you try to have a systemic view on things. You assume that the root cause of most ‘errors’ or sub-optimizations are in the system people work in and not the fault of the people themselves. When things go wrong you ask youself “how can we change the system in such a way that this situation cannot occur again”. A manager’s purpose is to coach and help the people learn how they can improve the way their work is done.
A senior Toyota manager once said the following

A manager knows that improving the company is not his job but the job of the people themselves. The managers’ job is to help the people understand this and make it possible for them to do so.

In Lean development the teams have authority to decide how they do their work. Teams know the deadlines, organize their work, choose who is their leader and even who is in or out of the team. This is needed because they are the ones who know best how to improve the way they work. Management accepts the decisions made by the team even if they are not happy with it.

Traditional management has a different view. They assume that the root cause of most ‘errors’ are in the people doing the work. When things go wrong they tell the people to change their behavior. You ask yourself “How can we change people in such a way that this ‘error’ cannot occur again”. Hand in hand with changing the people comes commanding how to do things and controlling what is done. It often means taking away even more responsibility and authority from the teams. “Yes we are management…. we know what is best… we know how to do things…. ofcourse that is why we are management right!”

Inflexibility v.s. Continues improvement

Standards are needed and used in both the mass as the Lean paradigm. But there is a difference.
In the Lean paradigm they are the basis for improvement. Without a standard you cannot improve. The people themselves make the standard and improve it as they learn. We acknolwedge that there are multiple ways of working better.

Taiichi Ohno once said

“There is something called standard work, but standards should be changed constantly… “

In the mass paradigm a standard is something to remain stable. It should not change because we need volume production in a standardized way. The standards can only be changed and improved by ‘specialists’ or managers. The people are only modestly involved in planning and improvements. Information is disclosed on a ‘need to know’ basis.

Some quotes I heard in a mass paradigm management companies

“We need to verify everything they do upfront, because otherwise they will build it wrong”

“We must specify as much as possible so that they do not need to think”

“You have to specify component design in detail so that they do not build the wrong thing”

“Yes they are smart people, that’s why they build their own things in their own way”

The funny part is that people often do not realize that they think like this. The way of thinking is so common that it is assumed obvisouly correct.

There are many more aspects in which the Mass and Lean paradigm differ but that is something for a future post.

Categories: Agile stuff, Lean, Scrum Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: