UNIVERSITA DEGLI STUDI DEL SANNIO DIPARTIMENTO DI INGEGNERIA

UNIVERSITA DEGLI STUDI DEL SANNIO DIPARTIMENTO DI INGEGNERIA DOTTORATO DI RICERCA IN INGEGNERIA DELL INFORMAZIONE CICLO XVII TESI DI DOTTORATO VALIDAZIONE EMPIRICA DEL PAIR PROGRAMMING RELATORI: CH.MO PROF. ANIELLO CIMITILE CH.MO PROF. GERARDO CANFORA DOTTORANDO: ING. CORRADO AARON VISAGGIO COORDINATORE: CH.MO PROF. MICHELE DI SANTO ANNO ACCADEMICO 2004-2005

Acknowledgements I d like to thank prof. Aniello Cimitle and Gerardo Canfora for their helpful leading along the three years of my study, explaining me how to study, how to realize research, how to evaluate my work. I hope they give me the opportunity to follow their steps forever. I d like to thank my father and my mother for staying at my side along all the way and giving me the suggestions and the strength to reach my final goal; they teach me to reject the fear to fall down, but to have ever the will to stand up and go on. I d like to thank also Gioia for her understanding, patience and help during the harder moments of weakness. Without her smile nothing could be done. I d like to thank also Gloria for being every time I needed to discuss with her. I d like to thank prof. Mario Piattini, Felix Garcia, Marcela Genero for their fruitful collaboration. I appreciate them both on the human and on the professional side. The deep relationship linking me to them is based on pure esteem and respect. I d like to thank prof. Giuseppe di Lucca and Emilio Bellini for their collaboration in the research. I d like to thank all the researchers and administrative people of the Research Centre of Software Technology (RCOST) for giving me all the organizational and human support to accomplish my research work in a very pleasant way. I d like to thank University of Sannio to give me the opportunity to take part to PhD program. Benevento, July 2005. Corrado Aaron Visaggio

ACKNOWLEDGEMENTS 2 ABSTRACT 6 CHAPTER I: INTRODUCTION 8 THE PLAN DRIVEN APPROACH TO SOFTWARE DEVELOPMENT: SOME LIMITS EMERGE 8 THE AGILE METHODS: MOTIVATIONS AND PURPOSE 9 THE INVESTIGATION: PAIR PROGRAMMING UNDER THE LENS 11 THE OVERALL ORGANIZATION OF THE THESIS 13 BIBLIOGRAPHY 14 CHAPTER II: THE DEBATE AROUND AGILE METHODS 16 THE ENTHUSIASM 16 THE SKEPTICISM 21 WHAT IS MISSING IN ORDER TO COMPLETE THE PICTURE? 24 THE STATE OF AGILE METHODS 32 BIBLIOGRAPHY 34 CHAPTER III: THE STATE OF THE ART 38 EMPIRICAL SOFTWARE ENGINEERING: THE IMPORTANCE OF THE EVIDENCE 38 EVIDENCE ON PAIR PROGRAMMING 43 FURTHER INVESTIGATIONS 53 THE RESEARCH PLAN 56 BIBLIOGRAPHY 58 CHAPTER IV: PRODUCTIVITY OF PAIR PROGRAMMING 62 THE EXPERIMENT ON PRODUCTIVITY 62 EXPERIMENT S CHARACTERIZATION 63 ANALYSIS OF DATA 64

4 STATISTICAL TESTS 67 THE EXPERIMENT ON STABILITY OF PRODUCTIVITY 67 ANALYSIS OF DATA 69 STATISTICAL TESTS 72 CONCLUSIONS 73 CHAPTER V: PAIR PROGRAMMING AND KNOWLEDGE LEVERAGING 74 THE PROBLEM: WHEN COULD PAIR DESIGNING BE THE PROPER SOLUTION? 74 THE EXPLORATORY EXPERIMENT 76 EXPERIMENT DESCRIPTION 76 THE RESULTS 80 THREATS TO VALIDITY 83 PRELIMINARY CONCLUSIONS 84 THE FOCALIZED EXPERIMENTS 85 INTRODUCTION 85 THE EXPERIMENTS 86 THE REPLICA IN SPAIN 89 ANALYSIS OF DATA 89 THE KNOWLEDGE DIFFUSION 91 THE KNOWLEDGE ENFORCEMENT 95 COMPARING KNOWLEDGE DIFFUSION AND ENFORCEMENT 99 EXPERIMENTAL THREATS 99 THE INDIVIDUAL BACKGROUND AS FACTOR OF SUCCESS OF PAIR DESIGNING 100 DESIGN AND RESULTS 100 CONCLUSIONS 102 BIBLIOGRAPHY 103 CHAPTER VI: PAIR PROGRAMMING AND DISTRIBUTED SOFTWARE DEVELOPMENT 107 INTRODUCTION 107 THE EXPERIMENTS 108 THE FIRST EXPERIMENT 108 QUALITY S RESULTS 116 EXPERIMENT S REPLICA 121 THE DISMISSAL PHENOMENON: CAUSES AND REMEDIES 124 EXPERIMENTAL VALIDITY 126

5 CONCLUSIONS 128 BIBLIOGRAPHY 130 CHAPTER VII: CONCLUSIONS 132 THE MAIN CONCERN ABOUT AGILITY 132 PRODUCTIVITY AND STABILITY OF PAIR PROGRAMMING THROUGHPUT 133 KNOWLEDGE TRANSFER WITH PAIR PROGRAMMING 134 DISTRIBUTION CAN AFFECT PAIR PROGRAMMING 134 LIMITS OF THE EXPERIMENTATION 135 FUTURE WORK 136 APPENDIX A 137 FORM 1 137 FORM 2 138 FORM 3 140 APPENDIX B 143 USER_BRENCH REGISTRATION 143 BOOK SEARCH AND SELLING TRANSACTION 148 CLASS DIAGRAM 1: ENTITY CLASSES 152 CLASS DIAGRAM 2: CONTROL CLASSES 154 CLASS DIAGRAM 3: PRESENTATION CLASSES 156 QUESTIONNAIRE QA 158 QUESTIONNAIRE QB 159 APPENDIX C 160 EXTREME PROGRAMMING 160 SCRUM 161 CRYSTAL FAMILY OF METHODOLOGIES 161 DYNAMIC SYSTEMS DEVELOPMENT METHOD 162 FEATURE DRIVEN DEVELOPMENT 163

6 Abstract In the last decade, the interest toward agile methods has increasingly grown up and several companies have adopted them in software production. However, the agile approach to software process seems to deny and contradict some grounding rules and good practices of software engineering. This motivated the growth of three different positions taken by researchers and practitioners with regard to the agile approach. The first includes the advocates of the agile approach, who think that it is adequate for any context of software production. The second position includes those who think that the agile approach is not suitable at all to software development. The third position considers that the agile approach has advantages and limitations: it is necessary to precisely detect both. The main concerns regards the following issues: Without a definition of a plan to execute and an accurate phase of analysis and design, the performances of the project could deteriorate. The question is: do the costs (and the risk) of the process increase? Without a proper documentation, is it the knowledge about the product and the process transferable, understandable, maintainable? Is the agile approach suitable to all software development contexts, or in some conditions is better to avoid it? The body of knowledge about agile approach lacks of empirical studies, demonstrating which are the positive aspects to save and which are the drawbacks to avoid, with quantitative analysis. The thesis aims at providing empirical evidence about the agile approach with regards to these aspects. In the space of a thesis to study all the agile practices was not feasible; thus, an agile practice was selected: pair programming. This practice was chosen because it seemed to be exemplar of the more general concerns of agile methods. The research on pair programming was developed along three directives: Is pair programming convenient in terms of the ratio costs/benefits? Is pair programming effective for managing knowledge? Is pair programming suitable to every context?

7 The research has been conducted throughout an empirical investigation and has produced the results, summarized as follows: Pair programming may lead to an higher productivity if compared with solo programming. Furthermore, the throughput of the practice shows a greater stability and predictability than solo programming. Pair programming has a specific benefit: it supports the diffusion and enforcement of tacit knowledge among project s members. It can not take the place of the documentation as source of knowledge, but it can effectively improve its usage. Pair programming needs a tight collaboration and fluent communication. Without these two conditions the advantages of pair programming are likely to be lost. This is a limitation of the practice and hinders the successful application of the practice in every context. Distributed software development is a case where pair programming did not produce the expected benefits, because collaboration and communication are usually poorer than when the pair s members are co-located.

Chapter I: Introduction For long time the plan driven approach to software development was considered the appropriate way to execute a software process. As a matter of fact, this approach brings about many advantages, as well as: ensuring high levels of maturity, obtaining products of quality, controlling and improving the process. The application demonstrated that the plan driven approaches are not successful in every context. They can fail in those environments characterized by a frequent and unpredictable variability. In order to satisfy the need for a proper method to produce software in these contexts, agile methods were introduced. The aim of this thesis is to validate the effectiveness of agile methods. This chapter discusses the goal of research, the method followed in order to achieve the goal, and the motivations which leaded to investigate the effectiveness of agile methods as an alternative to plan-driven processes for software developments. The Plan Driven Approach to Software Development: some limits emerge The term plan-driven refers to a process completely described by a comprehensive definition including the detail of the process model, the procedures to be executed, and the precise responsibilities assigned to the process roles involved. The plan-driven approach for developing software is largely considered as a synonymous for rigor and discipline. The exemplar instance of a plan-driven process is the Waterfall Process Model [9], where the flux of the process is sequential and the execution of each activity depends on the completion of the previous ones. The basic idea of the plan-driven approach is to identify and distinguish clearly the different phases of the process, such as: requirements definition, analysis, design, coding, testing, and installation. The concept of organization s maturity, widespread by the family of the Capability Maturity Models (CMM) [7] from the Canergie Mellon Software Engineering Institute (SEI), emphasized some aspects of process quality such as: comprehensive definition, exact repeatability, continuous monitoring, evaluation of performance through metrics. Consequently, on one hand the quality of a process is considered as tightly dependent on these aspects and thus linked to the organization s maturity, and on the other hand, the respect of these constraints entails a certain stiffness for software production: it is mandatory to execute precise routines to meet certain goals and to produce specific documentation within defined tasks; each deviations from the plan is usually considered a menace to the process quality.

9 This approach permits to take processes under control, makes them repeatable and measurable, but also gives the processes a certain rigidity. Consequently, the organization may be not enough flexible to sustain changes in the availability of resources, in the time pressure, in the stability of requirements and so forth. Researchers and practitioners attempted to define methods and process models with a twofold purpose: assuring high levels of quality as well as the plan-driven approach does, and enabling organization to properly respond to the changing of some operative context variables. The continuous proposing of new process models as well as the spiral process of Boehm [2], the Rapid Application Development (RAD), the Rational Unified Process [6], the Prototyping, demonstrated the urgency for finding a trade-off between quality and flexibility. The grounding principles and values of Agile Movement were introduced in the Agile Software Development Manifesto [1], written in the 2001 by a group of practitioners and researchers, who supported the Agile methods since the early nineties. The Agile Manifesto, discussed in the following section, proposes a radical change of direction, with respect to plan driven development, in order to achieve flexibility without deteriorating quality of neither processes nor products. The main concern is that agile manifesto (apparently) contradicts some fundamental propositions of process quality as intended by the plan-driven approach. The Agile Methods: Motivations and Purpose The agile movement was motivated by the need to cope with the turmoil, typical of certain environments of software development, without neither overrunning the schedule nor increasing the budget; the constraints imposed by these situations usually hinder the successful application of plan-driven approaches. The term agility refers to the capability to face a frequently and rapidly changing operative context, without affecting costs and quality of the product in a relevant way. The Manifesto indicates a set of principles, named values, to be followed in order to perform an agile process of software development. In the following, the agile values are discussed, highlighting the differences with the plan-driven s definition of quality. Individuals and interaction over processes and tools. In the plan-driven approach, the knowledge about the process is managed throughout process definitions while collaboration and team coordination is enabled by proper tools, according to precise routines and procedures. In the agile philosophy, the knowledge that each team s member can offer to solve the problems should be available to the overall team; the purpose is to share quickly the knowledge for overcoming pitfalls and remove obstacles as they arise, during the project. The tight collaboration among the people is strongly recommended, relying on the effectiveness of face-to-face communication in terms of bandwidth of the information flux and knowledge transfer. The grounding idea is to gather the best

10 people who know what to do and how, rather than letting everyone to execute a process, relying on a precise and accurate definition of the process and on a large availability of the proper tools to accomplish tasks. The loss of a process definition makes the processes unrepeatable: the agile process means a set of practices, well known to the members of the team, executed in a very simple sequence. The idea of process stability needs to be rethought and tailored to agile processes. Working software over comprehensive documentation. The plan-driven approach requires the production of a bulky documentation (e.g. requirements definition, design, test cases, test report). Furthermore, the implementation of the system begins after a series of activities, which do not produce any code: eliciting and formalizing requirements, defining the architecture to be developed, realizing rigorous estimations of the process performances. This is not negative per se, but in certain situations, characterized by a great time pressure and scarce resources, the managers and the team s members prefer to give the priority to the production of working software. It becomes an effective indicator to evaluate the progress of the project in terms of cost; to increase the confidence of developers, managers, and customers about the goals already reached and the ones to reach; and to identify the problems either defects as soon as possible in order to reduce their impact in scope, schedule, and cost. Documentation usually helps the understanding of the process and the product which the team is developing. Which are the effects on the maintainability and transferability of the process and the product? Customer collaboration over contract negotiation. The plan-driven approach fits very well contexts where the requirements are completely defined at the project s kick off. The customer is able to sign a contract which describes precisely the product the Software Organization is going to release. Otherwise, to produce an up-front design to be respected along all the project is really hard. In such a case, the agile approach prescribes the customer to take part to the development process; the customer should assess the versions produced at each iteration and provide timely useful feedback for properly adjusting the design if the product is not satisfactory. This principle does not focus on analyzing the requirements and establishing an high level architecture, but makes the architecture to emerge from the implementation of the code and the resolution of problems at any iteration. The effects of a top-down view of the product could affect its overall quality. Responding to change over following a plan. When the availability of the resources, the requirements, the schedule change suddenly or frequently, or are particularly poor, following a well defined process model may be infeasible or risky. As a matter of fact, the process definition shows a general model of the project, without dealing with the limitations of the actual contexts in which the project is going to be executed. The agile approach suggests to adopt very lightweight processes, which do not own a rigorous definition, but leave the project team free to make different decisions along the project according to the stimuli and the needs deriving from the external universe. This characteristic is intended as permitting to successfully adapt the team and the project to the unexpected

11 limitations or resource scarceness. This principle is a threat to the capability of realizing dependable estimations about the project and hinders project management in different facets. The project leader foresees the costs and time, relying on her exclusive experience and evaluation. Appendix C offers an overview of some of the most widespread agile methods. The investigation: Pair programming under the lens The agile approach does not indicate a precise process definition for developing software, but it focuses on the methods to be used in the process. The agile approach provides the guidelines about the practices to be executed and leaves the organizations free to adopt these practices in accordance to the their own culture, capabilities, business goals, and limitations. The commonalties among the different agile methods are: cycling small iterations, which produce a working software, also if not complete; requiring the customer to actively collaborate by providing timely feedback on the product under construction; and give the priority at the software to be released among all the other process products. The main concern with the agile approach is the following: even if it promises to give a great flexibility to the project team, in order to face a dynamic environment, it seems also to contradict and deny a number or rules and good practices of software engineering. Some questions arise: to which extent can agile methods be adopted in industrial setting? Which are their benefits? Which are their drawbacks? The set of the agile practices is too large for studying all of them in the space of a thesis: one practice was selected and put under a lens, with the aim of studying the greatest numbers of its facets. The selected practice is pair programming. Pair Programming consists of two developers, working at the same code, on the same machine: one develops the code, the other one reviews it. The two roles can be switched during the programming session and usually the switch occurs when one developers can not proceed. The idea of pair programming is that two phases, coding and reviewing, which are usually detached and far from each others in the process, are overlapped. The hypothesis behind is that the instantaneous review permits to detect and remove defects right when they are injected in the system. Currently, the debate around agile methods is focuses around three main concerns and it is largely discussed in the chapter II: Q1: Without proper estimates on the process and on the product, the return of investments of agile processes can be seriously affected. What is the ratio costs/benefits due to the agile methods? Q2: Considered all the points of weakness of the agile processes, are there specific benefits of agile methods?

12 Q3: Without an appropriate process definition agile methods can fail in certain contexts. Which are the contexts suitable to the adoption of the agile methods? Pair programming was selected because it could be seen as an exemplification of the concerns expressed by Q1, Q2, and Q3, and related to the overall set of agile practices. Suitable contexts Pair Programming Specific Benefits Costs/Benefits Fig. 1. The three dimensions of investigation about Pair Programming. The purpose of the thesis is to clarify the position of agile methods with respect to the plan driven approach, by focusing on the practice of pair programming. In particular, pair programming will be analyzed from the three viewpoints shown in fig. 1. Q1: A claimed benefit of pair programming is the increasing of quality and productivity. This is due to the continuos review of the code, which let pair to remove defects from the code when they are injected. Moreover, the role switching between the pair s components reduces the latency times. The conjecture is that pair programming should ensure high level of effort s stability and productivity. Q2: Pair programming is supposed to leverage knowledge sharing among team s members. This benefit is specific of the practice and could be the reason why managers decide to adopt it also in other kinds of software process. Q3: Pair programming needs tight collaboration and a fluid communication; these are the necessary conditions to perform successfully the practice. But this suggests that if these conditions are missing the benefits of the practice could be lost. Consequently, some operative contexts which do not allow a tight collaboration and a fluent communication could deteriorate the success of the practice. An example is the distributed software development. The conjecture is that the practice could be not adaptable to every context.

13 The conjecture underlining the research of this thesis is the following: agile methods are not supposed to be better than the plan-driven approach in all cases, but can be a valid alternative in those contexts where the plan-driven approach fails. The purpose is to understand the actual limits and the actual benefits of agile practices, and in particular, pair programming. The overall Organization of the thesis The thesis is organized in further six Chapters as follows: The Chapter II provides an overview about the three major positions of practitioners and researchers about pair programming. There is not a common agreement about agile methods, because the state of the art is not enough mature and the greatest part of literature consists of either anecdotal experience or qualitative study. The first position considers the agile approach as a suitable solution to certain operative situations: these ones are the advocates of the agile movement. The second position rejects agile methods all together, because its supporters consider agility as too contrasting the good practices of software engineering. The third position suggests to investigate in depth all the aspects of agile methods, in order to save the positive aspects and to avoid the drawbacks. In the second part of this chapter the most relevant knowledge about agile methods is collected, organized as pros, cons, and open issue. The Chapter III focuses on the current body of knowledge about pair programming and illustrates the research plan to be followed in the thesis. The first part provides an accurate examination of the most important studies accomplished on the practice. From such an analysis the motivations for the investigation discussed in this thesis emerges. Basically, what emerges is that the state of the art has a poor evidence of the expected benefits of the practice. The second part describes the plan of the research to execute in the thesis. Chapter IV discusses the experimentation on productivity and quality of pair programming. A concern about pair programming is about the cost of the practice: the organization has to pay two developers for the work of one of them, at least apparently. The advocates of the practice think that pair programming is not the work of one, and, moreover, it is the work of more than a pair of developers. Pair programming should produce better programs, because the review phase occurs at the same time of the development; it shortens the time for delivering the software because it reduces the number of the rework; and, finally, the switch of the pair

14 helps avoid the latency time due to the problem which developer ignores how to solve. Chapter V investigates the relationship between pair programming and one specific benefit of the practice itself: the knowledge transfer. Working side by side, at the same piece of code, discussing solutions and alternatives, should foster the knowledge sharing between the two developers. One of the phase which could particularly benefit from an effective knowledge sharing is the design of software system. As a matter of fact, the different levels of abstraction to master when dealing with the software design, make necessary experience and good strategies for successfully operate. This is the reason why, the concept of pair programming was applied to design phase and it was named pair designing. Thus, the chapter investigates to which extent pair designing emphasizes the knowledge transfer among the components of the pair. Chapter VI studies the practice in a particular context for software development, namely distributed teams. In the last decade the distribution of software processes became very widespread, for a number of reason: the need to enlarge the production cycle up to 24 hours a day, the dispersion of kinds of competency, which are required to accomplish the same tasks, projects shared by different organizations on the globe, and so forth. Pair programming requires a strict collaboration and a frequent communication, which are usually poor in distributed teams. Consequently, adopting pair programming in a distributed process could deteriorate the performances of the practice. This chapter investigates how distribution affects the outcomes of pair programming. Chapter VII discusses the conclusions at the three research questions, according with the results of the accomplished experimentation. Furthermore, it offers an overview of the open questions left by this research and the consequent future directions of investigation. Bibliography [1] Beck K., Beedle M., van Bennekum A., Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffres R., Kern J., Marick B., Martin R., Mellor S., Schwaber K., Sutherland J., and Thomas D. Manifesto for Agile Software Development, 2001, Http://AgileManifesto.org. (accesed on the 23 rd of June 2005) [2] Beck K. Extreme Programming explained: Embrace change. Addison-Wesley: Reading, Massachusetts, 1999.

15 [3] Boehm B.W. "A Spiral Model of Software Development and Enhancement" Computer, 11(4), 1988, IEEE CS Press, 14-24. [4] Cockburn A., Writing Effective Use Cases. The Crystal Collection for Software Professionals. Addison-Wesley Professional, Reading, Massachusetts, 2000. [5] DSDM Consortium. Dynamic Systems Development Methods, version 3., DSDM Consortium, Ashford, Eng 1997. [6] Kruchten P. The Rational Unified Process: An Introduction (2nd Edition). Addison-Wesley Professional: Reading, Massachusetts, 2000. [7] Humprey W.S. Characterizing the software Process. IEEE Software, 5(2) 1988,IEEE CS Press, 73-79. [8] Palmer S.R. and Felsing J.M. A practical Guide to Feature-Driven Development. Prentice Hall: Upper Saddle River, NJ, 2002. [9] Rising L. and Jannoff N.S. The scrum software development process for small teams. IEEE Software, 17(4), 2000, IEEE CS Press,26-32. [10] Royce W. "Managing Development of Large Scale Software Systems". Proc. of IEEE WESCON, August 1970

Chapter II: The Debate around Agile Methods This chapter discusses the different positions of researchers and practitioners on agile methods, with the aim of identifying the most urgent open issues to face and indicating the consolidated body of knowledge. The first section shows the standpoints in favor of agile methods; the second one discusses the points of weakness; and, finally, the third section enumerates the suggestions for successful adoption in real contexts. At the end of the chapter a synoptic table summarizes the three viewpoints, in terms of pros, cons, and open issues about the agile methodologies. This will provide the context and the motivation for the research discussed in this thesis. The enthusiasm Some authors believe that agile approaches are suitable to every context of software development. This section offers a comprehensive view of the most representative motivations of such a position. Agile methods are often considered as contrasting the practices used in the plandriven processes: this is one of the reason why many researchers and some practitioners do not sustain them. Barry Boehm [12] proposes to synthesize the two approaches, agile and plan driven, rather than considering them as polar opposites. The author proposes the planning spectrum, illustrated in the fig.2: unplanned and undisciplined methods occupy the extreme left, whereas the micromilestones planning ones stay at the extreme right. The author compares agile and plan driven approaches in five key areas: Developers. The agility is obtained by relying much more on the tacit knowledge embodied in the team rather than by writing the knowledge down in the plans. When the tacit knowledge is sufficient for the life-cycle needs and it is well communicated or transferred, things work fine. But there is also the risk that the team commits irrecoverable architectural mistakes because of unrecognizable shortfalls in its tacit knowledge. Plan-driven reduces this risk by investing in lifecycle architecture and plans, and using this to facilitate external expert reviews. In this case a risk must be accepted: the changes are so rapid that the plan can not change in perfect accordance with them and they begin obsolete or expensive to keep up to date. Customers. Agile methods are successful when the customers operate in dedicate mode with the development team and their tacit knowledge is sufficient for the full span of the application. These methods risk tacit knowledge shortfalls

17 that could be avoided with the plan-driven approaches by producing documentation and review board. Requirements. Plan driven methods work best when requirements can be defined in advance and remain relatively stable with change rates on the order of one percent per month. In the current changing environments the traditional emphasis on having complete, consistent, precise, testable, and traceable requirements encounters difficult to insurmountable requirements-update problems. Architecture. As with requirements, plan driven methods are preferred if the heavyweight architecture can accommodate and anticipate requirement changes. Size. Plan driven methods scale better to large projects. The cost of management for large teams could be not justified for small projects. The author concludes that hybrid approaches combining both methods are feasible and necessary for projects showing a mix of agile and plan-driven foreground characteristics. The agile approaches help to deal with the turmoil in the current technology trends, but the plan driven ones provide the dependability that is strongly requested in many marketplace contexts. The best solution stands in the word balance. Hackers XP Adaptive SW development Milestone Risk-Driven models Milestone Plan-Driven models Inch-pebble ironbound contract Agile methods CMM Software CMM Fig. 2. Boehm s Model. In [18] Cockburn and Highsmith recall that two dominant ideas drive agile development: reduce the cost of moving information between people, and reduce the elapsed time between making a decision and seeing the consequences of that decision. The first goal is met by: (i) placing people physically closer, (ii) replacing documents with talking in person and at whiteboards, and (iii) improving the team s amicability so that people are more inclined to release and spread valuable information quickly. The second goal is reached by: (i) making user experts available to the team or, even better, part of the team, and (ii) working incrementally. Provided that agile methods should respond to turbulent environment, agile teams require responsive people and organizations: in other words, agile teams focus on individual competency as a critical factor in project success.