athabasca university lean software development...
TRANSCRIPT
ATHABASCA UNIVERSITY
LEAN SOFTWARE DEVELOPMENT AND INFORMATION TECHNOLOGY
THE TOYOTA WAY
BY
PAUL MAH
A Master’s Essay submitted in partial fulfillment
Of the requirements for the degree of
MASTER OF SCIENCE in INFORMATION SYSTEMS
Athabasca, Alberta
February, 2008
© Paul Mah, 2008
i
DEDICATION
To my loving wife Cindy, Mom who was always there for me, and Dad who
taught me to always do my best.
ii
ABSTRACT
The software industry is plagued with many problems, such as high cost,
low quality, project failures, and missed deadlines. To overcome these
shortcomings, Lean as pioneered by Toyota is proposed as the way to improve
upon software development and Information Technology by making them Lean.
This becomes even more important as organizations adopt Lean, expects
Information Technology to adopt Lean.
As organizations becomes Lean, there exists new opportunities for
Information Technology to develop new software for these Lean organizations,
and this will be examined as well.
Finally a literature search is conducted to find the current state of using
Lean within the software industry to see what kind of impact it has on solving
software industry problems as a gauge to the success of this proposal.
iii
ACKNOWLEDGEMENTS
I would like to thank all the faculty and staff in the Master of Science in
Information Systems program at Athabasca University’s School of Computing
and Information Systems, especially my supervisor Dr. Qing Tan, reviewer Dr.
Richard Johnston, and chair Dr. Fuhua (Oscar) Lin.
I would also like to thank Mary Poppendieck who has opened my eyes to Lean
Software Development, when she gave a speech at the Calgary Agile Method
User Group meeting, and for Taiichi Ohno, the person who created the Toyota
Production System, and thus the idea of Lean.
Finally I would like to thank my wife Cindy who supported me in my endeavor, my
Mom who is always so caring, and my Dad who is my mentor.
iv
TABLE OF CONTENTS
DEDICATION.........................................................................................................i
ABSTRACT........................................................................................................... ii
ACKNOWLEDGEMENTS.................................................................................... iii
TABLE OF CONTENTS....................................................................................... iv
LIST OF FIGURES .............................................................................................. ix
CHAPTER I - INTRODUCTION............................................................................1
Statement of Purpose........................................................................................1
Research Problem or Question.........................................................................2
Assumptions of the Master’s Essay...................................................................2
Significance.......................................................................................................3
Limitations .........................................................................................................3
Definition of Terms............................................................................................4
Lean...............................................................................................................4
Kaizen............................................................................................................4
Delimitations......................................................................................................5
Organization of Master’s Essay.........................................................................5
Disclaimer .........................................................................................................6
CHAPTER II – TOYOTA AND LEAN ....................................................................7
Toyota, The Birth of Lean..................................................................................7
CHAPTER III – THE TOYOTA WAY...................................................................11
Long Term Philosophy ....................................................................................11
Establish Customer Defined Value..................................................................12
v
Create Continuous Process Flow.................................................................... 14
Overproduction ............................................................................................14
Waiting.........................................................................................................15
Unnecessary Transport or Conveyance ......................................................15
Over Processing..........................................................................................15
Excess Inventory .........................................................................................15
Unnecessary Movement ..............................................................................15
Defects ........................................................................................................15
Unused Employee Creativity........................................................................15
Use Pull Systems ............................................................................................16
Heijunka ..........................................................................................................16
Muda............................................................................................................17
Muri..............................................................................................................17
Mura ............................................................................................................17
Value Stream Mapping....................................................................................18
Culture of Quality............................................................................................. 20
Thoroughly Explore Alternative Solutions........................................................21
Standardized Task ..........................................................................................23
Use Visual Controls to Make Problems Visible................................................24
Use Reliable Technology ................................................................................24
Grow Leaders..................................................................................................25
Develop Exception People and Teams ...........................................................27
Respect and Challenge Partners and Suppliers..............................................29
vi
Genchi Genbutsu ............................................................................................31
Decisions by Consensus .................................................................................32
Become a Learning Organization.................................................................... 32
CHAPTER IV – APPLICATION OF LEAN TO SOFTWARE DEVELOPMENT
AND INFORMATION TECHNOLOGY ................................................................ 35
Long Term Philosophy ....................................................................................36
Establish Customer Defined Value..................................................................37
Create Continuous Process Flow.................................................................... 38
Overproduction ............................................................................................38
Waiting.........................................................................................................39
Unnecessary Transport or Conveyance ......................................................39
Over Processing..........................................................................................39
Excess Inventory .........................................................................................40
Unnecessary Movement ..............................................................................41
Defects ........................................................................................................41
Unused Employee Creativity........................................................................42
Use Pull Systems ............................................................................................42
Heijunka ..........................................................................................................43
Value Stream Mapping....................................................................................44
Culture of Quality............................................................................................. 45
Thoroughly Explore Alternative Solutions........................................................47
Standardized Task ..........................................................................................48
Use Visual Controls to Make Problems Visible................................................49
vii
Use Reliable Technology ................................................................................51
Grow Leaders..................................................................................................52
Develop Exception People and Teams ...........................................................53
Respect and Challenge Partners and Suppliers..............................................56
Genchi Genbutsu ............................................................................................56
Decisions by Consensus .................................................................................57
Become a Learning Organization.................................................................... 57
Lean Scrum.....................................................................................................58
CHAPTER V - LEAN OPPORTUNITIES FOR INFORMATION TECHNOLOGY 60
Kanban - Information Flow ..............................................................................65
Global Production Centre................................................................................66
Andon..............................................................................................................67
Check List ....................................................................................................... 68
Lean and Simulation........................................................................................68
Manufacturing Agent-Based Emulation System ..............................................69
CHAPTER VI – LITERATURE SEARCH ON APPLYING LEAN TO SOFTWARE
DEVELOPMENT AND INFORMATION TECHNOLOGY .................................... 70
Innovation in Software Development Process By Introducing Toyota
Production System..........................................................................................70
Learning to Love Lean IT ................................................................................72
Lean Software For The Lean Aircraft ..............................................................73
Introducing Lean Principles with Agile Practices at a Fortune 500 Company..74
Scrum and CMMI Level 5: The Magic Potion for Code Warriors.....................76
viii
Summary of Literature Search on Applying Lean to Software Development and
Information Technology...................................................................................77
CHAPTER VII - CONCLUSIONS AND RECOMMENDATIONS .........................78
Conclusions.....................................................................................................78
Recommendations ..........................................................................................79
Suggestions for Further Research...................................................................79
REFERENCES ...................................................................................................80
APPENDIX A ~ GLOSSARY............................................................................... 88
ix
LIST OF FIGURES
Figure 1 Value Stream Mapping .........................................................................18
1
CHAPTER I
INTRODUCTION
Statement of Purpose
The software industry is plagued with many problems such as project
failures, missed deadlines, high costs, and poor quality with no real solution to
resolve this in sight (The Standish Group, 1995). One way to solve these
problems is to borrow from the concept of Lean from the Toyota Motor
Corporation.
Software development has long borrowed from other industries. For
example, the idea of software engineering came from the engineering discipline.
Despite engineering has been around for quite a while, there too has been
failures in engineering, so one should not borrow from the engineering discipline
verbatim. Instead, one has to look at where engineering is practiced successfully,
and borrow from that. One such successful organization is Toyota where it has
up to 80% valued added engineering activity to design, and manufacture an
automobile (Kennedy, 2003). Toyota today, is poised to be the number one
automobile manufacturer (CBC News, 2008). Toyota did it the Toyota Way.
When the Toyota concepts were introduced to North America, and Europe, it was
referred to as Lean, because Toyota were able to design, and produce motor
vehicles with less resources, more quality, and faster than any other motor
vehicle companies (Womack, Jones & Roos, 1990). It is the principles of Toyota
2
which should be brought to the software industry to make software development
and Information Technology Lean, and thus become more successful.
Research Problem or Question
For this Master’s Essay, a literature search is conducted on the principles
of Toyota and the concepts of Lean as they are the cornerstone to Toyota’s
success.
To make the software industry more successful, the Lean Toyota
principles are then applied to software development and Information Technology
to come up with a new Lean way of software development and Information
Technology.
With some organizations becoming Lean, an examination is made of what
opportunities arise for Information Technology, as organizations adopt Lean.
A literature search is conducted to see what organizations have done
using Lean in software development and Information Technology as an indicator
of the current state of adopting Lean in the software industry, and whether the
proposal given in this Master’s Essay would be successful.
Assumptions of the Master’s Essay
It is assumed the reader knows about the problems within software
development and Information Technology, and they will not be discussed here
focusing instead on how Lean, the Toyota Way, can improve upon software
development and Information Technology.
3
Significance
The significance of this topic is many organizations have been adopting
Lean in order to survive in the competitive world. Organizations adopting Lean
has improved immensely in reducing waste, becoming more profitable, gaining
market shares, and be a leader within their own industry (Womack & Jones,
2003). The organization which pioneered the concepts of Lean even before it
became known as Lean is Toyota, and it is important the software industry learn
from Toyota’s Lean principles, and use it as a way to become Lean and
successful. This becomes even more important when organizations adopting
Lean expects software development and Information Technology to also adopt
Lean. When this happens opportunities for Information Technology arises as well
(Bell, 2006).
Finally it is important to find the current state of adopting Lean in the
software industry as an indicator of success in applying Lean to software
development and Information Technology.
Limitations
Although Toyota has been around for many years, and the concept of
Lean has been introduced into North America, its impact upon software
development and Information Technology is pretty much an unexplored area with
very little literature or research done in this area with the exception of Mary
Poppendieck (Poppendieck & Poppendieck, 2003, 2007). Lean Software
Development is categorized as part of Agile Software Development. While Lean
is Agile, Agile is not Lean, but Agility may evolve to be Lean.
4
Definition of Terms
Lean is a term coined by John Krafcik, a researcher for the International
Motor Vehicle Program. Lean because in comparison to companies doing mass
production, it uses less of everything, including less human effort, less
manufacturing space, less inventory, less investments on tools, and less
engineering hours with less time to develop a product. In addition, there are
fewer defects with a greater variety of quality products. The company which best
epitomize Lean is the Toyota Motor Corporation (Womak, James, & Roos, 1990).
In this paper, Lean and the principles of the Toyota Way are considered to
be one and the same.
Kaizen is the Japanese word for continuous improvement. It is derived
from two Japanese roots, kai meaning to take apart, and zen meaning to make
good. It is the art of reducing a system to its components, understanding how the
components work and interact with one another, and put it back together in a
better way (Bell, 2006). The philosophy of kaizen believes people’s life deserves
to be improved. Kaizen recognizes nothing is prefect, and there is always room
for improvement. As a result, one must always strive for perfection by improving
continuously (Imai, 1986).
This also implies once an improvement is thought of, one must do and not
merely talk about it, as these improvements will realize a benefit right away and
into the future (Ohno, 1988).
5
Delimitations
The concept of Lean easily covers several books, and it would be
unrealistic to fully talk about Lean here. For the purpose of this Master’s Essay
only the relevant points of Lean are highlighted, and for those who want to
pursue Lean further can refer to the References.
Organization of Master’s Essay
The Master’s Essay is organized into several sections categorized by the
various chapters. The separate sections are as follows:
Chapter I – Introduction, introduces the topic of Lean, and why it is
important to software development and Information Technology.
Chapter II – Toyota and Lean, gives a background of Toyota and Lean.
Chapter III – The Toyota Way, gives a description of the principles of the
Toyota Way.
Chapter IV – Application of Lean to Software Development and
Information Technology, describes how the principles of the Toyota Way can be
applied to software development and Information Technology to make it Lean.
Chapter V – Lean Opportunities for Information Technology, talks about
opportunities for Information Technology when an organization decides to
become Lean. This is an exploration of what these new opportunities would be.
Chapter VI – Literature Search on Applying Lean to Software
Development and Information Technology, is research on who may have used
Lean in Software Development, and what the outcome is, as a gage to the
6
success of the approach proposed in this Master’s Essay. This will be a literature
search on the World Wide Web.
Chapter VII – Conclusion, concludes the Master’s essay, with
recommendations on what should be done, and what further future research can
be done in this topic area.
References, contains a list of references used to write this Master’s Essay.
Appendix ~ Glossary, contains many of the non-English terminology used
in Lean. Many of these terminology has its root in Japanese, and it would be
easier for the reader to refer to the glossary if they come across a Lean
Japanese terminology they did not understand rather than flipping back through
the Master’s Essay to find the definition.
Disclaimer
I do not, and have not ever worked for Toyota. I do not even own a Toyota
motor vehicle. My eyes opened up to Toyota when one day I noticed most of the
cars I see driving around are Toyotas, and that relatives, friends, and neighbors
of mine all own Toyotas! As someone who is a career software developer, I am
always on the lookout on how to do software development better, and decided to
pursue the Toyota Way as a way to kaizen software development and
Information Technology.
7
CHAPTER II
TOYOTA AND LEAN
Toyota, The Birth of Lean
In the early days of automobile production, automobiles were made by
craft production. The workforce consists of highly trained skilled workers who
have to undergo an apprenticeship program to become a craftsman. The tools
used were general purpose machines, with no standard gauges, and thus each
part has to be custom fitted. Each automobile was custom made one at time with
a very low production volume, and high production cost. There could be many
companies competing against each other to make automobiles, each taking an
order from a customer, and custom building it. What this means is each
automobile is actually a working prototype where there is no consistency, and
reliability, due to lack of systemic testing. Since these companies also work
independently, there was no money to develop new technologies (Womak,
James, & Roos, 1990).
Henry Ford came up with an innovative way to reduce cost, and increase
product quality which he called mass production. The key to mass production is
the interchangeability of parts, and the simplicity of attaching parts which gave
him a huge advantage over craft production. Next Ford, created the moving
continuous assembly line which made the assembly of automobiles much easier.
In addition, the worker was interchangeable, as the worker does not need much
skill to assemble a vehicle. Each worker was only required to do a simple task in
8
their part of the assembly. Someone has to think of how to put the parts together,
and what the assembler should so, and this created the new profession of an
industrial engineer. A production engineer was required to figure out how to
move the product along as it is assembled. There are other people for cleanup,
maintaining the machines, and finally quality professional which acted like the
craftsmen who would fix defects in the vehicles after they were manufactured.
Mass production soon became the dominant way of manufacturing (Womak,
James, & Roos, 1990).
The story of Toyota begins with Sakichi Toyoda during the 1800s. To
prevent any confusion of the reader thinking there is a spelling mistake, Toyoda
is Toyota’s founding family name meaning “abundant rice field” in Japanese. For
marketing considerations, the company name was later changed to Toyota which
has no meaning in Japanese (Womak, James, & Roos, 1990).
Sakichi Toyoda was a tinker, and inventor. A lot of what he learnt, he
learnt himself by observing things first hand. This is the start of Genchi
Genbutsu, go and see. He grew up during a time when the then Japanese
government wanted to encourage cottage industries throughout Japan, and one
of those industries was textile. Sakichi Toyoda having learnt carpentry from his
father designed, and built a manual loom cheaper than anyone else, but the
looming industry was still very hard work, so he designed, and built an automatic
loom. What was so unique about the automated loom he created was that it has
a special device which can detect when a thread is broken, and automatically
stops the machine. This invention will eventually become one of the two pillars of
9
the Toyota Production System called jidoka which is automation with a human
touch (Womak, James, & Roos, 1990).
Sakichi Toyoda knew the world was changing and thought the power loom
was yesterday’s technology while the automobile will be tomorrow’s technology.
He instructed his son Kiichiro Toyoda to sell the patent for the automatic loom,
and start an automobile company; he wanted his son to have his own opportunity
in the world (Womak, James, & Roos, 1990).
Kiichiro Toyoda is the founder of Toyota Motor Company. He inherited his
father’s learning and creative ability, and added the second pillar of the Toyota
Production System, Just-In-Time (Womak, James, & Roos, 1990).
In 1945, when Japan lost the war, it was a new beginning for Toyota.
Kiichiro Toyoda wanted to catch up to the Americans in “three” years. He brought
in Taiichi Ohno as Chief Production Engineer to help build Toyota. Ohno had
heard the Germans were three times more productive than the Japanese, and
the Americans were three times more productive than the Germans, concluding
the Americans were nine times more productive than the Japanese. Ohno felt the
Japanese has too much waste in their productivity, and thus the start of the idea
for the Toyota Production System. Ultimately Ohno created the now famous
Toyota Production System (Ohno, 1988).
Lean production combines the advantages of both craft production and
mass production, while avoiding the high cost of craft production and avoiding
the rigidity of mass production. In order to achieve this, Lean production employs
multi skilled workers at all levels of the organization, and using highly flexible
10
machines to produce a greater number of products with greater variety for
consumers (Womak, James, & Roos, 1990).
In the 1973 oil crisis, when many companies suffered, Toyota did not
suffer as much, and recovered faster. This put Toyota in the spotlight (Ohno,
1988). Toyota continued to rise, and later in 1990, Womak, Jones, and Roos
wrote about Toyota in their book “The Machine that Changed the World”,
introducing the idea of Lean, and Toyota’s Leanness to North America. In their
revised edition in 2004, much of their predictions of Toyota’s greatness have
become true (Liker, 2004).
According to Ohno, “All we are doing is looking at the time line from the
moment the customer give us an order to the point we collect the cash. And we
are reducing that time line by removing the non-value-added waste.” (Ohno,
1988, p ix).
This is why we have to borrow from Toyota and Lean to improve the
software industry!
11
CHAPTER III
THE TOYOTA WAY
The Toyota Way is Toyota being a true learning company. Toyota
challenges its people to experiment, and learn by using initiative and creativity.
They challenge their workers to grow by constantly solving problems. The key to
the Toyota Production System is Toyota’s commitment to continuously invest in
its people, and foster a culture of kaizen. Their workers are given directives to
improve a process, and satisfy customers. At Toyota, it is not simply about
finding the best people which makes the company good. It is about finding
ordinary hard working people with a passion for automobile, which Toyota then
takes, and trains these people to make them a part of the Toyota culture (Liker,
2004).
Although the Toyota Production System is what Toyota is most famous
for, it is really the Toyota Way which makes Toyota what it is. The Toyota
Production System is only a manifestation of the Toyota Way, representing how
Toyota implemented the Toyota Way. The Toyota Way can be explained through
Toyota’s Principles (Liker, 2004). It is important to understand these principles in
order to apply it to software development and Information Technology. The
principals of the Toyota Way are as follows:
Long Term Philosophy
Toyota bases its management decisions on a long term philosophy, and
not on short term financial gains. Everyone at Toyota is instilled with the notion of
12
doing what is right for the company, employee, customer, and society (Liker,
2004).
Doing right for the company means using the money earned by the
company to reinvest back in the company. In addition, the company learned hard
to be self-reliant, doing things themselves instead of relying on outsiders (Liker,
2004).
When Toyota formed a joint venture with General Motors, they took over a
light truck factory in Fremont, California called NUMMI. Against General Motor’s
advice, Toyota hired back most of the workers including the union leaders, and
made the company a success surpassing all of General Motor’s plants in North
America in terms of productivity, quality, space, and inventory turnovers. When
times were bad, Toyota gained their trust by not laying off anyone, and placed
extra people on kaizen projects. This is because the short-sighted move of
layoffs will cause ill will, and encourage workers not to participate in kaizen
efforts. When extra workers arise due to productivity improvements, they too are
not laid off, with the best worker chosen to be leaders for other productivity
improvement projects (Liker, 2004).
Establish Customer Defined Value
In a Lean organization, the customer is the starting point. By establishing
customer defined values, value added activity can be separated from waste. The
customer defined values must be communicated, and used throughout the
product development process to align objectives, focusing on the customer, and
eliminate waste from the system. Those activities which does not add value from
13
the customer’s perspective is a waste. In product development, there are two
kinds of waste. The first waste is poor engineering, and the second is waste in
the product development process itself (Morgan & Liker, 2006).
To understand the customer better, Toyota creates a top program
leadership called the Chief Engineer. This Chief engineer has the background,
and experience to establish an emotional connection with the targeted customer
(Morgan & Liker, 2006). For example, the Chief Engineer responsible for the
RAV moved in with a young targeted family in Southern California. The Chief
Engineer for the Sienna drove a mini-van, usually a Sienna mini-van, through all
the states in the US, through all the provinces and territories of Canada, and
through Mexico (Morgan & Liker, 2006).
The Chief Engineer is responsible for delivering value to the customer,
creating the customer defined values, then communicating the customer-defined
values along with the objectives and goals of vehicle level performance to the
product team. The Chief Engineer creates the Chief Engineer’s Concept Paper
which is a twenty five page document of the vehicle product. It has input from
many people taking many months to complete, containing quantitative and
qualitative objectives for quality, cost, performance, and characteristics. Once
passed, the concept paper becomes the law, or direct order, and the Chief
Engineer develops the objectives for each functional program team with the
vehicle performance goals translated to specific measurable objectives for each
specialty area of the product team. A value hierarchy is created where high level
vehicle performance targets are decomposed, and assigned to tasks. The
14
module development team meets to define the measurable goals for the
subsystems, and communicates this to the Chief Engineer team. Value targets
and specific strategies are developed to deliver the value driven commitments of
the teams (Morgan & Liker, 2006).
Another way to establish customer value is to have Quality Function
Deployment (QFD). It is a method of designing with the aim of satisfying the
customer by translating customer needs through design targets and quality
assurance points which is used throughout each stage of the product
development (Akao, 1990). QFD is a set of techniques which focuses all efforts
and design traits on a set of customer values into product features. It is a
powerful tool to map customer values with design characteristics and design
tradeoffs (Middleton & Sutton, 2005).
Create Continuous Process Flow
In manufacturing, and services, it is important to have continuous flow, as
it is through flow, one would find inefficiencies, and waste. An often Lean
expression used is to lower the water level, as high water levels would hide
wastes such as excess inventory, and when the water level is lowered, one can
see waste easier such as the excess inventory. Flow is triggered when a
customer places an order which will cause a chain reaction of processes to fulfill
the order in a short period of time (Liker, 2004).
In Toyota, there are eight wastes identified as follows:
Overproduction. Producing items where there are no orders (Liker, 2004).
15
Waiting. Workers observing automated machines, or workers waiting for
the next step (Liker, 2004).
Unnecessary Transport or Conveyance. Transporting work over long
distances, or moving work in and out of storage (Liker, 2004).
Over Processing. Unneeded steps are taken in a process. This could be
due to improper design which results in rework on a product (Liker, 2004).
Excess Inventory. Excess inventory takes up extra space, can be
damaged, become obsolete, creates longer lead time, but more importantly hides
problems such a production imbalance, late deliveries, defects, equipment
downtime, and long setup time (Liker, 2004).
Unnecessary Movement. Wasted motion in the process, such as looking
for things, reaching, stacking, and walking (Liker, 2004).
Defects. Production of defect results in wasted resources. Defect requires
repair, rework, and replacement resulting in wasteful time and effort (Liker,
2004).
Unused Employee Creativity. Not engaging, or listening to employees,
resulting in lost learning opportunities, time, ideas, skills, and improvements
(Womak, James, & Roos, 1990).
Often one thinks an increase in speed for production would mean
sacrificing on quality. This is the exact opposite for flow. If one were to do things
in batches, and a defect occurs, the error would not be detected until much later,
and by that time, many more such errors would have occurred, and it would be
16
hard to trace back to the source of the error. As these defects occur, bureaucracy
will be created to handle problems, building in a lot of non-value added
processes such as waiting on others to make decisions. It would be better to take
the people who does the value added work, line them up, and let the project flow
through these people, thus gaining speed, productivity, and quality (Liker, 2004).
One way of seeing if there is continuous flow is to have one piece flow
where only one piece is allowed to flow making it easier to see problems (Liker,
2004).
Use Pull Systems
A push system is when products are pushed onto the next step whether it
is required or not. For example, an automobile manufacturer can push vehicles to
automobile dealers to sell whether they need to or not, and the automobile
dealers try to sell it to customers whether they want to buy it or not (Liker, 2004).
A better strategy is to use a pull system. In a pull system, it is very much
like a supermarket, where the customer picks up a product to buy which in term
will trigger a process to replenish the product. The customer only picks up the
products they demand, and the retailers only reorder the product which was sold.
To avoid excess inventory, you may even be willing to pay more for the on
demand service (Liker, 2004).
Heijunka
Heijunka means leveling out the workload. Earlier we talked about pull
where nothing gets made until there is a customer order. Unfortunately customer
17
orders can, be erratic where at times there are great demands, and at other
times, there are none. Strictly building to order would mean at times, there are
excessive work where there could be excess inventory along with a lot of
overtime, and then at other times there are no work. What needs to be done here
is to level the work. If customer orders are accumulated a little, to allow for
leveling of production, then the production line can be leaner (Liker, 2004).
The Japanese word for waste is muda. Focusing strictly on the eight
wastes above can be harmful, as there are two other wastes to consider in a
system, and they both start with an ‘m’. Therefore there is the elimination of the
three wastes as follows:
Muda – No Value Added Waste. These are the eight wastes discussed
earlier. They are wastes which lengthens lead time, extra movement, excess
inventory, which results in waiting (Liker, 2004).
Muri – Overburden Waste. This is the pushing of resources such as
people, and machineries beyond there natural limits. It some ways, it is the
opposite of muda. Pushing people too fast can cause safety concerns, and
decrease in quality. Overusing machineries can cause machines to breakdown,
and cause defects (Liker, 2004).
Mura – Unevenness Waste. This can be thought of as the balancing of
muda and muri. Unevenness occurs when at times there are more work than can
be handle, and then at other times there are not enough work. They can be due
to irregular scheduling or fluctuating production volumes. If mura is not resolved,
then muda will be the result (Liker, 2004).
18
To eliminate the waste of unevenness it is important to have enough extra
inventories, and people on hand to handle the highest level of production, even if
the average required is much lower. For example, focusing too much on muda or
the eight wastes will cause erratic one piece flow where there are stops and
starts, and thus creating underutilization, and over-utilization which in turn will
cause other problems such as lower quality. As a result it is more important to
work like the slow and steady tortoise, rather than like the jerky hare (Liker,
2004).
Value Stream Mapping
Mapping will enable you to see the ideal state or the better state to go to.
Figure 1 Value Stream Mapping
19
Toyota uses Material and Information Flow Mapping to depict current state
and future ideal state in the process of developing implementation plans for
installing Lean systems. Attention is given to eliminating waste, adding value,
and establishing flow. Toyota focuses on three flows, flow of material, flow of
information, and flow of people and processes. In Lean, Material and Information
Flow Mapping is called Value Stream Mapping (Rother & Shook, 2003).
A value stream is all the value added, and non value added actions
required to bring a product from raw materials to a finished good in the hands of
the customer. It consists of two flows, orders traveling upstream from the
customers, and products traveling downstream from raw materials to finished
goods to the customer (Jones & Womak, 2003). Using paper kaizen, one can
record all the work elements, and the time to take to do each work element. After
doing this, stack all the work elements, and remove the wasteful work elements.
The improved stack of work element is shorter than the original stack. Since the
value adding work is the same, by removing waste, future operators can devote a
greater percentage of work on the value added activity and thus do more without
working harder (Rother & Harris, 2001)! Value Stream Mapping is an essential
tool for Lean. It helps one visualize the flows and see the sources of waste, tying
together the Lean concepts and techniques, and avoid cherry picking practices.
Value Stream Mapping is the basis for implementing Lean, showing linkages
between information flow and material flow, and describes exactly what you are
going to do for process improvement (Rother & Shook, 2003). In Mapping Value
20
Streams, it is important to keep in focus the customer values, and one way to do
this is to integrate QFD with Value Stream Mapping (Middleton & Sutton, 2005).
Jones and Womak (2003) also talked of an Extended Value Stream
Mapping which is the same as Value Stream Mapping, but extended beyond a
single plant into multiple plants, and across companies. The same analysis in
Value Stream Mapping applies, but can analyze the added complexity of multiple
plants, and external companies. In this paper, the two concepts will be treated as
the same.
Culture of Quality
Create a culture which stops to fix problems, and have quality the first
time. This idea came for Sakichi Toyoda where one of his inventions is the
automatic loom, which automatically stops when a defect is found (Liker, 2004).
At Toyota, when a defect is found, the production line worker is trained to
pull an andon cord or stop cord when a defect is discovered. When the cord is
pulled, the supervisor comes over to see if the problem can be remedied, and
within a certain time limit, if the problem cannot be resolved, the whole assembly
line stops. Problem solving is done to find the problem, and how to fix the
problem so that it will not occur again, then the assembly line is started again
(Liker, 2004).
Poka-yoke is used to prevent errors before they happen. It is a way to
error proof a process. Ways to prevent errors are to be simple, and often comes
from the people doing the work. Often there is a tendency to introduce
bureaucracy and complicated steps for quality, thinking as long as these steps
21
are taken, quality would be there. The problem is that the people who think of
these steps do not work with the process, and often comes up with arcane steps
which hinder the process. It is better to have the people doing the work to come
up with ways for quality improvement, and creates the steps themselves. The
steps created have to be easy steps. In order to do this, the worker has to be
trained in problem solving, trained to go and see, analyze the situation, use one
piece flow to surface the problem, and ask why five times (Liker, 2004).
Toyota also uses check list to make sure steps are not missed to reduce
defects. Standard components from one vehicle can be used on other vehicles
as a way of doing incremental development, and ‘time out’ is used if people are
thinking too narrowly. It is not so much the tools to use for quality, but to have a
principle of quality (Liker, 2004).
Thoroughly Explore Alternative Solutions
At Toyota, product development is talent driven, committing the most
capable resources at the beginning. The best opportunity to explore alternative
solutions is at the beginning. Toyota front loads its product development process
with integrated cross-functional engineering to resolve major engineering
challenges early when the maximum possible options are available. This will
allow for exploring alternatives (Morgan & Liker, 2006).
Toyota uses what is called Set Based Concurrent Engineering (SBCE). In
SBCE, for every subsystem of both product and manufacturing system, multiple
solutions are explored simultaneously, as learning increases geometrically by
considering design alternatives at every level of the system. If this process is
22
managed carefully, a highly robust, reliable, and predictable product life cycle
can be created. For each solution, aggressively attack it with rapid low cost
analysis and tests to eliminate weak solutions. To avoid using excessive
resources in determining alternatives, a system is devised to eliminate weak
alternatives, and this is done through the use of knowledge base trade off curves.
Systematically synthesize learning such as the results of analysis and tests are
placed on design space maps where knowledge can be reused in subsequent
projects, which can then increase speed and quality of design. This runs counter
to iterative development. Basically in product development, it is important for
participants to reason and communicate in sets of ideas, and gradually narrow
the sets of ideas until there is a convergence to a final design. The convergence
to a solution is possible only after it has been proven (Ward, 2007).
Toyota uses SBCE to examine a broad range of alternatives, before
making a final decision. By using the “set-based” approach of examining multiple
alternatives simultaneously as opposed to point to point, Toyota increases its
chances of coming to an optimal solution which will minimize expensive changes
later on. An example of this use is the development of the first commercial
hybrid, the Toyota Prius. The Prius Chief Engineer Mr. Uchiyamada, despite tight
deadlines, asked four design studios to come up with competing styling designs,
of which two were chosen for clay models, before a final decision was made. In
using SBCE, Toyota engineers have a sense of how the vehicle work as a
system, and spends a lot of energy on interfaces, not only between components,
but how they will be manufactured later on. There is a focus on system
23
compatibility before the individual design is considered complete, rather than a
focus on individual design completion (Morgan & Liker, 2006).
Standardized Task
There is the misconception that standardization is about finding the best
way to do something. In fact kaizen cannot be done, until there is a stabilized
standard process. Standardized work is necessary for quality. When a defect is
discovered, the first step to discovering the problem is to see if standardized
work is followed. If it is, then standardized work must be changed to get rid of the
defect. The people who write the standardized work must be the ones actually
doing the work. This is because they are closest to the problem, and also most
likely to follow the standardized work if they created them themselves. To do
otherwise would create top down rigid bureaucracy, hierarchical structures with
slow communications, resistance to change, and standards not followed. What
Toyota does is to have an enabling bureaucracy which is organic where the
worker is the most valuable resource. The worker is an analyst and problem
solver and sets standards for themselves, and knows how to change the
standards for improvement. For example, engineers are taught the standards of
product development so that everyone knows what to do, and use a common
terminology. Check lists has evolved to show what practices are good, and what
practices are bad, but more importantly, the engineers know how to use
standards, and when to change the standards they use to make the standard
processes better (Liker, 2004). If the standards have not been updated for a
24
while, it means kaizen has stopped, so supervisors are encouraged to be
embarrassed when standards have not changed (Shingo, 1989).
Use Visual Controls to Make Problems Visible
To make sure no problems are hidden, use visual controls. One important
aspect of this is to keep the work area clean, because in a clean work area, one
can easily spot problems. One way for doing this is to use the Five S Program.
The Five S Program is as follows:
Sort (Seiri). – Sort items separating those which are needed from those
which should be disposed of.
Straighten (Seiton). – Orderliness, everything must be placed in the proper
place.
Shine (Seiso). – Cleanliness, where the act of cleaning serves as
inspection to expose abnormalities, and find pre-conditions for failure.
Standardize (Seiketsu). – Creating rules, developing systems and
procedures to monitor and maintain the first three S.
Sustain (Shitsuke). – Self discipline to stabilize and maintain the work
place for kaizen.
(Liker, 2004).
Use Reliable Technology
Toyota uses new technology only after it is proven to be useful by a broad
spectrum of people through some experimentation. When using new technology,
Toyota looks to see if it adds value. If the new technology has an adverse effect
25
on existing Toyota principles, the new technology is rejected, or delayed until the
problem the new technology introduces can be removed. The new technology
must help Toyota in its flow, and it must have visibility. Information Technology
does not drive Toyota, and it must not get in the way of Toyota’s principles.
Information Technology is still critical to Toyota, but technology is simply a tool
for Toyota, which must be evaluated like any other tools (Liker, 2004).
For example, instead of using complicated supply chain software, Toyota’s
preference is to use a manual system of kanban to control the supply chain
process. Instead of having Information Technology diagram of information
systems, Toyota prefers diagrams of how Toyota does business, and how the
Information Technology will support the business at Toyota. This is because
Toyota is an automobile manufacturer, and not a software manufacturer (Liker,
2004).
Grow Leaders
One of the biggest differences between Toyota, and other organization, is
Toyota grows their own leaders. All of Toyota’s CEO comes from within the
company while most of North America’s companies have their leader coming in
from the outside. For example, Fujio Cho, a former president of Toyota grew
through the ranks of Toyota. He was one of the original Sensei taught by Taiichi
Ohno himself. He was also the leader of the Toyota plant in Georgetown,
Kentucky. Throughout time, Toyota has always found the right person within the
company to lead the company in the right direction (Liker, 2004).
26
Since the leaders are all home grown, they all support the culture at
Toyota, unlike in North American companies, where leaders goes through a
revolving door going form one company to the next (Liker, 2004).
Another leader is the Chief Engineer. The Chief Engineer at Toyota is the
person responsible for the development of an automobile model. This person
goes through the typical training that all engineers does at Toyota. Only the top
engineer becomes a Chief Engineer, and this person must not only be a good
engineer but must have other expertise as well to be the champion of the
automobile model he is responsible for. The Chief Engineer is the one who “runs
the program”. Chief Engineer acts as the program manager, project manager,
leader, technical systems integrator, makes the difficult decision for problem
resolution, chief technical architect, champion of the product, delivering value to
the customer, holds the whole product development system together, and the
one person accountable for the success of the team. The range of responsibility
for the Chief Engineer includes being the voice of the customer, defining
customer value, concept of the product, objectives of the program, vision of the
program, and product planning. The Chief Engineer is also responsible for the
vehicle level architecture, performance, characteristics, and objectives. The skills
of a Chief Engineer includes exceptional engineering skills, exceptional
communicator, feel for what customer wants, intuitive, grounded in fact,
innovative, skeptical of unproven technology, visionary, practical, teach,
motivator, disciplinarian, patient listener, attitude of achieving targets, and ready
to get hands dirty (Morgan & Liker, 2006).
27
There is no such thing as someone walking out of university and be a
manager right away. In order to be a manager or team lead, one must be able to
teach, and train more junior workers. This is one of the ways management add
value to a product, as management activities are consider to be non-valued
added activities. If a worker has not learnt what they were suppose to learn for a
job, it is considered to be the fault of the manager! The managers themselves
learnt the same way from having their superiors teach them, and they can easily
substitute for the worker doing the work (Liker & Meier, 2007). For example,
when Fujio Cho was President of Toyota in the Kentucky branch, he is often
found on the shop floor teaching! If management cannot teach to their
subordinates and pass on skills acquired, the person cannot be a manager
(Liker, 2004).
Develop Exceptional People and Teams
Toyota develops exceptional people, and teams to follow the philosophy of
the Toyota way. While it is the individual which does the actual work, adding
value, it is the team which provides support for the individual, and also provides a
point of socialization to exchange ideas, and help one another. Toyota
establishes a balance between individual work and team work, and spends
consider effort to train an individual to develop depth of technical knowledge
along with a wide range of skills, and to have the Toyota philosophy second
nature to everyone. At the same time, team work is the foundation for the
individual to work hard for the company. The Toyota Production System originally
was also known as the “respect for humanity system” (Liker, 2004).
28
Technical excellence is fundamental to Lean product development, and is
revered at Toyota. Engineers at Toyota spend much of their time doing core
engineering. After a rigorous hiring process, engineers first learn to sell cars at
the dealership and door to door, learning to understand the customer better, then
are placed on a career path with a deep technical skill acquisition, and mentored
critical tactical skills. There is a push for engineers to get their hands dirty, and
use Genchi Genbutsu to go see directly for them self. It is important engineers
are connected to the product they design. Much of the engineers training come
through on the job training, and mentoring through a Sensei. Toyota managers
are also teachers, and they are responsible for the development of his
subordinates (Morgan & Liker, 2006).
Freshmen are also placed on a freshmen project lasting four to nine
months to hone their skills of using engineering tools and accomplishing the task
the Toyota Way. This means coming out with more than one solution, and
presenting the ideas in an A3 form. This is quite different than what they have
learned at university, and quite emotional as senior Toyota managers still
remembers there freshmen projects vividly. Following this, they are placed into a
two tier on the job training. In the first tier, CAD work is one of the things they
have to learn to do, and they spend time doing this for two years. In the second
tier, they spend three to six years working on designing related parts. Only when
they could do this are they considered an engineer. During this eight years, the
manager mentor interviews the engineer four times a year not only on
performance and peer review, but also on technical progress, adherence to
29
company process, and standard methodology based on Toyota’s standard skill
set. From this the manager outlines areas of improvement and develops an
action plan for the engineer to work on for the next interview (Morgan & Liker,
2006).
Most companies do not want to train their engineers to great depth,
because of the high turn over. What most companies does not realize is the fact
this education is necessary for Lean Product Development. Standardization of
skill sets is important, and all engineers have to strive to learn the standard skill
set. At the same time, the organization must be a learning organization where
managers and leaders are expected to be able teach and mentor others (Morgan
& Liker, 2006).
The commitment for a deep education of engineers evolved out of
Toyota’s history where they have to do almost everything from the ground up
when they first manufactured vehicles (Morgan & Liker, 2006).
Toyota invests in its people, and in return gets a commitment from its
people to do their best at Toyota (Liker, 2004).
Respect and Challenge Partners and Suppliers
Toyota not only uses the Toyota Way internally, they also move upstream,
and teaches the Toyota Way to its suppliers (Liker, 2004).
Toyota does not deal with its suppliers in an adversarial way, they go out
of their way to work with a supplier, and even have suppliers design part of a
system of an automobile such as the radiator. If Toyota wants its suppliers to cut
cost, it will also send people to the supplier to help them cut costs. When
30
suppliers have problem which causes Toyota to shut its assembly line, Toyota
will send people to the suppliers to help them diagnose the problem, and correct
the problem. Toyota focuses on fixing the problem, and not blame. Only as a last
resort, will Toyota terminate a supplier. If a supplier does very well, then in the
next automobile model, the supplier may have a bigger contract, as they have
proven themselves (Liker, 2004).
When a company becomes a supplier to Toyota, the company is
essentially adopted into the Toyota family and is treated as part of the Toyota
family. Often partnerships are formed between Toyota and suppliers, where
Toyota may take part ownership of the supplier (Liker, 2004).
Often engineers from suppliers can be found, at Toyota, and Toyota
engineers are found at supplies as a way to cross train. This does not mean
Toyota is totally dependent on its suppliers, and Toyota keeps some core
technologies in house, and as a rule, have two suppliers for the same part (Liker,
2004).
The respect, and challenges Toyota gives its employee, they do the same
to their suppliers. Suppliers are given respect, and they are also challenged to do
better, undergoing kaizen to reduce cost, and increase quality. In asking for a
part, Toyota may only give a general description, and it is expected, the supplier
will design the rest since the supplier will have the most knowledge in its own
field (Liker, 2004).
31
Genchi Genbutsu
To understand the situation or any part of a business problem, you must
go see for yourself first hand. Do not rely on reports from others, and do not take
anything for granted. This is the first part of any problem-solving. Accompanied
with this, one must have the skill to analyze, and understand the situation (Liker,
2004).
Teruyuki Minoura, a former president of Toyota Motor Manufacturing in
North America was taught by Ohno. Mr. Ohno made him stand in a circle for
eight hours on the shop floor to teach the power of observation, to think for
oneself what one sees, question, analyze, and evaluate. Data is important, but
fact is more important, as data is one step removed (Liker, 2004).
Toyota is a learning company, and it expects its employees, including the
president to go and see problems for themselves, and learn from it. For example,
when Chief Engineer Yuji Yokoya was assigned to develop the next version of
the Toyota Sienna, he traveled to North America, rented a van in most cases a
Toyota Sienna, and drove through all fifty states in the United States, all
provinces and territories in Canada, and all parts of Mexico. He did this to
personally see for himself what North Americans would like to have in a van. As
a result of this, the next version was a much improved version, and it became a
very popular mini-van in North America (Liker, 2004).
President and executives all practice Genchi Genbutsu, and spend a
considerable amount of time on the shop floor going and seeing for them self
(Liker, 2004).
32
Decisions by Consensus
At Toyota decisions are made by consensus after considering all options,
and then implementing the decision very rapidly. How one arrives to making a
decision is just as important as making the decision itself. Toyota management
will forget a wrong decision, if the process used to make the decision is the right
one, but will give a reprimand if the decision was the correct one, but the process
for arriving to the decision was based on chance (Liker, 2004).
Nemawashi is a process used to gain consensus. Young engineers are
taught to seek the input of others as a way to generate consensus, and by the
time the decision has to be made, it only becomes a formality because, a
decision has already been made before hand by consensus (Liker, 2004).
Such efforts are expended because it serves three purposes. The first is
all facts are uncovered to avoid painful backtracking. The second is gets
everyone on board for the decision, and the third is there is a great deal of
learning at the beginning even before a project is started (Liker, 2004).
Become a Learning Organization
Toyota is a learning organization. The Toyota Way is about how Toyota
learns as an organization. It involves the company to learn from its mistakes,
determine the root cause, provide effective counter measures, empower the
people to implement measures, and a process to transfer new knowledge to the
right people (Liker, 2004).
Toyota has a seven step method for practical problem solving as follows:
33
Initial problem perception is when a problem is first recognized. It could be
a defect discovered in the production line.
Clarify the problem is to “grasp the situation”, clarifying the problem to
understand the real problem. It starts with observing the situation with a
clear mind using Genchi Genbutsu, and comparing it to the standard.
Pareto Diagram can be used to sort the problems.
Locate area and/or point of cause trying to identify where the problem is,
where the cause is most likely, leading a person to the general vicinity of
the problem.
Investigation of root cause is conducted to identify the root cause. Toyota
uses a very simple and effective way of finding the root cause, and that is
to use the “5 Why” analysis. In the “5 Why” analysis, the problem solver
will ask why five times in order to determine the root cause. It does not
necessary have to be five times, it can be more, the point being often the
problem is not where you first see it, you must look at it deeper, and one
way of looking at it deeper is to ask why many times.
Countermeasure is developed to fix the problem, and prevent it from
happening again once the root cause is discovered.
Evaluate the countermeasure to see if it does what it is suppose to do.
Standardize the new process after the evaluation has shown the
countermeasure is effective in correcting the problem.
(Liker, 2004).
34
From these principles of the Toyota Way, the Toyota Product
Development System, and the Toyota Production System is created. In the next
chapter we will use these principles to apply on software development and
Information Technology to come up with Lean Software Development and Lean
Information Technology.
35
CHAPTER IV
APPLICATION OF LEAN TO SOFTWARE DEVELOPMENT AND
INFORMATION TECHNOLOGY
When Lantech, Inc. and Wiremold Company switch to Lean, they found
out their accounting department has to change also. Accounting departments
often produce information which is too late to be useful, and in fact some of the
financial statements run counter to what Lean is trying to do. For example, in
Lean, one of the goals is to reduce inventory, and if traditional cost accounting is
used, the lower inventory will result in confusing financial statements. This is
because of the use of standard cost and variance style income statement, where
the cost of the old inventory must be included in the expense column. When
inventories are lowered, the result of the Lean initiative will make the profit look
lower initially, and the results of the financial statements will look like it is worse
when doing the right thing of using Lean. It is important to remember the real
expense of carrying inventory is hidden in the old system, but brought out visibly
with Lean. Adding this with the pressure to show monthly or quarterly results for
public traded companies, it is important to work with investors of the meaning of
the confusing financial statements when adopting Lean (Cunningham & Fiume,
2003).
At the same time accounting departments must switch to cost
management, and not cost accounting, as the real goal here is to reduce cost. In
other words, the accounting department must work as a partner in the Lean
36
initiative, and not hinder it. As well the Lean initiative also applies to the
accounting department in making it Lean thus making the accounting department
more efficient with lower costs (Cunningham & Fiume, 2003).
Also when companies switch to Lean, their project management practice
has to change as well, especially if it is used in product development. Having
Lean product development also means to use Lean project management. Special
consideration must be given to heavy loading of resources at the beginning of the
project. As well the PMBOK guidelines must be modified to work with Lean,
especially the Toyota Way of doing Lean. Without this adaptation, project
management will hinder or kill the Lean initiative (Leach, 2005).
Information Technology must adjust accordingly like the accounting
departments in Lean organizations, and Lean project management. What this
means is Information Technology must act as a partner to the Lean initiative,
making it useful to the Lean process while at the same time find ways to be Lean
itself.
With this in mind, we will apply the Lean Toyota Way principles to software
development and Information Technology as follows:
Long Term Philosophy
Management should make Information Technology management
decisions based upon a long term philosophy.
Information Technology should do what is right for the company. This
means developing software which truly represent the needs of the company, and
37
keeping the software relevant to the company, reinvesting back to Information
Technology whenever possible.
What this means for Information Technology is as follow:
Instead of lay offs for Information Technology workers when times are
bad, and outsourcing jobs to lower wage countries such as India,
organizations should guarantee Information Technology workers job
security, putting excess Information Technology workers on kaizen
initiatives. This would gain trust to the worker. We want to be Lean, but not
mean. Nothing kills off kaizen, trust, initiative, and loyalty quicker than
having layoffs.
The customer is important. When releasing software to the customer, the
software should be free of defect, and if it is not, it should be fixed for free
rather then charging a customer for an upgrade release later on.
To be a benefit to society, organizations should allow its Information
Technology workers to donate their time for creating software for charity.
Establish Customer Defined Value
A modification to Agile Software Development would be to have a Chief
Engineer who is the product champion. If the software is developed for the
consumer market, then someone like the Chief Engineer would be the driver for
the product. For an in-house developed application, or custom built application,
the Chief Engineer must interact with the customer in their own environment to
understand what is required. Having the customer as part of the Team as in
Scrum and Extreme Programming is not enough. The Chief Engineer must
38
understand how the customer does their work, and how the new software will
support them in their work.
Instead of a model in Extreme Programming, a concept paper should be
created with input from everyone to describe what the new software is to do.
Each area of specialty will do the work to create a value hierarchy, and what
each area of specialty within the product development team should do. QFD can
be used to map customer values into software design, and software design
tradeoffs.
Create Continuous Process Flow
It is important to have continuous flow in software development. Instead of
a batch of analysis, then a batch of design, followed by a batch of coding, and
finally testing, it would be better to structure the work such that it flows. For
example instead of batching a horizontal slice, do a vertical slice for each feature
or function point of the software where each vertical slice gets its own analysis,
design, coding, and testing. This would make it easier to create any one feature.
For each cycle done, experience gained can be used in the next cycle.
In software development, there are eight wastes identified as follows:
Overproduction. Extra features are overproduction. Every code written has
to be tracked, compiled, integrated, and tested. Each new code written adds
complexity, and increases the point of failure. Since extra features are not
required in the first place, it may well not be needed, and become obsolete,
getting in the way. If there is not a clear economic need for a new feature, it
should not be done (Poppendieck & Poppendieck, 2007). One way to alleviate
39
this problem is to have an architecture which will allow features to be easily
added later, thus removing the need to add the features now (Poppendieck &
Poppendieck, 2003).
Waiting. Any delays keep the customer from realizing value as soon as
possible. This includes waiting for the necessary resources to be available for a
project, developers waiting to find the right people to understand a requirement to
be implemented, the project team waiting for top management to give approval
for the project, waiting for the change approval process, and waiting for code to
pass tests (Poppendieck & Poppendieck, 2007).
Unnecessary Transport or Conveyance. Handoff is unnecessary transport
or conveyance. When work is handed off from one to another, tacit knowledge is
loss. Tacit knowledge are knowledge which a worker possess about the work,
which is not written down, and often when the work is handed off to another
worker, much of the tacit knowledge is loss. To reduce this waste, there has to
be a reduction in handoff, and if that is not possible, have workers work in teams
where they can use face to face communication to pass the tacit knowledge
along better. Also release work for feed back earlier would reduce this defect
(Poppendieck & Poppendieck, 2007).
Over Processing. Unnecessary work which is not required such as paper
work which does not add value, especially when no one is going to read it! The
paper work consumes resource, slows response time, hides quality problems,
gets lost, degrades, and becomes obsolete. If the wasted paper work does not
add any value, do not require software developers to do it. This includes
40
requiring software developers to write various reports such as status reports. A
good test to see if the reports add value is to see if anyone uses the work
afterwards (Poppendieck & Poppendieck, 2007).
In addition, relearning is an example of rework in software development.
Sometimes software developers may have to relearn something they have learnt
once before, and then forgot about it. This can be alleviated by engaging
software developers more in the project (Poppendieck & Poppendieck, 2007).
Excess Inventory. Partially done work is excess inventory. Partially done
work ties up resources in investments which do not yield results, and there is no
guarantee the partially done work will work. They get in the way of other software
development, and if they never go into production, then they will truly be a waste
(Poppendieck & Poppendieck, 2007). Some examples of partially done work are
as follows:
Not coded requirements documentation. This is as a result of
requirements written too soon. The longer design and requirements
sit not coded, the more likely they need to be changed before
coding (Poppendieck & Poppendieck, 2003).
Unsynchronized code – Code checked out or in different branches
of version control which needs to be merged. The longer they are
unsynchronized as work progress on the different branches, the
harder it is to merge the code, and increases the need to put the
same or similar code in two different branches (Poppendieck &
Poppendieck, 2003).
41
Untested Code – Code has to be integrated, tested, and accepted
or it does not count. If testing is not done right away, there is no
immediate feed back to the developer who created the code, and if
the developer has moved on, then there would be no feedback at
all resulting in some other developing relearning the work to fix the
defect (Poppendieck & Poppendieck, 2003).
Undocumented Code – If documentation is needed, they should be
done as the code is written such as the user guide. The code itself
should be as self documenting as possible (Poppendieck &
Poppendieck, 2003).
Code Not Deployed – There should be a bias for deploying as
quickly as possible. Users can handle small increments better
(Poppendieck & Poppendieck, 2003).
Unnecessary Movement. The fastest way to do two things which have to
be done is to do it one at a time. When switching tasks, there is a significant
overhead incurred. One has to remember what they were doing, and what they
were thinking about before they can get back to the high level of concentration
necessary to complete the task when a task is switched from one to the other
(Poppendieck & Poppendieck, 2007).
Defects. Defect becomes a huge waste, if it goes on undetected. To avoid
this, test immediately, integrate often, and release to production as quickly as
possible (Poppendieck & Poppendieck, 2007). To get rid of defects, make use of
base classes, and frameworks, employ automated unit testing and integration
42
testing. Use exploratory testing to find defects, and put processes in place to
prevent defects from happening again. Defects should be detected as early as
possible. The primary purpose is to mistake proof the code, and to detect defects
as early as possible to prevent them from happening again. Inspection to prevent
defects is important, inspection to find defect is too late. Prevent errors from
happening. Never build good code on top of bad (Poppendieck & Poppendieck,
2003).
Unused Employee Creativity. Software developers and Information
Technology workers are expensive resources, and if they are not allowed to do
what they do best, then that is a waste.
Often one thinks an increase in speed for software development means
sacrificing quality. If one were to have continuous flow, where wastes are
eliminated, and allowing people who add value to kaizen their own processes,
the software development process will go much faster without sacrificing quality.
Use Pull Systems
In the Water Fall software development lifecycle where there is a batch of
analysis, followed by a batch of design, programming, then testing, the results of
each phase is pushed to the next phase.
Examples of having a pull system in software development is to not code
a feature until quality assurance can test it so that the code is tested as soon as it
is written. In turn, design is not done until a developer is ready to code it. Finally
analysis is not to be done until the feature is ready to be designed. In this way,
43
there is no batching of each step of the software development cycle such as the
water fall software development lifecycle. Ideally, we want flow, and if it is hard to
have flow, create flow by using pull, not push.
Heijunka
In software development, the problem of unevenness occurs quite often,
and they should be leveled to correct the problems of muda, mura, and muri.
Often an organization have a new budget at the beginning of the fiscal year, and
want to start all the software projects all at once, and then toward the end of the
fiscal year, they may find there is not enough funds, so there are not much work
to do. In this situation it is better to have the projects released throughout the
year as projects are created, and new projects are started.
Within a software project, there is also unevenness. Developers at times
could be waiting on getting approvals, waiting to get feed back, waiting for the
design, whereas at other times they have to work extra hours to code up a
feature. Quality assurance may not have much to do while code is being created,
but rush to test everything as all of a sudden they have a lot of code to test, and
may find out they have less time to do so due to developers taking up some of
the time of quality assurance in the overall schedule.
It is important to add slack time to a software project. Once pass 80%
utilization, cycle time increases especially with greater batches. To reduce cycle
time, it is important to have smaller chunks of work to even out the arrival of
work. In other words the waterfall software development life cycle creates huge
batches from one phase to the next. It is better to break this down into small sets
44
of work, say one feature at a time. Have budgeting processes such that not all
projects are released at the same time (Poppendieck & Poppendieck, 2003).
Value Stream Mapping
It is very important for Information Technology to learn Value Stream
Mapping. The concept of Value Stream Mapping is very similar to Process
Modeling, a skill a Systems Analysis should have. Part of a Systems Analysis’s
job is to look for improvement, especially in terms of using Information
Technology. Systems Analysis are accustomed to solve a problem for the user
through analyzing the practice of what the user are doing now, versus what
improvements to the process could be had if the user were doing what they are
doing with a new computer system. As a result, it would be easy for Information
Technology to adopt value stream mapping. When organizations adopt Lean,
Information Technology armed with Value Stream Mapping capability can be a
partner in helping other parts of the organization become Lean. In doing so,
rather than having information systems being in the way of being Lean, new
systems can be thought up to help Lean. Of course Information Technology can
also use Lean to improve its own department, and thus give it more credibility
when they help other parts of the organization become Lean.
Paper kaizen is also used along with mapping the future value stream of
the software development process to figure how long it takes to do each work
element and removing those processes which does not add value.
45
Culture of Quality
A culture of stopping to fix problems, and have quality the first time is
important to software development.
Poka-yoke for software development is writing the test cases first. These
test cases are to be automated so they can be easily run again, and again. As
code changes are made, the automated test cases can be run as a regression
test to prevent introducing an error to existing code. These automated testing can
be for unit testing and integration testing, using tools such as JUnit for Java, and
NUnit for C#. For web development, Watir can be used for quality assurance
testing, or acceptance testing which can be easily run each time code is
deployed to quality assurance. These automated tests can be hooked up with a
continuous build tool such as Cruise Control which will automatically check out
code, compile, and then run the automated tests. When an error is detected an
email is sent out to all that has made code changes since the last successful
build (Clark, 2004). Most developers do not know how to write the test case first,
and it is important to teach developers how to do this. As with Toyota, software
developers must be taught to go and see, analyze the situation, and ask why five
times to figure out the problem and how to fix it.
Another way to build quality is to create a well tested base class for
subclasses to inherit from. These base classes could be as a result of getting rid
of repeated code. Instead of having many repeated code, or variation of the
same code which does the same thing, get rid of the different versions, and
inherit from a common base class which encapsulates the same functionality. A
46
good example of this would be the desire to have a consistent look and feel on all
the screens of an application where the buttons and other functionalities have the
same behavior throughout the application. To implement a new screen, all a
developer has to due is to subclass the base class with the appropriate behavior,
and the specific screen behavior, and the screen is done. Automated testing is
only needed for the specific behavior, as the base class behavior already has its
own automated tests.
Standardized components can also be used in software. Within a
company certain software written has the same functionalities. If they are written
in the same language, then they can be reused in other projects. Many software
developers have a tendency to write their own code no matter what, in a sort of
‘not invented here’ syndrome, even when there are standardized software
component available to use. A good example is the wealth of open source
software out there which software developers can use. While not all open source
software has high quality, there are many which have high quality, especially
those in www.apache.org. For example, many Java software developers want to
write their own database connection pooling, their own object relational
database, and even their own application server. There is no need to write
software for these in a Java project, as the open source software will do,
especially when many of the open source software are well tested in the
community, and comes with their own set of regression tests.
47
In addition, analysis patterns, design patterns, implementation patterns,
and testing patterns can be used in software development. Patterns represent
time tested solutions for a given problem.
Software also benefits from having check list. For example, a method of
procedure can be created for deploying a new application to production. A check
list can be used on how to put a screen together, or how to map objects to a
relational database for object relational mapping. If developers are stuck on a
problem, then ‘time out’ is required to allow the developer to approach the
problem from another angle.
Thoroughly Explore Alternative Solutions
Encourage developers to take the time and explore alternative solutions,
front loading the project at the beginning to allow for this. Use Set Based
Concurrent Engineering (SBCE) for software development. In Extreme
Programming, there is an aversion to a Big Up Front Design, as a reaction to the
Waterfall Software Development Lifecycle, but Extreme Programming goes too
far the other way. Extreme Programming uses an emergent design, where the
design of the software will evolve through iterations. As the design emerges,
refactoring is necessary to achieve the emergent design. Perhaps the Extreme
Programmers should plan more and use set based concurrent engineering to
explore all options. By doing this, the amount of refactoring necessary for an
emergent design will be reduced. Also the iterations used in Agile Software
Development is point based which implies picking only one design, then you
have to move from one point to another to change the design. This is not to say
48
the Water Fall Software Development Lifecycle should be used, but to use
SBCE.
SBCE must be used in software development to find the optimal solution.
This would also make the design much better than upon relying on an emergent
design, as it is based upon exploring a broad range of options. Also, this will take
away a weakness of Scrum where the Scrum Master arbitrarily makes a decision
based upon the gut feeling of the Scrum Master just to get going. What is
important to note, with SBCE, the team pretty well knows where the direction is
going anyways, and not on the whim of a Scrum Master. This means front
loading the software development project with experts from each domain to iron
out problems at the beginning!
Standardized Task
Standardized work is necessary for software development quality.
Although there are parts of software development which requires creativity, there
are many parts of software development which is very procedural and can
probably be standardized. For example, the basic create, insert, update, delete
functionalities to the database, where the steps or repeated over and over again.
One can write standards to do this, and how to write unit tests for them to make
sure they work. Also developers can experiment with the best way to put a
screen together, and come up with a standard to do so. If there is a better way to
do it, then the standard will be updated by the developers themselves. Also
developers can all be trained the same way as the Toyota engineers are trained
on product development, so all the software developers within the same
49
company can work together with the same standards using the same
terminology.
Use Visual Controls to Make Problems Visible
The 5 S Program is also an important part of visual controls to keep the
work place clean in software development and Information Technology.
The 5 S Program can apply to Java coding as follows:
Sort (Seiri). - Reduce size of code based by removing unneeded items.
Examples of items to remove include commented out code, unused imports,
unused variables, unused methods, and unused classes. Refactor code to
remove redundant code.
Straighten (Seiton). - Organize projects, and packages, removing package
dependencies, and minimize dependencies. Classes should be loosely coupled
between them, and code should be very cohesive within the class.
Shine (Seiso). - Clean up so problems can be more visible. This means
resolving failed unit tests, improving the coverage of unit tests, and improving the
performance of the unit tests. Resolve warnings upon compiling including not
using deprecated methods, have proper JavaDocs in the code, and TODOs are
completed and then removed.
Standardize (Seiketsu). - Create standardize procedures, and follow them.
This includes such things as properly naming classes, methods, and variables.
Adopt a code format standard agreed to by the development team. If the project
uses a third party product such as Hibernate, create a set of procedures on how
to use the third party product, such as how to assemble the code, and
50
configuration files to use the third party product. If the project uses many
screens, then create a standard on how the screens can be assembled.
Sustain (Shitsuke). - Keep up with the discipline. Do this continuously.
(Poppendieck & Poppendieck, 2003).
Similarly, the 5 S Program can apply to Information Technology as follows:
Sort (Seiri). - Sort through workstations, and servers separating what is
not important from what is important. Not important files such as old versions of
software, old files, and old reports are backed up, and then deleted.
Straighten (Seiton). - For workstations which are commonly used, they
should conform to a common team layout, and logically organized to make things
easy to find. This will make it easy for team members to use wherever they log
in.
Shine (Seiso). - Clean up. This means the work place has to be clean
such as throwing away garbage, cleaning the monitor, clean the whiteboard after
taking pictures of the important design.
Standardize (Seiketsu). - Have automation and standards, such as each
work station has the latest version of tools, is backed up regularly, and do not
allow junk to accumulate.
Sustain (Shitsuke). - Keep up with the discipline.
(Poppendieck & Poppendieck, 2003).
The Five S Program is to be conducted every day, unlike most North
American companies where it is either not conducted, or if conducted, is only
51
once a month, or only once a week at the most, or only when an important visitor
comes. The idea is not simply to superficially do it, but to become a part of the
worker’s daily habit to properly organize the work area continuously to make the
work area a much better place to work.
For Information Technology, a dash board could be used to communicate
status. In software develop project management, user stories can be pinned on
the wall, and as they are completed, are moved from the not completed side of
the wall to the completed side of the wall, as a way for visually identifying the
status of a project. For continuous integration, and automated testing, lava lamps
could be use to indicate the status of a build along with automated testing where
the green lamp lighting means a successful build which passes all the automated
tests, and a red lamp lighting means otherwise (Clark, 2004).
Use Reliable Technology
This has huge implications for Information Technology. Information
Technology must support the business. Adding new technology does not
necessary mean the business will work better. Before new technology are used,
they must be shown to fit with the business needs of the company, and only if
there is a clear benefit would they be introduced.
Also technology is not flexible when changes are required. Often when the
environment changes, a request to make changes in technology may take time,
but with a manual system, people can adjust to the change very quickly. In other
words it is easy to have kaizen with people, but with automation, they cannot be
improved, as they only do what they are programmed to do.
52
In order for Information Technology to be more useful, the automation
must be able to be kaizen as well, where necessary process improvements on
the automation are quickly added by Information Technology. What this means is
that in addition to having efficient processes before automating, the automation
has to be easily adjusted through kaizen, since a fixed automated process will
show no process improvements (Liker, 2004).
Toyota prefers to use simple software applications which can work
collaboratively with the Toyota Way (Liker, 2004).
In doing software development, the same applies. It is often better to use
proven technology for developing a software application, and it must support the
software developers in what they were doing. For example, some companies
have a policy of adopting Microsoft applications such as C# and .Net for software
development without regards to whether it is appropriate or not. Developers then
struggle to create a web application using Visual Studio even when much of the
web development can easily be done with a simple text editor.
Grow Leaders
What companies should strive to do is to develop their own people,
including developing their own people to become leaders. In software
development, there have been studies done, where one of the most effective
software projects is to have the concept of a Chief Surgeon. The problem with
this is not everyone can be a Chief Surgeon, because no one has all the required
skills to be one (Schach, 2005). The implication to this is that Information
Technology, as well as other parts of the company must train their people well,
53
especially training people to become leaders within their own company. The
resource to do this is the leader, and the leader must be able to teach!
In software development within a company there may be a product
manager, program manager, project manager, technical architect, and team lead
which borders on being obscure because in small projects, there can be more
non-value added people than there are people who does the actual value added
work. A chief engineer can replace these five people with one person thus
reducing cost, and at the same time have a role similar to the Chief Surgeon. In
Extreme Programming, there is no concept of a leader of the project, with the
coach being the closest thing. Similarly in Scrum, there is the Scrum Leader who
leads the project, but is in no way anywhere near the responsibility,
accountability, and skill of the Chief Engineer. Often time, they mire themselves
in the methodology, rather than getting the real work done.
The concept of Chief Engineer would greatly enhance the software
development process, and software companies should take the time to develop a
Chief Engineer.
Develop Exceptional People and Teams
Most companies, after hiring their best, simply placed these people into
positions to fend for themselves. They are given no further education other than
company education programs which amounts to lip services, and their boss were
trained similarly with no ability, or desire to teach subordinates. This is true in
software development. In Extreme Programming, workers can learn from the
coach or from one another in pair programming, and in Scrum workers have to
54
try and learn from themselves or help each other learn. Even before thinking of
methodologies, organizations and Information Technology must invest in their
employees, and train them further. It is not enough from what employees learn at
a technical school or university, or someone taking a continuing education
program. At Toyota, engineers are trained for twelve years before they are
considered engineers. In Information Technology the same thing should be done
for Information Technology workers. If not, they will find a situation where
workers do not know what to do, and as a short term solution, hires outside
consultant to do the work, giving them the work experience, and then leaves the
organization taking the knowledge with them (Morgan & Liker, 2006).
Information Technology should borrow from the way Toyota train there
engineers. This starts with recruitment where in addition to hiring at the top of the
class the potential Information Technology worker must have an aptitude for
computers, technical competence, creativity, problem solving, ability to work in
teams, see the situation, communications, discipline, motivation, and dedication
to work. There should be a broad training of the Information Technology worker
including orientation, working on the company’s core business in the front line,
and doing a freshman project with a focus on finding alternative solutions and
presenting ideas in an A3 form. In addition they must learn modeling with Unified
Modeling Language (UML) and Entity Relationship diagrams, and be a part of a
project where they learn various technologies including open source software,
and learn how to write the test cases first before writing code. The freshmen
should be mentored by senior people as they progress, and does not become a
55
Senior Information Technologist until they gain all the necessary skills. This will
build an Information Technology worker who would have a standard set of in
depth technological competence.
For any organization, especially Information Technology, one person
cannot do a project, and project work requires workers to work in teams. Based
on the effort Toyota spends on developing the team, Information Technology,
should similarly expend the same kind of effort so that each member of the team
can contribute individually as well as contributing to the team. Team members
are to be taught to work together, and there must be no hands off leader. For
example, the software architect, must know how to code, and does so readily,
the project manager might chip in by helping quality assurance to test to help
meet deadlines. Testers can help write testing code to reproduce a defect to
make it easier for developers to correct a defect. Allow developers to talk to the
user to help the business analyst gather the necessary requirements he needs
to. Managers chip in with the project whenever they can without demanding
useless reports.
When starting a project, the first iterations should be slow, to allow for the
team to interact with one another in a social way to help one another. A leader is
there to help guide the project team. As the project proceeds, the leader steps
back, and let the team take over, but the leader can step in at any time to help,
as the leader cannot be hands off.
56
Since it is so important to see value from the customer’s point of view,
Information Technology workers should also be trained in the customer areas
where the software they are creating or maintaining is being used.
Respect and Challenge Partners and Suppliers
In Information Technology, sometimes there is a need to hire outside
consultants. Outside consultants have to be trained like regular employees to
understand how to work with the company and contribute as well. This means
the outside consultant will have to be trained just like the internal employee with
the same support system. In addition, internal developers do work in the
consulting company as a way to cross train, and gain more experience.
Genchi Genbutsu
For Information Technology one must go out and see how the customers
use the software created by Information Technology. This will give them a better
idea of how to make the software better, and more useful. In explaining the
failure of the Chrysler Three Corporation, Kent Beck, the founder of Extreme
Programming, blamed the new customer representative for failure of the project
as a single point of failure (Stephens & Rosenberg, 2003). In connecting with the
customer, it is more than simply having the customer as part of the team. For
example, Kent Beck should have used Genchi Genbutsu to see for himself,
analyze, and evaluate to make his software development better. Information
Technology professionals should use Genchi Genbutsu to understand their
customers better in order to create better software. Information Technology
57
managers, as well as company executive should take the time to talk to people
on the front line, and see things for themselves to help them better understand
how the business is doing (Middleton & Sutton, 2005).
Decisions by Consensus
In software development, it is important to get everyone on the same page
so the project team can all move at the same direction to get the software
developed without damaging conflict. Information technology should be taught to
seek the input of others as a way to generate consensus. This will allow for
uncovering all the facts, gets everyone on board for the decision, and be a
learning experience. By using consensus, the silos in software development of
business analyst, software architect, data administration, database
administration, developer, quality assurance will be removed.
An improvement made to Scrum would be instead of the Scrum Master
making a quick decision when a decision has to be made, the Chief Engineer
Scrum Master should allow the team to make the decision through consensus.
Alternative the Chief Engineer Scrum Master makes the decision by seeking
broad input from everyone including administration to thoroughly explore the
problem, and again gain consensus to make a well informed decision.
Become a Learning Organization
Often time in a software project there is not enough time to do things. In
the mad push to get things done, processes and code are written haphazardly on
the grounds that there is no time to do it the right way. Unfortunately what this
58
also means is there is always time to do things the wrong way despite the fact
the project will result in a product full of defects with missed deadlines.
What this means is hansei is required to reflect on what is not done right
and what should be done to improve, as a learning experience. If a developer
does self reflection and realized the over all consequences of having time to do
things the wrong way, then they will realize what needs to be done and have
time to do things the right way to achieve a high quality product while meeting
deadlines, and learning to do things the correct way.
In software development, one should do more than a post mortem to
determine what went well, and what can be improved. Instead of waiting for an
iteration, or end of project to determine problems, this should be done throughout
the project. This is because each improvement will make the process better, and
speed up software development.
Most developers look at defects as inevitable, quality assurance will
always find defect. Developers should do as much as possible to eliminate
defects first before releasing to quality assurance such as writing the test case
first. When defects are found through quality assurance, the seven steps for
practical problem solving should be used to discover the root of the defect, and
fix it, fixing it in such a way that these kinds of defects will not be repeated in the
future.
Lean Scrum
When Takeuchi and Hirotaka (1986) wrote about Scrum for product
development in “The New Product Development Game”, of which Scrum for
59
software development is based upon, they did not include Toyota in their study
amongst companies which they thought were successful in product development
(Schwaber & Beetle, 2002). Had they did that, Scrum for software development
may have included some of the principles of the applying the Toyota Way to
software development and Information Technology as stated in this Master’s
Essay to come up with a Lean Scrum.
60
CHAPTER V
LEAN OPPORTUNITIES FOR INFORMATION TECHNOLOGY
In this chapter, we will take a glimpse of establishing customer defined
value of a Lean organization from the point of view of Information Technology.
This is what a Chief Engineer of Information Technology intending to create
software for Lean organizations must at least know as a minimum to look for
opportunities which arises when organizations decides to become Lean. This is
limited to the scope of the principles of the Toyota Way as defined in this
Master’s Essay.
For manufacturers, there are two camps, Lean, and information systems.
These two camps are opposite one of another, and they clash. In the Lean camp,
there is a disdain for information systems, seeing them as introducing
complications, and extraneous tasks; if the production process was good to begin
with, there would be no need for an information system. Instead, kanban can be
used as the information system. Having automations and computer systems
would drain resources from the organization’s core business, as a huge amount
of time can be spent fixing misbehaving robots, and information systems instead
of building the product. Computer based planning and control would overly
centralize manufacturing which is especially true for Material Resource Planning
systems, and Enterprise Resource Planning systems which would lead to a huge
disconnect from the reality of the plant floor with the computer generated
schedules and inventories (Piszczalski, n.d.). Practitioner of Lean values kaizen,
adaptability, fluid organic systems, and rejects a system which is designed,
61
implemented, and then left alone. Lean requires each individual to search for
new ideas making improvements continuously and incrementally each minute of
each day. Information Technology, especially traditional Information Technology
is noted for rigidity, and does not bode well for Lean. Once Information
Technology is added, it is hard to take out, and becomes a technological
monument as far a Lean is concerned (Bell, 2006).
Even with the faults of Information Technology, most organizations,
especially a manufacturing plant, is a complex organization. Value streams are
becoming faster with more variables, global supply chains are more complex,
and capable, and customers are becoming more demanding (Bell, 2006). It is
only through computer systems could the organization manage itself. As a result,
Information Technology, and information systems will have to be integrated with
Lean, to create eLean or Lean Information Technology. If an organization is
unwilling to leverage Information Technology, it can find itself at a competitive
disadvantage (Piszczalski, n.d.) (Bell, 2006). From a manufacturing standpoint,
the two are trying to achieve the same end goal. Lean should be made the
foundation, with which computer systems layered on top to optimize Lean
(Piszczalski, n.d.). Information Technology can be used to add value and remove
waste, but if used improperly can institutionalize waste. If Information Technology
helps a Lean organization, then it is a useful tool, but the second it impedes,
becomes a crutch or a distraction, then it should be removed as waste (Bell,
2006)!
62
Organizations choosing to become Lean usually hire Lean consultants to
make them become Lean. Lean consultants advocates getting rid of the
expensive inflexible legacy computer systems, favoring pencil and paper, and
spreadsheets for doing streamlined value added chains. For large complex
organizations, the solution does not scale, and as a result, there is a need for
Information Technology solutions to help organizations scale the Lean solutions.
One area where Information Technology may help is to have software which will
help manufacturing organizations load level production especially setting the
pacemaker process. Also in streamlining the value chain, Information Technology
solutions will be required for integrating manufacturing, and logistics. With
complex operations possibly separated by geographical distances, software is
required to integrate all the different processes to enable the pull of the different
parts of the product being manufactured so there is no waiting for parts,
especially when inventory is not to be kept. As software vendors recognize the
unique characteristics of a Lean organization, they become better at supplying
software which will aid the Lean organizations, thus allowing for the maturing of
Lean Information Technology software. There is a movement away from
Materials Requirements Planning business models to Lean oriented business
models, especially solutions which enables Lean value chains. Information
Technology solutions should be customer focused, help eliminate waste such as
excess inventory, and simplify the value streams and operations. In this way
Information Technology can gain acceptance in Lean organizations by being an
enabler of Lean (Aberdeen Group, 2004).
63
Without automation, as Lean moves to the supply chain, it becomes more
difficult to orchestrate activities. Businesses are evolving to have integrated
companies which will serve the end customer, and not the intermediate
customer, creating a sort of virtual Enterprise. This makes supply chain very
important where the supply chain must not only integrate internally, but with
external organizations as well. Supply chain has to become more than point to
point interaction between organizations, but also being an information exchange
on the entire supply chain. From the context of Lean, supply chain management
entails the processes of product movement where value is gained and lost
(Aberdeen Group, 2006).
With Lean, supply chain has to pull, rather than push. In the execution of
the supply chain, the logistics are different such as there are more frequent
deliveries rather than one huge batch delivery. The elimination of large
warehouses means there is no need to retrieve, inspect, put away, store, and
retrieve process cycles. Supply chain event management requires business
processes for monitoring, notifying, simulating, controlling, and measurement.
These can be implemented independently of Enterprise Resource Planning
software applications, in a cost effective manner to allow enterprises examine
and measure Lean activities through the entire supply chain. This leads to
integration tools which will allow for the exchange of information in one usable
format (Aberdeen Group, 2006).
For supply chain intelligence, metrics must be tied to strategies,
objectives, and goals. All productivity measures which do not have a link to the
64
extended enterprise should be removed. Within the Lean philosophy, metrics
needs to be based on value stream activities with the goal of customer
satisfaction (Aberdeen Group, 2006).
For best of breed manufacturing organizations adopting Lean, there is
heavy use of systems integrator professionals to enable technologies, and
extend Lean across the entire supply chain. Over time, Lean manufacturing
organizations should make these Lean experts internal, rather than rely on
external expertise (Aberdeen Group, 2006).
When Lean experts advise against the use of a particular systems such as
Materials Requirements Planning, they are not saying to stop using technology
but to stop using technology as a substitute for thinking! Only when the manual
process is perfected with no room for improvement should the process be
automated, but the automation has to prove itself to be better than the manual
process, and even then, the manual process is still in place in case the
information system goes down (Liker & Meier, 2006).
Software could also be created to aid in schedules and activities. Flow of
product and materials flow can be easily collected on the shop floor with the aid
of bar code, wireless technology, and electronic kanban. Software can help with
scheduling, inventory management, logistics, quality, and maintenance.
Dashboard review can compare performance between two different sites. More
important, enabling technology can support manufacture’s needs to adjust to
market demands, facilitating root cause analysis, corrective action, and a
65
formalized processes for problem resolutions extending back to the supplier base
(Aberdeen Group, 2006).
Toyota has three information systems which will be of increasing
importance as follows:
1. Product Data Management – This is used to retrieve product information,
bring together functional components, and construct manufacturing
sequence tables.
2. Supply Chain Management – Used to arrange upstream and downstream
organizations in a chain and globally optimizes cost, quality, quantities,
and timing for all processes from sales outlet to suppliers, and does this
by leveling out flows.
3. Company Wide Information System – Toyota is very conservative on this,
preferring to see how other organizations uses it first. Toyota realizes it is
a competitive strength to do this and is currently rebuilding, and integrating
information systems throughout its company.
(Hino, 2006).
Kanban – Information Flow
Integration of Material Resource Planning systems with Just-In-Time
systems can improve manufacturing system efficiency. Information Technology
integration can facilitate the use of a pull system, both internal and external to the
organization, as it can transmit the order information through the entire supply
chain in a timely manner. Information Technology systems can reduce lot sizes.
Between firms Information Technology systems can improve lead time by having
66
the customer information transmitted from customer service or help desk to the
production system in a timely manner (Ward & Honggeng, 2006).
Information Technology integration by itself is not as effective as using
Information Technology integration with Lean/Just-In-Time. In order for
Information Technology integration to be effective, the organization must have a
sound Lean/Just-In-Time system first. Lean/Just-In-Time can first provide the
standardization, and then Information Technology can then reduce the
uncertainty. For example, Toyota has spent many years perfecting its Lean/Just-
In-Time system, but it also recognizes the importance of Information Technology
to improve its performance, and as a result, implemented SAP (Ward &
Honggeng, 2006).
Global Production Centre
In July 2003, Toyota established the Global Production Center to train
shop floor experts. Part of this effort was to convert implicit knowledge into
explicit “standardized knowledge” using digital technology. As Toyota grows,
Toyota’s “mother plan” system of support for its overseas affiliates are stretched
to the limit supporting over fifty manufacturing sites in twenty six countries. The
Global Production Centre, located in Toyota City, Aichi Prefecture, Japan, is
used to train approximately eight hundred people per year drawing from two
hundred and thirty personnel from Toyota Plants. In addition to teaching skills,
the facility has V-comm which is an engineering technology allowing engineers in
Japan to work with engineers overseas (Toyota Motor Manufacturing Kentucky,
Inc., 2004).
67
This came as a result of applying kaizen to the “mother plant” concept,
and found rooms for improvement, especially for overseas plants. This means
finding best practices from individual practices which were handed down person
to person. Digital technologies were used to compile these best practices into
visual manuals, keeping text to a minimum. Photos, animation, and video clips
were used to facilitate comprehension. Slow motion videos were used to
demonstrate to the student skills which a seasoned expert may do too fast. The
training is to provide a common base training which includes digital training along
with other hands on training, especially in concepts of Lean such as takt (Toyota
Motor Manufacturing Kentucky, Inc., 2004).
This center cuts training time in half (Toyota Motor Manufacturing
Kentucky, Inc., 2004).
Information Technology departs should similarly create a center to train
Information Technology workers for an organization. As part of this training,
implicit knowledge, and best practices should be digitized with photos, animation,
and video clips which can then be used to train the Information Technology
worker.
Andon
Andon is a sign used to indicate when something goes wrong (Liker
2004).
Andon can also used in Information Technology. For example, in doing
continuous build, when the application does not compile, or a test fails, then one
can use software such as Cruise Control to send emails to notify developers. In
68
addition, lamps can be hooked up to show green for a successful build and test,
with a red lamp to show an unsuccessful build to show something is wrong
(Clark, 2004).
Check List
The check list which Toyota engineer uses, along with the book of what
went wrong computerized at Toyota, and maintained by the people who uses
them (Liker 2004).
Information Technology should also use check lists and record what went
wrong, and these too should be computerized with the owners of these items
updating them.
Lean and Simulation
Lean can be hard to learn. Ncube (2007) came up with the idea of using
games and simulations for experiential learning. The Experiential Learning Cycle
(ELC) consists of four parts as follows:
Experience – activity phase of activity and doing;
Process – What, sharing reactions and observations, patterns and
dynamics;
Generalize – So what, develop real world principles;
Application – Now what, planning effectively using what has been learned.
She went on to create the Lemonade Tycoon simulation game for the
developmental learning of Principles of the Lean Enterprise. The outcome of
using Lemonade to learn Lean concepts included problem solving, team
69
development, and concept development, and has enhanced the learning of the
concepts of Lean. Good games allow students to make mistakes and learn from
their mistakes in a realistic environment, without suffering from the
consequences of real life.
Manufacturing Agent-Based Emulation System
Changing from traditional manufacturing approach to a Lean
manufacturing approach is a complex enterprise wide task. To ease the
transition, Ivezic, Potok, & Pouchard.(1999), came up with Manufacturing Agent-
Based Emulation System (MABES)., a distributed autonomous agent framework
is to emulate manufacturing allowing people to see the effects of the changes
before making the changes. It is an open framework to allow for the analysis and
design of manufacturing systems, enabling one to see the effects of
manufacturing approaches from traditional push to the Lean customer driven task
of pull systems with takt, minimizing inventory, and minimizing work-in-progress.
MABES have a collaborative interface to the design and analysis tool, and
can animate message passing among agents and display manufacturing-process
statistics for several metrics. This allows for the analysis of alternative scheduling
strategies such as push, pull, and takt, and the effects of special events such as
bottlenecks, and disruptions in production. From this, one can determine the
proper scheduling when converting to a Lean manufacturing approach (Ivezic et
al., 1999).
Clearly there are unique customer defined values for a Lean organization,
opportunities for Information Technology to provide services to.
70
CHAPTER VI
LITERATURE SEARCH ON APPLYING LEAN TO SOFTWARE
DEVELOPMENT AND INFORMATION TECHNOLOGY
In this chapter we will be taking a look at the results of a literature search
conducted on where Lean has been applied to software development and
Information Technology to give an indication of the state of Lean in the software
industry. The literature search was conducted on IEEE journals online using the
key word of “Lean”, as well as on search engine “Google” with keywords
“Toyota”, “Lean Software Development”, and “Lean Information Technology”. The
definition of a successful Lean implementation is that it must cut cost, use fewer
resources or be more productive with the same resource, and have a higher
quality of service or software product. The result of the search is as follows:
Innovation in Software Development Process By Introducing Toyota Production
System
Fujitsu Software Technologies sought to improve their software
development processes following the Information Technology bubble burst of
2000 to stem profit decline. They tried some things like using Unified Modeling
Language, but these efforts did not improve productivity as much as they wanted,
so they decided to introduce the Toyota Production System along with Agile
Software Development into their software development process. Their reasoning
for this was because the Toyota Production System has proven itself in hardware
manufacturing. As a result, they decided to introduce Toyota Production System
71
concepts of visual management, jidoka (automatic detection of defect), heijunka
(leveling), and the elimination of muda (waste) with Agile Software Development.
This was introduced experimentally to some divisions in 2003, and all divisions in
2004. By September of 2004, they have found their profits have stopped
declining, and began a slow process of recovery (Furugaki, Takagi, Sakata, &
Okayama, 2006).
Fujitsu Software Technologies used their own customized Agile Software
Development noting some aspects of Agile have the same concept as their
interpretation of the Toyota Production System. Acceptance tests were used to
create pull, customer prioritization was used to achieve Just-In-Time, use of
visual management, multi-skill development, and heijunka. Productivity was 24%
lower than company standard during the first iteration, and then improved to
26.6% in the last iteration (Furugaki et el., 2006).
For software maintenance, Fujitsu Software Technologies implemented
the following heijunka process using a store pull system for work execution,
workload management with a single queue, and control through visual
management. By using heijunka, they have found the overtime hours were
reduced with no one having to work during holidays like before, and productivity
improved by eighty percent in four months (Furugaki et el., 2006).
This is an indication of success as there is reduced cost of overtime, and
increased productivity along with an improvement of profits.
72
Learning to Love Lean IT
In 2004, Acuity Brands got a new CEO with a mandate of making the
company Lean. Pat Quinn came on board as CIO responsible for providing
systems to enable changes in manufacturing. As he learned about the Lean tools
of removing waste, and kaizen, he realized Information Technology can benefit
from Lean as well. The people in Information Technology was at first skeptical,
seeing itself as creative, but Quinn sees a lot of waste in software development,
and sees a process framework which can reduce waste, and at the same time
does not stifle creativity (Overby, 2007).
The people in Information Technology began conducting kaizen events,
and saw potential efficiency and process improvement in software development,
and network management. This resulted in weaning the company of mainframes,
and transitioning the company to use VoIP, as well as improving application
development (Overby, 2007).
Acuity Brand is well on its way to being Lean along with the Information
Technology. The kaizen requires a lot of training, and heavy involvement by the
CIO. Quinn points out they are not their yet saying Toyota has been at it for forty
years, and still not there yet, as it is an ever evolving kaizen (Overby, 2007).
The reduction in cost of not using mainframes along with improved
application development means this company is successful in transitioning
Information Technology to Lean.
73
Lean Software For The Lean Aircraft
Through the Lean Aircraft Initiative (LAI)., the U.S. Air force attempted to
spread the Lean paradigm to the aerospace industry by collecting lessons
learned from Lean production into a model called the Lean Enterprise Model
(LEM). The LEM consists of principles such as responsiveness to change;
minimization of waste; right thing at right place time, and quality; value streams,
kaizen, and quality (Sutton, 1996).
Lockheed Martin Aeronautical Systems (LMAS) has been evolving its
software practices for the last ten years to achieve high quality at a low cost.
Lean was applied to a specific Lean software project for the Lockheed
Martin Aeronautical Systems (LMAS) C-130J air lifter (Sutton, 1996).
For responsiveness to change, domain engineering is used to identify stable
repetitive structure of the problem and solution domain with the requirements,
and architecture structured along stable domain lines. Problems are divided into
sub-domains, to facilitate requirements engineering. The solution domain is
modeled such that repetitive elements are identified, generalized, and captured
with a Domain Specific Language Design (DSDL) with strict rules on how they
interact. This allowed for a “Lego” block approach to be used for component
construction and integration, and limits the scope of errors (Sutton, 1996).
Waste minimization is achieved through reuse, obtaining the maximum
benefit from all the work done in the program. Domain driven designed is
achieved through DSDL. A “Narrow-slice development” is used to develop a
narrow complete example of the next development phase’s product during the
74
current phase which is then used to refine the current phase’s product and next
phase’s process (Sutton, 1996).
Quality Function Deployment is used to prioritize customer desires and
project needs to enable doing the right thing at the right place, time, and quality
(Sutton, 1996).
Quality is achieved through correctness by construction with formal
requirements. For each stage of development, formal methods are used to make
the product inherently correct as it is produced, or use formal verification after a
product is produced. All release integrations are tested in the target environment
(Sutton, 1996).
Through Lean practices, they have been able to repeatedly do a new
software build from requirements to completed qualification testing in forty-eight
hours, with the software changes working correctly most of the time the first time.
As a result, few errors were discovered during FAA rigors testing, with the
software metric below industry metrics for schedule and budget. The Lean
paradigm enabled them to produce a superior and safe product at low risk, and
cost (Sutton, 1996).
The high quality of the product along with the lower cost definitely makes
this a success story.
Introducing Lean Principles with Agile Practices at a Fortune 500 Company
Capital One is a Fortune 500 financial services company faced with the
challenges of decreasing operating costs, and to be the first in delivering
innovative product offerings to customers with a goal of doing so with a reduced
75
timeframe to market. They did this by making a deliberate decision of applying
Lean Principles with Agile techniques (Parnell-Klabo, 2006).
Lean provided a framework to focus on delivering value to the customer.
Before they changed their process, they spent twelve weeks to define their
current processes, finding a wealth of quantitative and qualitative insights into
root causes of duration. A future value stream was created to show them where
to go to reduce this duration. Employing Lean principles, they found insights on
eliminating wastes, and used the “Five Whys” technique to do root cause
analysis, identifying processes for waste removal opportunities. These processes
were prioritized as to which one should be worked on first, moving quickly to
remove non value added tasks, and reducing handoffs (Parnell-Klabo, 2006).
At the same time, they explored Agile noting the fact average Information
Technology projects spend only 10% of the actually doing software development.
More importantly, they discovered their current processes do not support agile
development. They had attempted Extreme Programming before, but have to
abandon it. On the second time around, they have discovered Scrum
methodology to use as a guide (Parnell-Klabo, 2006).
To introduce Lean and Scrum, they selected a pilot project which is
representative of their current projects. The pilot became a learning experience
for both performers and stake holders. Success measures were defined including
decrease duration, no cost increase, decrease effort, no degradation in quality.
The outcome of this pilot shows a 40% decrease in duration compared with the
waterfall method, and coming 10% under the allocated budget with no
76
degradation in the quality of code. Furthermore, a targeted survey show an
increase morale by the performers, with other water fall projects wanting to be
next project to use Lean and Scrum, as well as positive endorsements from the
customer (Parnell-Klabo, 2006).
After the switch to using Lean and Scrum approach, projects were
delivered 40% to 50% faster than the waterfall approach with 10% to 17% under
budget. The ruling hypothesis is to start with the Lean tools first, applying Lean
principles, and then apply the agile techniques (Parnell-Klabo, 2006).
The decrease in duration with no increase in cost, decrease effort with no
degradation in quality means Capital One successfully achieved its Lean
Information Technology objectives.
Scrum and CMMI Level 5 : The Magic Potion for Code Warriors
Systematic is a company which has already a CMMI Level 5 practice, but
still wanted to do better, and decided to adopt Lean for future improvements
(Sutherland, Carsten, & Johnson, Kent, 2007).
Lean competencies were established through training and process were
identified and prioritized for using Lean. Pilot projects were created to use. The
results of the pilots confirmed the Lean mindset is a good way to identify
improvements, and that Scrum with story-based early testing can be adopted
while still maintaining CMMI Level 5. The pilot projects showed significant gains
in productivity and quality over traditional methods. Every category of work was
found to be reduced by almost 50% (Sutherland et al., 2007).
77
Systematic concluded CMMI and Scrum can result in significant
improvements while maintaining CMMI compliance. Lean Software Development
can be used as an operational tool to identify opportunities for improvement
within a CMMI 5 company (Sutherland et al., 2007).
The significant gain in productivity along with reduced work without
affecting CMMI compliance clearly shows Lean in Information Technology is
successful here.
Summary of Literature Search on Applying Lean to Software Development and
Information Technology
The literature search on applying Lean to Software Development and
Information Technology did not turn up a huge number of hits. This is not
surprising considering the fact Lean is still a very new concept in many
organizations outside of Japan, let alone be used in software development and
Information Technology. Of the small sample set of results returned, they all
implemented some aspects of the Toyota Way, but not all of it. More importantly,
they all indicated positive feed back on the use of Lean in either software
development, or Information Technology based on the criteria of cutting cost,
using fewer resources or be more productive with the same resource, and having
a higher quality of service or software product. This is not a definitive affirmation
of applying the Lean Toyota Way to software development and Information
Technology, but it does say this is the right direction to go.
78
CHAPTER VII
CONCLUSIONS AND RECOMMENDATIONS
Conclusions
A background of Toyota and Lean is given to show why we should borrow
from Toyota to improve the software industry.
The Lean principles of the Toyota Way are given, as they are basically the
cornerstone to Toyota’s success and what it truly means to be Lean. These
principles are then applied to software development and Information Technology
to come up with a new Lean way of doing software development and Information
Technology in an effort to solve the problems encountered in the software
industry.
Also with organizations becoming Lean there are Lean customer defined
values for Information Technology to be aware of. The Lean customer defined
values represent new opportunities which Information Technology must be aware
of to provide services for the Lean organization.
Through a literature search, there is really not much material found on
using Lean within the software industry making the sample size too small to
make any definitive conclusion. Of those which were found and illustrated in this
Master’s Essay, they achieved successes in applying some aspects of Lean to
software development and Information Technology. Success is defined as cutting
cost, using fewer resources or be more productive with the same resource, and
having a higher quality of service or software product, This is not enough to
79
indicate if the proposal given in this Master’s Essay would be successful, but it
does give an indication this is the right direction to go.
Recommendations
With the success of Toyota through its use of Lean, and the formula given
in this Master’s Essay for applying Toyota’s Lean principles to software
development and Information Technology, as well as some successes of Lean in
the software industry as found through a literature search, organizations should
adopt Lean in their software development and Information Technology.
As well, Information Technology should also take advantage of the
opportunities which exists when organizations decides to become Lean.
Suggestions for Further Research
Find a software development or Information Technology organizations
which has adopted Lean, and to see how they compare with those software
development or Information Technology organizations which has not adopted
Lean. Do Lean in software development and Information Technology
organizations have the same kind of success as Toyota? One such company to
investigate is Google.
If one cannot find a Lean Information Technology organization, perhaps
an experiment can be done where one creates such an organization, operating
on the Lean Toyota Way principles. This would ultimately show if Lean has the
same kind of successes when applied to software development and Information
Technology.
80
REFERENCES
Aberdeen Group (2004, June). The Lean Strategies Benchmark Report.
Manufacturing Excellence Moves to the Value Chain.
Retrieved January 8, 2008 from
http://www.lean.org/Community/Registered/ArticleDocuments/LeanStrateg
iesReport.pdf
Aberdeen Group (2006, September). The Lean Supply Chain Report
Lean Concepts Transcend Manufacturing through the Supply Chain.
Retrieved January 8, 2008 from
http://www.lean.org/Community/Registered/ArticleDocuments/Aberdeen_L
eanSC_MB_3450.pdf
Akao, Yoji (Eds.). (1990). Quality Function Deployment.
Integrating Customer Requirements into Product Design.
(Mazur, Glenn H., Trans.).
New York: Productivity Press (Original work published 1988).
Bell, Steve (2006). Lean Enterprise Systems
Using IT for Continuous Improvement
Hoboken, NJ: John Wiley & Sons.
CBC. News (2008, January 23). No. 1 automaker? Too close to call
Retrieved January 23 from
http://www.cbc.ca/money/story/2008/01/23/gm-toyota.html
Clark, Mike (2004). Pragmatic Project Automation
How to Build, Deploy, and Monitor Java Applications
81
Raleigh, North Carolina: The Pragmatic Programmers, LLC.
Cunningham, Jean E., Fiume, Orest J (2003). Real Numbers
Management Account in a Lean Organization.
Durham, NC: Managing Times Press.
Furugaki, Koichi., Takagi, Tooru., Sakata, Akinori., & Okayama, Daisuke (2006).
Innovation in Software Development Process
by Introducing Toyota Production System.
FUJITSU Sci. Tech J. January 2007, 139-150.
Retrieved January 8, 2008 from
http://www.fujitsu.com/downloads/MAG/vol43-1/paper16.pdf
Hino, Satoshi (2006). Inside the Mind of Toyota
Management Principles for Enduring Growth (Dillon, Andrew P. Trans.).
New York: Productivity Press (Original work published 2002).
Imai, Masaaki (1986). KAIZEN The Key to Japan’s Competitive Success.
New York: McGraw-Hill.
Ivezic, Nenad., Potok, Thomas E., & Pouchard, Line (1999).
Multiagent Framework for Lean Manufacturing
IEEE Internet Computing, September October 1999, 58-59
Retrieve January 17, 2008 from
http://0-
ieeexplore.ieee.org.aupac.lib.athabascau.ca/iel5/4236/17230/00793459.p
df?tp=&arnumber=793459&isnumber=17230
Jones, Dan., & Womack, Jim (2003). Seeing the Whole
82
mapping the extended value stream.
Cambridge MA: Lean Enterprise Institute.
Kennedy, Michael N (2003). Product Development for the Lean Enterprise.
Richmond, Virginia: The Oaklea Press.
Leach, Lawrence P (2005). Lean Project Management:
Eight Principles for Success.
Boise, Idaho: Advanced Projects Inc.
Liker, Jeffrey K (2004). The Toyota Way.
New York: McGraw-Hill.
Liker, Jeffrey K., & Meier, David P (2007). The Toyota Talent
Developing Your People The Toyota Way.
New York: McGraw-Hill.
Liker, Jeffrey K., & Meier, David P (2004). The Toyota Way Fieldbook
A Practical Guide For Implementing Toyota’s 4Ps.
New York: McGraw-Hill.
Marchwinski, Chet., Shook, John (Eds.). (2006). Lean Lexicon
A graphical glossary for Lean Thinkers (3rd ed).
Cambridge, MA: Lean Enterprise Institute.
Middleton, Peter. & Sutton, James (2005). Lean Software Strategies
– Proven Techniques for Managers and Developers
New York: Productivity Press
Morgan, James M., & Liker, Jeffrey K (2006).
The Toyota Product Development System
83
Integrating People, Process, and Technology.
New York: Productivity Press.
Ncube, Lisa B (2007). Exploring the application of experiential learning in
developing technology and engineering concepts:
The Lean Lemonade Tycoon
37th ASEE/IEEE Frontiers in Education Conference.
2007 IEEE, F1J-5 – F1J-10.
Retrieved January 17, 2008 from
http://0-
ieeexplore.ieee.org.aupac.lib.athabascau.ca/iel5/4417794/4417795/04418
021.pdf?tp=&arnumber=4418021&isnumber=4417795
Ohno, Taiichi (1988). Toyota Production System (Dillon, Andrew P. Trans.).
New York: Productivity Press (Original work published 1978).
Overby, Stephanie (2007). Learning to Love Lean IT.
Retrieved January 8, 2008 from
http://www.cio.com/article/106900/Learning_to_Love_Lean_IT
Parnell-Klabo, Emmal (2006). Introducing Lean Principles with Agile Practices at
a Fortune 500 Company.
Proceedings of AGILE 2006 Conference (AGILE’06).
IEEE COMPUTER SOCIETY
Retrieved January 17, 2008 from
84
http://0-
ieeexplore.ieee.org.aupac.lib.athabascau.ca/iel5/11054/34909/01667584.
pdf?tp=&arnumber=1667584&isnumber=34909
Piszczalski, Martin (n.d.). Lean vs. Information Systems.
Sextant Research
Retrieved January 8, 2008 from
http://www.autofieldguide.com/columns/0800it.html
Poppendieck, Mary., & Poppendieck, Tom (2007).
Implementing Lean Software Development From Concept to Cash.
Upper Saddle River, NJ: Addison Wesley.
Poppendieck, Mary., & Poppendieck, Tom (2003).
Lean Software Development An Agile Toolkit.
Upper Saddle River NJ: Addison Wesley.
Rother, Mike., & Shook, John (2003). Learning to See
Value-Stream Mapping to Create Value and Eliminate Muda.
Cambridge MA: Lean Enterprise Institute.
Rother, Mike., & Harris, Rick (2001). Creating Continuous Flow
an action guide for manager, engineers & production associates.
Cambridge MA: Lean Enterprise Institute.
Schach, Stephen R., (2005). Object-Oriented & Classical Software Engineering
(6th ed).
New York: McGraw-Hill
Schwaber, Ken., & Beedle, Mike (2002).
85
Agile Software Development with Scrum.
Upper Saddle River NJ: Prentice Hall.
Shingo, Shigeo (1989). A Study of the Toyota Production System.
(Dillion, Andrew P. Trans.). New York: Productivity Press.
(Original work published 1981).
Stephens, Matt., & Rosenberg, Doug (2003). Extreme Programming Refactored:
The Case Against XP.
New York: Apress.
Sutherland, Jeff., Jakobsen, Carsten Ruseng., & Johnson, Kent (2007).
Scrum and CMMI Level 5: The Magic Potion for Code Warriors
Agile 2007.
IEEE COMPUTER SOCIETY
Retrieved January 17, 2008 from
http://0-
ieeexplore.ieee.org.aupac.lib.athabascau.ca/iel5/4293562/4293563/04293
608.pdf?tp=&arnumber=4293608&isnumber=4293563
Sutton, James M. Sutton (1996).
Lean Software Development For The Lean Aircraft
IEEE 1996, 49-54.
Retrieved January 17, 2008 from
http://0-
ieeexplore.ieee.org.aupac.lib.athabascau.ca/iel3/4139/12182/00559134.p
df?tp=&arnumber=559134&isnumber=12182
86
Takeuchi, Hirotaka., & Nonaka, Ikujiro (1986).
The New Product Development Game
Harvard Business Review, January – February 1986, 1-12.
Retrieved November 18, 2007 from
http://apln-richmond.pbwiki.com/f/New+New+Prod+Devel+Game.pdf
The Standish Group (1995). The Standish Group Report Chaos
Chaos Report, 1-8.
Retrieved November 2, 2007 from
http://www.projectsmart.co.uk/docs/chaos-report.pdf
Toyota Motor Manufacturing Kentucky, Inc (2004).
New Facility Efficiently Trains Experts to Support Toyota’s Expanding
Scale of Global Manufacturing
Retrieved January 6, 2008 from
http://www.toyotageorgetown.com/gpc.asp
Toyota Production System (n.d.). Toyota Production System
Retrieved December 8, 2007 from
http://www.toyota.co.jp/en/vision/production_system/index.html
Ward, Allen C (2007). Lean Product and Process Development.
Cambridge MA: Lean Enterprise Institute.
Ward, Peter., Honggeng, Zhou (2006). Impact of Information Technology
Integration and Lean/Just-In-Time Practices on Lead-Time Performances
Decision Sciences 37(2)., 177-203.
Retrieved December 8, 2007 from
87
http://www.google.com/search?as_q=Impact+of+Information+Technology
+Integration+and+Lean%2FJust-In-Time+Practices+on+Lead-
Time+Performances&hl=en&num=100&btnG=Google+Search&as_epq=&
as_oq=&as_eq=&lr=&cr=&as_ft=i&as_filetype=&as_qdr=all&as_nlo=&as_
nhi=&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images
Womak, James P., & Jones, Daniel T., Roos, Daniel (2003). Lean Thinking.
New York: Free Press.
Womak, James P., & Jones, Daniel T., Roos, Daniel (1990).
The Machine That Changed the World.
New York: Free Press.
88
APPENDIX A ~ GLOSSARY
andon – A Japanese term for lamp. It is a visual management tool for highlighting
the status of operations in an area in a single glance. It signals red whenever an
abnormality occurs, but can also indicate production status in terms of units
planned versus actual units processed. Problems can be tripped by an
automated error detection device or a worker pulling a cord or pushes a button,
signaling a quick response is required by the team leader (Marchwinski & Shook,
2006).
autonomation - Automation with a human touch, not to be confused with
automation. It means an automated machine can shut itself off autonomously
when it detects an error (Ohno, 1988).
Genchi Genbutsu – A Japanese term for go and see, but translated as actual
place and actual thing. It is the Toyota practice of personal observation at the
source of the condition to confirm information or data. For example, a decision
maker including executives, and managers, will go to the shop floor personally to
investigate a problem instead of relying solely on information from others or
computer data (Marchwinski & Shook, 2006).
hansei – A Japanese term for reflection. It is the practice of looking back at
oneself to determine shortcomings which can be improved, and the same applies
for processes. Hansei meetings is typically conducted at Toyota during
89
milestones and end of project to identify problems along with countermeasures to
the problems, and these are communicated to the rest of the organization as
improvements so the same mistakes are not made over and over again. It is also
the check, of the Plan, Do, Check, and Action cycle (Marchwinski & Shook,
2006).
heijunka – A Japanese term for leveling. Over a fixed period of time, it is
important to level the type, and quantity of production. It is important to efficiently
meet customer demands while at the same time avoid batching to minimize
inventories, costs, manpower, and lead time through the whole value stream.
One way of doing this is to level the production (Marchwinski & Shook, 2006).
hetakuso-sekke – A small book used at Toyota containing failures in the pass as
a reminder of what to avoid (Morgan & Liker, 2006).
hoshin kanri – A Japanese term for shining metal, pointing directions, policy
deployment, and policy planning (Middleton & Sutton, 2005). A management
process to align both vertical and horizontal functions and activities with strategic
objectives. It is a specific plan to develop measures, responsibilities, timelines,
actions and goals (Marchwinski & Shook, 2006).
ijiwaru – Testing to the point of failure (Morgan & Liker, 2006).
90
jidoka - Provide operators and machines the ability to stop work immediately
when an abnormal condition has occurred to allow for fixing the problem, and
thus build in quality. It is one of the two pillars of the Toyota Production System
along with just-in-time (Marchwinski & Shook, 2006).
kaizen – Continuous improvement (Marchwinski & Shook, 2006).
kanban – A Japanese term for sign or signboard. It is a signaling device which
gives instruction and authorization for the withdrawal or production of items in a
pull system (Marchwinski & Shook, 2006).
kentou - The idea proposal stage of a designing a new vehicle at Toyota (Morgan
& Liker, 2006).
kozokeikaku – Phase of designing a new vehicle at Toyota where all the pieces
are pulled together which is basically the requirement of the vehicle, and the
body execution plan (Morgan & Liker, 2006).
muda – An activity which does not create value to the customer, but consumers
resources. There are two kinds of muda. Type one muda are non-value activities
which cannot be removed immediately, and type two muda which can be easily
be removed through kaizen (Marchwinski & Shook, 2006).
91
mura– Unevenness, an operation which is uneven. It can be eliminated by having
a level schedule, and a good paste of work (Marchwinski & Shook, 2006).
muri - Overburdening of operators and equipment, running them harder or higher
pace with more force and effort for a longer time than what workforce
management will allow or what the equipment is designed for (Marchwinski &
Shook, 2006).
nemawashi – A Japanese term for preparing the ground for planting. It is the
process of gaining pre-approval, acceptance, and consensus on a proposal. This
is done by first evaluating the idea, and secondly by planning with stakeholders
and management getting their input, anticipating resistance, and aligning
proposal with the organization’s perspective and priorities. The formal approval
comes in a formal meeting, but by that time, it is a mere formality (Marchwinski &
Shook, 2006).
ninjutsu - the art of invisibility (Ohno, 1988).
obeya – A Japanese term for big room. It is a major project management tool at
Toyota to coordinate effective timely communication used especially in product
development to ensure product success. The room contains highly visual graphs
and charts indicating the progress to date, timing, and milestones, with
92
countermeasures for technical problems and timing. It is a shorten version of the
Plan, Do, Check, Act Cycle (Marchwinski & Shook, 2006).
Ohno, Taiichi – Toyota executive widely credited for the Toyota Production
System (Marchwinski & Shook, 2006).
poka-yoke – error proofing, mistake proofing and baka-yoke for fool proofing. It is
a way to avoid mistakes in a process. For example, in a production line, parts
may have a certain shape to prevent installing parts with the wrong orientation,
photo cells above parts container preventing the movement to next stage if
operator’s hand did not break the light in obtaining the necessary parts
(Marchwinski & Shook, 2006).
seiketsu – standardization; standardize the maintaining of cleanliness
(Marchwinski & Shook, 2006).
seiso – cleanliness; wash and clean, everyone must clean the workplace
(Marchwinski & Shook, 2006).
seiton orderliness; after seiri, properly place everything in its proper order for
quick retrieval and storage. There is a place for everything, and everything has
its place (Marchwinski & Shook, 2006).
93
sensei – Japanese term for teacher. In Lean thinking, it is someone who has a
master level of Lean knowledge with many years of experience in Lean and
knows how to transform the work place to Lean. The role is very similar to the
sensei in martial arts such as in karate (Marchwinski & Shook, 2006).
senzu – Stamping of engineering drawings where each stamped component
have a three view drawing with all special information placed in the relevant
places (Liker, 2004).
seiri – tidiness; separate needed items from unneeded, and discard the
unneeded (Marchwinski & Shook, 2006).
Shingo, Shigeo – Consultant to Toyota who made key contributions to the Toyota
Production System such as the Single Minute Exchange of Die (SMED) for quick
change over of manufacturing different products on a production line
(Marchwinski & Shook, 2006).
shitsuke – commitment; discipline to practice the Five S’s daily as a way of life
(Marchwinski & Shook, 2006).
shusha – chief engineer (Liker, 2004).
94
takt – German word for a precise interval of time such as a musical meter on a
metronome. It is the rate of customer demand, the rate at which customers are
buying products. It is the interval to move a product ahead to the next production
station (Liker, 2004) (Marchwinski & Shook, 2006).
technik – German for superior technology as a means for market success
(Middleton & Sutton, 2005).