oXabcaARRAAKALSL.docx

“
o
X
a
b
c
a
A
R
R
A
A
K
A
L
S
L
K
E
S
1
M
o
e

g
A
S
o
(
P
S
i
i
f
X
d
B
k
0
d
The Journal of Systems and Software 85 (2012) 1287– 1299
Contents lists available at SciVerse ScienceDirect
The Journal of Systems and Software
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c
a t e / j s s
Leagile” software development: An experience report
analysis of the application
f lean approaches in agile software development
iaofeng Wang a,∗ , Kieran Conboy b, Oisin Cawley c
Free University of Bozen/Bolzano, Italy
School of Information Systems, Technology and Management,

UNSW, Sydney 2052, Australia
Lero, The Irish Software Engineering Research Centre, Ireland
r t i c l e i n f o
rticle history:
eceived 1 September 2011
eceived in revised form 27 January 2012
ccepted 31 January 2012
vailable online 15 February 2012
eywords:
a b s t r a c t
In recent years there has been a noticeable shift in
attention from those who use agile software develop-
ment toward lean software development, often labelled as
a shift “from agile to lean”. However, the reality
may not be as simple or linear as this label implies. To
provide a better understanding of lean software
development approaches and how they are applied in agile
software development, we have examined
30 experience reports published in past agile software
conferences in which experiences of applying
lean approaches in agile software development were
reported. The analysis identified six types of lean
application. The results of our study show that lean can be
applied in agile processes in different man-
gile software development
ean software development
crum
eagile
anban
xperience report

ners for different purposes. Lean concepts, principles and
practices are most often used for continuous
agile process improvement, with the most recent
introduction being the kanban approach, introducing
a continuous, flow-based substitute to time-boxed agile
processes.
© 2012 Elsevier Inc. All rights reserved.
oftware engineering
. Introduction
Agile methods have become highly prevalent since the Agile
anifesto1 emerged in early 2001 as a response to the
inefficiency
f existing software development methods in rapidly changing
nvironments (Highsmith, 2002). In agile literature, agile
methods
enerally denote a family of methods under the umbrella of the
gile Alliance, including: eXtreme Programming (XP, Beck,
1999),
crum (Schwaber and Beedle, 2002), Dynamic Systems Devel-
pment Method (DSDM, http://www.dsdm.org), Crystal Methods
Cockburn, 2001), Feature-Driven Development (FDD, Coad and
almer, 2002), Lean Development (Charette, 2003) and Adaptive
oftware Development (ASD, Highsmith, 2002). Although differ-
ng in specific techniques, these methods have much in common,
ncluding short iterative life cycles, quick and frequent feedback
rom customers, and constant learning. Among them, Scrum and
P/Scrum hybrid are by far the most widely adopted in the past
ecade (VersionOne, 2010).
∗ Corresponding author at: Dominikanerplatz 3 piazza

Domenicani, I-39100
ozen/Bolzano, Italy. Tel.: +39 0471 016 181.
E-mail addresses: [email protected], [email protected] (X.
Wang),
[email protected] (K. Conboy), [email protected] (O. Cawley).
1 http://www.agilealliance.org.
164-1212/$ – see front matter © 2012 Elsevier Inc. All rights
reserved.
oi:10.1016/j.jss.2012.01.061
In recent years however the agile community has started to
look toward lean software development approaches, in addition
to agile methods such as XP and Scrum. Emerging lean
conferences
(e.g. Lean Software and Systems Consortium conference series,
Lean
Enterprise Software and Systems conference) show that lean
adop-
tion is spreading. Lean approaches are claimed to be “the next
wave of software process”.2 Even though originally lean
software
development was viewed as just another agile method
(Highsmith,
2002; Dybå and Dingsøyr, 2009), there is an increasing focus on
lean and it is viewed as being a method category in itself rather
than an instance of agile methods (Hibbs et al., 2009). More and
more people advocate “from agile to lean” (Hiranabe, 2008),
and
the application of lean approaches in agile software
development.
Some claim that lean software development provides the theory
behind agile practices (Poppendieck and Poppendieck, 2003,
2006).
Others argue that lean is a necessary progression for
organisations

planning to scale up agility from the project or team level to the
organisational level, which agile methods fail to address
satisfy-
ingly (Smits, 2007). “Scrumban” is a term coined for a software
production model based on Scrum and kanban (Ladas, 2009). It
is
believed to be especially suited for maintenance projects or
projects
with frequent and unexpected user stories or programming
errors.
2 http://atlanta2010.leanssc.org/.
dx.doi.org/10.1016/j.jss.2012.01.061
http://www.sciencedirect.com/science/journal/01641212
http://www.elsevier.com/locate/jss
http://www.dsdm.org/
mailto:[email protected]
http://www.agilealliance.org/
http://atlanta2010.leanssc.org/
dx.doi.org/10.1016/j.jss.2012.01.061
1 ems and Software 85 (2012) 1287– 1299
I
n
c
U
a
o

m
d
d
g
s
o
(
l
W
d
a
t
a
g
h
r
a
w
o
t
t
2
f
t
s
e
f
w
2
p
u

a
s
m
w
t
l
2
m
m
S
a
s
i
b
“
c
r
Table 1
Lean principles relevant to software development.
Lean Software
Development
Principles
(Poppendieck and
Poppendieck, 2003)a
The Principles of
Product Development
Flow (Reinertsen,
2009)
The Kanban Principles

(Anderson, 2010)
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimise the whole
• Use an economic
view
• Manage queues
• Exploit variability
• Reduce batch size
• Apply WIP (Work in
Progress) constraints
• Control flow under
uncertainty
• Use fast feedback
• Decentralise control
• Visualise the
workflow
• Limit WIP
• Manage flow
• Make process policies
explicit
• Improve
collaboratively (using
models and the
scientific method)
288 X. Wang et al. / The Journal of Syst
n such cases the time-boxed sprints of the Scrum model are of
o appreciable use, but Scrum’s daily meetings and other

practices
an be applied, depending on the team and the situation at hand.
sing these methods, the team’s workflow is directed in a way
that
llows for minimum earliest completion time for each user story
r programming error, but on the other hand ensures each team
ember is constantly employed (Ladas, 2009).
Despite the shifting focus of practice from agile software
evelopment represented by Scrum and XP to lean software
evelopment, few studies have been conducted that can offer a
ood understanding of the application of lean approaches in agile
oftware development, due to the fact that lean in software
devel-
pment is a nascent research area yet to be explored. Naylor et
al.
1999) coin the term “leagility” whereby principles were estab-
ished for combining both lean and agile in a supply chain
strategy.
e borrow the term and use “leagile” software development to
enote the software development processes that include both
agile
nd lean elements.
The purposes of our study, consequently, are (1) to provide a
bet-
er understanding of the application strategies of lean approaches
in
gile software development, and (2) to demonstrate how these
strate-
ies are being implemented in practice. To achieve these goals,
we
ave conducted a secondary data analysis of a set of experience
eports in which the real world application of lean approaches in
gile software development is evidenced. These experience

reports
ere published in the past Agile and XP conference series.
Patterns
f lean application in agile software development that recurred in
hese experience reports were identified. The results are intended
o be useful for both research and practice.
The remaining part of the paper is organised as follows. Section
introduces basic lean concepts and lean principles and practices
or software development. This is followed by a section that
reviews
he relevant literature on the application of lean approaches in
agile
oftware development. Section 4 describes the research approach
mployed. Then the findings are reported in the next section, and
urther reflected upon in the discussion section. The paper ends
ith concluding remarks.
. Lean software development
It is well acknowledged that the terms ‘agile’ and ‘lean’ are
oorly defined in the software development literature, and the
se of these terms is often poorly considered, multi-dimensional,
mbiguous and inconsistent (Conboy, 2009). For the purpose of
our
tudy, however, we need to make it as explicit as possible what
we
ean by lean software development. Corresponding to relatively
ell-accepted agile values, principles and practices, we consider
hat lean software development also involve three main
elements:
ean concepts, lean principles and lean practices.
.1. Lean concepts

Leanness, like agility, is not a term unique to software develop-
ent. It has a much older origin rooted in other disciplines, with
ost literature tracing the origins back to the Toyota Production
ystem (TPS) in the 1950s (Ohno, 1988). However, it did not
make
significant impact in the mainstream literature until MIT’s
(Mas-
achusetts Institute of Technology) 5-year study of the
automotive
ndustry identified lean as a source of huge productivity
differences
etween the US and Japan (Womack et al., 1990).
Lean thinking is a way of thinking that enables organisations to
specify value, line up value-creating actions in the best
sequence,
onduct these activities without interruption whenever someone
equests them, and perform them more and more effectively”
a These seven principles have been rephrased and rearranged by
The Pop-
pendiecks. The newest version can be seen at
http://www.poppendieck.com/.
(Womack and Jones, 1996). Five inherently interlinked guiding
lean
concepts underpin lean thinking:
• Value: It is defined by the customer and it is paramount to
have
a clear understanding of what that is.
• Value stream: A map that identifies every step in the process
and
categorises each step in terms of the value it adds.

• Flow: It is important that the production process flows
continu-
ously.
• Pull: Customer orders pull product, ensuring nothing is built
before it is needed.
• Perfection: Striving for perfection in the process by
continuously
identifying and removing waste.
2.2. Lean principles
The primary focus and guiding principle of lean is the identi-
fication and elimination of waste from the process with respect
to customer value. In Japanese this waste is referred to as muda,
although other terms such as mura (unevenness), and muri
(over-
burden) are also used. Lean thinking classifies work into three
categories: value-adding activities, required non-value adding
activities, and non-value adding activities. By mapping out the
pro-
cess using a value stream map, those process steps which do not
contribute to creating value can be identified and eliminated. It
is worth noting that the concept of waste can be quite broad and
context dependent. In the domain of software development, the
types of waste can be interpreted as: extra features, waiting,
task
switching, extra processes, partially done work, movement,
defects and
unused employee creativity (Poppendieck and Poppendieck,
2003;
Hibbs et al., 2009).
The contemporary understanding of lean software development
is largely driven by practitioners writings (e.g., Poppendieck

and
Poppendieck, 2003, 2006; Hibbs et al., 2009; Reinertsen, 2009;
Anderson, 2010). Maintaining the core intent of lean, different
lean
principles for software development have been proposed and are
constantly evolving. Table 1 lists several sets of lean principles
better known in agile community. These sets of lean principles
overlap to large extent which reflects the core and essence of
lean
approaches.
It is worth noting that the kanban approach is the most recent
addition to the agile and lean software development affray.
Again,
it gets its name from the world of lean manufacturing. A kanban
system is “a production control system for just-in-time
production
and making full use of workers’ capabilities” (Sugimori et al.,
1977).
The core objective of the kanban system is to minimise the
amount
http://www.poppendieck.com/
ems and Software 85 (2012) 1287– 1299 1289
o
W
o
c
f
d
c

t
b
w
2
w
a
t
w
t
t
o
i
m
C
w
i
a
s
T
w
t
T
l
g
3
d
s
J
m
o
t

t
c
d
l
S
s
f
a
i
a
r
o
o
c
o
w
s
s
e
Table 2
Lean practices relevant to software development.
Lean software development practices
• Address bottlenecks (Liker, 2003; Goldratt, 1992, 1997;
Middleton et al.,
2005; Poppendieck and Poppendieck, 2003)
© Cumulative Flow Diagram (CFD)
• Avoid too much local optimisation (Poppendieck and
Poppendieck, 2003)
• Defer decision making (Thimbleby, 1988; Poppendieck and
Poppendieck,

2003)
• Develop appropriate incentives/rewards (Ambler and Kroll,
2007)
• Hansei: relentless self-reflection, to acknowledge one’s own
mistakes
and to commit to making improvements (Liker and Hoseus,
2008).
• Heijunka: workload levelling, production smoothing. It aims
at reducing
muda (Liker, 2003; Middleton et al., 2005).
• Hide individual performance (Poppendieck and Poppendieck,
2003)
• Jidoka: intelligent automation, automation with a human
touch. People
should not serve machines but vice versa (Liker, 2003; Liker
and Hoseus,
2008).
• Kaikaku: radical improvement within a limited time (Womack
and Jones,
1996).
• Kaizen: continuous improvement to establish a smoother flow
(Liker,
2003; Hibbs et al., 2009; Joyce and Schechter, 2004).
• Kano analysis: link voice of the customer to requirements
(Middleton
et al., 2005; Raffo et al., 2010).
• Make everything transparent (Womack and Jones, 1996):
© Make project status highly visible
© Visualise all work items

• Measure and manage (Anderson and Garber, 2007)
© Employ queuing theory (Reinertsen, 1997; Goldratt, 1997,
1992) but
measure the right things (Reinertsen, 1997)
© First-In-First-Out (FIFO) queue
• Move variability downstream (Poppendieck and Poppendieck,
2003)
• Plan-Do-Check-Act (PDCA) cycle (Deming, 1986)
• Poka-Yoke: defect detection and prevention (Robinson,
1997).
• Pragmatic governance (enable first, manage/control second)
(Ambler and
Kroll, 2007)
• Pull the andon cord: promote a “safe to failure” environment
and instil a
“stop the line” mentality (Poppendieck and Poppendieck, 2003;
Womack et al., 1990)
• Quality Function Deployment: transform the voice of the
customer into
engineering characteristics and appropriate test methods (Raffo
et al.,
2010).
• Reduce slack (Middleton, 2001)
• Root cause analysis
© The 5 whys? (Womack et al., 1990)
• Use pull systems
© Kanban board, Limitied WIP, CONWIP (Sugimori et al.,
1977; Bradley,

2007; Kniberg and Skarin, 2010)
© Batch control processing (Bradley, 2007), Minimal
Marketable Feature
(MMF)
• Value stream mapping: analyse and design the workflow
required to
X. Wang et al. / The Journal of Syst
f WIP. Excess WIP is one form of waste from a lean
perspective.
ork should be “pulled” through the system as it is needed, as
pposed to “pushing” it through. Only when a downstream pro-
ess is ready and needs to do some more work does it pull work
rom an upstream process. The signalling between upstream and
ownstream processes is typically done via some sort of coloured
ard which physically travels between processes. The aim is to
keep
he process flowing at an even but continuous rate. This is
achieved
y controlling the number of kanban cards which are in
circulation
ithin the process.
.3. Lean practices
Some lean software development practices have already been
ell established in agile methods, and regarded as agile practices
s well, even though they have origins that can be traced back
o pre-agile days. For example, back in the 1970s, Michael
Fagan,
hile working for IBM, formalised the practice of code reviews
in a

echnique known as Fagan’s Inspections: “Because errors were
iden-
ified and corrected in groups [early in the process] rather than
found
ne-by-one during subsequent work and handled at the higher
cost
ncumbent in later rework, the overall amount of error rework
was
inimised, even within the coding operation” (Fagan, 1976, p.
187).
ode inspections support one of the cornerstones of what lean
soft-
are development is founded on, finding and fixing defects early
n the development process.
In order to help categorise the empirical data in terms of lean
pproaches, we generated a list of what we considered to be lean
pecific practices relevant to software development, as shown in
able 2. Due to the overlapping nature of lean and agile
practices,
e limited the practices to those we found were less represented
in
he agile literature but were recurring themes within a lean
context.
his categorisation was somewhat subjective. However, the final
ist was agreed by consensus among the researchers and offers a
ood starting point for cataloguing lean practices.
. Application of lean approaches in agile software
evelopment
Agile and lean are seen as just two different names for the
ame thing in some software literature. In the study reported in

alali and Wohlin (2010), for example, no meaningful
distinction is
ade between the two. This study conducted a literature review
f agile practices used in global software engineering. The fact
that
he search string “agile and lean” was used to denote agile prac-
ices indicates a lack of distinction between the two. Barton
(2009)
laims that many organisations that have modified their software
evelopment system based on Scrum consider their work to be a
ean implementation. Barton argues that even in its simplest
state,
crum uses a lean ‘pull’ technique to smooth the flow through
the
ystem and prevent overloading. Scrum also implements a
process
or eliminating muda, or waste. If no distinction is made between
gile and lean, the application of lean in agile context, if
happens,
s generally a non-purposeful act of the adopting organisation.
Most literature, however, does consider the differences between
gile and lean approaches, thus motivating an analysis of their
elationship and a study that analyses the purposeful application
f lean approaches in agile software development. Agile meth-
ds are believed to be tactical in nature, and therefore the major
hanges required to become agile must be initiated from the top
f the organisation. Organisational strategy becomes the context
ithin which agile processes can operate effectively. Without this
trategic piece, agile development is “shunted aside by the
organi-

ational forces that seek equilibrium” (Highsmith, 2002).
Dall’Agnol
t al. (2003) also suggest that agile and lean address a different
bring a software or service to a customer (Womack and Jones,
1996;
Liker, 2003; Poppendieck and Poppendieck, 2003; Mujtaba et
al., 2010).
audience. They believe that XP describes a set of practices
primar-
ily designed for use by developers. It is aiming to ease the
tension
often exhibited between developer and customer due to
conflicting
aims. Instead, lean management is applied from an upper man-
agement perspective, with the objective being the optimisation
of activity across the whole entire organisation. Therefore lean
management is a top-down approach. Smits (2007) claims that
“experience gathered during large scale implementation of agile
concepts in software development projects teaches us that the
cur-
rently popular agile software development methods (like Scrum)
do not scale to programme, product and organisation level
without
change. The fundamentals for changes to these methods are
found
in lean principles, or: “the future of agile methods is found in
its
origins.” This claim is echoed by industry practitioners
(reported in
Serignese (2011)) who believe that “lean is both the precursor
and
future of agile”. Similarly, Hibbs et al. (2009) view agile
methods
as mostly concerned with the specific practice of developing

soft-
ware and the project management that surrounds that software
development. They do not generally concern themselves with
the
surrounding business context in which the software
development
1290 X. Wang et al. / The Journal of Systems and Software 85
(2012) 1287– 1299
Table 3
The application of lean approaches in agile software
development.
Types of lean application in agile software development
Non-purposeful combination of agile and lean in software
development
processes
Purposeful application of lean approaches in agile software
development
Lean approaches are applied to the business areas related to
software
development
i
f
e
a
t
s

l
a
d
e
t
w
C
t
a
v
p
F
a
t
p
n
e
s
t
p
p
t
t
r
c
s
r
c
a
r
s
g
e
a
t

4
w
o
t
a
t
t
t
d
Table 4
The source conferences and the numbers of the selected
experience reports.
Conference Number of experience reports selected
Agile 2004 2
Agile 2006 4
Agile 2007 3
Agile 2008 5
Agile 2009 4
XP 2010 3
Agile 2011 8
XP 2011 1
Total 30
Lean approaches are applied to software development processes
directly
s taking place. Instead, lean principles can be applied to any
scope,
rom the specific practice of developing software to the entire
nterprise where software development is just one small part.

Poppendieck and Poppendieck (2003, 2006) focus more on the
pplication of lean in software development activities. They
claim
hat lean thinking is principles that guide ideas and insights
about
oftware development discipline. Principles are viewed as under-
ying truths that do not change over time or space, while
practices
re the application of principles to a particular situation and
should
iffer from one environment to the next and change as a situation
volves. They believe that lean development further expands the
heoretical foundations of agile software development by
applying
ell-known and accepted lean principles to software
development.
onsequently they suggest use lean thinking as guiding principles
o develop and adapt agile practices. Morien (2005) also sees
that
gile project management has roots in the lean thinking which
pro-
ides strength and credibility to the concept and practice of agile
roject management. Along the same line, the study of Perera and
ernando (2007) attempts to identify possible improvable parts in
gile software development processes, and explores how lean
prac-
ices could be used to improve them. A hypothesis “agile
software
rocess’s development can be improved using lean practice tech-
iques” is proposed in their study. They conducted a controlled
xperiment with university student projects to test the hypothe-
is and obtained positive evidences to support it. They conclude
hat applying lean techniques help stabilise the agile
development
hase especially in later stages of the phase. Instead, Ambler
(2009)

roposes a governance framework built upon the lean principles
hat is claimed to enable agility at scale. Lean governance prac-
ices such as aligning the team structure with the architecture,
isk-based milestones, and staged programme delivery address
omplexities inherent in large or distributed teams. Other
practices
uch as continuous project monitoring, integrated lifecycle envi-
onment, and embedded compliance help to address the
additional
omplexity of regulated environments.
Table 3 is a summary of the possible applications of lean
pproaches in agile software development suggested in the
eviewed literature. The limited yet increasing literature on lean
oftware development depicts a fragmented picture of the strate-
ies of lean application in agile software development. The
mpirical evidences of such applications and their
implementation
re yet to be collected in a systematic manner. Our study is one
of
he earliest attempts to address this knowledge gap.
. Research approach
To explore how lean approaches have been applied in agile soft-
are development, we have conducted a secondary data analysis
f the real world cases that contain the evidences of lean applica-
ion in agile software development. Secondary data analysis is
the
nalysis of data that was either collected by individuals other
than
he researchers that conduct the study, or for some other purpose
han the one currently being considered, or often a combination
of
he two. The sources of secondary data include newspapers,

census
ata, maps, etc. The advantage of using secondary data is that the
data collection process can be unobtrusive, fast and
inexpensive,
even though it needs to be cautioned that there are issues related
to data quality control, accuracy of data, etc., which need the
atten-
tion of the researchers. Secondary data analysis is frequently
used
in social science research. If it is undertaken with care and
diligence,
it can provide a cost-effective way of gaining a broad
understanding
of research questions. It is also often considered a starting point
for
other research methods, helpful in designing subsequent primary
research and can provide a baseline with which to compare the
pri-
mary data analysis results (Boslaugh, 2007). Given the
exploratory
nature and early stage of our study, we consider secondary data
analysis a feasible way to build initial understanding of the phe-
nomenon under the study.
Agile development has been the subject of several conferences,
and some of these conferences have published experience
reports
which share industry experiences of agile software
development.
To obtain the secondary data needed for this study, we collected
the experience reports that have been published in the agile
related
conferences from 2000 to 2011 (including the XP Conference
series,
Agile Conference series and XP/Agile Universe series) and that

are
publicly available online (Agile 2010 experience reports and the
proceedings of XP 2000, XP 2001, XP 2002 and XP Universe
2001
are not publicly available online). For each experience report,
we
conducted a full-text search for any lean concept, principle or
prac-
tice as defined in Section 2. If an experience report contained
one
or more lean keywords, we then read through the report to
decide:
(i) if it has an agile software development context, and (ii) if it
contains explicit evidences of applying one or more lean
concepts,
lean principles and/or lean practices in the agile context. In
total
30 experience reports satisfy the selection criteria and have
been
included in the secondary data analysis (see Appendix for a list
of
these experience reports). Table 4 shows the source conferences
and number of the selected experience reports per conference.
The 30 selected experience reports focus on different aspects of
software development. The angles and detail levels of the
descrip-
tion of lean application vary from one experience report to
another.
This diversity posed a challenge to qualitatively analyse these
30
experience reports at the same depth and in a unified manner.
We started with the initial classification scheme of lean applica-
tion in agile software development presented in Table 3.
Combined
with our understanding of lean approaches, it acted as a sense-

making and categorisation device for the identification of
patterns
of lean application in agile software development. Meanwhile,
we
used an open coding process and allowed more detailed patterns
emerge from the collected data which enriched and extended the
initial classification scheme. Some initial insights gained
through
analysing a subset of the reports has been reported in Wang
(2011).
The following section describes the findings of the analysis of
all 30
experience reports.
X. Wang et al. / The Journal of Systems an
Table 5
The six categories of lean application in agile software
development.
Type of lean application Type code
Non-purposeful combination of agile and lean in software
development processes
A
Purposeful application of lean approaches in agile software
development
Lean approaches are applied to the business areas related to
software development
Agile within, lean out-reach: using lean approaches to
interact with neighbouring business units while keeping

agile development processes internally
B
Lean approaches are applied to software development processes
directly
Lean facilitating agile adoption: before or during the
transition process
C
Lean within agile: using various lean elements to
improve agile processes
D
From agile to lean: comprehensive application of lean
approaches to transform agile processes
E
5
e
m
n
fi
h
i
a
I
t
i
d
i

p
i
o
r
t
l
d
v
i
5
p
c
h
r
F
Synchronising agile and lean: agile team and lean team
work in parallel in a synchronised manner
F
. Findings
The 28 organisations reported in the 30 experience reports (3
xperience reports regard the same company) range from small
and
edium to large and multi-national. They operate in diverse busi-
ess domains, such as software engineering, telecommunication,
nance, healthcare and public administration. Lean approaches
ave been applied to various agile projects of these
organisations,

n various manners and to various degrees. In some companies,
lean
pplication is limited to a single, or several agile teams or
projects.
n others instead, it is a company-wide endeavour. Table 5 shows
he six categories of lean application in agile software
development
dentified based on the analysis of the 30 experience reports. The
istribution of the experience reports per application type is
shown
n Fig. 1.
A more detailed distribution of the experience reports per type
er year is shown in Table 6.
It can be seen that Type D, using lean to improve agile
processes,
s the most common and frequently appearing lean application
type
ver the past years, with almost a half of the selected experience
eports containing the relevant evidences. Another observation is
hat, Type E seems to be an emerging trend of lean application in
the
ast several years. In the following sub-sections we present in
more
epth what the six categories of lean application mean and how
arious lean concepts, principles and practices have been applied
n the cases reported in the experience reports.
.1. Non-purposeful combination of agile and lean
The reporter of [ER13] presented the agile practices that he
racticed in a project where he worked as a technical lead (The
ompany’s name was not revealed in the report). The practices in

is armoury included both agile practices (Keep/Problem/Try
Ret-
ospective, Estimate Retrospectives, Iteration Planning, etc.) and
A B C D E F
0
2
4
6
8
10
12
14
1
5
6
13
4
1
Type of lea n appl ica tio n
N

u
m
b
e
r
o
f
e
x
p
e
ri
e
n
c
e
re
p
o
rt
s
ig. 1. The distribution of the selected experience reports per
lean application type.
d Software 85 (2012) 1287– 1299 1291

lean practice (Task Kanban). Evidently he was practicing a
com-
bined approach of agile and lean practices, even though he
regarded
them as agile practices in general. In this report lean and agile
prac-
tices were presented in parallel and no specific distinction
between
the two was made. Therefore it is a case of non-purposeful
combi-
nation of agile and lean practices. It is interesting to mention
that
the Japanese background of the development team might be an
explanation of the natural and implicit adoption of lean
practices.
5.2. Agile within, lean out-reach
Five experience reports are grouped under this category. Table
7
lists the cases contained in these reports.
In the Cardiac Rhythm Disease Management of Medtronic Inc.,
when the software group adopted agile development, they
quickly
realised that not only were they learning something new, but
they also needed to learn how to communicate it with other
business units ([ER5]). Lean concepts and principles became a
convenient choice as a communication tool with the product
devel-
opment organisation since the product development organisation
had already implemented a lean initiative. Therefore when com-
municating with product development organisation, the software
group emphasised the principle of eliminating waste, meanwhile
implemented customised agile practices like the Customer Role,
Stories, Sprint Planning and Release Planning to put focus on

value-
added activities.
The experience of Ericsson R&D in the Netherlands suggests
that
agile software development should be implemented as a broader
“lean” initiative ([ER12]), which can create involvement of
neigh-
bouring units, for example, service and delivery units, product
management, market units and customers. This foundation
would
be an incentive for neighbouring units to cooperate and optimise
as
a whole, and the resistance to collaborate with agile
development
would be reduced effectively. Their experience also suggests
that
lean can help align management quickly:
“In a bottom-up approach line and project management have
lim-
ited involvement. However, line and project managers are a key
in
making the change stick, helping people resolve impediments
and
conflicts, building a learning organization and, above all,
showing
what is meant with Agile and lean ways of working. Speaking
the
same language and agreeing on principles like ‘build quality in’
and
many more is highly needed for successful cross unit
cooperation.”
([ER12], p. 158)
An interesting case was reported in [ER2] where a company

applied lean thinking and systems thinking on the customer
busi-
ness process in order to understand what features the developers
should develop that really delivered business values. Cyrus
Inno-
vation is a consulting group in New York City specializing in
agile
software development, usability design and operational
consulting.
One of their customers – a restaurant chain – needed to improve
aspects of their operations that were breaking due to their rapid
growth. Their main objective was reducing operating expenses
by
cutting down on the food product wasted each day. Cyrus
Innova-
tion used XP for development and strongly believed in the
power of
agile development; however they saw that agile alone was
insuffi-
cient to make every software project successful:
“XP customer will tend to drive development without regard
to how features impact the business system from a throughput
perspective. . . If business managers do not adopt analytic tech-
niques that are more synergistic with XP, the developers
themselves
simply become a local optimization of the software development
process. As a result, XP by itself cannot drive overall system
improvement and thus by itself cannot make a company sustain-
able.” ([ER2], p. 81)

(2012) 1287– 1299
Table 6
The distribution of the selected experience reports per
application type per year.
A B C D E F
2004 [ER2] [ER1]
2005
2006 [ER5] [ER3] [ER6]
[ER4]
2007 [ER7][ER9] [ER8]
2008 [ER13] [ER12] [ER10] [ER11]
[ER14]
[E
[E
[E
s
a
t
w
b
t
q
s
o
a
t
a
b
w

c
t
i
p
p
d
t
o
f
e
S
t
i
k
W
o
i
a
t
T
T
2009 [ER17]
2010
2011 [ER24] [ER28]
Projects must be coupled with a complimentary approach to
trategy in order to achieve the overall business goals. Rather
than
ccepting whatever the customer demanded to deliver, the project
eam used lean thinking and techniques, including eliminating
aste, value stream mapping, flow, and theory of constraints, to
etter understand what really delivered business value to the cus-
omer. Then the development team used agile development to

build
uality software that effectively contributed to overall business
uccess.
In DTE Energy, a Fortune 300 company, agile software devel-
pment and project management encountered the legacy mindset
nd culture of portfolio management ([ER14]), which meant that
he annual budgeting cycle drove a mindset that scope, budget,
nd schedule must be established up front, often many months
efore project work began. Success meant delivering on that
scope
ithin the budget and schedule commitments. As the IT teams
suc-
essfully applied agile methods at the project level, they began
o address their approach for managing portfolios of projects to
ncrease the amount of value they delivered with their business
artners. Lean training was organised for the leadership team,
and
otential applicable lean techniques identified. They also intro-
uced lean terminology and concepts to help better understand
he constraints and how they could reorganise the way they pri-
ritised their commitments and funded their work. As the way
orward, one overarching strategy in their IT was to leverage an
xisting corporate system which is a combination of lean and Six
igma thinking, seeing, and doing tools and techniques based
upon
he Plan-Do-Check-Act (PDCA) cycle.
Similarly Exilesoft, an offshore software development company
n Sri Lanka which caters to the Scandinavian and Australian
mar-
ets, applied lean to its Human Resource (HR) department
([ER24]).
ith the rapid change from a traditional project culture to an
agile

ne and the speedy growth of the project organisation, support-
ng functionalities such as HR and operations were stressed out
nd a high degree of negative stress and frustration was created
hroughout the company:
“. . . software companies adapt agile concepts for their
development
teams rapidly. However, the lack of understanding of such
concepts
able 7
he cases in the “agile within, lean out-reach” category.
Experience report no. Organisation name Business dom
[ER5] Medtronic Inc. Medical devic
[ER12] Ericsson Telecommuni
[ER2] Cyrus Innovation Agile software
consulting gro
[ER14] DTE Energy Gas and electr
[ER24] Exilesoft Software deve
a Which specific lean concepts were applied is not explained in
the report.
R15] [ER16] [ER18]
R19] [ER20][ER21]
R22][ER23][ER25][ER26][ER27] [ER29] [ER30]
by other facilitating entities of the organization, such as HR

depart-
ment, may create complexities and slow down the expected
return
of such agile transformation by its production staff.” ([ER24],
p.
166)
Based on the believe that employing the same agile concepts
within the HR department would also deliver positive results
and
that having one work culture across the organisation would
remove
many challenges faced by the company, the senior management
group launched an initiative to introduce agile concepts to its
HR
department. However, due to the nature of the work in HR,
feasi-
bility of implementing Scrum was rejected, including the
concepts
of time boxing, scheduled releases, story point estimation,
sprint
burn down, etc. Instead, kanban was seen a better fit for the HR
department. Kanban supported everyday planning required for
HR functions. It did not demand story point estimation/relative
estimation, and allowed to monitor cycle time and set limit to
work-in-process, which solved one of the biggest issues in the
HR
department, preventing it from committing to work on various
tasks which would exceed their capacity.
In brief, the five cases show that the agile teams have used
purposefully lean approaches to involve and interact with their
surrounding environments while keeping the agile processes
inter-
nally. They have demonstrated lean approaches, especially the
lean

concepts and principles, could help agile teams to better
collaborate
with different stakeholders of software development, including
neighbouring business units and customers, and extending agile
mindsets and practices to non development, organisational level
activities.
In the following sub-sections we show how lean approaches
have been used purposefully in software development activities
directly and demonstrated their effectiveness as software
develop-
ment approaches.
5.3. Lean facilitating agile adoption
Six experience reports contain evidences that lean concepts and
principles have been utilised to facilitate agile adoption, either
ain Lean elements applied
e Concept: Value
Principle: Eliminate waste
cation Principle: Build quality in
development
up
Concept: Flow
Principle: Eliminate waste
Practice: Avoid too much local optimisation,
Value stream mapping
ic utility services Lean conceptsa
Practice: PDCA cycle
lopment Principle: Limit WIP

Practice: Kanban board
X. Wang et al. / The Journal of Systems and Software 85 (2012)
1287– 1299 1293
Table 8
The cases in the “lean facilitating agile adoption” category.
Experience report no. Organisation name Business domain Lean
elements applied
[ER3] Capital One Financial service Principle: Eliminate waste
Practice: Value stream mapping, Root-cause
analysis
[ER9] Systematic Software systems Principle: Build quality in,
Create knowledge,
Deliver fast
[ER4] (not revealed) Automotive engineering consultancy and
software Concept: Self funding transformationa , cost
accountinga
[ER7] Salesforce.com Enterprise software Principle: Respect
people, Deliver fast
[ER17] SEP Software solution for regulated industry Practice:
Kanban board
[ER28] Cisco Voice Technology Group Voice technology and
service Concept: Value, Flow
Principle: Principles of product flowb

b
fi
u
s
p
m
t
s
t
i
s
a
m
f
M
D
d
i
t
o
t
f
c
g
a
t
o
r
“
i
c
p
T

a
d
a
f
t
p
v
c
f
c
d
b
a Considered lean elements in the report but not included in our
definition.
b Which specific principles were applied is not explained in the
report.
efore or during agile transition initiatives. Table 8 shows the
pro-
les of the six cases.
Capital One, a large Fortune 500 financial services company
sed the lens of lean to evaluate the current delivery process and
treamline the business values prior to agile transition ([ER3]).
Lean
rinciple, eliminate waste, and practices including value stream
apping, root-cause analysis (5-whys) were applied to analyse
he processes of a product or service type before Scrum was
cho-
en as the adopted agile method. According to the experience of
he company, lean principles and practices could help in achiev-
ng a smoother transition and would increase the likelihood of a
uccessful agile pilot with tangible business metrics.

The experience of Capital One is echoed by that of Systematic,
n independent software systems company ([ER9]). Systematic
ade a strategic decision to use lean as the dominant paradigm
for
urther improvements after achieving CMMI (Capability
Maturity
odel Integration) Level 5. The company identified Lean
Software
evelopment of Poppendieck and Poppendieck (2003) as the lean
ialect most relevant to Systematic. The analysis of systematic
mprovement opportunities and lean causal dependencies led to
he decision to seek improvements based on the lean principles
f build integrity in, amplify learning and deliver fast. These
lean
hinking tools gave inspiration to consider Scrum and early
testing.
[ER4] describes an interesting experience of the bottom-up,
self-
unded agile adoption in an engineering consultancy and
software
ompany that is involved in the automotive industry “where
analo-
ous concepts under the umbrella term ‘lean’ are part of the
landscape”
nd some of the companies they do business with were the
origina-
ors of lean. Therefore it is natural that the driving force behind
a lot
f what they did came from an awareness of lean. According to
the
eport, a self funding transformation is one of the key concepts
they
stole” from lean. Another concept that they borrowed from lean

s that of cost accounting, viewing your software team as a fixed
ost overhead. In addition, what inspired them to bootstrap agile
ractices themselves include also the “inspect and adapt” cycle.
herefore, the success of this self-funded agile adoption can be
ttributed to the guidance of both lean and agile concepts.
In contrast to the bottom-up, self-funded agile adoption
escribed in [ER4], Salesforce.com took a completely different
pproach ([ER7]). Salesforce.com has completed an agile trans-
ormation of a two hundred person team within a three-month
imeframe. During this large and fast “big-bang” agile rollout,
lean
rinciples, such as empowered teams and delivering customer
alue early, were used as key communication tools to communi-
ate the value of changing current behaviour. If the teams were
eeling that something was not working the way it should be,
they
ould refer back to the values and reject anything they thought
id not correlate with their core values. Lean principles help
agile
ehaviours to stick.
This claim can be supported by the experience of SEP ([ER17]).
SEP is a privately held software engineering company with
more
than 70 employees. It offers full lifecycle software solutions to
clients in the medical, aerospace, healthcare and national
defence
markets. In the process of adopting one of the agile methods,
Fea-
ture Driven Development, SEP found that it failed to have the
desired lasting impact across the entire organisation. However,
things changed when a kanban system was implemented later
on
alongside the agile practices. Kanban provided a more effective

vehicle to introduce agile practices and principles in the
company.
The culture on project teams began to change as they learned
the
system. And more importantly, the attitudes of team members
changed. The implementation of kanban helped the agile
mindsets
to stick in the company.
The agile transition in Cisco Voice Technology Group (VTG)
was
also a top-down organisational wide initiative ([ER28]). VTG is
a
global organisation with three business units, with a total of
about
2500 people within the larger Cisco Systems, Inc. When Scrum
was to be implemented in the organisation, it was realised that,
even though “. . . it is often suggested to implement Scrum by
using
Scrum: create a backlog of process changes, prioritise, and start
imple-
menting”, the kanban approach was found more appropriate to
implement Scrum in VTG:
“we had a vision and model we wanted to implement, we had a
backlog of steps to take, and when problems occurred, we would
prioritize the issue, put it on the backlog, and address it when it
became the highest priority. Sometimes that meant addressing
an
issue immediately.” ([ER28], p. 274)
An important lesson learned by VTG was that implementing
agile methods into an organisation was “interrupt-driven, not
plan
driven. We had some interesting hurdles to clear, but once
taken they

became a strong driver in the change process.” Other lean
concepts,
such as value and flow, and the principles of product
development
flow, also inspired and helped the different organisational units,
including the executives, to comprehend the nature of the agile
transition happening in the organisation.
As shown in these six cases, regardless the agile adoption style
(top-down organisational undertaking or grass-root, bottom-up
initiative) or applied before or during agile adoption, lean con-
cepts, principles and practices can smooth the agile
transformation
process and help agile mindsets to be institutionalised in
adopting
organisations.
5.4. Lean within agile
Using various lean elements to improve agile processes is a pat-
tern that appears repeatedly in 13 out of 30 experience reports
analysed. Table 9 is a list of the 13 cases.
(2012) 1287– 1299
Table 9
The cases in the “lean within agile” category.
Experience report no. Organisation name Business domain Lean
elements applied
[ER1] Government of a major California county Public
administration Principle: Reduce batch size
[ER16] Canonical Open source solution, collaborative software

systems Concept: Value stream
Practice: Address bottlenecks,
Kaizen
[ER6] Wireless Data Services Global Services to mobile
companies Principle: Eliminate waste
[ER8] Sabre Airline
Solution
s Product development for airline industry Principle: Eliminate
waste
Practice: Value stream mapping
[ER10] British Telecom Telecommunication Principle:
Eliminate waste
[ER11] (not revealed) (not revealed) Principle: Eliminate waste
[ER19] ASR Insurance Insurance Principle: Visualise the
workflow,
Limit WIP, Manage flow
[ER23] Fundamo Mobile financial services products Practice:
Kanban board, CFD
[ER27] SumTotal Des Moines Learning management system

Practice: Value stream mapping,
FIFO queue
[ER26] (not revealed) Financial service Practice: Visualise all
work items,
Root cause analysis, Kaizen
[ER22] (not revealed) Telecommunication Practice: Use pull
systems, Kanban
board, Value stream mapping,
e syst
t
i
b
w
t
e
s
t
d
a
t

D
u
a
t
T
t
p
p
i
p
e
e
t
p
h
c
d
t
I
S
l
t
p
I

a
t
i
t
B
[ER15, ER25] Systematic Softwar
Lean concepts and principles have been used as thinking tools
o make sense and guide the use and adaptation of agile practices
n [ER1]. The Government Workflow Project, a project initiated
y the government of a major California county to automate the
orkflow of key business processes in the criminal justice sys-
em, has adopted agile practices incrementally. The project team
nded up performing more up-front analysis and using small
batch
ize for estimations as a response to frustrating velocity fluctua-
ions and inconsistent completion of features. Initially the team
had
oubts that performing additional up-front analysis was against
gile principles. However, “in retrospect, the team realised this
prac-
ice implements the ‘smaller batch size’ principle of Lean
Software
evelopment, and in fact increased their agility”. Notice that

lean was
sed as a sense making tool retrospectively after a practice was
dapted. More lean principles have been applied in a distributed
eam of 35 developers spanning 5 continents in Canonical
([ER16]).
he lean principles that play an important role in the experience
of
his highly distributed agile team include end-to-end view of the
rocess, removing bottlenecks in the process, and Kaizen where
rocess improvement experiments are encouraged.
One of the lean principles, eliminating waste, is a recurred
theme
n [ER6, ER8, ER10, ER11]. In Wireless Data Services Global, a
service
rovider to wireless companies and mobile phone manufactur-
rs, the development teams “have experienced tremendous
positive
ffects from utilizing Extreme Programming practices on
development
eams”. However, they “have yet to find the agile path to
regularly
roviding positive business value” ([ER6, p. 175]). Over the
time, they
ave found a family of four agile practices that merged the XP

prin-
iples of implementing the “highest value features first”, and
“don’t
o anything extra”, with lean principles such as “eliminate
waste”
o address the highlighted issues. The four practices – Value-
based
nvestment Decisions, High Confidence Stories First,
Incremental
tory Delivery, and Story Ownership – embody both agile and
ean principles and are believed to be most effective when
applied
ogether. In [ER8], Sabre Airline

oXabcaARRAAKALSL.docx

More Related Content

Similar to oXabcaARRAAKALSL.docx (20)

More from alfred4lewis58146 (20)

Recently uploaded (20)

oXabcaARRAAKALSL.docx