COVER FEATURE Introducing an Agile Process to an Organization The transition from a plan-driven to an agile process affects not only the development team members, but also other teams, departments, and man- agement. The authors describe common pitfalls and effective approaches to making this change. Mike Cohn ince the publication of Kent Beck’s Extreme simple projects reached across many departments Mountain Goat Programming Explained,1 agile processes or functional areas. A failure to sell the process Software have grown increasingly popular. Agile change to any one area can negatively impact the processes allow for changing require- project’s outcome. Doris Ford S ments throughout the development cycle Through trial and error, we have discovered sev- Precision Projects and stress collaboration between software devel- eral approaches for successfully introducing agile opers and customers and early product delivery. processes to organizations. The “Agile Manifesto” establishes a common framework for these processes: Value individuals DEVELOPERS and interactions over processes and tools, working Most developers respond to the proposed intro- software over comprehensive documentation, cus- duction of an agile process with the appropriate tomer collaboration over contract negotiation, and combination of skepticism, enthusiasm, and cau- responding to change over following a plan.2 The tious optimism. Other developers, however, either processes most commonly considered agile include resist the change or overzealously jump into the pro- Extreme Programming (XP),1 Lean Development,3 ject without enough forethought. Either reaction Crystal,4 and Scrum.5-6 can cause problems. In Scrum, projects progress in a series of month- long iterations called sprints. Development teams Resistance meet with the client, or product owner, before each In general, agile processes value code production sprint to prioritize the work to be done and select the more than plan-driven processes do. In a plan-dri- tasks the team can complete in the upcoming sprint. ven process, developers might treat Unified During the sprint, the team stays on track by Modeling Language designs and other noncode holding brief daily meetings. At the end of each items as first-class artifacts. In an agile process, sprint, the team delivers a potentially shippable however, these items usually exist only to support product increment. Scrum is ideally suited for pro- the coding activity. jects with rapidly changing or highly emergent While introducing Scrum to various project requirements such as Web projects or product devel- teams, we invariably found programmers who opment for new markets. enjoy producing noncode artifacts far more than Over the past four years, we have introduced they are willing to admit. We also encountered pro- Scrum to seven organizations in four states. Some grammers who measure their contribution to a pro- of the projects were complex and involved distrib- ject by the number of meetings they attend. These uted teams. Others were straightforward and programmers go beyond “analysis paralysis” and involved small, colocated teams. However, even the actively seek opportunities to add formalized tasks 74 Computer Published by the IEEE Computer Society 0018-9162/03/$17.00 © 2003 IEEE back into an agile process. One programmer, for sprint types introduces just enough formality example, created a formal document type and that the teams can more clearly see their way attempted to coerce his peers into generating the through the project. As the teams become Teams using document for hundreds of cases when it was called more adept with the informality of the agile agile processes for in perhaps a dozen. process, they gradually drop the sprint types tend to make In such situations, it is best not to intervene. The concept. decisions more other team members can quickly assess the value quickly than of these activities and will not adopt them if they do Distributed development not help the overall development effort. Teams using agile processes tend to make plan-driven decisions more quickly than plan-driven teams. Micromanagement teams, relying on more frequent (and usually A surprising number of developers view using informal) communication to support this agile processes as an attempt to micromanage. pace. Because approaches like Scrum and XP accelerate A failed attempt to use an agile process in a pro- project cycles, developers typically interact with their ject with sites 2,000 miles apart taught us that orga- managers more frequently but for shorter periods. nizations should resist distributed development for In a plan-driven process, a manager might go a full at least the first two or three months after initiat- week without talking with a particular developer, ing an agile process. The companies involved in the but daily contact is the norm in most agile processes. merger that initiated the project needed to resolve Developers who view agile processes as micro- their political and cultural issues before developers management tend to perceive interactions with could succeed with a project shared across multi- their project managers as being about due dates and ple cities. missed deadlines. To avoid this problem, project If distributed teams must be combined, bringing managers should constantly demonstrate their as many people as possible together for the first desire to remove obstacles as quickly as possible week or two of the project can increase the likeli- and not complain if a task takes too long. hood of success. We have successfully used this Managers can be surprised, but should not be judg- approach on multiple distributed projects. mental, when told that a task will take longer than originally thought. The need for top talent Barry Boehm’s principle of top talent, “use bet- Transitioning from a heavyweight process ter and fewer people,”7 is central to an agile Some developers we encountered preferred process. Agile processes strip nonessential activi- heavyweight plan-driven processes because they ties from projects, leaving developers more time to believe they looked better on a resume. Because develop. these individuals do not have deeply held convic- Although the difference in productivity between tions about the process’s value, they can eventually the best and worst programmers on a team may be swayed by their coworkers’ opinions and actions. exceed the documented ratio of 10:1,8 the produc- A gradual transition from a heavyweight to an tivity difference matters most when the program- agile process can make the change easier on the mers are working on tasks essential to software development team. Some teams, when first intro- delivery. Productivity differences are irrelevant duced to Scrum, are overwhelmed to the point of when the programmers are engaged in nonessen- inaction by the freedom of not having a day-by-day tial activities. Gantt chart directing their work. When fully engaged and comfortable with an We have helped teams ease into Scrum by defin- agile process, a development team moves very ing a set of sprint types: quickly. Too many slow workers either slow the entire team or end up left behind by their faster col- • prototyping, leagues. • requirements capture, • analysis and design, Overzealous teams • implementation, and One team we worked with was overly enthusi- • stabilization. astic about a move to XP. At the project’s onset, team members aggressively began documenting We then work with the teams to define the arti- requirements by writing user stories, planning iter- facts that will result from each sprint type. Using ations, and pairing up for programming tasks. June 2003 75 They even moved out of their existing space receive on most agile process projects. As with pro- Agile processes and into an adjacent abandoned building bet- grammers, testers will see over time that an agile do not imply ter suited for XP. Unfortunately, they did all process is not synonymous with micromanagement. of this so quickly that the rest of the organi- We have encountered testers who secretly want making zation had no idea what they were doing, to be programmers and use a project’s early itera- decisions resulting in a number of problems. tions to sneak in some programming. We also have without Although agile processes promise greater worked with testers who either volunteer or are forethought. productivity once in place, productivity may coerced into writing unit tests for programmers. decrease during the transition while the team Especially during a project’s earliest iterations, you learns new techniques. Not having antici- should discourage testers from such inappropriate pated this decreased productivity, the team activities. First, if the tester knows enough about pro- chose to redouble its efforts when it occurred. gramming to program and you need another pro- Agile processes do not imply making decisions grammer, hire the tester. Second, writing a unit test without forethought, a distinction this overzealous for someone else may result in a useful test, but it team missed in its quest for speed and agility. To almost certainly loses some of the white-box advan- this team, Beck’s recommendation to “put in what tages inherent in self-written unit tests. you need when you need it”1 meant they needed to think only about an hour ahead. They didn’t have UPPER MANAGEMENT the discipline XP requires, and, while paying lip Upper management often presents unique chal- service to XP, they were actually doing nothing lenges to organizations wishing