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
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.
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:
Specify value from the standpoint of the end customer by product family
Identify all the steps in the value stream for each product family,
eliminating whenever possible those steps that do not create value
Make the value-creating steps occur in tight sequence so the product
will flow smoothly toward the customer
As flow is introduced, let customers pull value from the next upstream
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
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
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 is
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.
This is not officially part of Ohno's two pillars, but I think it's
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.
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
says: "Because it costs nothing, eliminating waste is one of the easiest
ways for an organization to improve it's operations.".
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):
Development / SE
Possible Remedies (my possible suggestions)
Prioritizing, Real Requirements
Deciding what not to do
Real management, Empowerment
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:
Remove unnecessary things
Arrange remaining things orderly
Keep things clean
→ uncovers hidden problems
Keep doing it, standardize
→ know what to improve
Keep training it
→ resisting inevitable entropy
→ minimize waste
→ optimize flow
→ 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
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:
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
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?"
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
what people have to do is partly 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!" If then, 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
in the processes used to develop the product
in the processes their product (system) uses to support the users letting
the value crystallize
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
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
A project manager
Root-Cause-Analysis on every defect found? We don't have time for
Some essential ideas behind Lean:
Delivering the right stuff, the right way, at the right time, as efficiently
Delivering the right stuff, the right way, at the right time, as efficiently
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
Perfection - Quality is cheaper
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
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.
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 35 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 100 projects in 25+ organizations in the Netherlands, Belgium,
China, Germany, Ireland, India, Israel, Japan, Romania, South Africa 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