Agile Software Development in Large Organizations

COMPUTING PRACTICES Agile Software Development in Large Organizations

While agile practices can match the needs of large organizations—especially for small, collocated teams—integrating new practices with existing processes and quality systems will require further tailoring.

Mikael n recent years, the use of, interest in, and con- of large organizations with well-established struc- Lindvall troversies surrounding agile methods have all tures and processes. Fraunhofer Center increased dramatically—as has anecdotal evi- We base this analysis on experience collected and for Experimental dence for agile methods’ effectiveness in cer- shared among four SEC members—ABB, Daimler- Software tain environments and for specific project Chrysler, Motorola, and Nokia—and focus on the Engineering, types. Exactly in which environments and under following areas: Maryland I what conditions agile methods work remains unclear, however. A development team at Motorola, • identifying the business drivers that led to the Dirk Muthig for example, noted that, “a plethora of subjective evaluation of agile methods, Fraunhofer Institute for Experimental evidence exists to support the use of agile develop- • ascertaining whether their pilot projects Software ment methods on non-life-critical software pro- reached their goals, Engineering jects.”1 Yet the team found no information about • articulating lessons learned regarding incom- using the approach for its particular development patibilities with the project environment, and Aldo focus: mission-critical software products. • determining their conclusions regarding future Dagnino This shows the need for more evidence that a new use of agile methods. technology works in a certain context before devel- Christina opers promote and deploy it on a larger scale. Four SEC meetings and one electronic workshop Wallin Although most organizations have similar needs, (http://fc-md.umd.edu/projects/Agile/3rd-eWorkshop/ ABB the need to see compelling evidence before adopt- summary3rdeWorksh.htm) in which the member ing new methods looms greater in large organiza- companies shared experience on the application of Michael tions because of their complexity and the need to agile methods provide the core data for our analysis. Stupperich integrate new technologies and processes with exist- The “Sharing Agile Expertise through the SEC” side- DaimlerChrysler ing ones. bar describes these meetings in greater detail. We also To further evaluate agile methods and their collected experience reports internal to the compa- David Kiefer underlying software development practices, several nies that provided input to the meetings and gathered Software Experience Center (SEC) member com- additional information from the member companies John May panies initiated a series of activities to discover if to clarify and reﬁne the results. We have referenced Motorola agile practices match their organizations’ needs. reports that are publicly available. Unattributed Although each organization evaluated agile meth- quotes refer to unpublished reports and presentations Tuomo ods according to its speciﬁc needs, here we attempt proprietary to individual companies that are not pub- Kähkönen to generalize their findings by analyzing some of licly available. Nokia their common experiences in the particular context We must admit that the data collection does not

For the past five years, several large global businesses have • engineering project management, been sharing experiences in software development practices. • requirements engineering, The member companies founded the consortium that makes • transition from the SEI CMM to the CMMi, this possible in 1999 so that they could share their experience • Six Sigma and system development, while protecting its proprietary aspects. The Fraunhofer Center • R&D results deployment, for Empirical Software Engineering, Maryland (FC-MD), and • system and software architectures, and the Fraunhofer Institute for Empirical Software Engineering • product line practices. (IESE) in Germany agreed to facilitate the consortium and provide the legal umbrella to make this possible. Each company brings appropriate presentations to the three- The member companies of the Software Experience Center day meetings. The steering committee then plays a key role in consortium aim to improve their software competencies and identifying and selecting topics that are of broad interest to the development practices by actively sharing experiences with one membership, so that each member can participate. another. The current SEC members are ABB, Boeing, During the meetings, member companies make company- DaimlerChrysler, Motorola, and Nokia. Fraunhofer directors specific presentations on the selected topics. These presenta- Victor Basili and Dieter Rombach have served to guide the SEC, tions are covered by nondisclosure agreements. Each attendee providing enormous benefits by assuring that key issues are receives a complete set of all presentations offered at each meet- adequately addressed. ing. These company representatives then disseminate the results Each of the member companies hosts three-day meetings, when they return to their day-to-day activities. held semiannually on a rotating basis. The SEC Steering The information shared at SEC meetings has a variety of Committee, which draws its members from the participating uses. For example, in one member company, the SEC Steering companies and two Fraunhofer organizations, develops the Committee representative prepared a trip report and posted it program of topics for each meeting. An enduring theme has to an internal Web site, along with hot links to the presenta- been the sharing of strategies for improving engineering pro- tions. At another company, meeting attendees made their trip ductivity and product quality. report to an internal committee at a regularly scheduled inter- Topics addressed at these meetings have covered the gamut nal meeting. All company participants have been satisfied with of current software engineering and system development issues, the extent of sharing they see and the information they gain including through the exchange.

• agile methods, • software process improvement, Allan Willey is a fellow of technical staff at Motorola Labs. • software and system quality metrics, He received an MS in management sciences from George Wash- • software subcontractor management, ington University. Contact him at [email protected]. follow the ideal scientific process: The data was what drives most organizations to look for new defined after the pilot projects ended, it is mostly ways to develop software. qualitative, and different people collected it. Problems related to requirements supplied However, the collected data, drawn from about 15 another common theme, and developers identified different pilot projects influenced by eXtreme them as strong drivers among the four organiza- Programming2 (XP) across four different organi- tions. For example, because mandated ship dates zations, provides a broad overview of the use of require that software development begin after defin- agile methods in large companies. ing only a portion of the requirements, the organization must look for better ways to manage projects BUSINESS DRIVERS for which requirements are not yet fully specified. Many small organizations have shown interest Another problem typically arises when the in agile methods because they seek alternatives to requirements are passed along to the development the traditional software development methodolo- team at a high level. This can make it difficult to gies, which they find too cumbersome, bureau- decompose the requirements up front into detailed cratic, and inflexible. They also feel pressure to software specifications. This problem drives the produce more at lower costs. organization to find ways to better understand the We found that these same needs drive large orga- end users’ real needs. nizations as well. One Motorola team identified a In addition, work on the specifications is time- need shared by all organizations in this study when consuming, and the resulting specifications are they observed: “Software development teams face often obsolete by the time they are finalized. a continuous battle to increase productivity while In addition to the problems associated with ill- maintaining or improving quality.” This is indeed defined and high-level specifications, rapid changes

December 2004 27 in the requirements and other environmental these organizations evaluated agile methods. Before introducing factors drive the need to adapt swiftly to keep The pilots all used and tailored XP in some way, new practices, the pace with evolving markets and technologies. either using XP as is, choosing selected XP prac- This leads organizations to seek a flexible tices and incorporating them into their regular development team process capable of adapting to volatile processes, or using XP terms to refer to the prac- must understand requirements. The need to show early tices they already used. To cover the numerous vari- their effects progress to the customer and present upper- ants, we simply say they were all influenced by XP. and implications. level management a first version quickly also We emphasize that XP and agile methods are not promote this behavior. interchangeable terms, but that XP is the most com- While any organization that develops soft- monly used agile method today because it is the ware could encounter these problems, some best documented and thus the easiest to implement. are more likely to occur in large organizations. For Researchers at ABB applied and evaluated agile example, some participants reported their disap- practices in several different ways. For example, pointment with heavy process approaches and cur- they conducted a systematic study as a pilot XP rent quality systems that are too generic and project over 10 weeks. Along with piloting XP, the complex to provide good support. Large organiza- project members also evaluated software develop- tions are more likely to implement defined devel- ment lifecycle models and methodologies. In addi- opment processes, including a system for assuring tion, on three occasions the developers used quality throughout the software development ADEPT, an evolutionary in-house lifecycle model process. These processes and systems often put con- that combines agile and traditional practices, in straints on the development team, limiting what their evaluations of agile practices. ADEPT incor- development practices they can and must use, which porates selected XP practices and is recommended affects how quickly they can develop software. for use when teams cannot implement a complete When pressured to quickly deliver a product to agile lifecycle model. capture a market opportunity, one software team DaimlerChrysler researchers have made several reported that they felt they must fight two battles partial attempts to apply agile methods, and they at the same time—one to develop a product in a have extended their development approaches with short time and the other to fulfill the quality sys- selected XP practices. Typical applications include tem’s requirements. Finding alternative ways to administrative, interactive software portal, Web, develop software faster and more flexibly without and embedded projects. DaimlerChrysler has con- compromising these organizations’ high quality ducted several XP practice studies. For example, standards thus becomes essential. the corporate researchers studied a software project in a business unit that embarked on a conven- APPLYING AND EVALUATING AGILE PRACTICES tional project and later switched to XP. Before introducing new practices, the develop- At Motorola, researchers have applied agile prac- ment team must understand their effects and impli- tices in the form of XP several times. In one 18- cations. Although the organizations participating month study, four separate teams developing in this study were aware of reports indicating that embedded systems participated in a pilot project agile methods do indeed work, they remained using XP. In another study, developers used XP for unconvinced that these practices would work for a project to develop a large safety-critical, real-time them. For example, they needed to evaluate system with extremely high quality requirements.1 whether agile practices would increase productiv- At Nokia, developers introduced XP practices on ity and reduce cycle time while maintaining the cur- several projects. In addition, on at least three pro- rent level of quality and maintainability. jects, developers defined and applied an in-house In addition, they questioned whether an estab- method that combined XP and traditional prac- lished company could use agile practices to develop tices. In general, Nokia has adopted XP practices large, complex, safety-critical systems that would for projects when deemed appropriate. be maintained for decades. They also wanted to assess whether they could use agile practices to APPLICATION RESULTS shrinkwrap product development. An organization must consider several important To evaluate agile methods, these large organiza- aspects when introducing agile methods. From a tions have conducted numerous pilot projects, stud- business viewpoint, delivering high-quality soft- ies, and other activities. The pilot projects we ware on time and within estimated cost and effort describe here offer a representative sample of how is essential. In the context of applying agile prac-

28 Computer tices, understanding which aspects of the process Although the pilots conducted at Motorola became more agile is equally important. all followed slightly different processes, they Developing rough Other aspects to consider include how difficult showed relatively consistent results based on introducing and sustaining the practices will be, data collected on both qualitative and quan- specifications their desirable and undesirable side effects, and titative aspects of the process. The data shows instead of detailed employees’ satisfaction with using the methods. that the projects achieved quality levels com- ones generated cost Based on internal acceptance testing and prelimi- parable to or better than other processes. savings, which nary product test results, the ABB pilot project indi- Defect density, for example, measured sig- cates that the resulting product exhibits higher nificantly better than the division average. decreased the need quality than previous releases. In addition, the The development teams used custom for- for specification product meets its required scope, and the project mal technical reviews to ensure that the pro- updates. only slightly exceeded the required delivery time. ject produced a maintainable design. When The resulting code exhibited high quality, thanks surveyed, 82 percent of the pilot developers both to pair programming, which prevented gold believed that the design and code generated plating and complex design, and to automated using XP resulted in understandable, maintainable, tests, which prevented introducing errors or hav- and extensible software. In addition, 88 percent ing them remain undiscovered. Continuous inte- believed that the deliverables produced using XP gration helped improve the quality of changes by would be adequate for future development and quickly uncovering integration problems. maintenance. The pilot teams also experienced a The increased agility was reflected in the speed significant increase in engineer productivity com- with which the developers implemented change pared to similar teams within Motorola that used requests. Team members encountered fewer unpleas- different development processes. ant surprises at the development cycle’s end, and they A survey distributed to all developers involved shared a common view of the project. In addition, in the pilot—29 respondents—showed that team pair programming helped to spread information and morale increased, the learning curve for new engi- knowledge throughout the team, and daily stand-up neers shortened, and test coverage improved. meetings improved work discipline. Among the respondents, 85 percent indicated that Developers noted that they could easily learn XP they enjoyed using XP, and 80 percent reported that without making major investments in tools or they had more confidence in the design and code training. generated while they used pair programming than DaimlerChrysler’s experience demonstrated that while they worked alone. using agile methods combined with constant test- These pilot projects succeeded because the team ing and other classical QA techniques produced produced and tested code earlier. In addition, they high-quality software throughout its projects. The developed the system and executed it in smaller practice of developing rough specifications instead pieces. Altogether, this meant that the teams could of detailed ones also generated cost savings, which detect and fix problems earlier. decreased the need for specification updates and All pilot projects this study covers had similar resulted in further savings. positive experiences. The subjective and objective Agility increased in several ways. For example, measures indicate that these projects succeeded in flexibility grew through faster responses to chang- terms of increased agility and made improvements ing requirements, and development velocity in- to one or more of the following attributes: customer creased as implementations finished more quickly. satisfaction, quality, productivity, and cost. In addi- One DaimlerChrysler project team reported that tion, most developers involved in the projects had using XP cut costs while achieving high levels of positive experiences, team morale increased, and quality and customer satisfaction. The development introducing the practices did not prove costly. team considered the project a success, due in large Overall, the teams applying the XP-influenced part to the impact of adopting XP practices. This practices viewed their experience as very successful. project showed that adapting agile elements for use These findings resemble other experiences with in a conventional project environment could lead to XP.3-6 noticeable cost savings while maintaining high quality. Further, the communication between the LESSONS LEARNED project members and the customer improved sub- The greatest challenge to adopting agile practices stantially thanks to a variation on the onsite cus- involves integrating each pilot with the project envi- tomer practice and the planning game practice. ronment’s existing processes.

December 2004 29 Customers Organizational software Requirements processes Development Team Planning game, Short development cycles, Change Pair programming, Test-first programming, control Collective code ownership, Frequency integration, Architecture must be able to communicate and coordinate with boards NeverXP solving a problem pilot that has not yet occurred, other teams in the organization, and the developed Refactoring, Minimal documentation software must integrate smoothly with a larger software system. In addition, the team must also ﬁt into Quality systems Legacy systems the standard processes and quality systems deﬁned Other teams by the organization.

Cross-team communication support Figure 1. Tailoring Tailoring XP Tailoring XP practices and adding support for XP to the All four organizations learned the absolute neces- cross-team communication presents an important organization. sity of tailoring XP to their particular requirements. lesson, one particularly prominent at Nokia.7 Large The lightning The experience at Nokia showed that introducing organizations often distribute teams across several symbols show the XP in a large organization without extensive tai- physical locations. However, XP practices aim to incompatibilities loring is generally infeasible. Motorola had a sim- increase a software development project’s agility between the XP pilot ilar experience: XP is not a one-size-fits-all software by collocating the team. Consequently, XP prac- project and the development process. tices do not address problems arising from com- environment. To Figure 1 shows that the challenges lie not in the munication and coordination between multiple maximize efficiency, agile project itself and the new practices it puts in teams.7 This creates a need for more formal com- organizations must place, but in the interface between the new and munication, such as meetings and documentation. resolve these existing practices. In a large organization, a project As a result, communication between teams is less incompatibilities. cannot be truly independent, but must interact with effective than within teams, creating additional and follow the rules of the organization overall. developer overhead7 and decreasing each project’s The amount of tailoring varied from project to agility. project. In one example, a Motorola team tailored Cultural differences between teams add to this the process by modifying the customer role slightly, problem. At Motorola, for example, project man- creating a baseline architecture, adding and modi- agement noticed on several occasions that XP teams fying some documentation, and adding some for- have difficulty interfacing with teams that use tra- mal reviews. Another Motorola team adopted ditional development processes. For example, when some XP practices, dropped others, and supple- two types of teams shared work on an interface, mented others with traditional practices.1 In this the XP team wanted just one or two pieces of the case, the mix of traditional and agile practices interface to work with at a time, while the tradi- resulted in a situation in which “an outsider could tional team wanted to develop and review the entire easily interpret the process as a CMM-based interface before providing it to the XP team. process with some of the XP practices added to it.”1 Nokia believes that one solution to this problem While some of the tailoring efforts aimed to make lies in minimizing the need for cross-team commu- the practices work for a particular pilot project, nication. This is possible when, for example, each most challenges related to making the pilot project team is developing independent subsystems and work well within the organizational environment. occupies one physical space. Nokia’s experience, DaimlerChrysler, for example, learned that it is however, shows that achieving and maintaining this essential to modify XP practices so that they align alignment and architecture can be difficult in a large with the environment and the rest of the project. organization. Even though it might be possible to ABB reports a similar experience, noting that most achieve such an alignment once, the architecture difficulties were found in the project environment, will evolve, causing loss of alignment. Determining not in XP. Motorola had a comparable experience how developers can reduce communication struc- and reports that the project postmortem revealed ture complexity to minimize the need for cross- that—although some traditional practices, such as team communication while maximizing synergies the change control board (CCB), clashed with XP within teams remains an open question. Another practices—few defects could be traced directly to approach that Nokia has been exploring to over- XP.1 come this problem uses a continuum of facilitated We think this summarizes the differences between cross-team workshops. Several projects at Nokia a large organization and a small one. Individual pro- reported that these workshops, which amass peo- jects in a large organization often depend on their ple from different parts of organizations to perform environment in several ways. For example, work is a specific, well-defined task, can be used effectively often distributed across several teams.7 The team to solve issues that span multiple teams.7

30 Computer Refactoring and CCB clashes bined with small releases guarantees the con- XP encourages the somewhat controversial prac- stant availability of an executable system. As tice of continuous refactoring. This practice can a result, the team could always deliver work- Large organizations easily clash with existing quality control systems, ing software when necessary. often follow defined such as using a CCB to oversee management of Motorola experienced some difficulties software processes, changes to the source code. Refactoring encom- when the CCB began exercising its power to which can result passes changes to the system that leave its behavior control which changes were integrated. The in double work unchanged and enhance its quality. These changes board met weekly to plan the next build, so include simplicity, flexibility, understandability, and integrations took place weekly. This clash when projects apply performance. XP’s reliance on collective ownership with the CCB decreased the project’s agility. new practices. means that any developer can change any line of On one occasion, the CCB postponed inte- code to refactor it. Refactoring, an integral part of gration of a minor defect fix. Meanwhile, the XP, makes changing the codes easier, thereby allow- code underwent significant changes before the ing the implementation of changed customer CCB approved the fix. By this time, the file version requirements without breaking the design. with the defect fix differed significantly from the Most reports on refactoring consider it beneficial. mainline version and, consequently, the merge One Nokia team even considered the practice a fac- became nontrivial and had to be done manually.1 tor in a project’s success “because the architects stayed with the project, refactored the architecture Organizational software processes continuously and accomplished the survival and Large organizations often follow defined soft- evolution of the architecture.”8 One Motorola pro- ware processes, which can result in double work ject, however, encountered risks when large refac- when projects apply new practices that have not torings created some significant project defects.1 been well integrated with these traditional The controversy surrounding refactoring arises, processes. This applies to both input and output however, because it runs contrary to the commonly from the project and raises the following issues. applied practice of “if it isn’t broken, don’t fix it.” Scope and delivery planning. A team at ABB experi- In a culture that encourages a “get it right the first enced double work when traditional processes time” approach to development, many see the need overlapped or conflicted with agile practices. to refactor as a process failure.1 Traditionally within ABB, the program defined the Refactoring can also easily clash with using scope and delivery time for the project in advance, CCBs, which manage and limit code changes. A as it did for the XP pilot. The program, for exam- Motorola team reported that the refactoring clashed ple, developed plans up front, with little or no with the CCB’s desire to minimize code base development team participation. The program also changes. To reconcile refactoring and the CCB, required that the documentation be frozen before Motorola introduced several process modifications. design and implementation started. Developing For example, management encouraged each devel- plans without involving the team and freezing doc- oper to think of refactoring ideas but to ask per- umentation clashes with XP’s core ideas. mission from the CCB before implementing them.1 Traditional requirements management. By design, XP expects coarse input requirements, but ABB’s tra- Continuous integration and CCB clashes ditional approach to running programs that Continuous integration is an XP practice that applied XP required delivering detailed require- resembles refactoring in how it interacts with exist- ments to the development project in advance. ing processes. Experience shows, for example, that These requirements did not take the form of user this practice can easily clash with the CCB. stories, had not been defined with involvement Continuous integration means that developers from developers, and were seldom accurate by the should integrate and release code into the code time development actually started. For the XP repository whenever possible, at least every day. pilot, this resulted in double work because the pro- Continuous integration contributes to a project’s ject team analyzed and decomposed the market agility by detecting and removing integration- requirements twice, first into traditional project related defects early and by dividing the integra- requirements at the program level, then into user tion work into smaller, easier to manage chunks. stories and engineering tasks during the pilot itself. Most projects reported positive experiences with Traditional acceptance test management. XP expects continuous integration. ABB’s experience, for acceptance tests to be run continuously during example, showed that continuous integration com- development, but ABB traditionally calls for the

December 2004 31 project to design and implement the code performance, such as engineering and manpower. first, then let another team perform the prod- Although this would not have been necessary in Having mature uct acceptance test. This procedure caused XP, the procedure did help avoid conflicts with the processes already in the developers to view the acceptance tests control department and other organizational units. place ensures that done in the XP pilot as internal only, thus efforts to become they required another round of acceptance FUTURE PROSPECTS more agile do not tests after the pilot had been finished. The Based on this experience, ABB concluded that double acceptance test occurred because any organization that develops manageable system turn a mature customers and quality systems often require elements with small teams could try XP. Further, it organization into running such tests independently, with little determined that nothing prevents large organiza- a chaotic one. or no developer involvement. In addition, tions from trying XP on a small scale. As most XP testers often perform these tests on a system practices can, by themselves, be useful in traditional for which many different teams may have development projects, they can become part of the developed the components. Thus, the accep- toolbox offered to projects. Some practices have tance test the project conducts serves as a test of already spread outside the development team. A the component. broader implementation of XP, however, would Quality management. XP asserts that when prop- require changes to ABB’s culture and current qual- erly used, pair programming eliminates the need ity system. for formal reviews. But eliminating formal reviews DaimlerChrysler acknowledges that mature clashes with traditional quality systems. In most processes require activities such as quality man- cases, the pilot projects found that they needed an agement, documentation, and measurement. It also additional layer of quality assurance. realized that reducing time to market has become One Motorola team, for example, introduced increasingly difficult. The company concluded that pair programming and replaced the mandated for- agile practices can help mature organizations mal technical reviews with informal reviews.1 become more flexible. Having mature processes When the team later reviewed test cases formally, already in place will ensure that efforts to become they found missing tests and identified ways to more agile do not turn a mature organization into improve the test suite. a chaotic one. DaimlerChrysler thus identifies agile In Motorola’s complex environment, a pair of methods as another tool in the software process people will not be able to consider all effects on the improvement toolbox that includes, for example, entire system, which makes it unlikely that pair pro- the SEI’s Capability Maturity Model. gramming will eliminate all mistakes during cod- The pilot projects’ success convinced the ing. Further, project management deemed valuable Motorola team that it is possible to use XP to the discussions that take place in reviews involving develop large, complex, safety-critical systems with developers with many different viewpoints. They long life cycles. Motorola’s developers note, how- thus concluded that formal code and test case ever, that integrating an agile process into a com- reviews can complement pair programming. pany with a culture that favors more traditional Motorola also prevented another of its teams from development processes can be difficult. The stan- skipping the rigorous review process because that dard XP process needs tailoring to better mesh with group developed products that could affect public an organization’s specific circumstances. Carefully safety. introducing agile processes yields positive results, DaimlerChrysler expected that agile processes however. would not mesh with the project’s more conven- Nokia notes that small software development tional environment. This is exactly what happened: teams are more productive than large ones. Thus, Both the control and quality management depart- they strive to apply the most appropriate software ments demanded the same documentation as proof method for the task at hand and view agile methods of project progress for this special case, just as they as another tool in the software process improve- would for any standard project. The project part- ment toolbox.9 Nokia decided that XP works best ners therefore decided to treat the project as a con- for small, independent, collocated projects and that ventional one on the outside, satisfying all using selected agile techniques will become increas- requirements defined by quality management. For ingly common. Agile methods will primarily influ- example, the team set up quality gates and quality ence other processes. Hybrid processes of different plans in accordance with standard templates. As agile influence levels will be the primary means for usual, the contractor kept track of its own project applying agile development ideas. To achieve orga-

32 Computer nizational agility, Nokia has defined a set of agile References software engineering patterns that organizational 1. J. Bowers et al., “Tailoring XP for Large System Mis- units can use to select agile practices that fit them sion Critical Software Development,” Proc. 2nd XP instead of trying to apply a one-size-fits-all solution. Universe and 1st Agile Universe Conf. on Extreme Programming and Agile Methods, Springer, 2002, pp. 100-111. ased on the experiences of the organizations 2. K. Beck, Extreme Programming Explained: Embrac- we have studied, we believe agile practices ing Change, Addison-Wesley, 1999. B match the needs of large organizations, espe- 3. D. Karlström, “Introducing Extreme Programming— cially for small, collocated teams. Even so, inte- An Experience Report,” Proc. 3rd Int’l Conf. grating new practices with existing processes and Extreme Programming and Agile Processes in Soft- quality systems that govern the conduct of software ware Eng., Springer, 2002, pp. 24-29. development requires further tailoring. The chal- 4. J. Grenning, “Launching Extreme Programming at a lenge here lies not in applying agile practices to a Process-Intensive Company,” IEEE Software, project, but in efficiently integrating the agile pro- Nov./Dec. 2001, pp. 27-33. ject into its environment. To fully benefit from agile 5. C. Poole and J. Huisman, “Using Extreme Program- practices, organizations must better define the inter- ming in a Maintenance Environment,” IEEE Soft- faces between the agile team and its environment, ware, Nov./Dec. 2001, pp. 42-50. thus avoiding the double work caused by the con- 6. B. Rumpe and A. Schröder, “Quantitative Survey on flict between agile practices and traditional ones. Extreme Programming Projects,” Proc. 3rd Int’l These obstacles will not stop large organizations Conf. Extreme Programming and Flexible Processes from using agile methods, especially as the promis- in Software Eng., Springer, 2002, pp. 95-100. ing results in pilot projects increase interest in them. 7. T. Kähkönen, “Agile Methods for Large Organiza- Now that the hype about agile methods has been tions—Building Communities of Practice,” Proc. substantiated with real-world results, many project Agile Development Conf. (ADC 04), IEEE CS Press, teams will view agile methods as a useful resource. 2004, pp. 2-11. As these projects identify a few practices that suit 8. J. Vanhanen, J. Jartti, and T. Kähkönen, “Practical them well, they will then implement them as part of Experiences of Agility in the Telecom Industry,” Proc. their regular processes. By using this hybrid ap- 4th Int’l Conf. Extreme Programming and Agile proach, these organizations can maintain existing Processes in Software Eng., Springer, 2003, pp. 279- quality systems while becoming more agile so that 287. they can serve their customers better. 9. K. Känsälä, “Good-Enough Software Process in Nokia,” LNCS 3009, Springer, 2004, pp. 424-430.

Acknowledgments Mikael Lindvall is a scientist at the Fraunhofer We thank the following for contributing to this Center for Experimental Software Engineering, article: at Motorola, Azeem Ayoob, Matthew Maryland. His research interests include agile meth- Baarman, Jason Bowers, Erik Melander, Andrij ods, software process improvement, software archi- Neczwid, David Noftz, Rekha Raghu, and Jerry tectures, and experience and knowledge manage- Drobka; at DaimlerChrysler, Jan-Peter van ment. Lindvall received a PhD in computer science Hunnius and Kurt Schneider; at Nokia, Jouni Jartti, from Linköping University, Sweden. Contact him Kari Känsälä, and Jari Vanhanen. We also thank at [email protected]. the SEC Steering Committee that made it possible to write this report: Victor Basili, Fraunhofer Dirk Muthig is a department head at the Fraun- Center for Experimental Software Engineering hofer Institute for Experimental Software Engi- Maryland, and Dieter Rombach, Fraunhofer neering. His research interests include product line Institute for Experimental Software Engineering; engineering, system architectures, and variability Martin Bollinger and Manfred Schoelzke, ABB; management. Muthig received a PhD in computer Thilo Schwinn, DaimlerChrysler; and Allan Willey, science from the Technical University of Kaiser- Motorola. We also thank the following people for slautern, Germany. Contact him at dirk.muthig@ helping improve the article: Patricia Costa, Forrest iese.fraunhofer.de. Shull, and Roseanne Tesoriero Tvedt for ideas and feedback; Ioana Rus and Michelle Shaw for review- Aldo Dagnino is a senior principal scientist in soft- ing the text; and Jen Dix for prooﬁng. ware engineering at the US Corporate Research

December 2004 33 Center of ABB. His research interests include soft- David Kiefer is an engineering manager at ware architectures, software processes, and knowl- Motorola. His research interests include public edge-based technologies. Dagnino received a PhD safety communication systems with an emphasis in systems design from the University of Waterloo, on mission-critical voice over IP. Kiefer received a Canada. Contact him at [email protected]. BS in computer engineering from the University of com. Illinois at Chicago. Contact him at David. Kiefer@ motorola.com. Christina Wallin is a software engineering consul- tant. She was previously at ABB and is now at John May is a principal staff engineer at Motorola. Process Key. Her research interests include software His research interests include agile methods, soft- development processes. Wallin received a Licenci- ware productivity metrics, and call processing design ate in computer science from the University of patterns. May received an MS in engineering from Mälardalen, Sweden. Contact her at christina. Cornell. Contact him at [email protected]. [email protected]. Tuomo Kähkönen is a process development man- Michael Stupperich is a senior researcher at Daim- ager at Nokia Technology Platforms. His research lerChrysler. His research interests include engi- interests include process modeling, process assess- neering processes for embedded systems, distrib- ments, and agile software development methods. uted software engineering, and agile process mod- Kähkönen received an MS in industrial engineer- els. Stupperich received a Diploma in computer sci- ing and management from Lappeenranta Univer- ence from the University of Karlsruhe. Contact him sity of Technology, Finland. Contact him at tuomo. at [email protected]. [email protected].

34 Computer