Conference PaperPDF Available

Applying Lean to Improve Quality in Software Development Projects



As the role of IT shifts from being a cost center to building the core value proposition, it becomes crucial to ensure the quality of the delivered software solutions. While lean has become a standard approach in manufacturing, supply chain management and other domains, software development has been dominated by Agile. Delivering fast has been a central focus of IT industry and much too often the software quality has been compromised in favor of speed. There has been an assumption that it is possible either to deliver the product fast or in a good quality, which is challenged in this paper. This action research examines the impact of applying lean methods to software development project; study has been done by comparing two projects where lean implementation has been triggered in one of the project teams. The result shows that despite the common belief of productivity shrinking with increasing quality, it is possible to deliver high quality products without compromising the delivery speed.
Applying Lean to Improve Quality in Software
Development Projects
Gaitis Kasims
Turiba University
Department of Business Administration
Riga, Latvia
As the role of IT shifts from being a cost center to building the
core value proposition, it becomes crucial to ensure the quality of
the delivered software solutions. While lean has become a
standard approach in manufacturing, supply chain management
and other domains, software development has been dominated by
Agile. Delivering fast has been a central focus of IT industry and
much too often the software quality has been compromised in
favor of speed. There has been an assumption that it is possible
either to deliver the product fast or in a good quality, which is
challenged in this paper. This action research examines the impact
of applying lean methods to software development project; study
has been done by comparing two projects where lean
implementation has been triggered in one of the project teams.
The result shows that despite the common belief of productivity
shrinking with increasing quality, it is possible to deliver high
quality products without compromising the delivery speed.
CCS Concepts
Software and its engineering Software creation and
management Software development process management
Software and its engineering Agile software development
Lean; quality; defect density; lead time; software development;
agile; leagile; experience report.
Modern economy can be characterized by speed, dynamics and
the permanent process of change. Companies that are faster to
adapt to new consumer behavior are growing, while companies
reluctant to the changes are getting out of market, as stated by
former CEO of General Electric’s Jack Welsh, “We’ve long
believed that when the rate of change inside an institution
becomes slower than the rate of change outside, the end is in
sight.”[3] This statement summarizes very well what is happening
in the economy currently.
Companies like Kodak, Polaroid, Blockbuster, Pan Am and many
more failed to respond to the fast changing technology and
consumer behavior and went out of business. Whole new
economy sectors are emerging and disrupting the previous
business models, be it a retail sales, insurance, banking or
medicine. Looking forward at the factors, which will drive future
economy and differentiate losing companies from thriving
companies, it is clear that technology and especially IT will be
one of the major factors. D. Newman (2016) in his article in
Forbes states: “Changing the old model of IT as a separate entity
into a breathing part of the business will mean a thriving
enterprise—and one that runs smoothly.” [12] As the IT becomes
more and more crucial part of the companies, there is an
overwhelming number of new IT projects starting each year with
a lot of hope attached to them, however all too often they end with
disastrous outcome, being delivered over budget, in bad quality
[17] not meeting the deadlines or getting cancelled altogether for
not achieving milestones and losing relevance [1].
Since 1970s software development was dominated by the
Waterfall approach [13], it being a intuitively understandable and
simplistic approach to managing the software development
projects. This method evolved in a similar way as the Fords
manufacturing approach, becoming highly formalized, consisting
of sequential stages and therefore not able to control uncertainty
and changes. [6]
As computer capabilities evolved, more and more complicated
problems were getting targeted by the computer systems, which
exponentially increased the complexity of software systems [7].
Not only had the complexity increased but also the requirements
started changing more rapidly as businesses were trying to
respond to the ever changing environment and customer demands.
In response to this situation, the agile methods evolved in early
2000s [2]. The adoption of agile methods has been successful in
addressing the changing requirements and getting systems
developed faster. However, companies applying and adapting
agile methods did not end up with a better quality, only with
larger functionality. While looking at improving the quality, it has
been a common fear that increase in quality will immediately
result in slowing down the speed of delivery by increasing the
cycle times. [5]
Quality issues and costs in software industry have been similar to
the same problems faced by mass production at automotive
companies. Alternative approach in manufacturing arose in Japan
at the Toyota Production System, where the lean approach of
reducing batch sizes, eliminating waste and concentrating on the
flow has shown itself as the more successful approach and
allowed Toyota to quickly become one of the leading automotive
companies. One of the biggest wastes is the rework caused by
quality issues [4], which was addressed at Toyota by building the
quality in.
The application of lean methods in IT, especially its quality
aspects, are not as well researched and analyzed as agile methods.
This paper will contribute to a better understanding of the lean
role in IT by focusing on analysis of the quality implications
while applying the lean methods to the software development
The roots of lean go back to Toyota Production System or TPS,
and the term lean was first defined later in 1988. and 1990.
Krafcik was first to introduce the term lean in his article Triumph
of the Lean Production System. Talking about TPS, he used a lean
production system as the opposite to buffered production system.
The term Lean Production became known worldwide thanks to
Womack, Jones and Roos who wrote the book The Machine That
Changed the World, published in 1990, where they published the
results of a five-year study on the future of automobile industry,
analyzing its move from mass production to lean production. [20]
This book allowed for introduction of lean into IT as well, through
analysis of lean product development which has a lot of
similarities with the software development.
Abstraction of lean from Toyota Production System (TPS) and
moving into lean thinking made further implementations in
different domains easier. This has been analyzed in two works
Taiichi Ohno’s (1988) Toyota Production System: Beyond Large-
Scale Production, and Womack & Jones (1996) Lean Thinking.
Taiichi Ohno focuses on underlying philosophy of TPS in his
book and tries to address misunderstandings and misconceptions
about the system as well as its methods. Womack and Jones
extended lean thinking, showing that it allows companies to
specify value, line up value creating actions in the best sequence,
conduct these activities without interruption whenever someone
requests them, and perform them more and more effectively
which leads to the five principles of lean Value, Value Stream,
Flow, Pull and Perfection. [21]
After the lean approach showed its applicability and success in
automotive production, the first research into applying lean in
software development was done. Initial approach on how to
implement lean in software were explored by Poppendieck in
2003 [14] and Sutton in 2005 [11]. Software development projects
in processes are similar to the inventory in a manufacturing plant
and the steps in the waterfall process, except analysis and coding
is seen as a waste. [11] Poppendieck suggests the mapping
between the different types of waste in production and in software
development. Defects are one type of waste the amount of waste
caused by a defect is the product of the defective impact and the
time it goes undetected. The way to reduce the impact of defects
is to find them as soon as they occur. Thus, the way to reduce the
waste caused by defects is to test immediately, integrate often, and
release to production as soon as possible. [14]
In his book Lean Software Strategies: Proven Techniques for
Managers and Developers, Sutton explores how to apply the lean
principles from manufacturing to software development projects.
Sutton also points out that CMM implementation is similar to
mass production, by disintegrating the parts of process and trying
to optimize each of them, whereas the focus should be on
optimizing the process as a whole. Sutton looks at the different
aspects of CMM and suggests how lean would handle the same
process. [11]
It’s interesting that Womack et al already suggested that quality
costs less [8] or even comes free [20], which still remains a
central discussion point about applying lean in IT. At same time,
the cost of low quality can be immense as it increases the overall
cost in several ways, first of all the with the time spent to produce
a product of insufficient quality, time spent on identifying and
fixing the defects and, moreover, with the customers lost or not
acquired due to the insufficient quality. [19]
As the lean methodology has brought immense quality advantages
in the manufacturing it is expected to bring same advantages in
software development projects as well. Improving the process
quality has been seen as the single most important goal for
adopting lean in companies with 73% of companies saying so,
compared to 39% importance while adapting agile. [15] Even if
the result was based only on 11 lean adoption, compared to 137
agile adoptions, it shows the expectation differences, as agile is
primarily adopted to reduce time to market, but lean to improve
quality. This is confirmed by the observation that companies
adapting both agile and lean have set as evenly important
priorities the reduction of time to market and the improvement of
the process quality. [15]
There have been several pieces of evidence from different case
studies showing that lean method application significantly
improves the quality. One of its first implementations was at the
Timberline Software in Oregon in 2002 with 450 staff. They
reported considerable improvement in quality, but their focus on
setting a common tempo or ‘‘Takt" time for software development
based on creating similar-sized work units was not easy to
implement. [9]
Lean implementation at BBC Worldwide also has shown several
improvements software is being delivered with 47% less
variance and 37% quicker on average. Not only software was
getting delivered quicker but quality was not sacrificed either.
Problems were being fixed more quickly. The mean numbers of
bugs open each week slightly declined as well, while the amount
of defects that were still open and reported each week fell by
24%. The necessity of allowing software developers time to
improve the quality of their code was mentioned by the team as a
factor in the improved bug rates. [10]
Staats and Upton analyzed implementation of lean in a software
outsourcing company Wipro. A rapid prototyping approach was
chosen there with short iterations to deliver early prototypes to
customer. The prototypes helped the team find bugs sooner, fix
them quicker, and avoid repeating the same mistakes. The PM
estimated that 25% of the savings came from this last point.
Overall implementing lean allowed reduction of average number
of defects per thousand lines of code from 0.37 to 0.13. [18]
The aim of this paper is to analyze the quality improvement using
the lean methods. This is achieved by analyzing the currently
available literature as well as doing an action research at Eurofins
Genomics company and comparing the software quality before
and after applying the lean methods.
To analyze the quality implications, defect density is being used
as primary indicator. It is a widely adopted indicator, which
measures the number of defects per number of story points
delivered. It allows the comparison of the evolvement of quality
over the time, showing relative quality of the work. Another
indicator to look for is the delivery speed, or the number of story
points per sprint being used. This can also be used to compare the
evolvement of delivery speed over time. The project data has been
collected between March 2017 and March 2018. For Ecom team,
the data is available until January 2018, as the project was closed
after that. The lean implementation in Golims team started in
October 2017.
The study is using the action research methodology, which is
similar to the case study method. However, case studies are purely
observational while action research is focused on and involved in
the change process. [16]
The purpose of this study is to analyze the effect of lean methods
on the quality of the process by comparing the two teams, one
using the traditional agile methods and the second team applying
the lean methods. The effect is being analyzed not only with the
comparison of the teams, but also with the comparison of the
performance of second team before and after the application of
lean methods.
This study is conducted at Eurofins Genomics, which is a leading
genomics company in the areas of Sanger and NGS sequencing as
well as oligonucleotide and gene synthesis. Software development
in Eurofins Genomics is provided by an internal IT department
and is distributed over several geographic locations with the
development team members based in US, Japan, Denmark
Germany as well as in offshore development center in India. Most
of the development is being done in India, except local integration
work done on site; projects are mainly supervised from Germany
headquarters. Offshore development team in India is following the
Capability Maturity Model Integrated (CMMI) standard and has
been certified for CMMI level 3 compliance. In addition, the
software needs to comply with regulatory requirements, such as
For this study, two project teams have been chosen with a similar
maturity, experience level and team size. Ecom team is working
on extending and maintaining the ecommerce platform while
Golims team is responsible for the Oligonucleotide Lims system.
Both teams have started development in 2012 and are supporting
systems which are already in productive use, but still being
enhanced. The Golims team was chosen for lean implementation,
which was based on two main considerations Ecom project had
been scheduled to be closed in January 2018 whereas the Golims
project team was supposed to continue work until end of 2019,
also the Golims team was having more quality issues with higher
impact then Ecom team.
Lean implementation was kicked off in October 2017 with a series
of team discussions focused on the current problems in the
projects and the lean methodology. Furthermore, the
implementation was delegated to the team itself, with a regular
review done by the management. Several changes were made
during the development process to better align with the lean
values and implement specific methods. First important change
was to reduce the release cycle from 3 sprints to having a release
at each sprint. This allowed the team to receive feedback faster
and reduced the number of work items waiting for deployment,
thus reducing the lead time. To achieve this, the team had to
identify tools for improving and automating deployment process
and to avoid downtimes in production, which was a major limiting
factor for having more often releases. One of the biggest and most
difficult changes for the development team was the shift in
responsibilities. It was achieved by delegating the responsibility
for the final quality back to the development. The role of quality
assurance team was redefined from writing the test automation
and inspecting the quality of implemented functionality to a
responsibility for automation of regression testing, maintaining
test suite quality, doing hardening testing along with performance,
load and security testing as well as ensuring compliance with
GAMP5 requirements. The responsibility for automating the tests
of all the new functionality was transferred to the development
team to ensure the functionality fulfills the minimum quality
criteria before being submitted to the central code repository.
Based on the initiative from the team, peer code testing and
functional review was also introduced, in which a peer developer
did the functional testing and code review of the newly submitted
functionality along with the code review.
The most controversial change at the beginning was Stop the line
or the Andon cord. Due to its counter-intuitive nature, it was
feared to completely slow down the development without any
advantage as “defects are addressed on priority anyway”. To
implement Andon cord, the development team built a simple
device with the light and sound signal being triggered by the push
of a physical button. Any time when either QA or developer
pushed the button, the team gathered and looked together at the
discovered defect to understand the reason why it had escaped and
to decide how to improve the work in future. These changes had
been implemented over the course of first two months of lean
implementation. The results of these initiatives became quickly
visible as the number of defects started reducing rapidly (see
Figure 1).
0,28 0,33
0,15 0,11
0,05 0,03 0,07 0,09 0,07
0,48 0,55
6.3.1 6.3.2 6.3.3 6.3.4 6.4.1 6.4.2 6.4.3 6.4.4 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 7.6.1 7.6.2 7.6.3
Golims Ecom
Figure 1. The defect density for Golims and Ecom teams per sprint
Figure 1 shows the comparison between defect density of Ecom
and Golims teams, as well as the effect of applying the described
lean methods on the defect density. Sprint 6.3.1 started
10.04.2017, sprint 7.6.3 ends 16.03.2018, each sprint lasting for 3
weeks. The lean initiative was introduced during sprint 6.5.1 and
even if results were first expected only in 2018. the figure 1 shows
that the defect density dropped immediately in the next sprint,
becoming 3 times lower than before. As more changes were done
in the sprints 6.5.2 and 6.5.3, additional reduction was observed.
However, the trend further shows that the defect density is
fluctuating around 0.07. The obtained results need to be treated
with caution as there is an effect from legacy code being deployed
in the production. Due to the large portion of code being written
since 2012, there are still defects being found in production not
directly linked to the new development being done. This might be
another reason for the defect density fluctuation. To better
understand this effect, further analysis would be required,
categorizing the defects between legacy and new code.
When compared to Golims implementation, it can be seen that the
Ecom team defect density was showing the upwards trend. Data
for Ecom have been partially disrupted by the burst in defect rate
during sprint 6.4.3, which was caused by the implementation of a
test automation suite revealing a lot of older defects. The results
of Ecom team however can be also affected by the fact that the
team was aware about the project being closed, and even if there
were no layoffs planned, the team was unsure about the future and
the way new projects would be run, which might have had its
effect on team performance.
Before and after the lean implementation individual discussions
were also done with each team member to identify their
motivation level as well as major concerns. Results of discussions
showed that before the implementation of lean methods the
Golims team was feeling frustrated by the number of incidents
reaching from production and was feeling not valued by the
management and the internal customers, but during the follow up
discussions in sprint 7.6.2, the team members were highly
motivated, speaking about their pride of working for the Golims
team and being happy to deliver high quality functionality.
Not only did the team motivation increase, but also the internal
customers from oligonucleotide production were happy with
result and felt that “there is no real need to test the software as it
works anyway”, which was the major shift in perception. The
effect of increasing team motivation, however, is not consistent.
While motivation did increase in the development team, surveys
showed that the motivation and satisfaction of quality assurance
members were much lower. Team motivation needs to be
observed over longer period of time to see if the positive lean
effects on motivation are sustainable.
The increasing quality of software, despite the initial concerns,
did not result in the productivity drawbacks. Even if after the
initial lean implementation during the sprint 6.5.1 there has been a
drop in productivity, already in the sprint 6.5.3 productivity turned
back to previous levels, as shown in Figure 2. As it has been
already suggested by Womack, the quality comes for free [20],
which was also observed while applying lean methods to the
Golims team.
Figure 2. Story points delivered by Golims team per sprint
Figure 2 confirms that after introducing the lean methods, there
has been no major negative impact on the number of story points
delivered. On contrary, it shows an increase in the team
productivity from sprint 7.6.3 onwards. This spike in productivity
needs to be observed over longer period of time, however, to see
if the trend sustains.
The positive results of applying the lean methods on software
development projects have to be further studied during a longer
time period, while applying also the methods to other project
[1] Boehm B.W.,2017,Software Cost Estimation Meets Software
Diversity, IEEE/ACM 39th International Conference on
Software Engineering Companion(Buenos Aires, Argentina,
[2] Fowler, M., and J. Highsmith.The Agile Manifesto.
SoftwareDevelopment, Vol. 9, No. 8 (August2001), 28-32.
[3] General Electric Co., 2001. 2000 Annual Report, retrieved
April 27, 2018 from General Electric:
[4] Hafer, M. Applying lean to new product development.
Manufacturing Engineering, 147, 85-91.
[5] Harter E.D. & Krishnan, S. M. & Slaughter A. S. Effects of
Process Maturity on Quality, Cycle Time, and Effort in
Software Product Development. Management Science. 46
(April 2000). 451-466. Doi=
[6] Huub J.M. Ruël, Tanya Bondarouk, and Stefan Smink. 2010.
The Waterfall Approach and Requirement Uncertainty: An
In-Depth Case Study of an Enterprise Systems
Implementation at a Major Airline Company. Int. J. Inf.
Technol. Proj. Manag. 1, 2 (April 2010), 43-60. DOI=
[7] Jolly, S., System of Systems in Space Exploration: Is
Software Broken? in Ask Magazine, 34 (Spring 2009), 22 -25
[8] Krafcik, J. F., 1988: Triumph of the Lean Production System,
Sloan Management Review, 30 (1), 41-52.
[9] Middleton P., Flaxel A. & Cookson A., Lean Software
Management Case study: Timberline Inc.. Lecture Notes in
Computer Science, 3556, DOI=
[10] Middleton P., Joyce D., Lean Software Management: BBC
Worldwide Case Study. Engineering Management, IEEE
Transactions on. 59. 20 - 32. DOI=
[11] Middleton P., Sutton J., 2005. Lean Software Strategies.
Productivity Press, New York.
[12] Newman D., 2016. The Changing Role Of IT In The Future
Of Business. Retrieved April 14 2018, from
[13] Ofume J. W., 2010, Agile Methodology and UCD: The Right
Approach to Building Usable Software in: Agile 2008
conference (Toronto, Canada, 2008) IEEE, 204-208, DOI=
[14] Poppendieck M. & Poppendieck T., 2003. Lean Software
Development: An Agile Toolkit., Addison-Wesley, Boston,
[15] Rodríguez P., Markkula J., Oivo M., Garbajosa J. Analyzing
the Drivers of the Combination of Lean and Agile in
Software Development Companies. in Product-Focused
Software Process Improvement. PROFES 2012. Lecture
Notes in Computer Science, vol 7343. (Madrid, Spain, 2012)
Springer, 145-159., DOI=
[16] Runeson, P. & Höst, M. Guidelines for conducting and
reporting case study research in software engineering.
Empirical Software Engineering, 14, 131-164. DOI=
[17] Shahzad B., Awan K. M., Lali. M.I., Aslam W., 2017
Identification of Patterns in Failure of Software Projects.
Journal of Information Science and Engineering. 33, 1465-
1479, DOI=
[18] Staats B. R., Upton D.M., 2009. Lean Principles, Learning,
and Software Production: Evidence from Indian Software
Services, Harvard Business School, Boston
[19] Töpfer A.,2013. Six Sigma: Konzeption und Erfolgsbeispiele
für praktizierte Null-Fehler-Qualität, Springer, Berlin
[20] Womack, James P.; Daniel T. Jones; Daniel Roos, 1990. The
Machine That Changed the World, Free Press, New York
[21] Womack, James, P.; Jones,, Daniel, T., 1996. Lean Thinking:
Banish Waste and Create Wealth in Your Corporation, Free
Press, New York
... Kasims [16] Applying Lean to Improve Quality in Software Development Projects 0 ...
Full-text available
This research aims to contribute to the development of knowledge in project management, by searching for management approaches that can be useful in construction projects. A bibliometric approach based on quantitative analysis methods was applied to investigate the synergy between Traditional, Agile, and Lean management approaches. This study also evaluates the status of the three different approaches using a visualization analysis of journal articles. The bibliometric study was developed with a portfolio of 200 papers around "synergy between Traditional, Agile and Lean approaches" collected at the Web of Science database, covering the evolution of this topic over the last ten years (from 2011 to 2020). The retrieved records were analyzed in terms of year of publication, country, subject, and keywords. The analysis of the original articles revealed that the total number of publications has continuously increased over the last few years. The country producing more papers on this theme was the United States followed by England and Germany. Few studies in the literature have discussed this theme in the construction industry, which means that the concept of combining Traditional, Agile, and Lean approaches is a new concept in construction projects.
We propo se an applied Bayesian learning approach for continuous planning and evolution of information system projects and portfolios. Unlike traditional project management approaches for information system, the proposed approach considers the cumulative effect of all past experiences to achieve continuous performance and reliability prediction. The results of quantitative comparisons with other common estimation approaches, such as non-learning point estimates and traditional Bayesian approach, using real case data indicate that the proposed approach can generate a more realistic metric to continuously plan and measure the performance of evolving LeAgile projects or portfolios. This study can support decision makers, engineering teams, and management by supplying a practical and scalable project performance prediction tool for continuous planning and system evolution.
Full-text available
Software development is not an easy job to manage, in result, many projects end in failure. It has been acknowledged that despite of all mitigation techniques, the successful completion rate of the software till 2016, by the Standish group reports remains 30-40%. With an increase in the scope and investment of the software projects, this failure rate is quite high. In outsourced projects the failure rate is even more significant. The aim of this research is to explore the fundamental reasons of software failure in outsourced and in-house software projects. We have found new patterns to identify the causes of failure in software projects. To address our research questions, systematically we identified different articles from the literature that provide the evidences for causes of failure in software. We have identified thirty-seven different risks of inhouse and thirty-nine risks of outsourced software projects.
Full-text available
The Waterfall approach has been the dominant approach for enterprise systems (ES) implementation since the 1970s. It offers ES project managers a simple, step-by-step way to make ES projects manageable and minimize drawbacks. The main criticism of this approach centres on its inflexibility regarding requirement uncertainty. In this article, the authors challenge this criticism. By means of an in-depth case study of a Waterfall approach-based ES implementation project within the maintenance department of one of the world’s biggest airline companies, this article will illustrate how it deals with requirements uncertainty and required flexibility in practice.
Conference Paper
Full-text available
Agile software development has been widely accepted by the software industry as a means for improving flexibility and innovation capabilities. More recently, lean thinking has emerged as a new paradigm to make software development more efficient. In practice, quite often lean is seen as an evolution of agile when agile is not considered to be enough. However, how they can relate to each other is not clearly understood. This paper presents the results of a survey study conducted among 408 software practitioners of 200 software intensive companies in Finland, which is one of the early adopters of lean for software development. The results highlight the interest of software professionals in adopting a combination of agile and lean paradigms, to achieve both flexibility and economical efficiency. Unlike manufacturing, the transformation is being actually conducted as a single trip where the borders between agile and lean are not clearly defined.
Six Sigma ist konsequentes Projektmanagement für Null-Fehler-Qualität durch Analysieren von Qualitätsproblemen und deren nachhaltige Beseitigung auf der Basis mathematisch-statistischer Methoden und unter Einsatz gängiger fortschrittlicher Qualitätsmanagement-Tools. Die Durchschlagkraft erhält Six Sigma dadurch, dass es neben nachhaltigen Kostensenkungen immer auch auf eine Steigerung des Kundennutzens sowie auf eine Verbesserung der Unternehmensergebnisse ausgerichtet ist. Ausgangspunkt von Six Sigma Projekten sind jeweils Prozesse, die mithilfe eines stringenten Vorgehensmodells analysiert und verbessert werden. Im Ergebnis soll auf diese Weise praktizierte Null-Fehler-Qualität in allen Wertschöpfungsbereichen erreicht werden. Dieses Buch liefert die theoretischen Grundlagen und zeigt die erfolgreiche Anwendung von Six Sigma. Autoren aus renommierten Unternehmen informieren über wichtige Anforderungen und Trainingskonzepte bei der Einführung und berichten in zahlreichen Fallbeispielen über die praktische Umsetzung des Konzepts unter Berücksichtigung der Unternehmensgröße, der Branche oder der nationalen Kultur. Die Anwendung von Six Sigma in vor- und nachgelagerten Wertschöpfunsprozessen von Industrieunternehmen wird ebenfalls behandelt wie der Einsatz in Service und Dienstleistung. Die zahlreichen Fallstudien kommen u.a. von General Electric, Ford, Norgren, Motorola, Siemens und Bank of America. In der Neuauflage wird zusätzlich gezielt auf den Einsatz von Six Sigma im Krankenhaus als neuem Anwendungsfeld eingegangen.
Companies across all industries typically develop one concept of a product and see it through many iterations to completion. Applying lean concepts to the product development process ensures that the pace of knowledge capture and decision making supports the creative process of product development. Lean transformation often starts with manufacturing and spreads into the support functions, enabling reduction of waste to improve productivity, performance, and the release of capacity in delivery value streams. Gathering customer needs and wants is the starting point of all lean journeys. Engineering/scientific and creative/marketing activities must use these needs and wants to come up with ideas that enhance customers' lives. Rework is probably the biggest cause of waste in the engineering process because many believe it is a necessary iteration required of the design process. Engineering and design is about the transformation of information using learning and the capture of that knowledge so it can be used by the company to deliver the right products.
Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster. In the past 12–18 months, a wide range of publications—Software Development, IEEE Software, Cutter IT Journal, Software Testing and Quality Engineering, and even The Economist—has published articles on what Martin Fowler calls the New Methodology (see, reflecting a growing interest in these new approaches to software development (Extreme Programming, Crystal Methodologies, SCRUM, Adaptive Software Development, Feature-Driven Development and Dynamic Systems Development Methodology among them). In addition to these "named" methodologies, scores of organizations have developed their own "lighter" approach to building software. Formation of the Agile Alliance On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, 17 people met to talk, ski, relax and try to find common ground. What emerged was the Agile Software Development Alliance. A bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. Although the Manifesto provides some specifics, a deeper theme drives many Alliance members. At the close of the two-day meeting, Extreme Programming mentor Bob Martin joked that he was about to make a "mushy" statement. Though tinged with humor, Bob's sentiments were shared by the group—we all enjoyed working with people who shared compatible goals and values based on mutual trust and respect, promoting collaborative, people-focused organizational models, and building the types of professional communities in which we would want to work. The agile methodology movement is not anti-methodology; in fact, many of us want to restore credibility to the word. We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who brand proponents of XP, SCRUM or any of the other agile methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term (a "hacker" was first defined as a programmer who enjoys solving complex programming problems, rather than someone who practices ad hoc development or destruction).