Lean Software Development: A Systematic Review Henrik Jonsson Etteplan Box 1089, SE-721 27 Västerås, Sweden +46 70 680 33 41 henrik.jonsson@etteplan.com ABSTRACT How can management principles originating from the Toyota production system help us build software? This systematic literature review identified eight major seminal sources for so called lean software development and compared how they interpret these principles for use in software development, and what it means for different software engineering disciplines. Although multiple set of principles were found, they were largely in agreement. However, there are important differences in what they emphasize and how useful they are for different disciplines. Out of 30 peer reviewed papers found, seven reported empirical results from various industries. Reduced lead time, higher productivity, lower cost and higher customer satisfaction were some of the positive results reported. The need for management commitments, requirements of change in organization and the office space and incompatibility with traditional project management was identified as main impeding factors for introduction of lean software development. The promising initial results, but low number of studies, suggest that this is an area that should be investigated more in detail to find ways of developing software more successfully. Categories and Subject Descriptors A.1. [Surveys], D.2.9 [Software Engineering]: Management, K.6.1 [Management of computing and information systems]: Project and people management General Terms Management, Human Factors, Standardization, Theory Keywords Lean software development; Systematic Literature Review; Software Process Improvement 1. INTRODUCTION The software industry is a relatively young business, actively searching for new ways of developing products. The turn-over rate for both technology and methodology is very high. New (small scale) paradigms succeed each other, sometimes almost like fashion. One decade is it object-oriented programming that is hot, another it is 4G languages. On a methodology plan, sequential waterfall ish methods dominated before, to be replaced by iterative methods (e.g. spiral and unified process). Permission to make digital or hard copies of all or part of this work for classroom use is granted without fee provided that copies are not made or distributed outside the group of participants in the Research Methodology course, and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission from the author. Research Methodology Course Mini Conference (IRCSE 12), November, Västerås, Sweden Copyright 2012 Henrik Jonsson, Etteplan. Today is agile methods the hot topic [7]. What will the next wave be? At the same time the software industry is often described as an industry in crisis, with some reputation of bad quality and costly project delays. All of us have experiences of software tools that fail to help us to perform its intended function. According to the Standish Groups 2009 report only 32 percent of IT projects considered successful. To increase the success rate many initiatives have been taken, for instance the Capability Maturity Model (CMM) [20] that has been created to help organizations to build up a mature organization able to deliver quality software efficiently. Middleton and Sutton [16] compares the software industry with other more mature industries, in particular the automotive one. In the beginning car manufacturing was a craftsmanship performed by a few talented engineers. The same reliance on individual skill was (and is still) found in small software firms. To scale up production however, more disciplined ways is generally needed. In the automotive industry, Henry Ford s mass production paradigm soon outperformed most craft firms. In analogy, so called plan-driven methods have dominated the large-scale software industry for a long time. Middleton and Sutton show that CMM and the principles of mass production have much in common. In the 80 s, it was realized that Toyota developed cars much more efficiently and with higher quality than the American ones, with steadily growing marking shares. This phenomenon was thoroughly studied by researchers at the Massachusetts Institute of Technology (MIT). What they found was a new management and production philosophy that they labeled lean [28]. For the automotive industry, up to doubled productivity was reported for the best Japanese manufacturer following these principles, compared to American ones. Although these figures have been questioned [8], the lean principles are now applied in most car industries, and their use is spreading to other domains, now also including the software industry. However, since software has several unique features compared to physical products, such as an intangible design, very complex logic, high design cost but low production cost, it is not obvious how to translate these production principles to the software industry. The purpose with this paper is to give the reader a scientific overview of the current status of lean in software development, as basis for further research and applications in industrial settings. It is based on a systematic literature review of the current scientific literature. The main contribution of such secondary (meta-) study is to summarize and aggregate existing findings by others, rather than presenting new results. This serves as an important introduction for all researchers and practioners starting a scientific endeavor within this field. In addition, since individual case studies are the most common and valuable form in empirical software engineering research focusing on whole processes several studies must be compared to be able to draw more general conclusions.
The specific research questions for this literature study were RQ1. Which are the seminal sources defining lean software development? RQ2. How is the lean principles interpreted when applied to software development by the seminal sources? RQ3. What empirical evidence exists for lean in software development in peer reviewed literature? RQ4. Which impediments have been identified? RQ5. What are the characteristics of organization and projects have lean been applied to? The remaining part of the paper is organized as follows: Section 2 presents previous similar work. Section 3 details the research method. Section 4 presents the results, section 5 discusses the findings and section 6 concludes and gives further directions for research. 2. Related Work In one of his papers [15], Middleton provides a literature review of lean in software development, but not as exhaustive and systematic as this one. He discusses the roots of Lean from 1950 and points out that there are important differences between Japanese and Western management cultures, and concludes that there is a clear need for more rigorous case studies. In another literature review Wang et al. [27] studied the application of lean concepts in combination with agile principles. They found that lean concepts have been successfully used both non-purposefully and intentionally in combination with agile methods. It is therefore clear that agile and lean have several things in common. Empirical studies of agile methods have been summarized by Dybå and Dingsøyr in a large systematic literature review [7]. They revealed that it was easy to find rigor studies in the field and although agile methods can provide higher team and customer satisfaction, several shortcomings have also been identified, including the heavy reliance on a highly available and present customer, and individual skills. Evidence was also found that agile methods not necessarily are the best choice for large projects. 3. RESEARCH METHOD This study was performed as a systematic literature review with an approach and a protocol according to the guidelines given by Kitchenham [10]. Initial primary papers were searched using the EBSCO Discovery Service including the databases ABI Inform, ACM Digital Library, SpringerLink and ScienceDirect and IEEE Xplorer, October 11, 2012. The search terms were the combination of LEAN and SOFTWARE in the all metadata fields, and with subject terms "computer software development", "software engineering", "software process" or "computer science". Only English peer reviewed sources were included. Papers only mentioning lean in some other context in the abstract or author line was excluded. When in doubt the, full paper was reviewed to determine whether it should be included or not. To answer research question 1 [RQ1], each included paper was searched for referenced seminal papers about lean. Seminal paper was in this study defined as a reference made when explaining the background for the study (mainly found in the introduction part of the papers). As a comparison, number of citation was also obtained from Google Scholar (October 25, 2012). To answer RQ2, the seminal sources identified were scrutinized to find summarizing principles as well as more practical examples and guidelines to be applied by different disciplines in software engineering. To answer RQ3 and RQ4, each primary paper was searched for empirical evidence, i.e. results from experiments or case studies. Based on the level of details given about the environment and case study setup, as well as the details of quantitative and qualitative data, the paper quality were assessed. In papers where empirical evidence was found, the environment (organization size, domain, size of code, distributed) was identified [RQ5]. 4. RESULTS 4.1 Primary papers found In the first database lookup 140 hits were found, including six duplicates. After reading through the abstracts (and full paper when in doubt) 30 peer-reviewed journal and magazines papers remained. Out of these only eight contained empirical evidence, either quantitative results, qualitative results, or both. The other papers were more general descriptions and discussions about the potential of lean principles in software engineering. In subsection 4.5 and Table 2 below the papers which included empirical evidence are further analyzed. 4.2 Seminal sources By looking at which references the 30 primary papers made when explaining lean and lean software development, the seminal sources (books) were identified. Table 1 summarizes the number of references to each of the identified seminal papers. The seminal sources were divided into those that refer to descriptions of Lean Production in general and those that refers to descriptions of Lean software development in particular. Total number of references to these sources in Google Scholar is also reported. Note that the latter includes references from other sources than peer-reviewed papers as well as references not focusing on software. From these results it is obvious that Womack s books have been the most influencing on the lean software movement, but both Womack and Liker refers back to Ohno and other Japanese sources. When it comes to interpretation of lean in software development, the Poppendiecks are the far most cited source, with three books in the area. Andersson has also become popular, mainly for his work on the Kanban project management method, which can provide benefits compared to the very popular agile method Scrum. Middleton and Sutton are less cited but provide more rigor scientific evidence (see primary papers) and more concrete guidance on how to apply lean concepts in the software business. Coplien and Bjornvig also give more concrete guidance to software, but with main focus on lean architecture. Morgan s master thesis from 1998 was the oldest reference seminal paper found, but the work of Ayoyama, indentified as a primary paper, shows that lean principles in software has even older roots from the Japanese industry.
Table 1: Seminal sources for lean Author Ref. References from primary papers Google Scholar references Lean Production Womack [28] 8942 14 [29] 3694 Liker [11] 5 1723 Ohno [18] 2 2588 Lean Software Development Poppendieck [20] [23] [24] 4.3 Basic lean concepts This section summarizes and discusses how the seminal papers define lean in terms of values and principles [RQ2]. 4.3.1 Concepts from Lean Production Liker s [11] starting point for explaining the The Toyota way is the 4P s: Philosophy, Process, People/Partners and Problem Solving. The main Philosophy is to add value to customers and society. The Process parts emphasizes that we have take the right process path to reach our goals efficiently, and also to have a long-term perspective. The People and Partner part, also known as respect for humanity, emphasizes that production and development is a learning and challenging human environment. Finally, the Problem solving part stresses the importance to continuously solve root problems and continuously learn. Liker then provides us with 14 principles, most usable for management: L1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals. L2. Create a continuous process flow to bring problems to the surface. L3. Use pull systems to avoid overproduction L4. Level out the workload (heijunka). (Work like the tortoise, not the hare.) L5. Build a culture of stopping to fix problems, to get quality right the first time. L6. Standardized tasks and processes are the foundation for continuous improvement and employee empowerment. L7. Use visual control so no problems are hidden. L8. Use only reliable, thoroughly tested technology that serves your people and processes. L9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. L10. Develop exceptional people and teams who follow your company s philosophy. L11. Respect your extended network of partners and suppliers by challenging them and helping them improve. L12. Go and see for yourself to thoroughly understand the situation (genchi genbutsu). L13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (nemawashi). L14. Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen). 13 525 183 27 Andersson [1] 6 58 Middleton&Sutton [16] 3 33 Coplien&Bjornvig [5] 1 27 Morgan [16] 2 4 In contrast, Womack and Jones [29] summarize Lean Thinking by five important concepts (text in brackets are this paper s author s summary): W1. Value [Ensure that we understand value from the customer s perspective, and take time to explore this with our customers] W2. Value Stream [Identify process steps that create value and map them in time to bottlenecks and unnecessary waiting times] W3. Flow [Try to create a even and steady flow of material and information] W4. Pull [Only create value on demand on the customer (justin-time)] W5. Perfection [Continually work to improve quality and the process flow] Comparing both definitions Womack s concepts are more concise and technical (process-oriented), whereas Liker s principles include the same concepts, give more details and focuses more on the human side of it. 4.3.2 Concepts for lean software development Whereas the above principles are for lean production and development in general, this subsection presents and analyses how the seminal sources interprets them for software development in particular. According to their homepage, Poppendiecks principles for Lean Software Development are P1. Optimize the whole (Focus on entire value stream; Deliver a complete product; Think long term) P2. Eliminate waste (Build right thing; Learn; Eliminate trashing) P3. Build quality in (Mistake-proof process; Break architectural dependencies) P4. Learn constantly (Predictable performance is driven by feedback; maintain options, last responsible moment) P5. Deliver fast (Rapid delivery; High quality, low cost are fully compatible; Queuing Theory applies, Managing workflow is easier than managing schedules) P6. Engage everyone (Use semi-autonomous teams; provide challenges and feedback; work for a purpose) P7. Keep getting better (Failure is a learning opportunity; Standards exist to be challenged and improved; use the scientific method). As stated above Poppendiecks principles are in line with Liker s principle, but not as concretely expressed. Björklund s [3] thorough analysis of Poppendiecks principles [20] showed that they were largely in agreement with Liker s lean principles. One difference found was that Liker emphasizes standardization of working methods very important, whereas the Poppendiecks more focus on self-determination. The main problem with Poppendiecks principles, according to Björklund, is that they do not describe how work should be documented and when issues should be discussed. Andersson states the following principles for software Kanban [1] (figures in parentheses refer to corresponding principle in Liker): A1. Visualize the workflow (L7) A2. Limit work in progress (L3, L4, P5)
A3. Manage flow (L2,L4) A4. Make process policies explicit (L6) A5. Improve collaboratively (using models and the scientific method) (L14, P7) Compared to Poppendiecks principles (P1-P7 in the above list) these are more practice oriented, and more focused on the project management issues, as described in Kanban. The mapping between Liker s principles (L1-L14 in above list) and Andersson s shows that most of the principles were covered. However, Andersson do not emphasize long-term decisions [L1] and just like the Poppendiecks he does not mentions that decisions should be taken slowly by consensus [L13]. This likely reflects a difference between the Japanese and Western cultures. The lacking reference to L8 may reflect that both Poppendieck and Andersson comes from agile environments where technology turn-around times are very rapid. For safety-critical applications this principle can be very relevant however. Andersson is also one of the founders of the Lean Software & Systems Consortium (www.leansystemsociety.org) promoting lean in many domains, including software. Their current preliminary principles are S1. Follow a Systems Thinking & Design Approach S2. Emergent Outcomes can be Influenced by Architecting the Context of a Complex Adaptive System S3. Respect People (as part of the system) S4. Use the Scientific Method (to drive improvements) S5. Encourage Leadership [in contrast to management] S6. Generate Visibility (into work, workflow, and system operation) S7. Reduce Flow Time S8. Reduce Waste to Improve Efficiency These are in line with the above principles, but on a very high level, not as concrete as Liker s. The multiple references to scientific methods are analyzed more in the Discussion section below. Coplien and Bjornvig summarize the lean principle ( secret ) as this rule of thumb: everybody, all together, from early on. Middleton and Sutton do not try to create an own definition, but discusses the implications of the lean concepts from Womack and Jones when applied to software development, which will be analyzed more in the next subsection. 4.4 Lean in the software life-cycle So, what does lean mean to different disciplines within software development? According to the seminal papers, a very important thing is to ensure to add customer value and to create only artifacts that helps in other steps of the process. The Poppendiecks also stress that it is the appropriate to adopt practices from others. The important thing is to follow the principles and create practices in line with these principles that suites the local situation. With that in mind, the following section summarizes the major points for the different disciplines involved in the software life-cycle. 4.4.1 Requirement engineering Middleton and Sutton argue that traditional requirement engineering should be rethought as a search for custom values. More focus on building the right thing than to just build the thing right. Several seminal sources refer the Kano Model that categorize product attributes (requirements) as must-be (often not explicitly told by the customer), performance factors, and attractive factors (exciting features). Concrete guidelines of ways to express requirement in an effective way, that both can be understood by the customer and effectively be used in subsequent steps are given. Middleton and Sutton argue for a tabular driven requirement representation called Software Cost Reduction method (SRC), appropriate for real-time systems. Coplien and Bjornvig argue for Use Cases, more suitable in more (human) interacting software. Poppendiecks also refers to such specification techniques. All of them stress the importance of Domain Modeling as a tool to understand the customer space and build high integrity products, easy to maintain. 4.4.2 Architecture Besides stressing that the user domain should be reflected in the software architecture, in order to build software with high integrity. Middleton and Sutton refer to Parnas principle of information hiding [19] as an important lean software design practice. They, together with Coplien and Bjornvig, argue that building an architecture with a few method-rich objects are central lean ideas, by referring to Parna s work and a method called DCI, respectively. 4.4.3 Programming On a lower implementation level, Middleton and Sutton discuss the lean principles implications for choice of programming language. They conclude that for high integrity software it is more lean to select a language with proven ability to be statically verified, such as SPARC ADA, than a cooler more powerful language like C++. This is in line with Liker s principles to choose proven techniques that serve the purpose of optimizing the whole process flow [L8]. Design-by-contract, enabling local verification of input and output data, sometimes even before the code has been run is in line with L5 and the lean jidoka practice, where a machine is devised to automatically detect worker errors and stop the item (code in this case) to be passed away to next step. 4.4.4 Testing and verification Poppendiecks argue much for a test-first strategy such as Test Driven Development from the agile method Extreme Programming [3]. At the same time they point out that testing is an activity that does not directly contribute to customer value but is necessary to ensure quality. Hence testing is classified as necessary waste. Middleton and Sutton points out that that much of the testing (and rework) effort can be reduced much by selecting an easy-to-verify requirement and architecture as described above. 4.4.5 Integration Building software is not the same as assembling cars. For lean principles to work, we must break down the work in small pieces, preferably of similar size. For software development this essentially means that we must build the system incrementally. To be able to maximize the flow we also want concurrent development, i.e. several persons are working at the same time with the source code. In this context integration plays a crucial role. To be able to stop defects as early as possible Continuous Integration [3] is essential. Both the Poppendiecks and Middleton and Sutton refer to Microsoft s Synch and Stabilize process [6] as an example of a process with frequent integration points and high quality demands.
4.4.6 Project management Management of flow is the keyword for lean project management, and managing workflow is a lot easier than managing schedules according to Poppendiecks. Andersson s software Kanban method emphasizes that limiting work in progress is the important thing for a small team. Visual control [L7] is also an important feature of Kanban as well as the agile Scrum method. The role for a product and project manager changes in a lean organization. Poppendiecks talks about a product champion whose role is to align all project members, work and flow towards producing customer value. Emphasis is more on leadership (set direction, align and motivate people) rather than traditional management (plan, organize, delegate, track and control). Liker s principles also have a lot to say about leadership [L9, L10, L12]. 4.5 Empirical evidence So what empirical evidence for and against lean in software development was found by reviewing the primary papers (Table 21) and the seminal papers (Table 1) [RQ3 and RQ4]? Middleton et al [14] studied an organization that had several problems with project resource allocation and tracking, with too high costs for development. Before the lean initiative they had a complex process with a huge number of steps, handoffs and review meetings. They introduced a number of changes in the spirit of lean principles, and managed to substantially improve their processes. According to an informal estimate by senior staff the productivity increased about 25 percent. The staff mostly agreed that lean ideas do apply to software development and did not make things worse. Schedule slippage fell from months or years to at most 4 weeks. The defect fixing time was decreased by 65 80 percent and the amount of defects that had to be fixed a second time dropped by 50 percent. Customer response to the first lean releases was overwhelmingly positive as the organization managed to deliver exactly the functionality that they needed. The results reported are very positive, but the absence of detailed data makes it hard to judge the reliability of the study. In 2001, Middleton performed a two-team experiment in industrial setting, with the main focus on increasing the flow between the analysts and the developers, and applying the principle to stop to fix problems immediately [13]. The frustration with this new practice was at first very frustrating, but gradually the participants became much more careful in their work. This practice was more problematic in the team with more experienced and highly educated workers. The practice could not be sustained Table 2: Primary papers with empirical evidence Ref Authors Primary lean principle/practice Organization and project characterization studied [25] Sjøberg, Johnsen, Solberg A2 Limit work in progress Document management system, 100 developers, distributed [15] Middleton, Joyce L2, L3, L4, L5, L6, L7,L8 Large organization (BBC), Webmedia, 9 team members, co-located [21] Petersen, K; Wohlin, C L3, L4, L7 Large organization (Ericsson), telecom, >5MLOC, distributed [9] Kindler, Noah B.; Krishnakanthan, L1, L2, L4, L5, L6 US retail bank, European retailer Vasantha; Tinaikar, Ranjit [14] Middleton, P; Flaxel, A; Cookson, A L2, L4, L5, L6, L7, W1, W3 Construction industry software, 160 developers [13] Middleton, P. L2, L5 Large organization, financial/management systems, Co-located teams Aoyama, M Large organization (Fujitsu), 5 MLOC, for long due since it challenged organization hierarchy and promotion patterns too. It also uncovered too much problems, and the learning and improvement program was hindered by company rules. In a third paper, Middleton et al [15] studied an large organization that applied seven of Liker s principle, with practices such as Kanban boards, information radiators, test-driven development, and minimal marketable features (MMF), on a nine-person team. By introducing those practices, the time to deliver features was reduced by in average 37 percent with 47 percent less variance. The mean time for the part the development team had full responsibility declined by 73 percent and number of releases per month from 2 to 16. In the continuous improvement program the number of raised issues rise, but the blocking time of each issue fell. Obstacles that were identified were 1) need for office rearrangements 2) lean does not work well together with traditional project management, such as milestones and Gant charts. 3) The rest of the organization may feel that the IT team goes beyond their remit when proactively searching for true customer value. In a study from a retail bank and a retailer, Kindler et al [9] claim that the cost of application development and maintenance can be reduced by 8 to 40 percent, but since no the underlying data presented the reliability of this report is low. Obstacles to the lean transformation identified were the required change of technical system, organization, roles, metrics and incentive programs. They conclude that lean transformation requires a substantial investment of time and long-term commitments from upper management. Petersen and Wohlin [@Petersen] showed that how cumulative flow diagrams and control charts, often used in lean production, can be useful for software practioners to identify bottlenecks in the process. Sjøberg et al studied a developing organization that went from agile Scrum to lean Kanban, with data from more than 10,000 work items [25]. Their data suggests that the average lead time and variation of lead time was reduced, but the lead time was at the same level in the period when the switched method. In terms of productivity (KLOC per developers), it increased by 21 percent for project backlog items, but decreased by 11 percent for bugs. This paper shows how difficult to measure productivity. The qualitative evaluation by interviews showed that Kanban was preferred to the time-boxed Scrum. Time-boxing and the need for time estimates was perceived to be artificial and unnecessary. Full
allocation of people (testers in particular) was more easily done with Kanban. 5. DISCUSSION 5.1 Limitation of this study With all literature studies, there is a risk of a publication bias, that is negative results are often not published. However, since the basis for this study was peer-reviewed scientific papers with explicit requirements to be objective and balanced this is as the best we can get. Another limitation of this study is that not all conference papers were included. As conference papers are a very common way to present results in the computer engineering field, important empirical evidence for and against lean concepts in software development may have been missed. On the other hand, journal papers have more credibility in general. Assessment of quality could have been more rigid and less subjective by following a more formal protocol as in [7] and by including a second researcher to validate the result. 5.2 Lean and science Interestingly, all of the lean software seminal papers refer to science in one way or another. When referring to the scientific method, this usually means a systematic way of formulating a hypothesis, testing it out and evaluating. It is common to refer to the PDCA (Plan-Do-Check-Act) cycle, when discussing how teams and organizations should work to continuously improve themselves. In an ideal lean organization all employers should be taught and apply scientific thinking, at least in small scale, applying it their own local situation, in order to improve the process as a whole. Lean recognizes that the search for problems and solutions is a very fundamental human capability, which should be exploited rather than suppressed. Another common scientific reference is to the Theory of Constraints and Queuing theory, which is used to explain why it is important to get an even flow of material and activities to reduce total lead time. This also motivates the wish to reduce variations, both in batch sizes and individual performance. In lean organizations gathering and statistical analysis of performance data plays a central role, in particular in the form of cumulative flow diagrams and control charts showing the flow and variations. Both Poppendiecks and the LeanSSC have direct references to Systems Thinking, i.e. the process of understanding how things influence one another within a whole [Wikipedia]. From a software development perspective this means that we should not just try to optimize a part of the process, for instance software testing, but instead look how the parts can be made fit together. To reduce the risk of sub-optimization we must also look beyond the software development team, optimizing the whole process from sales to delivery and supporting services such as human resources. In some organizations, including truly agile ones, it might even be natural to model the software development using Complex System Theory with several independent actors interacting to form sometimes stable, sometimes chaotic structures. One of the LeanSSC principles actually refers to complex adaptive systems and emergent outcomes. Finally, it is also interesting to see that lean thinking brings in much about sociology and study of human conditions in the software engineering world, traditionally dominated by technology and process thinking. 6. CONCLUSIONS This study has identified several seminal sources of lean software development and their roots from Lean production. Womack is the most referenced source from lean production, whereas the Poppendiecks seems to have been most influential so far in the interpretation for software. While the Poppendiecks and Andersson emphasize the compatibility between agile and lean, Middleton and Coplien&Bjornvig more emphasizes the differences between lean and agile thinking. The empirical evidence from lean applications in software development found is encouraging in terms of reduced lead time, increased productivity and higher team and customer satisfaction, but the limited number of studies and the dominance of a single author (Middleton), in the report calls for more studies. Further work includes extending the literature review to more conference papers and of course performing more empirical studies of lean principles in organizations developing software. 7. REFERENCES [1] Andersson, D.J. 2010. Kanban, Blue Hole Press. [2] Aoyama, M. 1996. Beyond software factories: concurrentdevelopment process and an evolution of software process technology in Japan. Information and Software Technology, Volume 38, Issue 3, p. 133 143 [3] Beck, K. 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley [4] Björklund, P. 2011. LUT A method for system development with lean software development, Thesis, University of Borås/School of Business and Informatics. 2011. [Swedish] http://hdl.handle.net/2320/8372 [5] Coplien, J., Bjornvig, G. 2010. Lean architecture: for Agile Software Development. John Wiley & Sons Ltd. [6] Cusumano, M.A., and Selby, R. 1995. Microsofts Secrets: How the world s most powerful software company creates technology, shapes markets and manages people. New York: The Free Press. [7] Dybå, T. and Dingsøyr, T., Empirical Studies of Agile Software Development: A Systematic Review, Information & Software Tech., vol. 50, nos. 9 10, 2008, pp. 833 859 [8] Dyba, T. and Sharp, H. 2012. What's the Evidence for Lean?. Ieee Software, 29(5), 19-21. [9] Kindler, Noah B., Vasantha Krishnakanthan, and Ranjit Tinaikar. 2007. Applying lean to application development and maintenance. Mckinsey Quarterly no. 3: 99-101 [10] Kitchenham, B. 2004. Procedures for performing systematic reviews. Keele University Technical Report TR/SE-0401 [11] Liker, J.K. 2004. The Toyota Way: 14 Management Principles from the World s Greatest Manufacturer. McGraw-Hill [12] Meyer, B. Balancing Agility and Formalism in Software Engineering. 2007 Second IFIP TC 2 Central and East European Conference on Software Engineering Techniques, CEE-SET, Poznan, Poland, October 10-12, 2007, Revised Selected Papers [13] Middleton3 Middleton, Peter. 2001. Lean software process. Journal Of Computer Information Systems 42, no. 1: 21 [14] Middleton2 Middleton, P, A Flaxel, and A Cookson. 2005. Lean software management case study: Timberline Inc.
Extreme Programming And Agile Processes In Software Engineering, Proceedings 3556, 1-9 [15] MiddletonBBC Middleton, Peter, and David Joyce. 2012. Lean Software Management: BBC Worldwide Case Study. IEEE Transactions on Engineering Management 59, no. 1: 20-32. [16] Middleton, P. and Sutton, T. 2005. Lean Software Strategies: Proven Techniques for Managers and Developers. Productivity Press [17] Morgan, T. 1998. "Lean Manufacturing Techniques Applied to Software Development," Massachusetts Institute of Technology, MSc. Thesis. [18] Ohno, T. 1998. Toyota Production System: Beyond large scale production. Productivity Press. [19] Parnas, D.L.1972. On the criteria to be used in decomposing systems into modules. CACM [20] Paulk, M. et al, 1991 Capability Maturity Model for Software, CMU/SEI-91-TR-24 [21] Petersen, K, and C Wohlin. "Measuring the flow in lean software development." Software-Practice & Experience 41, no. 9 (n.d.): 975-996. [22] Poppendieck, M. and Poppendieck, T. 2003. Lean Software Development: An Agile Toolkit, Addison-Wesley [23] Poppendieck, M. and Poppendieck, T. 2006. Implementing Lean Software Development: From Concept to Cash, Addison-Wesley [24] Poppendieck, M. and Poppendieck, T. 2010. Leading Lean Software Development. Addison-Wesley [25] Sjøberg, D. I.K., Anders Johnsen, and Jørgen Solberg. 2012. Quantifying the Effect of Using Kanban versus Scrum: A Case Study. IEEE Software 29, no. 5: 47-53. [26] Standish Group, 2009. The CHAOS report 2009, www.standishgroup.com [27] Wang, Xiaofeng, Kieran Conboy, and Oisin Cawley. 2012. Leagile software development: An experience report analysis of the application of lean approaches in agile software development. Journal of Systems & Software 85, no. 6: 1287-1299. [28] Womack, J.P., Jones, D.T. and Roos, D. The machine that changed the world. 2 nd Ed. 2007.Simon & Schuster UK. [29] Womack, J.P., Jones, D.T. Lean Thinking