Proceedings of the Federated Conference on DOI: 10.15439/2018F53 Computer Science and Information Systems pp. 969–973 ISSN 2300-5963 ACSIS, Vol. 15 Agile to Lean Software Development Transformation: a Systematic Literature Review Filip Kisˇsˇ and Bruno Rossi Faculty of Informatics Masaryk University, Brno, Czech Republic Email: {390917,brossi}@mail.muni.cz Abstract—Context: Lean development has been often proposed field in a systematic way [6]. To conduct the review on ”agile- as an adaptation to agile for scaling-up to larger contexts. Goals: to-lean” transformations, we followed the SLR guidelines by we wanted to better understand the ”agile-to-lean” transforma- Kitchenham and Charters [6]. tion, in terms of: i) reported benefits, ii) challenges faced, iii) met- rics used. Method: we performed a Systematic Literature Review A. Needs for an SLR (SLR) about ”agile-to-lean” transformations. Results: reduced lead time, improved flow, continuous improvement, and improved ”Agile-to-lean” is a less explored research area compared defect fix rate were the main reported benefits. Adaptation to lean to ”waterfall-to-agile” (e.g., Middleton [7]). There are other thinking, teaching the lean mindset, identification of the concept SLRs performed on lean methodologies but they are focused of waste, and scaling flexibility were the main challenges. Lead time was the most reported metric. either at the business level [8], or at the level of metrics used in lean / agile software projects within industry [9]. One literature I. INTRODUCTION review on the ”agile-to-lean” transformation [10], focused on categorizing and comparing the transformations including 30 OWADAYS, many software organizations use agile experience reports. Compared to the study by Wang et al. [10], methodologies for their software development processes, N our study is more focused on benefits, challenges and metrics. finding benefits for process improvement [1]–[3]. Lean soft- ware development [4] has been used to optimize development B. Research questions processes, mainly due to the concept of waste reduction in- RQ1. What are the benefits that have been reported after the volved in the optimization of all activities producing inefficien- adoption of lean principles in the context of an ongoing cies [4]. This view is complementary to agile principles, more agile development process? focused on all activities that create value for the customer. RQ2. What are the challenges that have been reported after The term lean software development originated from the the adoption of lean principles in the context of an work of Mary and Tom Poppendieck [4]. Lean software ongoing agile development process? development can be characterized as a combination of lean RQ3. Which metrics have been used to measure the ”agile- manufacturing with the lean IT principles and their application to-lean” transformation? into software development [5]. This approach is driven by a series of seven principles: eliminate waste, decide as late as C. Search strategy & study selection possible, amplify learning, deliver as fast as possible, empower We have collected research papers available online in three the team, build integrity in, and see the whole [4], [5]. Many authors suggest that lean thinking can be used as digital repositories: Web of Science (WoS), IEEExplore, ACM ”lean guiding principles to implement and adopt agile development Digital Library (DL) (on 2017-06-10, Fig. 1). We used software development OR agile transformation OR lean trans- practices [4]. Wang [1] has identified and analyzed various formation” combinations of lean and agile as reported by previous re- as search string, as we preferred to start with a search: lean principles can either be used to adapt existing more general query and filter out results later. agile practices or to scale-up the agile software development The first stage of search strategy (automated search in practices [1]. However, there is no universal type of ”agile- online databases) included only studies written in English. The lean” combination that can be used for every situation [1]. EndNote reference manager software was used for excluding The goal of this paper is to identify benefits, challenges, and duplicates and narrowing down the initial search results from metrics used in ”agile-to-lean” transformations. Identification 1,787 to 856 research papers (Fig. 1). We have included of such factors can allow to better understand ”agile-to-lean” journals and conference papers published since 2003, after the transformations, providing more evidence about how such work of Mary and Tom Poppendieck [4]. transformation is happening. In the second stage (filtering based on title and abstract), multiple search criteria have been applied such as the exclusion II. SLR of papers that involved lean manufacturing or any other subject A Systematic Literature Review (SLR) is a process which areas outside software engineering. A total of 131 papers have summarizes, organizes, and documents previous research of a passed the second stage of the search strategy (Fig. 1). IEEE Catalog Number: CFP1885N-ART c 2018, PTI 969 970 PROCEEDINGS OF THE FEDCSIS. POZNAN,´ 2018 Stage three (full-text filtering) was performed manually going through the remaining entries. 18 papers were included based on full text reading. Quality criteria (section II-D) were applied to find papers involving organizational transformation from agile to lean. After quality assessment, a total of 8 papers were included in the final SLR list (Fig. 1). Fig. 2. Benefits mapped to papers. O = benefit reported in the paper lead times contributes to flow improvement so that activities are organized continuously, enabling smooth deliveries to the customer. Middleton and Joyce [2] also state that they Fig. 1. SLR papers selection process have experienced 47% less variance and on average 37% shorter lead time to deliver software, which is a significant D. Study quality assessment criteria improvement. Moreover, Walter et al. [27] have recorded an enhancement of approximately 70% which can dramatically After 18 papers were selected (Table I), we have conducted increase the time-to-market responsiveness. Early feedback a quality assessment process to select the papers fitting the from the customer implies frequent integration, an important exact purpose of this research: factor to improve the software product quality. C1. Is the agile methodology at the initial state of the 2) Improved flow: Improved flow was reported in four cases transformation? [12], [19], [23], [27]. Walter et al. [27] have discovered that C2. Is the reported company making a transformation to- the secret to improve the flow is to control Work-in-Progress wards lean software development practices? (WiP) items. By reducing the number of simultaneous tasks C3. Does the paper provide metrics used for the transfor- they have reached lean flow state with constant throughput. mation and states clear outcomes? Flow can be seen as the number of WiP items, so that Papers were given points from 0 (meaning ”no”), 0.5 lowering the number of such items can speed-up the whole (”partly”) to 1 (”yes”). All papers reaching the score marked process and more features can be implemented and eventually as ≥ 2.5 for sum(C1,C2,C3) (Table I) were included for delivered. Therefore, to speed-up the flow, it is essential to conducting the literature review (Table II). remove waste in the inventory to avoid piling up user stories. Rodr´ıguez et al. [19], Middleton and Joyce [2] state that TABLE I QUALITY ASSESSMENT OF THE SELECTED PAPERS limiting WiP is an important element for achieving flow. Limited WiP leads to more organized activities so that the SLR Article C1 C2 C3 Score improved flow can lead to smooth deliveries [19]. Additionally, S1 Hayata et al. [11] yes no no 1.0 S2 Jakobsen and Poppendieck [12] yes yes yes 3.0 continuous integration and test automation significantly sup- S3 Kuusela and Koivuluoma [13] yes partly no 1.5 ported the flow by frequent and smaller builds [19]. According S4 Middleton and Joyce [2] yes yes yes 3.0 S5 Misaghi and Bosnic [14] yes yes yes 3.0 to Swaminathan and Jain [23], tracking and acting on the S6 Paasivaara et al. [15] no yes yes 2.0 visual indicators provided by the cumulative flow diagram S7 Perera and Fernando [16] yes yes yes 3.0 S8 Petersen and Wohlin [17] yes yes yes 3.0 helped to maintain a uniform flow. Moreover, it also helped S9 Rodr´ıguez et al. [18] no yes yes 2.0 to identify and remove bottlenecks and improve the efficiency S10 Rodr´ıguez et al.[19] yes yes yes 3.0 S11 Samanta et al. [20] - yes yes 2.0 of the process. This increase in efficiency also enforced rapid S12 Schnitter and Mackert [21] yes partly partly 2.0 development and continuous improvement to software delivery S13 Sjøberg et al. [22] yes no partly 1.5 S14 Swaminathan and Jain [23] yes yes yes 3.0 [23]. Jakobsen and Poppendieck [12] have improved the flow S15 Trimble and Webster [24] no yes no 1.0 of story implementation from 30% to 60%. The flow was S16 Vilkki [25] no yes no 1.0 S17 Viswanath [26] no yes yes 2.0 improved in various areas such as test, development, project S18 Walter et al. [27] yes yes partly 2.5 start-up and customer activities related to contracting and ongoing clarifications, major benefits for the company. 3) Continuous improvement: Four studies [2], [12], [23], III. SLR RESULTS [27] experienced continuous improvement as a benefit of their A. Benefits (RQ1) transformation. In Swaminathan and Jain [23], the story rate To answer our first research question (RQ1, Fig. 2), we have per iteration was used as a metric to measure continuous im- reviewed and categorized the reported benefits. provement, which was proved by the evidence of cumulating 1) Reduced lead time: The most common benefit that has story points.