Lean for Systems Engineers (and developers)     pdf version

November 2011 I presented at the "Lean & Agile for Systems Engineers" seminar in Stockholm, organized by INCOSE-Sweden. I was asked to talk about "How is it possible that most organizations still survive, while their competitors are applying Lean?" (short answer: "They don't", pun intended), and "My Practical Approaches for Becoming Lean and Really Agile". I was also asked first to present a "Lean & Agile Primer", in order to set the stage: What are we actually talking about? I wanted to avoid the usual hallelujah stories about Lean and Agile, so I researched to find and present about the "essence" of these ideas and how these ideas can actually improve Systems Engineering results.

Here are some of my findings about Lean. Perhaps I can write another time about my findings about Agile. Short advice: avoid the hype and the tools; try to find the essence and go for that.

Lean
The origin of the word "Lean" comes from people from MIT, who tried to find the secret behind the Japanese Car Production 'miracle' (read: 'Toyota'). The word started the Lean hype with the book The Machine That Changed the World: The Story of Lean Production by Womack, Jones and Rook (1990). A reviewer of the book noted: "A lot of the cost of vehicles is based on bad design, poor management, and an attitude that problems, no matter how small, can be overlooked". Sounds familiar? Womack writes: The goal is reduction of waste. To achieve this, a company must look at what creates value, and eliminate all other activities:

  1. Specify value from the standpoint of the end customer by product family
  2. Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value
  3. Make the value-creating steps occur in tight sequence so the product will flow smoothly toward the customer
  4. As flow is introduced, let customers pull value from the next upstream activity
  5. As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced, begin the process again and continue it until a state of perfection is reached in which perfect value is created with no waste.
Nice sounding words, but what do they really mean? I decided, instead of reading second-hand material, to go to the Japanese original, Taiichi Ohno's book: Toyota Production System: Beyond Large-Scale Production (1978) as well as background information from other Japanese sources. I found:
Around 1950 the company (Toyota) nearly went bankrupt, and had to lay off one third of its employees.
This stimulated Ohno to focus on four specific aims (with my comments): To quote some lines from Ohno's book: Where the US version of Lean seems to focus on tools and techniques (which of course sell nicely), the Japanese simply used and keep using the Deming Cycle (Plan-Do-Check-Act), and asking 5 times "Why?", to find solutions for their own particular issues and circumstances in order to continuously improve. After all, they are not in the business of selling a "method". Ohno is a modest man, admitting that he actually got his ideas when reading Henry Ford's books, and looking at US supermarket supply principles. Like Henry Ford, he took old ideas, and adapted them for his clear purposes and need.

Those who don't learn from history are doomed to repeat it (after Santayana), so let's dig up some more roots of Lean ideas:

Ohno says there are two Pillars of the Toyota Production System:

We see here an enlightened way of management, not policing with command and control, but rather management being subservient to the workers to help them to become more efficient. Quite a different attitude from what we see in contemporary management attitudes in the West. It was, however, borrowed from the original type of management that, before World War II, made the US companies so powerful and prosperous. This knowledge was exported to Japan after the war (see "CCS Management Course") and in the US replaced by what the Hopper brothers in their book "The Puritan Gift" call the "Cult of the (so called) Expert", showing how this led to the current economic crisis.

Capacity = Work + Waste
The capacity in an organization is used for:

Identifying Waste
People are not stupid. If it were easy to recognize and eliminate waste, it would have been done already. Apparently, it's counter-intuitive. Therefore it doesn't happen automatically
To help us identifying waste, Ohno mentions seven types of waste, to which an eighth was later added. In the following table we see these wastes, with a translation what these would mean to development (or Systems Engineering) tasks and possible remedies to do something about it (not necessarily the best, but examples to make you start thinking):

Manufacturing Development / SE
(after Poppendieck)
Possible Remedies
(my possible suggestions)
Overproduction Extra features
Unused documents
Prioritizing, Real Requirements
Deciding what not to do
Inventory Partially done work Synchronization, Just In Time
Transport Handoffs
Keeping in one hand/mind:
  • Responsibility (what to do)
  • Knowledge (how to do it)
  • Action (doing it)
  • Feedback (learning from Result)
Processing Design inefficiency
Wishful thinking
Knowledge, experience, reviews
Preflection
Waiting Delays Process/Organization redesign
Movement Task Switching Max 2 tasks in parallel
Defects Defects Prevention
Ignoring ingenuity of people Ignoring ingenuity of people Real management, Empowerment
Bottom-up responsibility

5S and 3 Mu
When people talk about Lean, you soon will hear about 5S and about the 3 Mu's. These are an aid for people to internalize the essence:

Seiri Remove unnecessary things → waste
Seiton Arrange remaining things orderly → flow
Seiso Keep things clean → uncovers hidden problems
Seiketsu Keep doing it, standardize → know what to improve
Shitsuke Keep training it → resisting inevitable entropy
     
Muda Waste → minimize waste
Mura Irregularities → optimize flow
Muri Stress → sustainable pace

What is real Value ?
When Heathrow (London Airport) Terminal 5 was built, it was a huge technical success. It was quite an achievement, to build such a multi-billion pound project on time and on budget. However, the people for whom the terminal was actually built (without passengers there is no need for a terminal!) aren't interested in the technical details of a terminal.
They only want to:

They didn't.

One of the problems is to determine what the value of the project (or our work in general) really is about. By the way, a project doesn't even deliver value itself. It only can deliver the conditions for the users of the system to create the value.

This is about what we call 'Real Requirements'. Requirements engineering is quite underdeveloped in most projects. Why? I think it's lack of proper education.

Example of identifying waste (Value Stream Mapping)
Assume that the users of our system encounter a problem that costs them extra time (Problem occurring: negative value or waste to the users), see figure:

Value Stream Mapping example

Then it may take some time:

In this process, there are a lot of value adding activities, all (seemingly) necessary to create the value of the solution. It's obvious that between these activities, there is a lot of waiting time.

From this example we can see the following:

While 'solving' the problem, we are actually wasting almost 187k$, instead of spending 'only' 5k$. Having mapped the value stream, we can now look for minimizing the delays between the value adding stages. We may challenge the necessity and efficiency of the value adding stages themselves. And of course we also do a root-cause analysis why we produced the problem in the first place. Still, we must be careful not to optimize everything at once, because if we try to perfect too much in too short time, we will probably fail.

So-called "Process Improvers" usually start "improving" the value adding activities within the boxes (see figure). Now we can see that they should better first start with removing the waste between the boxes.

Value Stream Mapping in Development or Testing
The previous example is used for production: repeated actions, which we can observe and then improve on. Some people maintain that this cannot be applied to development. A lot of what we do in development as well as in testing, however, is more of the same, with a lot of waiting and inefficient synchronizing. Here we can use the same regular value stream mapping principles as described. Some development activities (mainly within the boxes of figure 1) are however specific to this particular development, and analysis after the fact has not much use, because once we find out that we could have saved waste, the time is already spent and the waste is already produced.
Instead of relying only on reflection on what we should have done better, we'd better use preflection: imagining which elements of what we are going to do will produce waste, before doing it. Only before doing it we still can decide not to do it. This is the only way to avoid this waste.

This is what we routinely do with the Evolutionary Planning approach, where we use 'magic sentences' like:

This way, we already routinely save 30% of time while producing better results. Because it's so easy, people learn to save time within several weeks only. Why don't they already do this, or why does it take even several weeks? Because it is counter-intuitive. That's why it hasn't happened spontaneously already. A coach helps them by saying "Can you do this 3 weeks for me? Trust me, it always worked, at least until now!" Then, if within 2 weeks people find it starts working for them, new intuition is born. From then it will go automatically, and the coach can start focusing on other issues.

I'm only a Systems Engineer!
What has this to do with me? After all, I'm a Systems Engineer (developer, tester, or whatever else), and not a Project Manager. Well, the Project Manager is responsible for the project to deliver a very effective and efficient Result. However the workers in the project, and especially the Systems Engineers, determine the time they spend and the efficiency of the solutions they provide for the users. This makes Systems Engineers even more responsible for being aware of all time elements:

Some snippets

Conclusion

Some essential ideas behind Lean:

Looking at what I learnt during the past decades in my work to help projects greatly improving their performance, it's all Lean: not doing what is not necessary, not spending more than necessary, and continuous pursuit of perfection: I call it Quality on Time. My father, as a business consultant, did similar things in the 60's, optimizing the flow and performance of e.g. bicycle production, without ever having heard of Toyota. That's not surprising, because after all it's just common sense as he used to say, although "Common sense apparently is not so common", is a sentence I kept hearing in the corridors of the INCOSE International Symposium in Chicago. A lot of the things we have to do to make projects successful and on time are counter-intuitive, which makes it almost impossible to happen spontaneously. Without active and continuous coaching by management, it will not happen. If management doesn't know yet how to do this, they can ask external coaches for assistance.

Reading

Niels Malotaux is an independent Project Coach and expert in optimizing project performance, helping organizations around the world to optimize the predictability of their projects. He has over 40 years experience in designing hardware and software systems, at Delft University, in the Dutch Army, at Philips Electronics and 20 years leading his own systems design company. Since 1998 he devotes his expertise to helping projects to deliver Quality On Time: delivering what the customer needs, when he needs it, to enable customer success. Niels effectively teaches Evolutionary Project Management (Evo) Methods, Requirements Engineering, and Review and Inspection techniques. Since 2001, he taught and coached well over 400 projects in 40+ organizations in the Netherlands, Belgium, China, Germany, Ireland, India, Israel, Japan, Poland, Romania, South Africa, the UK, and the US, which led to a wealth of experience in which approaches work better and which work less well in practice. He is a frequent speaker at conferences.