Definitions of Agile Software Development and Agility

Definitions of Agile Software Development and Agility Maarit Laanti1, Jouni Similä2, and Pekka Abrahamsson3 1 Nitor Delta, Finland Maarit.Laanti@nitorcreations.com 2 University of Oulu, Finland Jouni.Simila@oulu.fi 3 Free University of Bozen-Bolzano, Italy Pekka.Abrahamsson@unibz.it Abstract. The Agile Manifesto and Agile Principles are typically referred to as the definitions of "agile" and "agility". However, many other definitions exist in the literature. Thus the different definitions provide interesting source for research. For each definition we examine where their emphasis is and compare that to the emphases found in the Agile Principles. 1 The Agile Manifesto as a Definition Agile Software Development is most typically defined via the “Manifesto for Agile Software Development” [1, 2]. The Agile Manifesto was formulated in 2001, when Cockburn invited a group of respected software engineering professionals to ski and to discuss topical issues in software engineering. Cockburn [2] defines Agile Methods as techniques that allow a team to track rapid changes in people, technology, and business. He further explains that although the ideas of agile development are based to some extent on the theory of constraints and Lean Thinking, the agile way of working was born separately. The Agile Manifesto is a document that is discussed and argued about a lot. The argumentation is partially related to how the Agile Manifesto is understood (or not understood) and whether people agree or do not agree about it. Partially because of this, a non-profit organization called the Agile Alliance was formed in 2001 to promote the principles and values listed in the Agile Manifesto [4]. Because of the controversy some people have an urge to explain the manifesto and even some agile experts such as Ambler [5], would like to make some changes or updates to it. The Agile Manifesto has also been criticized; for example, Coplien has stated that the Manifesto should talk about Usable software rather than Working software in order better to take the usability aspect into account. There has also been critiques of the Agile Manifesto, stating that it is “too vague” to be used as a basis for scientific work. It has been claimed that it lacks a proper grounding in management theory and philosophy [3]. It has also been stated that even though there are some methods that are called Agile Methods (such as Scrum and Extreme Programming), these methods focus heavily on some of the Agile Principles, but not evenly on all of those. As an alternative, Conboy and Fitzgerald [3] proposed a conceptual framework of Agile Methods, explaining agility as flexibility which F. McCaffery, R.V. O'Connor, and R. Messnarz (Eds.): EuroSPI 2013, CCIS 364, pp. 247–258, 2013. © Springer-Verlag Berlin Heidelberg 2013 248 M. Laanti, J. Similä, and P. Abrahamsson reflects the robust, proactive, reactive, and temporal dimensions: “the ability of an entity to proactively, reactively, or inherently embrace change in a timely manner, through its internal components and its relationships with its environment.” The problem of the framework proposed by Conboy and Fitzgerald is that it covers only one aspect of the Agile Manifesto, i.e., the ability to embrace change, while it leaves the simplicity of processes, incremental deliveries, and the people aspect all uncovered and unrecognized. Conboy and Fitzgerald also compare Agile Software Development with Lean Thinking and the Toyota Production System. Zaninotto was apparently the first one to make this connection in a keynote talk at the XP2002 conference that discussed the tie-ins between Agile Methods and Lean Manufacturing [6, 7]. However, we know from the testimony of Cockburn [2] that the Agile Manifesto was born separately and independently from Lean Thinking, Lean Manufacturing, and Agile Manufacturing, although Cockburn admitted in his keynote speech at the ICAM 2005 conference that some of the signatories of the Agile Manifesto may have known about these methods, and that might have had an impact on why they decided to call the new paradigm “Agile Software Development” and not “adaptive software development”, which was a name suggested earlier by Highsmith [8]. 2 What Is Emphasized in Different Agile Definitions Table 1 contains an analysis of the Agile Principles and where the emphasis is put in each principle. The first principle places an emphasis on: 1. customer satisfaction, 2. continuous delivery, 3. value, and 4. early deliveries. The second principle places an emphasis on 5. adaptability, 6. competitiveness, and customer benefit. Customer benefit (or the customer’s competitive advantage) is close to customer satisfaction, so those two can be combined into 1. customer satisfaction/benefit. The third principle places an emphasis on frequent deliveries. This is close to early deliveries, so these two can be combined into 4. early/frequent deliveries. The fourth principle emphasizes 7. collaboration. The fifth principle places an emphasis on 8. motivated individuals, 9. good environment, 10. support, and 11. trust. The sixth principle places an emphasis on 12. efficiency and 13. communication. The seventh principle is the only one on metrics, and places an emphasis on 14. measure progress via deliverables. The eighth principle emphasizes 15. sustainability and 16. people. The ninth principle emphasizes 17. focus on technical excellence and 18. good design as an enabler of agility. The tenth principle emphasizes 19. simplicity and 20. optimize work and the eleventh 21. self-organization. The twelfth, and last, principle emphasizes 22. built-in improvement of efficiency and behavior. Given that the Agile Principles are widely agreed on as defining Agile Software Development, it would be interesting to compare any other definitions of Agile Software Development and agility against the Agile Principles. The analysis of the emphasis of the Agile Principles is further used as a basis for such a systematic analysis in this thesis. Definitions of Agile Software Development and Agility 249 Table 1. Agile Principles and what they emphasize Agile Principle Emphasis Our highest priority is to satisfy the customer through Customer satisfaction, early and continuous delivery of valuable software. Continuous delivery, value, early deliveries Welcome changing requirements, even late in develop- Adaptability, competiment. Agile processes harness change for the customer's tiveness, customer benecompetitive advantage. fit Deliver working software frequently, from a couple of Frequent deliveries weeks to a couple of months, with a preference for the shorter timescale. Business people and developers must work together daily Collaboration throughout the project. Build projects around motivated individuals. Give them Motivated individuals, the environment and support they need, and trust them to good environment, supget the job done. port, trust The most efficient and effective method of conveying Efficiency, communicainformation to and within a development team is face-to- tion face conversation. Working software is the primary measure of progress. Measure progress via deliverables Agile processes promote sustainable development. The Sustainability, people sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good Focus on technical exdesign enhances agility. cellence, Simplicity – the art of maximizing the amount of work Simplicity, optimize not done –is essential. work The best architectures, requirements, and designs emerge Self-organization from self-organizing teams. At regular intervals, the team reflects on how to become Built-in improvement of more effective, then tunes and adjusts its behavior accor- efficiency and behavior dingly. 3 Tenth Anniversary of the Manifesto In February 2011 30 leading agile thinkers convened to discuss the manifesto, Out of the discussions came a consensus that the agile community should: • • • • demand technical excellence promote individual change and lead organizational change oganize knowledge and promote education maximize value creation across the entire process [9] 250 M. Laanti, J. Similä, and P. Abrahamsson When this list of four items is compared with the emphasis of the twelve Agile Principles we can see that a lot of the original emphasis has been lost: there is no mention of customer satisfaction or benefit, Competitiveness, motivated individuals, a good environment, support, trust, communication, collaboration, sustainability, people, simplicity, or self-organization. Other areas of emphasis are now seen as being even more important, especially the demand for technical excellence. It should be noted that while the promotion of individual change and leading organizational change is about people, these areas of emphasis are not seen in the same way as was originally the case in the Agile Principles: the new area of emphasis focuses on the dynamics of the organization (i.e., change), whereas the Agile Principles are “taking what is given”; building around motivated individuals. The former is a view of someone developing the organization; the latter (in the Agile Principles) is of a project manager’s or entrepreneur’s view on selecting the people to be on the team. The viewpoint on Adaptability is different: where the Agile Principles focus on the Adaptability of the Requirements, the view in promoting individual change and leading organizational change is on the adaptability of the organization. Thus it can be seen that this meeting raised promotion of individual change and leading organizational change as a new area. Similarly, the organization of knowledge and promotion of education can also be seen as a new area. Continuous delivery, value, early or frequent deliveries, efficiency, measuring progress via deliverables, and optimizing the work, as well as built-in improvement of efficiency and behavior, can all be seen as being included in the maximization of value creation across the entire process. 4 More Definitions In 1990 the US Congress became concerned about American industrial capability not matching its competitors, especially Japan. That is why a special technology advisory board was set up to study how US industry should be developed. Agile Manufacturing, an Agile Competitive Environment, and the Agile Enterprise were proposed by this group as answers to the question of how to raise competitiveness. [10] In 1994 some of the group members, namely Goldman, Naegel, and Preiss, published a book called Agile Competitors and Virtual Organizations that was based on this work. Goldman defines agility as: “a comprehensive response to the business challenges of profiting from rapidly changing, continually fragmenting, global markets for highquality, high-performance, customer-configured goods and services. It is dynamic, context-specific, aggressively change-embracing, and growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride out fearsome competitive “storms”, it is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share, and customers in the very center of the competitive storms many companies now fear.” [11] Definitions of Agile Software Development and Agility 251 Interestingly, Cockburn [12] describes this as “the best description he has found for agility”. Kettunen [13] claims that there is no uniform definition of “Agile Software Development” but provides a comprehensive list of different definitions of Agile Software Development, in chronological order. A copy of that table is presented in Table 2, but a third column is now added in this dissertation work. The third is an analysis of each agile definition, explaining where the emphasis is in the corresponding definition. Table 2. Definitions of agile software development [adapted from Kettunen 2009, third column added] Source Cockburn 2001 Anderson 2003 Larman 2003 Schuh 2004 Lyytinen 2006 Subramaniam 2005 Ambler 2007 Definition of agile Emphasis of the corresponding definition Being effective and maneuverable. Effective, steerable, Use of light-but-sufficient rules of rule-based, people, comproject behavior and the use of hu- munication man and communication-oriented rules. Ability to expedite. Speed Rapid and flexible response to Speed, flexibility, responchange. siveness Building software by empowering People, empowerment, and trusting people. Acknowledging change, feedback, value, change as a norm, and promoting speed constant feedback. Producing more valuable functionality faster. Discovery and adoption of multiple Delivery, innovations, restypes of Information Systems De- ponsiveness velopment innovations through garnering and utilizing agile sensing and response capabilities. Uses feedback to make constant ad- Feedback, adaptability, justments in a highly collaborative collaboration environment. Iterative and incremental (evolutio- Iterative, incremental, selfnary) approach to software devel- organizing, less processcollaborative, opment which is performed in a driven, highly collaborative manner by self- cost-conscious, speed, cusorganizing teams with “just enough” tomer-driven ceremony that produces high-quality software in a cost-effective and timely manner which meets the changing needs of its stakeholders. 252 M. Laanti, J. Similä, and P. Abrahamsson Table 2. (Continued) Nerur and Bali- Define Agile software development jepally 2007 via strategic thinking (of uncertainty), holographic organization theory, “emergent metaphor of design” and Agile Methods as people-centric, competent people and their relationships, high customer satisfaction through quick delivery of quality software, active participation of concerned stakeholders; creating and leveraging change. Evolutionary delivery through short iterative cycles, intense collaboration, selforganizing teams and high degree of developer discretion. Learning, teamwork, self-organization and personal empowerment. Responsiveness and flexibility. Interchangeability of roles and jobs based on autonomy. IEEE 2007 Capability to accommodate uncertain or changing needs up to a late stage of the development (until the start of the last iterative development cycle of the release). Wikipedia 2007 Conceptual framework for software engineering that promotes development iterations throughout the lifecycle of the project. Strategic thinking, uncertainty, chaos theories, holographic organization, non-traditional, emergent design, people-centric, competent people and their relationships, high customer satisfaction, quick delivery, active participation, creating and leveraging change, short iterative cycles, intense collaboration, self-organizing teams, developer discretion, learning, teamwork, selforganization, personal empowerment, responsiveness, flexibility, heterarchy, role interchangeability and autonomy. Iterative, responsive Iterative, framework conceptual Cockburn's [14] definition of Agile Software Development places the emphasis in such a way that agile is defined as 1) effective, 2) steerable, 3) rule-based, 4) (about) people, and 5) communication. Only the latter two are the same as can be found in the Agile Principles; see Table 2. Anderson [15] places the emphasis only on 1) speed. Besides speed, Larman [16] also places the emphasis on 2) flexibility and 3) responsiveness. Schuh [17] also places the emphasis on 1) speed, but also on 2) people, 3) empowerment, 4) change, 5) feedback, and 6) value. Lyytinen [18] places the emphasis on 1) feedback, 2) adaptability, and 3) collaboration. Subramaniam [19] emphasizes 1) feedback, 2) adaptability, and 3) collaboration. Ambler [20] states that agile is 1) iterative, 2) incremental, 3) self-organizing, 4) less process-driven, 5) collaborative, 6) cost-conscious, 7) (about) speed, and 8) customer-driven. Definitions of Agile Software Development and Agility 253 Nerur and Balijepally [21] state that the field of software development has progressed by leaps and bounds like also 1) strategic thinking facing 2) uncertainty and 3) non-traditional, 4) emergent design as well as 5) chaos theories and 6) holographic organization theories have and define agile software development by defining Agile Methods as 7) people-centric, 8) competent people and their relationships, 9) high customer satisfaction through quick delivery of quality software, 10) active participation of concerned stakeholders; 11) creating and leveraging change. Important features are evolutionary delivery through 12) short iterative cycles, 13) intense collaboration, 14) selforganizing teams and high degree of 15) developer discretion. Agile development’s value depends largely on 16) learning, 17) teamwork, 18) self-organization and 19) personal empowerment. 20) Responsiveness and 21) flexibility are achieved through 22) “heterarchy” characterized by self-organizing collaborating teams. Holistic teams encourage 23) interchangeability of roles and jobs based on 24) autonomy. IEEE [22] states that agile is 1) iterative and 2) responsive, whereas Wikipedia 2007 definition [23] stated that agile is 1) iterative and 2) a conceptual framework. Those definitions that name only one or two points of emphasis can be considered narrow. The other definitions partially cover the same points of emphasis as the Agile Principles (see Table 2.1) but use slightly different terms or viewpoints on agility. When Cockburn states that agile is about communication – which is also one point of emphasis in the Agile Principles – Ambler states it is about collaboration. These kinds of nuances might seem irrelevant, but they can cause confusion in a large organization when Agile Methods are being used. In practice, people will come and ask what it is that the organization is aiming to do – and is collaboration better than communication? Obviously, the length of the definition is not the only measure of its goodness, although the longer the definition is, the more points that are emphasized it can cover. When the Agile Principles are compared to Goldman’s definition, it can be seen that there is no single point that is emphasized that can be stated as being the same. Instead of customer satisfaction or benefit Goldman talks about “customer-configured goods and services”. Even the contrary is true: while one aspect found in the Agile Principles is “efficiency”, Goldman [11] states that being agile “is not about efficiency”. Nerur’s and Balijepally’s [21] definition is broadest of all definitions. They examine agile software development from the perspective of Agile Methods in general, and compare the changes that have happened in software development to how other disciplines have changed. This kind of broad view puts Agile Methods into perspective and thus is very useful read to practitioners; however this paper still lacks for very coincided definition that would be of practical use. The definition have some common emphases with Agile Principles however there is also emphases to points missing from other definitions – perhaps rooting to other disciplines than software development. 5 Agile Software Development on the Project Level In order to understand how we can scale Agile Software Development and achieve agility we can take a look at the further definitions that are available, especially from sources that look into agility from a perspective that is wider than that of just one team. 254 M. Laanti, J. Similä, and P. Abrahamsson One of these attempts to define agility in a larger context took place in 2005, when Cockburn gathered a group of project managers together to discuss agility within a project context and from a project management viewpoint. This gathering resulted in the Declaration of Interdependence (DOI), which links people, projects, and value with agile and adaptive approaches. The Declaration of Interdependence states: [24] We are a community of project leaders that are highly successful at delivering results. To achieve these results: • We increase return on investment by making continuous flow of value our focus. • We deliver reliable results by engaging customers in frequent interactions and shared ownership. • We expect uncertainty and manage for it through iterations, anticipation, and adaptation. • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. • We boost performance through group accountability for results and shared responsibility for team effectiveness. • We improve effectiveness and reliability through situationally specific strategies, processes, and practices. Analyzing the Declaration of Independence gives hints as to how the emphasis of Agile Methods may change when the viewpoint is changed from a team perspective to a project perspective. Table 3 contains an analysis of the DOI and states the emphasis of each statement. Table 3. Emphasis in agility definition in the Declaration of Interdependence DOI statement We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situationally specific strategies, processes, and practices. Emphasis Maximizing return on investment, flow of value Customer engagement, delivery accuracy, collaboration adaptability, proactivity, anticipation Innovativeness, people, environment Shared responsibility, effectiveness Reliability, situationality Definitions of Agile Software Development and Agility 255 The first statement in the DOI places the emphasis on 1) maximizing ROI and 2) flow of value. The second statement in the DOI emphasizes 3) customer engagement, 4) delivery accuracy, and 5) collaboration. The third statement emphasizes 6) adaptability, 7) proactivity, and 8) anticipation. The fourth statement emphasizes 9) innovativeness, 10) people, and 11) environment. The fifth principle emphasizes 12) shared responsibility and 13) effectiveness. The sixth principle emphasizes 14) reliability and 15) situationality. When Table 3 is compared with Table 1 and the emphasis in the Agile Principles it can be seen that five of these aspects are the same (value, collaboration, adaptability, people, and environment) but the majority are new (maximizing ROI, delivery accuracy, proactivity, anticipation, innovativeness, reliability, and situationality) or the viewpoint is slightly different (customer engagement rather than customer satisfaction, shared responsibility rather than self-organization). This raises the question of whether these differences can be explained just with a different viewpoint, or if the understanding of Agile Methods has evolved, as the DOI was written four years after the Agile Manifesto. New points of emphasis (maximizing ROI, delivery accuracy, proactivity, anticipation, innovativeness, reliability, and situationality) can also be considered as requirements from the project management level for Agile Methods. 6 More Recent Definitions Research papers seem to avoid defining Agile Software Development and agility, or define it via references to a few existing sources, e.g., the definition of Conboy and Fitzgerald [3], or define agility via the methods researched. Assuming that the understanding of Agile Methods increases as people practice these methods more, it is interesting to see how the definitions have evolved and how the emphasis differs from the Agile Manifesto and Agile Principles. Since research provides little help in this respect, the latest agile literature is researched. Advancing Agile Methods seems to be primarily driven by industry practitioners, not by academic researchers. Wikipedia [25] defines agile as 1) a group of software development methodologies, 2) iterative, 3) incremental, 4) self-organizing, 5) cross-functional, and 6) evolutionary. Poppendieck [26] defines agile as 1) a system development frame, 2) technical practices, and 3) effectiveness. Larman and Vodde [27] place the emphasis in agility as 1) ability to change quicker and easier than the competition. Later [28], Larman and Vodde define agile via House of Lean, i.e., as systems improvement using Agile Practices. Appelo states that Agile is context-specific, having its roots in complexity theory. Leffingwell [29] sees Agile as context-specific processes including a set of practices bringing business benefits. Cohn [30] does not give a definition of Agile Software Development but asks the reader to refer to his earlier books. Here, agile is seen as 1) non-sequential, 2) non-traditional, 3) high-quality, 4) speed, 5) meets user needs, 6) low-cost, 7) process, 8) productivity, 9) visibility, 10) predictability, and 11) in-control. From Table 4 it can be seen that even these recognized gurus do not have a unified vision of what Agile Software Development is and are struggling with the definition. 256 M. Laanti, J. Similä, and P. Abrahamsson If the Wikipedia definition is omitted as practical (and thus as an outlier), the rest of the definitions can be categorized as follows: • A null definition (agile is agile ; differing from all the previous and succeeding definitions) Larman’s 2009 [27] recursive definition that agile is agile and a list of negative statements about what it is not, which contradicts almost all of the succeeding definitions of Agile Software Development and agility. • Traditional. Cohn’s 2009 definition as a negative statement of what it is not [30, 29] also aligned himself with the previously discussed (positive) aspects. • Set of practices. Agile as a set of practices that should be used together with Systems Thinking [31, 28, 26]. • Context-specific. Agile as a context-specific set of processes and practices [29] which may vary as the problem that we are solving varies, rooted in complexity theories [32]. Most of the newest definitions of Agile Software Development have stopped talking about effectiveness, but describe agile rather as a set of practices that you can try when doing systems improvement. But agile must be more than just a set of practices that are applied: while the first attempts at putting agile into use in large organizations were about trying out some practices [24], there was a lot of complaining that agile must mean a lot more than some teams (or even some individuals) following some Agile Practices only: for example, you could well do pair coding and still follow a traditional process. An organization needs to know when it has become agile. The agile literature defines no point after which an organization has adopted enough practices to be called agile. Rather, the literature presents various operational models but little guidance as how to get to that dream state. It has also been stated that agility is rather the mindset with which to approach the problems at hand, but an organization cannot simply change to an agile mode by simply stating that it has done so. A large organization would need something it can develop, deploy, and measure. Appelo [32] states that most people have got agility wrong, because they have not understood that agile originates from complexity theories — or rather that they do not understand complexity theories. Thus any simplistic, linear model (or attempt to create one) is bound to fail, and we should rather focus on the adaptability, not the predictability. In fact, conflict is a natural aspect of Complex Systems and a prerequisite for creativity and innovation [32]. This provides an additional challenge for developing large-scale agile models. 7 Conclusion In a way, the definitions can also be taken as a promise what Agile Software Development has to offer. This interpretation would explain how Agile Software Development is sometimes criticized as being a “silver bullet”. It might just be better for the clarity, if we would start talking about different agile practices and what benefits those do bring instead of speaking generally about “agile” and “benefits of agile”. Another view on this data is that Definitions of Agile Software Development and Agility 257 what we understand with “agile” has been developing over time. As new concepts are born, we have struggle on understanding those until finally enough time has passed and we become familiar with those concepts with their own terms. [34] This is why we often create new concepts on the basis of old concepts – e.g. the concept of “airport” is built upon the concept of “port” although the two have only little in common. As Agile Software Development is an abstract concept, it will likely take even more time before it is fully understood. The different perceptions that people have on “agile” and “agility” make deployment of Agile Methods very difficult. The final conclusion is, that people really do mean different things when they are talking about Agile Software Development and agility. Before creating too many misunderstandings, it might be better just to check what the other person’s perceptions are. While the other person may completely focus on people’s interactions within one team and how to create hyper-productive teams the other one may be worried about optimizing the whole organization as a system or leading the product development organization from the basis of complexity science. References 1. Agile Manifesto (2001), http://www.agilemanifesto.org (accessed on July 2011 and May 2012) 2. Cockburn, A.: Two Case Studies Motivating Efficiency as “Spendable” Quantity. In: Proceedings of the International Conference on Agility (2005) 3. Conboy, K., Fitzgerald, B.: Toward a Conceptual Framework for Agile Methods: a Study of Agility in Different Disciplines. In: Proc. ACM Workshop on Interdisciplinary Software Engineering Research (WISER), pp. 37–44 (2004) 4. Fowler, M., Highsmith, J.: The Agile Manifesto. Software Development (August 2001) 5. Ambler, S.: Examining the Agile Manifesto (2011), http://www.ambysoft.com/essays/agileManifesto.html (accessed on July 2011 and May 2012) 6. Poppendieck, M., Poppendieck, T.: Lean Software Development: An Agile Toolkit. Addison Wesley (2003) ISBN 0-321-15078-3 7. Fowler, M.: Is Design Dead? (2004), http://www.martinfowler.com/articles/designDead.html (accessed on July 2011 and May 2012) 8. Highsmith, J.: Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing Company (1999) ISBN-10: 0932633404 9. Stevens: What is next for the Agile Manifesto (2011), http://www.dennisstevens.com/2011/02/13/whats-next-for-theagile-manifesto/ (accessed on August 2011 and May 2012) 10. Preiss, K.: Agility – the Origins, the Vision and the Reality. In: Proceedings of the International Conference on Agility (2005) 11. Goldman, S., Naegel, R., Preiss, K.: Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer. Wiley (1994) ISBN 0471286508 12. Cockburn, A.: Agile Software Development: the Cooperative Game, 2nd edn. AddisonWesley (2006) ISBN-10: 0321482751 13. Kettunen, P.: Agile Software Development in Large-Scale New Product Development Organization: Team-Level Perspective. Helsinki University of Technology, Doctoral Dissertation. TKK Dissertations 186 (2009) ISBN 978-952-248-113-9 258 M. Laanti, J. Similä, and P. Abrahamsson 14. Cockburn, A.: Agile Software Development. Addison-Wesley (2001) ISBN-10: 0201699699 15. Anderson, D.J.: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall (2003) ISBN-10: 0131424602 16. Larman, C.: Agile & Iterative Development. A Manager’s Guide. Addison-Wesley Professional (2003) ISBN-10: 0-13-111155-8 17. Schuh, P.: Integrating Agile Development in the Real World. Charles River Media, Inc. (2004) ISBN-10: 1584503645 18. Lyytinen, K., Rose, G.M.: Information System Development Agility as Organizational Learning. European Journal of Information Systems 15, 183–199 (2006) 19. Subramaniam, V., Hunt, A.: Practices of an Agile Developer – Working in the Real World. The Pragmatic Bookshelf (2005) ISBN-10: 097451408X 20. Ambler, S.W.: Disciplined Agile Software Development: Definition (2007), http://www.agilemodeling.com/essays/agileSoftware Development.htm (accessed on November 2007 and May 2012) 21. Nerur, S., Balijepally, V.G.: Theoretical Reflections on Agile Development Methodologies. Communications of the ACM 50(3) (March 2007) 22. IEEE, Draft Recommended Practice for the Customer-Supplier Relationship in Agile Software Projects. P1648/D5 (2007) 23. Wikipedia, http://en.wikipedia.org/wiki/Agile_software_development (accessed on July 2007) 24. DOI, Declaration of Interdependence (2005), http://www.pmdoi.org/ (accessed on July 2011 and May 2012) 25. Wikipedia, http://en.wikipedia.org/wiki/Agile_software_development (accessed on July 2007) 26. Poppendieck, M., Poppendieck, T.: Leading Lean Software Development: Results are Not the Point. Addison Wesley (2010) ISBN-10: 0-321-62070-4 27. Larman, C., Vodde, B.: Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison Wesley (2009) ISBN-10: 0-321-48096-1 28. Larman, C., Vodde, B.: Practices for Scaling Lean & Agile Development. In: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley (2010) ISBN-10: 0-321-63640-6, ISBN-13: 978-0-321-63640-9 29. Leffingwell, D.: Agile Software Requirements. In: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley (2011) ISBN-10: 0-321-63584-1, ISBN-13: 978-0-321-63584-6 30. Cohn, M.: Succeeding with Agile: Software Development using Scrum. Addison-Wesley (2009) ISBN-10: 0-321-57936-4 31. Senge, P.: The Fifth Discipline. The Art & Practice of the Learning Organization. Random House Business Books (2006) 32. Appelo, J.: Management 3.0. Leading Agile Developers, Developing Agile Leaders. Addison-Wesley (2011) ISBN-10: 0-321-71247-1, ISBN-13: 978-0-321-71247-9 33. Kähkönen, T.: Agile Methods for Large Organizations – Building Communities of Practice. In: Proc. Agile Development Conf. (ADC), pp. 2–10 (2004) 34. Bassett, P.G.: Framing Software Reuse: Lessons from the Real World. Yourdon Press Computing Series (1997) ISBN 0-13-327859-X