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):
  • Deliver the highest possible quality and service to the customer
    Without quality, the customers won't buy, and if the customers don't buy our products, all other issues are irrelevant. Is it coincidental that Deming presented his speech to Japanese top-management in 1950?
  • Develop employee's potential based upon mutual respect and cooperation
    The employees create the value. All management can do is to facilitate and help them to create the value more efficiently. Still, "Death by Overwork" is an official Japanese Government statistic, and Toyota only recently decided that overtime should be limited to 360 hours per year, which means that people are still expected to work overtime up to 1.5 hour every day.
  • Reduce cost through eliminating waste in any given process
    There are so many things we tend to do which do not contribute to creating value for the customer, and it is the task of everybody in the organisation to recognize and actively eliminate waste in whatever we do and not do.
  • Build a flexible production site that can respond to changes in the market
    Because Toyota initially didn't build so many cars, they had to adapt what they learnt from Ford's mass-production (you can buy any model and any colour, as long it's a model T and it's black) towards making small-scale and varying production as efficient or even better.
To quote some lines from Ohno's book:
  • All we do is looking at the TimeLine from Order to Cash, removing the non-value-adding wastes (page ix)
    is what Ohno replied when asked what Toyota currently actually was doing. This provides a clear focus to continuous improvement, not wasting time and resources nobody is waiting for.
  • The Toyota Production System began when I challenged the old system (page 11)
    Continuously challenging the old system is the basis of improvement. As Einstein and Benjamin Franklin already said: Insanity is doing the same thing over and over again and expecting a different outcome. The old system apparently needed improvement, so it should be challenged. We should be so humble as to admit that we always can improve. For those who think that continuously improving quality of what we do and what we produce does cost more: Crosby already found that Quality is Free. Already in 1950 Deming told the Japanese, and this is also my own observation, that quality costs less.
  • Necessity is the mother of invention: improvements are made on clear purposes and need (page 13)
    We see the US Lean movement pushing the tools and techniques they found at Toyota. At Toyota, they make improvements on clear purposes and need. Their tools and techniques emerged out of necessity, and will be different tomorrow, because the improvement cycle never stops. This makes me remember the story of what an US mission to Japan found: They visited many successful Japanese companies, and saw that every morning the people were doing exercises. So back at home they advised US companies that doing morning exercises would make them more successful. The mission failed to observe unsuccessful Japanese companies, where people also did morning exercises every day.
  • The TPS has been built on the practice of asking "Why?" 5 times (page 17)
    Before jumping to implementing the first solution that comes to mind, better first to develop the problem, looking for possible solutions and selecting the most promising one. 5 times "Why?" is usually sufficient to find the root problem from which we then can design the appropriate solution. In practice we see so many projects developing a perfect solution for the wrong problem. Better develop the problem first!
  • The time that provides me with the most vital information about management, is the time I spent in the plant, not in the office (page 20)
    The 'working floor', where the people are creating the value, is the place where you can observe what can be improved, and how you can help the people who create the value to become more effective and efficient. Sitting behind your office desk, you will create theoretical solutions that do not work as expected in practice. This is what Masaaki Imai describes in his book "Gemba Kaizen - A Common Sense, Low-Cost Approach to Management" (1986), Gemba being "the working place", and Kaizen being "continuous improvement".
  • Toyota's top management watched the situation quietly and I admire the attitude they took (page 31)
    What Ohno did was not very Japanese: he squarely told people the truth, instead of trying them not to 'lose face'. He got quite some opposition, and he admits that without clear Executive Support he wouldn't have been able to implement his ideas. Sounds familiar?
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:

  • Just in Time (JIT) - no inventory
    Inventory is stuff waiting to be used later. Inventory deteriorates, and has to be kept, managed, transported, which is all considered waste, because it doesn't create value: it only costs. Ohno admits that the idea is simple, but the implementation is a lot of hard and continuous work. An example of inventory with Systems Engineering is detailing requirements way before they are used. Once they are needed they are deteriorated by improved insight in what the project really is about.
  • (Perfection)
    This is not officially part of Ohno's two pillars, but I think it's implied.
    Perfection is a condition for JIT to work. If the things that are delivered Just In Time are not in perfect order, they cannot be used, the flow is disrupted, and it isn't JIT any more.
    If a defect is found: stop the line, find the cause, fix it immediately. Use root-cause-analysis to find the root of the problem, or as they say: there is a process that is producing this defect. Find this process and eliminate it, or replace it with a process that doesn't produce the defect. Continuous improvement of product, project and process.
  • Autonomation
    The loom runs unattended until signalling it needs help. Originally, the Toyoda's produced autonomous looms. If one wire at the loom breaks, it's of no use keeping the loom running, because it'll be producing defective and therefore unusable cloth. If the looms run autonomously, and signal a defect when it occurs, one operator can attend many looms. The sales of Toyoda's patents on autonomous looms to a company in the UK provided the money to start developing automobiles.
    If we translate Autonomation to development:
    • The development team runs unattended until signalling they need help (caused by an issue beyond their control)
    • Management observes the team and facilitates them to become ever more efficient, and prevents issues delaying them beyond the teams control - Education, Empowerment and Responsibility of people
    • If an issue does occur, management helps to remove obstacles quickly, making sure it doesn't happen again
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:

  • Work, which creates value
  • Non-value adding, but necessary work
    Example: management is waste, unless they organize, facilitate, and optimize the work of the workers much better than their salary's worth
  • Waste: anything that does not contribute to value creation
    As Imai says: "Because it costs nothing, eliminating waste is one of the easiest ways for an organization to improve it's operations.".

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:

  • check-in their luggage as easily as possible, and
  • get their luggage back as quickly as possible in acceptable condition, at their destination

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:

  • Before some of the users start complaining (Problem recognized)
  • Before the problem is reported to those who can do something about it (Problem to development)
  • Before development, (receiving it e.g. by email) puts it in their issue-database (Problem into database)
  • Before the Change Control Board decides whether and how to handle the issue (CCB decision)
  • Before handling the issue is scheduled (Time allocated)
  • Before the problem gets solved
  • Before the solution is verified and validated (V&V)
  • Before the solution is Deployed
  • Before the problem doesn't hinder the users anymore

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:

  • The total time the users keep having the problem is 114 days.
  • The value-adding time is 1.6 days and the non-value adding time is 112 days.
  • If, using our system, twice a day 100 users experience this problem, spending an extra 10 minutes every time, the wasted business cost of the users waiting for the solution is (with some assumptions): 2 times per day x 100 people x 10 minutes extra x 112 days x 400$ per day = 187k$.
  • The net cost of producing the value of the solution is (with some more assumptions): 3 people x 1.6 days x 1000$ per day = 5k$.

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:

  • "Why are we doing this?"
  • "Is it really necessary?"
  • "Is it really necessary now?"
  • "Who's waiting for it?"
  • "How much time would you need?" - "How much time do you have?" - "How much time should you use?" - "How much time will you give yourself?"
  • Some more at the sentences page

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:

  • in the product (system) they are conceiving
  • in the project, how they come to good solutions, how they organize their work
  • in the processes used to develop the product
  • in the processes their product (system) uses to support the users letting the value crystallize

Some snippets

  • Womack
    Most managers think their greatest contribution to the business is doing work-arounds on broken processes, rather than doing the hard work to get the process right so that it never breaks down.
  • Imai in Gemba Kaizen - A Commonsense Low-Cost Approach to Management
    90% of all corporate problems can be solved using common sense and improving quality while reducing cost through the elimination of waste.
  • Tom Harada (worked under Ohno)
    The Plan-Do-Check-Act cycle was by far the most important thing we did in hindsight.
  • A project manager
    Root-Cause-Analysis on every defect found? We don't have time for that!

Conclusion

Some essential ideas behind Lean:

  • Delivering the right stuff, the right way, at the right time, as efficiently as possible
  • Understanding what real Value means
  • Quickly and easily adapting to all Stakeholders (beware: only the Customer pays, the other Stakeholders don't mind the cost!)
  • (especially for software) Total system focus - software is only an aid - only provides value when it is used successfully
  • Continuous elimination of Waste
    • Doing what contributes the most value
    • Not doing what doesn't contribute value
    • Prevention rather than repair - relentless problem solving - root cause analysis
    • Perfection - Quality costs less
  • Predictability: Continuously being able to tell what will be done when (to take appropriate action)
  • Delivering in small steps to real Stakeholders doing real things
    Minimizing the waste of incorrect perceptions, assumptions and implementations, optimizing productivity of Stakeholders - not just demos
  • Continuously optimizing what we do, how we do it, and how we organize things using PDCA
  • Empowerment - everybody feeling responsible for the Result (remember the Goal of a Project)
  • Assertiveness - actively removing impediments, no need for excuses
  • Understanding that it's not about tools: a lot is craft (you cannot 'implement' Lean)
  • Management facilitating and coaching the workers to do the right things the right way at the right time
  • Management to be personally responsible for continuous improvement (not just change)
  • JIT, Autonomation, Kanban, Value Stream Mapping, Flow, 5S, 3Mu, etc. However: beware of technique-fetishism!
  • Involving the whole organization

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.