Answered the questions

“ 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/.

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

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)

1292 X. Wang et al. / The Journal of Systems and Software 85 (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

Practice: Kanban board

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.

1294 X. Wang et al. / The Journal of Systems and Software 85 (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 Solutions 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 Practice: Kanban board

[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 Solutions, a company developing roducts for the airline industry, encountered agile plateau effect.

n the effort of overcoming the plateau, the company chose to pply lean concepts, such as seeing waste and value chain mapping, o brainstorm the ways to improve quality, and develop quality

mprovement goals and action plans accordingly. [ER10] examines he use and adaptation of the “product owner team” practice in BT, ritish Telecom. Product owner team is used to manage the details

Kaizen, Pull the andon cord ems Practice: Kaizen, PDCA cycle, Root

cause analysis, Jidoka

of what should be built in a project implementing an up to 24 Mbps service over the 21CN network. The lean principle of eliminating waste and the seven types of waste help the company to “break the silo mentality and simplify the delivery by reducing the work in progress and developing collaborative teams focused on customers’ prioritised needs”. It is believed that the project was successful due to “the collaborative efforts of the core team to eliminate waste – apply- ing one of the core principles of lean”. Similarly, in a mission-critical commercial-off-the-shelf upgrade project described in [ER11], lean thinking, especially eliminating waste, is used as the guidance to the improvement of the manual testing process which is crucial to the project.

Kanban is another frequently used approach to improve agile processes. [ER19] reports the projects in the IT department of ASR Insurance, one of the top 3 insurance companies in the Netherlands. While most projects that used Scrum were successful, other Scrum teams were having some difficulties. The major reason was that these projects most of the time were involved in operations work or small maintenance. The work was hard to distribute properly over sprints and often needed to be changed more frequently than the 2- week sprints allowed. What the client wanted was more flexibility and more control over the immediate results. The company wanted to keep the agile mindset and at the same time do something more appropriate for maintenance and operations so that they too can cooperate with the rest of the IT departments and projects. Kanban technique was adopted, together with the underlying principles – make work visible, limit work in progress and help work to flow. As a result, much better understanding and cooperation between developers from different technologies as well as with the testers was observed, even though the team encountered different team and organisational challenges.

A similar story is recounted in [ER23]. Fundamo is a provider in mobile financial services products. The Product and Technology teams faced heavy support tasks for multiple customers. Scrum was used for the development work, while kanban was used for support. The teams started with a simple basic kanban board and allowed the board to emerge and add complexity when necessary since “a less formal process and kanban board, less reluctance to change”. However they did use a CFD (Cumulative Flow Diagram) from day one and

recorded the number of issues in each column at the same time each day after daily meeting. This diagram helped measure cycle time and make predictions around their defect fix rate. They also

ems an

t b p i d t a w a t t a p t p

a c p e t f l s d s t t F fl

l d w P n a t

w s w a n i c p t w i t t p

( n i “ s

for code and services. Many of these teams have been using Scrum,

X. Wang et al. / The Journal of Syst

ried to achieve a better balance between demand and throughput y closely collaborating with Professional Service teams at weekly rioritisation meetings where they reviewed the current outstand-

ng issues and agreed on what they would tackle next. The meeting rove the issues that they added to the kanban board. At the end, he kanban board advanced significantly with more columns, buffer reas and WIP limits. Kanban allowed for issues to be added to the ork queue at any time rather than on a fixed cadence as in Scrum,

nd for releases to be decoupled from the sprint cadence so the eams have flexibility to release a patch at any point rather than at he end of the fixed-length sprint. Kanban also provided a mech- nism to quantitatively measure the effects of any changes in the rocess so that they are able to quantify both their demand and hroughput and ensure these stay balanced by changing explicit olicies.

Metrics were also carefully implemented in [ER27] where the pplication of lean helped to better manage defect resolution pro- ess of SumTotal Des Moines, a Learning Management System rovider that uses a Software as a Service (SaaS) approach to deliv- ring its product to customers. The company has various issues with heir defect resolution process. Defects were not getting resolved or a long time which upset the customers. The process did not end to efficient use of expensive developer time of the production upport team. With the help of the customer support team, the pro- uction support team was able to expose waste by creating a value tream map of the old process. The exercise revealed that a defect ook roughly 4 days to fix but spent 100 days waiting. To address hese issues, a new main queue was used, which was a First-In- irst-Out (FIFO) queue. A process to keep track of each defect as it owed through the development process was established:

“Each time a new defect was picked from the new FIFO queue, a developer pair was responsible for creating a card and placing it on the board within the In Progress column. As defects flowed out of In Progress into QA, the pair would move the card. Each day after stand up the team lead would take count of the number of defects in each category and mark them in a spreadsheet.” ([ER27], p. 271)

In this process, the most important metric to collect was current ead time; e.g. how long until a defect is fixed, which provided pre- ictability to the customer support team. Each day the team lead ould count the number of defects in six categories: Backlog, In

rogress, Blocked, In QA, Release Ready, and In Production. These umbers helped the production team determine their cycle times nd lead times for defects while their CFD helped them visualise heir defect flow.

Technical debt is a serious issue faced by many agile teams, hich seems to accumulate with the progress of iterations. [ER26]

hows how a very large Fortune 200 financial services company, ho had some successful pilots using agile and was in the midst of

company roll out, started to address this issue by making tech- ical debt visible through so called “code Christmas trees” located

n the walkway of the company. It evoked conversations and dis- ussions among developers and whoever is interested. To avoid unitive uses of the information revealed by the code Christmas rees, root cause analysis techniques like fish bone diagrams and 5 hys analysis were applied. The teams never stopped with a single

ndividual when searching for the cause of problems. Meanwhile, he company kept experimenting with new adaptations of their rees since it was believed that “it is easy to overlook big, visible roblems over time when they do not change materially.”

Continuous improvement was the central theme of [ER22]. FFM Field Force Management) project of one of the biggest inter- ational telecom companies had been facing several challenges,

ncluding no scope defined, no measurement of the team capability, push scheduling” mentality was pervasive, the trust of business takeholders in the team was minimal, and most team members

d Software 85 (2012) 1287– 1299 1295

were junior with little experience and exposure to agile methods. While the team started to use agile requirements analysis, they set up a kanban board to track each story as it flowed through the work flow. From the very beginning, they instilled the “Pull Scheduling” concept into the team, which managed the queue of items that should happen next; the team usually pulled an item off the top of the queue when planning work. The team pulled stories from the list in each iteration based on team capacity and capability. Con- tinuous improvement opportunities were identified through the application of value stream mapping, which revealed that there was too much waste in the deployment process flow. Team depen- dences, or segregation of cross functional teams, were identified as a cause. With team dependencies, it would be very difficult to deliver even a small feature set since it required a large amount of communication and coordination among teams. The team had also learnt the importance to pull the “Andon” cord to “stop-the-line” if a true iterative iteration (in which the development team produce a releasable application) could not be achieved.

Continuous improvement was also at the heart of Systematic’s experience. The result of the pilots in Systematic reported in [ER9] confirmed the general idea of using lean mindset as source for iden- tification of new improvements. Actually that was what happened in Systematic later on, which is the main subject of another two experience reports about the same company ([ER15, ER25]). View- ing lean as a “Scrum Troubleshooter”, Systematic used PDCA cycle with an A3 problem solving technique and the 5 why root cause analysis, to identify problems and opportunities for organisational wide improvement. Senior management involvement is significant in this case:

“Many of the adjustments implemented are characterized by being desired but beyond the control of the projects. Had the projects driven these improvements on their own, they might have dis- carded the ideas for adjustments because of the need to involve senior management or VP’s in the decision. When the problem solv- ing is initiated by senior management, the negative impact of the problem is viewed both from the project perspective and also from the business unit or company perspective. In this larger problems build high management larger perspective commitment, because the impact of the problem and the benefit of the solution is visible in a larger scale.” ([ER25], p. 174)

However, Systematic’s most important learning from the improvements during the past five years was the lean concept of Jidoka – respect that those who do a particular part of work, are those who are best qualified to improve how this work is done. Make people responsible for solving their own problems and ensure that management supports it.

As shown in these 13 cases, continuous improvement, or Kaizen, is at the core of this type of lean application. Agile methods also advocate continuous improvement, but do not answer how it can be implemented. Lean approaches, instead, offer specific directions (eliminating waste in software development processes, focusing on flow, etc.) and specific practices (kanban, value stream mapping, root cause analysis, etc.) to improve agile processes continuously.

5.5. From agile to lean

Four experience reports contain the lean application cases that can be classified in this category. They are published recently (within 2009–2011). Table 10 is the profiles of these cases.

Yahoo! runs websites visited by hundreds of millions of users a day. Hundreds of development teams at Yahoo! rely on one another

including Yahoo! Sports team ([ER29]). Yahoo! Sports team used a lot of code written by other teams. Team interdependency was a commonplace. It was said that “the worst customer for a Scrum

1296 X. Wang et al. / The Journal of Systems and Software 85 (2012) 1287– 1299

Table 10 The cases in the “from agile to lean” category.

Experience report no. Organisation name Business domain Lean elements applied

[ER29] Yahoo! Internet services Concept: Flow Principle: Eliminate waste, Reduce batch size Practice: MMF

[ER18] Inkubook Online photobook Concept: Pull Practice: Kanban board, Limited WIP, MMF

[ER20] Codeweavers Financial and insurance web services Concept: Flow Practice: Value stream mapping, Kanban board, Limited WIP, CONWIP, MMF

[ER21] (not revealed) (not revealed) Concept: Value Principle: Manage flow, Limit WIP, Visualise the workflow Practice: Kaizen, Visualise all work items, Same-size work itemsa

a

t s w s t a h t A p t o w w b t a t p b t a o t t s

t d a n b i t s t d i m l t k i

b d o a

Considered lean elements in the report but not included in our definition.

eam is another Scrum team”. Different Scrum teams had different print lengths, velocities and priorities. Often Scrum teams did not ant to be distracted during their sprint. However, sometimes a

porting event would occur before another team could commit o resolving a dependency, which forced the Sports team to find

solution themselves. Due to the intense release schedule, the igh demands of the product, and the many dependencies on other eams, the Sports team realised that they could not operate as usual. mong the transformational events that enabled the team to keep ace with the demands of the online sports world while main- aining team cohesion, motivation and high quality, an important ne was daily release. Before the 2010 World Cup, the Sports team as deploying large feature releases that occurred at least every 2 eek sprint. However, as the World cup event was set to begin, it

ecame apparent that there would always be something that had o be delivered daily. What enabled the team to achieve such an ggressive cadence, among other themes, was the concentration of he team efforts on two lean elements: a better flow and smaller ieces of code. The team reviewed the timing of specific handoffs etween teams everyday and made changes frequently to reduce he waste. They also focused on build automation as well as test utomation by having the developers and testers share test devel- pment responsibility and do their work in parallel. Over time the eam got better at identifying the MMF (Minimal Marketable Fea- ure) and delivering smaller increments of code to production to a mall subset of users.

Inkubook is an emerging player in the online photobook indus- ry. The journey of the Inkubook team to improve their software evelopment process is documented in [ER18]. The team initially dopted Scrum “by the book”. However, they entered into a chaotic o process stage when the mandate arrived that a product would e delivered in sixty days. When the schedule slowed down again,

n order to avoid burnout and staff turnover, the team moved back o Scrum, but this time it was really a “flow-based, iterationless ver- ion” of Scrum. After three months of being in the same “sprint”, he team recognised that flow was working well for getting things one and therefore they abandoned estimates, implicitly organiz-

ng around a WIP limit of two MMFs. Finally, after several more onths passed, the team accepted that they were using a work-

imited, pull-based kanban approach and updated the usage and erminology to reflect that fact. According to the team, “the use of a anban implementation survived a round of layoffs, an extreme change n team and management composition, and is still being used today”.

A similar case is reported in [ER20]. The title “From Chaos to Kan-

an, via Scrum” illustrates the evolutionary path of the software evelopment team in Codeweavers. The company is a UK business f approximately 20 people, delivering motor finance and insur- nce web services. The team comprises 8–10 co-located developers.

Using simple inspect-and-adapt cycle to adopt one practice a time, the team adopted Scrum practices first to tackle the chaos, then used value stream mapping and adopted kanban board to have a better visibility of upstream and downstream activities other than work in progress on the story board. Step by step following the kanban adoption, the team introduced limit to WIP, fine tuned it while the team began batching tasks into MMFs. Along the way, the team also adopted automated regression test and adapted stand- up meeting to hold it twice per day to ensure tasks were worked on as things developed. At the end, the development process assem- bles more a flow-like lean process rather than a time-boxed Scrum process. Meanwhile, as the focus on flow and throughput became more deeply ingrained in the development team, the developers’ view of the value stream gradually increased, from focusing only on the “in development” column to downstream to ensure the code developed was accepted and deployed to customers. Later still they looked further down-stream, helping customers to adopt the new services, and upstream, helping the business to decide what was needed and how to prioritise it. The focus was expanding even further into the company’s sales and marketing functions.

If the transition of Yahoo! Sports team, Inkubook and Codeweavers from agile to lean was an incremental or unplanned process, the experience documented in [ER21] was a more systemic move. The software development team (not named in the report) had run a Scrum-based development process for several years. The practices included continuous integration, automated, nightly build and deployment to QA servers, and suites of automated unit and integration tests. In spite of the processes and practices in place, the team was still challenged by the issues such as frequent mid- iteration changes and non correlated work items. That is the reason why the team decided to embark on a lean journey. After careful research, the team arrived at a set of core concepts for their flow- based development: schedule individual value-adding work items, define a workflow, limit work in process, same-size work items, establish holistic key performance indicators, visualise all the work and the entire workflow, and improve relentlessly. The team found that “it was fully possible to run agile software development without time-boxes by using a continuously updated work item priority queue instead”. The team’s experience shows that WIP limit is a good con- trol variable compared to controlling capacity and scope of work under high variability, and a single WIP limit (CONWIP) works well for the team.

The four cases in this category demonstrate that a comprehen- sive application of lean approaches can transform agile processes.

Starting with the application of lean techniques to improve agile processes, these organisations ended up in a situation in which lean processes become dominant and agile practices play the supporting role.

ems an

5

k a l c b 6 t a a a m b a d 5 m s

6

t s d 2 a a o a a f l “ a a

f d e ( i d t t t a b w m o

a c a

X. Wang et al. / The Journal of Syst

.6. Synchronising agile and lean

[ER30] reports an interesting case of one agile team and one anban team working in parallel in a synchronised manner to ddress different aspects of the same development process. Much ike most systems development teams, the teams in WMS, spe- ialised in interactive entertainment, were constantly working to alance large scale system feature upgrades that make up about 0% of the work with small-scale changes and bugs that cover he remainder of developers’ time. Over the time two coordinated gile/kanban teams were formed. The agile team run in a typical gile fashion. They were responsible for all large-scale projects that ffect the system including any architectural roadmap work that ay lead to structural changes to the software as a whole. The kan-

an team instead were responsible for all small feature requests long with bugs. The team used a kanban board to manage the evelopment process only, starting from the currently selected top

priority items and spanning all the way to a deployed queue. They aintained a cycle time and lead time metric integrated with the

tory point system of the company. WMS’s experience shows that:

“. . . running both [agile and kanban] processes in synchronization, and not blending them, has been highly valuable for our organiza- tion... The random interruptions and fire fighting of supporting a product in the field always seems to cause disruptions to Iterative teams. By adding a synchronized Kanban team alongside an Itera- tive team we have been able to even out our iterations and create a productive and healthy work environment where we are able to meet our customers’ needs.” ([ER30], p. 268)

. Discussion

As shown in the findings section, there can be various ways o apply different lean concepts, principles and practices in agile oftware development. Apart from one experience report that escribes non-purposeful combination of agile and lean practices, 9 out of 30 experience reports demonstrate the application of lean pproaches in agile software development with specific objectives nd strategies. The five strategies identified are: agile within, lean ut-reach; lean facilitating agile adoption; lean within agile; from gile to lean; and synchronising agile and lean. With the first two nd the last strategies, even though lean approaches are used to acilitate agile process implementation and effective use within arger organisational contexts, agile processes remain relatively pure” or intact. In contrast, the strategies of “lean within agile” nd “from agile to lean” result in processes that blend both agile nd lean elements, to various degrees.

Among these five strategies, the most common one is where dif- erent lean elements are used to improve existing agile software evelopment processes, evidenced by 13 out of the 30 selected xperience reports. As claimed in Poppendieck and Poppendieck 2003), lean concepts and principles have often been used as think- ng or sense making tools to guide the practice of agile software evelopment. The commonly cited lean concept and principle in hese reports are value and eliminate waste. It can be argued that hese two lean elements provide both target and route for con- inuous agile process improvement. Another discernible pattern cross these 13 experience reports is that, in the past, lean had een used more as a thinking tool but in a less conscious manner; hereas in more recent years, the trend has been to adopt more and ore concrete lean practices, as a conscious choice of the adopting

rganisations.

The kanban approach is also at the core of the strategy “from

gile to lean”. 3 out of the 4 experience reports in this category an be seen as detailed demonstrations of how kanban transforms gile processes. Although the kanban approach shares similarities

d Software 85 (2012) 1287– 1299 1297

to agile approaches, such as a prioritised feature list, it’s primary concern is to limit work in progress (WIP). However, there is a second significant difference between it and agile methods. The concept of a time-boxed (fixed duration) iteration is no longer used. Instead, the kanban board is used to set clearly visible limits to the number of tasks allowed to be in progress at any given time. There is no fixed number for each WIP limit but by measuring the lead time of individual tasks, the WIP limits and process itself can be optimised (Kniberg and Skarin, 2010). Kanban software develop- ment pursues the concept of continuous flow or what (Hiranabe, 2008) refers to as “Sustaining Kanban”.

What has been seen through the experience reports analysis is that the kanban approach suits particularly well to software main- tenance or support type activities where uncertainty is higher than in normal development activities and change is more frequent than that allowed by agile iterations. Another point worth making is that, when an agile adopting organisation is mature enough in using agile and especially lean practices, they have a tendency to move away from time-boxed agile processes to more flow-based lean processes, as several experience reports have shown ([ER18, ER20, ER21]). It is also interesting to note that these experience reports were recently published (2009 and 2010). This, together with recently practitioners-authored kanban books/articles, might indi- cate that moving from time-boxed agile processes to flow-based lean processes is a recent tendency in agile software development.

It is also worth noting that the lean concepts, principles and especially lean practices applied in the 30 experience reports are only a subset of what are defined in the relevant literature (as described in Section 2). Some lean elements, such as the princi- ple of waste elimination and the practicing of kanban, were found to be more often applied than others. It might be an indication that these elements complement agile processes therefore are a better fit within an agile context.

Last but not least, even though the six types of lean application were presented as distinctive, unrelated categories, and each expe- rience report was classified under one category only according to its primary focus, it does not mean that organisations can or do use lean in one manner only. The case of Systematic, the subject of three experience reports ([ER9] in 2007, [ER15] in 2009 and [ER25] in 2011) is a good example of an organisation applying lean in dif- ferent manners to suit different needs at different stages of agile maturity. Firstly the company used lean as a facilitating tool for a smooth Scrum adoption, then applied a lean mindset and analysis techniques as sources for continuous agile process improvement.

7. Conclusion

The recent focus shift from agile methods such as XP and Scrum to a lean approach in software development has been noticeable and evokes the interests of both research and practice alike. The objective of our study has been to investigate how lean approaches have been applied in agile software development. To explore this phenomenon, we have conducted a secondary data analysis of 30 experience reports containing real-world experiences of the appli- cation of lean approaches in agile software development. We have identified six types of lean application in these experience reports and categorised them in a more systemic way.

The findings of the study enrich our understanding of how lean can be applied in agile software development. Since the research on the broad topic of lean software development is considered a nascent area (Dingsøyr et al., 2008), we believe our study is an

important addition to this branch of research in general, and on the topic of combining agile to lean in specific. The definition of lean approaches in software development in terms of lean con- cepts, principles and practices brings certain extent of clarity to

1 ems an

t t d a i s r o c

e a E p a i t e t y

a i d a c p p r

a d m t h d y a o t p c c c l

A s

298 X. Wang et al. / The Journal of Syst

he understanding of lean software development. It contributes o a better conceptual basis for further studies on lean software evelopment. The lean application types we identified can serve as

thematic map for the researchers who intend to conduct more n-depth study of the phenomenon of what is termed as “leagile oftware development” in this paper. A significant area for further esearch could be to provide operational guidance to help devel- pers (i) map the various potential “leagile processes” to their own ontext and (ii) implement the selected process combination.

The practical implication of our study is that it reveals differ- nt strategies to apply lean concepts, principles and practices in gile software development. There is no one-type-fits-all solution. ach organisation should reflect on its own development context, roject objectives, and constraints as well as reflect on the various spects of agile and lean before embarking on the journey of “leag- le software development”. The potential strategies summarised in his study could provide them with some promising directions to xplore. However, how to effectively tailor these strategies to suit he specific situation and needs of the organisation is a challenge et to be addressed and therefore worth further studying.

One limitation of the research is that, since “agile” and “lean” re very broad and often poorly defined terms, their interpretations n the experience reports are often vague and the terms can mean ifferent things in different reports. Future research could examine gile and lean at the more detailed and operational practice level, omparing the commonality and contradiction of agile versus lean ractices. A detailed analysis of practice level comparisons was not ossible in this study as not all experience reports provided the equired level of detail.

Another limitation of our study is related to the secondary data nalysis method we applied, which leads to the weak basis of the ata source. It must be noted that researchers using secondary data ust be aware of issues related to data quality and accuracy. Since

he collected experience reports represented secondary data, we ad no control on the quality of data and especially the level of etails we desired. The 30 experience reports included in the anal- sis therefore were not equally informative and illuminative. In ddition, the organisations covered in these reports vary in terms f sizes and business domains they operate, which may pose poten- ial threat to the validity of the findings reported in this study. One otential avenue for future research would be to conduct primary ase studies which allow to design a better sampling strategy, to ollect more specific and in-depth data, and to explore the issues, hallenges and opportunities associated with the application of ean in agile software development.

ppendix A. The list of experience reports included in the econdary data analysis

[ER1] Hodgetts, P., 2004. Refactoring the development process: experiences with the incremental adoption of agile practices. In: Agile Development Conference, pp. 106–113. [ER2] Rand, C., Eckfeldt, B., 2004. Aligning strategic planning with agile development: extending agile thinking to business improve- ment. In: Agile Development Conference, pp. 78–82. [ER3] Parnell-Klabo, E., 2006. Introducing lean principles with agile practices at a fortune 500 company. In: Agile 2006 (Agile’06), pp. 232–242. [ER4] Poon, D., 2006. A self funding agile transformation. In: Agile 2006 (Agile’06), pp. 342–350. [ER5] Weyrauch, K., 2006. What are we arguing about? A frame-

work for defining agile in our organization. In: Agile 2006 (Agile’06), pp. 213–220. [ER6] Yap, M., 2006. Value based extreme programming. Agile 2006 (Agile’06), pp. 175–184.

d Software 85 (2012) 1287– 1299

[ER7] Fry, C., Greene, S., 2007. Large scale agile transformation in an on-demand world. In: Agile 2007 (Agile 2007), pp. 136–142. [ER8] Packlick, J., 2007. The agile maturity map a goal oriented approach to agile improvement. In: Agile 2007 (Agile 2007), pp. 266–271. [ER9] Sutherland, J., Jakobsen, C.R., Johnson, K., 2007. Scrum and CMMI Level 5: the magic potion for code warriors. In: Agile 2007 (Agile 2007), pp. 272–278. [ER10] Croix, A.D.S., Easton, A., 2008. The product owner team. In: Agile 2008 Conference, pp. 274–279. [ER11] Geras, A., 2008. Leading manual test efforts with agile meth- ods. In: Agile 2008 Conference, pp. 245–251. [ER12] Goos, J., Melisse, A., 2008. An ericsson example of enterprise class agility. In: Agile 2008 Conference, pp. 154–159. [ER13] Kinoshita, F., 2008. Practices of an agile team. In: Agile 2008 Conference, pp. 373–377. [ER14] Thomas, J.C., Baker, S.W., 2008. Establishing an agile port- folio to align IT investments with business needs. In: Agile 2008 Conference, pp. 252–258. [ER15] Jakobsen, Carsten Ruseng, Sutherland, Jeff, 2009. Scrum and CMMI going from good to great. In: Agile 2009 Conference, pp. 333–337. [ER16] Lacoste, F.J., 2009. Killing the gatekeeper: introducing a continuous integration system. In: Agile 2009 Conference, pp. 387–392. [ER17] Shinkle, C.M., 2009. Applying the Dreyfus model of skill acquisition to the adoption of kanban systems at software engineering professionals (SEP). In: Agile 2009 Conference, pp. 186–191. [ER18] Willeke, E.R., 2009. The inkubook experience: a tale of five processes. In: Agile 2009 Conference, pp. 156–161. [ER19] Maassen, O., Sonnevelt, J., 2010. Kanban at an Insurance Company (are you sure?). In: Proceedings of the 11th International Conference on Agile Software Development (XP2010). Springer Verlag, Trondheim, pp. 297–306. [ER20] Rutherford, K., et al., 2010. From Chaos to Kanban, via Scrum. In: Proceedings of the 11th International Conference on Agile Software Development (XP2010). Springer Verlag, Trond- heim, pp. 344–352. [ER21] Birkeland, J.O., 2010. From a timebox tangle to a more flexible flow. In: Proceedings of the 11th International Confer- ence on Agile Software Development (XP2010). Springer Verlag, Trondheim, Norway, pp. 325–334. [ER22] Zang, J.J., 2011. A never ending battle for continuous improvement. In: Proceedings of the 12th International Confer- ence on Agile Processes in Software Engineering and Extreme Programming, pp. 282–289. [ER23] Greaves, K., 2011. Taming the customer support queue. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 154–160. [ER24] Wijewardena, T., 2011. Do you dare to ask your HR Manager to practice KANBAN? In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 161–167. [ER25] Jakobsen, C.R., Poppendieck, T., 2011. Lean as a scrum trou- bleshooter. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 168–174. [ER26] Kaiser, M., Royse, G., 2011. Selling the investment to pay down technical debt the code christmas tree. In: Agile 2011 Con- ference. IEEE Comput. Soc., Salt Lake City, UT, pp. 175–180. [ER27] Prior, M., 2011. “You want to do what ?” Breaking the rules to increase customer satisfaction. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 269–273.

[ER28] Smits, H., Rilliet, K., 2011. Agile experience report transition and complexity at cisco voice technology group. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 274–278.

ems an

R

A

A

A

A

B

B B

B

C

C

C

C

D

D D

D

F

G G H

H

H

J

J

K L

L L

M

M

M

X. Wang et al. / The Journal of Syst

[ER29] Nottonson, K., 2011. Yahoo! Sports: sprint 100 & beyond. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 252–255. [ER30] Polk, R., 2011. Agile and kanban in coordination. In: Agile 2011 Conference. IEEE Comput. Soc., Salt Lake City, UT, pp. 263–268.

eferences

mbler, S.W., 2009. Scaling agile software development through lean governance. In: Proceedings of Software Development Governance SDG’09 – ICSE’09 Work- shop, Vancouver, Canada: IEEE Computer Society.

mbler, S.W., Kroll, P., 2007. Best practices for lean development governance. Avail- able from: http://www.ibm.com/developerworks/rational/library/jun07/kroll/ (accessed on 01.09.11).

nderson, D., 2010. Kanban – Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

nderson, D.J., Garber, R., 2007. A Kanban System for Sustaining Engineering on Software Systems. Available from: http://www.agilemanagement.net/index. php/blog/A Kanban System for Sustaining Engineering (accessed on 01.09.11).

arton, B., 2009. All-out organizational scrum as an innovation value Chain. In: The 42nd Hawaii International Conference on System Sciences, Waikoloa.

eck, K., 1999. Extreme Programming Explained. Addison Wesley, Reading, MA. oslaugh, S., 2007. An introduction to secondary data analysis. In: Secondary Data

Sources for Public Health: A Practical Guide. Cambridge University Press. radley, R., 2007. Push to Pull: How Lean Concepts Improve a Data Migration. AGILE,

13–17 August, pp. 365–370. harette, R.N., 2003. Challenging the fundamental notions of software development.

Cutter Consort. Exe. Rep. 4 (6). oad, P., Palmer, S., 2002. Feature-Driven Development. Prentice Hall, Englewood

Cliffs, NJ. ockburn, A., 2001. Crystal Clear: A Human-Powered Software Development

Methodology for Small Teams. Addison-Wesley, Reading, MA. onboy, K., 2009. Agility from first principles: reconstructing the concept of agility

in information systems development. Inform. Syst. Res. 20 (3), 329–354. all’Agnol, M., Janes, A., Succi, G., Zaninotto, E., 2003. Lean management – a

metaphor for extreme programming? In: Proceedings of the 4th International Conference XP2003, Genova, Italy, pp. 26–32.

eming, W.E., 1986. Out of the Crisis. MIT Center for Advanced Engineering Study. ingsøyr, T., Dybå, T., Abrahamsson, P., 2008. A preliminary roadmap for empirical

research on agile software development. In: Proceedings of Agile 2008 Confer- ence, Toronto, pp. 83–94.

ybå, T., Dingsøyr, T., 2009. What do we know about agile software development? IEEE Software 26 (5), 6–9.

agan, M.E., 1976. Design and code inspections to reduce errors in program devel- opment. IBM Syst. J. 15, 182–211.

oldratt, E.M., 1992. The Goal: A Process of Ongoing Improvement. North River Press. oldratt, E.M., 1997. Critical Chain. Aldershot, Gower. ibbs, C., Jewett, S., Sullivan, M., 2009. The Art of Lean Software Development: A

Practical and Incremental Approach. O’Reilly Media, Inc. ighsmith, J., 2002. Agile Software Development Ecosystems. Addison-Wesley

Longman Publishing Co., Inc., Boston, MA, USA. iranabe, K., 2008. Kanban Applied to Software Development: from Agile

to Lean. Available from: http://www.infoq.com/articles/hiranabe-lean-agile- kanban (accessed on 01.09.11).

alali, S., Wohlin, C.,2010. Agile practices in global software engineering – a system- atic map. In: Proceedings of the 5th International Conference on Global Software Engineering (ICGSE 2010). IEEE Computer Society, pp. 45–54.

oyce, M., Schechter, B., 2004. The lean enterprise – a management philosophy at lockheed martin. Defense Adv. Res. J.

niberg, H., Skarin, M., 2010. Kanban and Scrum-Making the Most of Both. InfoQ. adas, C., 2009. Scrumban – Essays on Kanban Systems for Lean Software Develop-

ment. Modus Cooperandi Press. iker, J., 2003. The Toyota Way. McGraw-Hill. iker, J.K., Hoseus, M., 2008. Toyota Culture: The Heart and Soul of the Toyota Way.

McGraw-Hill, New York, NY, USA. iddleton, P., 2001. Lean software development: two case studies. Software Qual.

J. 9, 241–252.

iddleton, P., Flaxel, A., Cookson, A., 2005. Lean Software Management Case Study:

Timberline Inc. Extreme Programming and Agile Processes in Software Engi- neering.

orien, R., 2005. Agile management and the Toyota way for software project man- agement. In: Proceedings of the 3rd IEEE International Conference on Industrial

d Software 85 (2012) 1287– 1299 1299

Informatics, (INDIN’05), Perth, Western Australia: IEEE Computer Society, pp. 516–522.

Mujtaba, S., Feldt, R., Petersen, K., 2010. Waste and lead time reduction in a software product customization process with value stream maps. In: Software Engineer- ing Conference (ASWEC), 2010 21st Australian, 6–9 April, pp. 139–148.

Naylor, J., Naim, M., Danny, B., 1999. Leagility: integrating the lean and agile man- ufacturing paradigm in the total supply chain. Eng. Costs Product. Econ. 62 (1), 107–118.

Ohno, T., 1988. The Toyota Production System: Beyond Large Scale Production. Pro- ductivity Press, Portland, OR.

Perera, G.I.U.S., Fernando, M.S.D., 2007. Enhanced agile software development – hybrid paradigm with LEAN practice. In: Proceedings of 2nd International Con- ference on Industrial and Information Systems (ICIIS 2007), Peradeniya, Sri Lanka: IEEE Computer Society, pp. 239–244.

Poppendieck, M., Poppendieck, T., 2003. Lean Software Development: An Agile Toolkit. Addison Wesley Professional.

Poppendieck, M., Poppendieck, T., 2006. Implementing Lean Software Development from Concept to Cash. Addison Wesley Professional.

Raffo, D., Mehta, M., Anderson, D.J., Harmon, R., 2010. Integrating Lean principles with value based software engineering. In: Technology Management for Global Economic Growth (PICMET 2010), 18–22 July, pp. 1–10.

Reinertsen, D., 1997. Managing the Design Factory: The Product Developer’s. Toolkit The Free Press.

Reinertsen, D.G., 2009. The Principles of Product Development Flow: Second Gener- ation Lean Product Development. Celeritas Publishing.

Robinson, H., 1997. Using Poka-Yoke techniques for early defect detection. In: Sixth International Conference on Software Testing Analysis and Review.

Schwaber, K., Beedle, A., 2002. Agile Software Development with SCRUM. Prentice- Hall, Upper Saddle River, NJ.

Serignese, K., 2011. A Sprinkle of Agile: A Dash of Lean. SPTechWeb. Smits, H., 2007. The impact of scaling on planning activities in an agile software

development center. In: Proceedings of the 40th Hawaii International Confer- ence on System Sciences (HICSS’07), Waikoloa.

Sugimori, Y., Kusunoki, K., Cho, F., Uchikawa, S., 1977. Toyota production system and Kanban system Materialization of just-in-time and respect-for-human system. Int. J. Product. Res. 15, 553–564.

Thimbleby, H., 1988. Delaying commitment (programming strategy). Software IEEE 5, 78–86.

VersionOne, 2010. 5th Annual State of Agile Development Survey. Available from: http://www.versionone.com/pdf/2010 State of Agile Development Survey Results.pdf (accessed on 01.09.11).

Wang, X.,2011. The combination of agile and lean in software development: an expe- rience report analysis. In: Proceedings of Agile 2011 Conference. Salt Lake City, UT. IEEE Comput. Soc., pp. 1–9.

Womack, J.P., Jones, D.T., 1996. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Simon & Schuster.

Womack, J., Jones, D., ROOS, D., 1990. The Machine that Changed the World. Rawson Associates, NY.

Xiaofeng Wang is a researcher in Free University of Bozen/Bolzano. Her research areas include software development process, methods, agile software develop- ment, and complex adaptive systems theory. Her doctoral study investigated the application of complex adaptive systems theory in the research of agile software development. Her publications include several journal and conference papers in major IS journal and conferences, including Information Systems Research (ISR), Journal of Information Technology (JIT), the International Conference on Information Systems (ICIS) and the European Conference on Information Systems (ECIS).

Kieran Conboy is an associate professor in Information Systems in UNSW, Australia. His doctoral research focused on agile methods for systems development as well as agility across other disciplines. Kieran’s other research interests include systems analysis and management accounting in systems development projects. Some of his research has been published in various journals and conferences such as Infor- mation Systems Research (ISR), European Journal of Information Systems (EJIS), the International Conference on Information Systems (ICIS). Prior to joining NUI Gal- way, Kieran was a management consultant with Accenture, where he worked on a variety of projects across Europe and the US.

Oisin Cawley is currently a doctoral researcher with Lero – The Irish Software Engi- neering Research Centre at the University of Limerick in Ireland. Previously he had

been working for 17 years in software development for mostly multinational com- panies, and has held many positions including Global Software Development and Application Support Manager. He holds a BSc in Computer Science from University College Dublin, Ireland and an MBA from Dublin City University, Ireland. He is a member of the Irish Computer Society.