Extreme Programming and Agile Software Development Methodologies

Lowell Lindstrom, Object Mentor, Inc., [email protected] Ron Jeffries, xprogramming.com, [email protected] ______

As a stakeholder of a software project, how does this sound to you? You can have releases as often as you like. The small number of defects is unprecedented. All of the features in the system are the most valuable ones to your business. At anytime, you have access to complete, accurate information as the status of any feature and of the quality of the system as a whole. The team developing your project works in an energized space with constant communication about the project. You are not dependent on any one or even two programmers for the continued success of the project. If your needs change, the development team welcomes the change of direction. As a developer of a software project, how does this sound to you? No one estimates your tasks but you, period! You always have access to a customer to clarify details about the features you are implementing. You are free (and required) to clean up the code whenever necessary. You complete a project every two weeks. You can work in any part of the system that you wish. You can pick who will help you on any given task. You are not required to work constantly long hours. Does this sound to good to be true? Teams are achieving these advantages using a relatively new set of software methodologies. Collectively, they are referred to as Agile Software Development Methodologies. The most pervasive is Extreme Programming. This chapter will introduce you to these exciting, popular, yet controversial new approaches to software development. ______

BACKGROUND as the current economic downturn limits capital investment, innovators and Trends In Software Development entrepreneurs are pushing the limits in areas of biotechnology and nanotechnology. The last half-century has seen a dizzying progression of technical advancement in the Supporting all of these advances is software areas of computer, software, and running on some kind of computer. From communications technology. With each the spreadsheets to anti-lock brakes to advance came rapid changes in the way phones to toys, logic that was once society works and lives. The impact of implemented in mechanics, circuitry, or technology is increasingly pervasive. Even pencil and paper, is now a set of instructions

Copyright 2003 © Lowell Lindstrom and Ron Jeffries Copyright 2003 © CRC Press LLC

controlling one or many computers. These computers communicate with each other Despite these delivery problems, strong over networks ignorant to the limits of demand seems to hold steady. Reports still geography and even wires. The notion of a suggest a shortage of software professionals program running on a computer is largely a and college graduates, despite the implosion memory as the emergence of distributed of the Internet industry slowing the growth computing models, most recently Web of demand and the emergence of offshore Services, allow many different computers to programming market increasing supply. participate in the “running” of a program or system to yield a given output. Improvement Remains Elusive Efforts to improve the success rate of In this explosive environment, software software projects have since the first bug professionals have the challenge to deliver a was detected. Recently, these efforts have seemingly infinite backlog of software focused on four distinct part of the software projects, while keeping abreast with the development process: requirements latest advances. The results are debatable at gathering, designing and developing the best. Survey after survey continues to software, testing the results, and overall confirm that most software projects fail project management. Formal requirements against some measure of success. Most definition and analysis addressed the software developers have many more stories problem of requirements that were of failure than of success. Given the friction incomplete or did not reflect the needs of the and finger pointing that accompanies the end customer. Formal design before of a failed project, it is difficult to research implementation addressed the goals of reuse, the causes of software failures. However, consistency of operation, and reducing typically, projects fail for the one of more of rework. Testing catches defects before they the following: reach the users. Project Management ? Requirements that are not clearly addressed the problem of coordinating the communicated efforts of multi-department teams. These ? Requirements that do not solve the areas of focus follow a logical approach to business problem process improvement: improve the quality ? Requirements that change prior to of the inputs (requirements), improve the the completion of the project quality of the output (designing and ? Software (code) that has not been developing, project management), and tested improve the detection and elimination of ? Software that has not been tested as defects prior to shipping (testing). Methods the user will use it and tools focusing on these four distinct ? Software developed such that it is areas of software development have hard to modify. proliferated. ? Software that is used for functions for which it was not intended For some projects, these efforts have been ? Projects not staffed with the effective. For others, it yielded silos of resources required in the project plan responsibility, with poor communication between the groups and distributed ? Schedule and scope commitments are made prior to fully understanding ownership and accountability. If a project is late, it is easy for the programmers to blame of the requirements or the technical risks. the requirements gatherers and vice versa. If

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 2

the users detect defects, finger pointing ensues between developers and testers. A few people started to author papers about Project Management techniques try to better these disciplined, yet lighter approaches to coordinate the activities of the multiple software development. They called them groups involved in delivering the project, Extreme Programming, SCRUM, Crystal, but add yet another silo and area of Adaptive, etc. Different authors emphasized accountability. The most popular project different aspects of software development. management techniques focus on developing Some focused on approaches to planning a plan and sticking to the plan. This and requirements, some focused on ways to improves coordination, but reduces the write software that could be changed more ability of the project to adapt to new easily. Some focused on the people information regarding the requirements or interactions that allow software developers the implementation details. to more easily adapt to their customers’ changing needs. These various efforts Emergence Of Agile Methods created a focal point for a community that furthered the set of practices that succeed The additional process steps, roles, and without many of the activities and artifacts artifacts helped many teams to enjoy higher required by more defined methodologies. success rates and more satisfied customers. Unfortunately, many projects failed In the fall of 1999, Extreme Programming, attempting to use the same techniques. Embrace Change1, was published and the Some projects got lost in the documents and trend had found its catalyst. In early 2001, never implemented any code, missing the the different innovators that were creating window of opportunity for the software. different agile methodologies held a retreat Others did not leave enough time at the end and scribed the Agile Manifesto for for implementation and test, and delivered Software Development.2 By the spring of systems inconsistent with the documents and 2002, Computerworld.com ran the following designs on which most of the project time headline: "More than two-thirds of all was spent. corporate IT organizations will use some form of ‘agile’ software development At the same time, numerous projects were process within 18 months, Giga Information very successful that did not follow methods Group predicted this week at its application with binders of documents, detailed designs, development conference here."3 and project plans. Many experienced programmers were having great success AGILE METHODOLOGIES without all of these extra steps. The At the retreat in early 2001, a number of determining factor of project success leaders of the agile software development seemed more and more to be the people on movement held a retreat to discuss their the project, not the technology or the approaches and to explore the methods that were being used. After all, commonalities and differences. What people end up writing the software at some emerged was the Agile Manifesto for point. To some, the developers that did not Software Development. The manifesto embrace the new methodologies appeared to articulates core values and principles that be undisciplined and indifferent to quality, guide agile methodologies. despite their successes at delivering quality software that people wanted to use.

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 3

Agile Manifesto ? Working software is the primary We are uncovering better ways of measure of progress. developing software by doing it and ? Agile processes promote sustainable helping others to do it. Through this development. The sponsors, work we have come to value: developers, and users should be able to maintain a constant pace Individuals and interactions over indefinitely. processes and tools ? Continuous attention to technical Working software over comprehensive excellence and good design enhances documentation agility. Customer collaboration over contract ? Simplicity – the art of maximizing negotiation the amount of work not done-is Responding to change over following a essential. plan ? The best architectures, requirements, and designs emerge from self- That is, while there is value on the organized teams. items on the right, we value the items ? At regular intervals, the team reflects on the left more. on how to become more effective, then tunes and adjusts its behavior Principles behind the Agile Manifesto accordingly.

We follow these principles: Agile Methods The number of methods that claim to align ? Our highest priority is to satisfy the the Agile Manifesto will continue to grow customer through early and with the popularity of the agile software continuous delivery of valuable methodologies. The early initial software. methodologies include4: ? Welcoming changing requirements, even late in development. Agile ? Extreme Programming processes harness change for the ? SCRUM customer’s competitive advantage. ? Crystal ? Deliver working software frequently, ? Feature Driven Development from a couple of weeks to a couple ? Lean Development of months, with a preference to ? Adaptive Software Development shorter time scales. ? DSDM ? Business people and developers must work together daily throughout the EXTREME PROGRAMMING project. ? Build projects around motivated Extreme Programming (XP) is the most individuals. Give them the widely used agile methodology. XP shares environment and support they need, the values espoused by the manifesto but and trust them to get the job done. goes further to specify simple set of ? The most efficient and effective practices. Where as many popular method of conveying information to methodologies try to answer the question and within a development team is “What are all of the practices I might ever face-to-face conversation.

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 4

need on a software project?” XP simply In Extreme Programming, every contributor asks, “What is the simplest set of practices I to the project is a member of the “Whole could possibly need and what do I need to Team”, a single do to limit my needs to those practices?” business/development/testing team that handles all aspects of the development. The significance of this difference cannot be Central to the team is the “Customer”, one understated. The most frequent critique of or more business representatives who sit XP is that it is too simple to work beyond a with the team and work with them daily. narrow set of project criteria. Yet, the set of known successes with XP continues to Extreme Programming teams use a simple stretch the breadth of projects applicable for form of planning and tracking to decide XP. It would seem that the parameters that what to do next and to predict when any we use to determine what methods are desired feature set will be delivered. appropriate for what project are still Focused on business value, the team inadequate. produces the software in a series of small fully integrated releases that pass all the To many, XP is a set of twelve tests that the Customer has defined. The interdependent software development core XP practices for the above are called practices. Used together, these practices Whole Team, Planning Game, Small have had much success, initially with small Releases, and Acceptance Tests. There are teams, working on projects with high specific recommendations for all of these, degrees of change. However, the more one which we’ll discuss briefly here, and as we works with XP, the more it is apparent that go along. the practices don’t capture the essence of XP. As with the heavier methods, some Extreme Programmers work together in teams have great success with the XP pairs and as a group, with simple design and practices, some less so. Some larger teams obsessively tested code, improving the have greater success than smaller ones. design continually to keep it always just Some teams with legacy code have success; right for the current needs. others do not. There is something more The core XP practices here are Pair than just the practices that enable teams to Programming, Simple Design, Test-Driven succeed with XP. This extra attribute of XP Development, and Design Improvement. is the XP Values. The Extreme Programming team keeps the system integrated and running all the time. What Is Extreme Programming? The programmers write all production code Extreme Programming is a discipline of in pairs, and all work together all the time. software development based on values of They code in a consistent style so that simplicity, communication, feedback, and everyone can understand and improve all the courage. It works by bringing the whole code as needed. team together in the presence of simple The additional practices here are called practices, with enough feedback to enable Continuous Integration, Team Code the team to see where they are and to tune Ownership, and Coding Standard. the practices to their unique situation. The Extreme Programming team shares a common and simple picture of what the

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 5

system looks like. Everyone works at a pace that can be sustained indefinitely. Methodology Values Principles Practices These practices are called Metaphor, and CMMI® No No YES Sustainable Pace. (KPAs) SA/SD No No YES RUP® No YES YES XP Values Agile YES YES NO XP YES YES YES The XP Values are Communication, Simplicity, Feedback, and Courage. CMMI: Capability Maturity Model Integration, Software Engineering Institute “The essence [of XP] truly is simple. SA/SD: Structured Analysis/Structured Design RUP: Rational Unified Process, IBM Rational Be together with your customer and fellow programmers, and talk to each TABLE 1: Comparison of Methodologies other. Use simple design and programming practices, and simple Organization methods of planning, tracking, and reporting. Test your program and On a project using XP, there are two explicit your practices, using feedback to roles or teams defined: the Customer and steer the project. Working together 5 the Programmer. In keeping with the value this way gives the team courage.” of simplicity, most of the XP literature describes the customer as a single person These values guide our actions on the that can represent the requirements, project. The practices leverage these values acceptance criteria, and business value for to remove complexity from the process. the project. In practice, it is a team of people that communicate with one voice The impact of the XP Values is significant with The Programming Team. As such, this and unique. XP remains the only role is also referred to as The Customer methodology that is explicit in its values and Team. This chapter will use the term practices. This combination gives specific “Customer” to describe the role, whether guidance on what (the practices) to do on a acted on by an individual or a team. The project, but also on how to react (defer to the Programmer is a member of the values) when the practices don’t seem to be Programming Team that implements The working or are not sufficient. Most methods XP Customer Team’s requirements. Again, are specific on practices, some specify 6 the convention will be to use the term principles, but few combine both . For “Programmer” to describe an individual or example, CMMI describes Key Practice the team. Areas (KPAs), but does articulate a set of values or principles. RUP provides guiding On all but the smallest projects, there will principles, such as Develop Iteratively, but also be a Management Team, which does not include values that give guidance allocates resources for the teams, manages beyond the software development practices. the alignment of the project to the goals of How these values are used to guide the team the business, and removes any obstacles in its use of the practices is described later in impeding the team’s progress. Extreme the section Fitting XP to Your Project. Programming does not specify management practices. XP attempts to simplify

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 6

management by empowering the Customer Rhythm Of An Xp Project and Programmer to make most of the An XP project proceeds in iterations of 2 decisions regarding the project. Often, XP weeks in length. Each iteration delivers teams are described as self-managing. As fully developed and tested software that projects grow in size and complexity, more meets the most valuable small set of the full management is typically required to project’s requirements. Figure 1 shows the coordinate the efforts of different teams. primary activities of the Customer and Many of the other emerging agile Programmer during the initial iterations of a methodologies are focusing more attention project. The project proceeds in a steady 7 on management practices, such as Scrum , rhythm of delivering more functionality. 8 Lean Development , and Extreme Project The Customer determines at what point in 9 Management . time the full system can be released and deployed.

Week 0 Weeks 1and 2 Weeks 3 and 4 Week ‘n’ Preparing The rhythm for the first Iteration 1 Iteration 2 Continues… iteration

Exploration Prep for next Iteration Prep for next Iteration Story writing Manage Release Schedule Manage Release Schedule Alignment Communicate with Communicate with End Users/Stakeholders End Users/Stakeholders Customer Customer Team Tests Customer Tests Customer Tests

Daily Stand up Daily Stand up Agree on Sit Together Sit Together process Discuss detailed requirements Discuss detailed requirements Run Customer Tests Run Customer Tests Exploration Continuously Continuously

Tasks Tasks Spikes Programming Continuous Builds Continuous Builds Team Development Some Spikes Some Spikes Environment Estimation of new stories Estimation of new stories Preparations for later iterations for later iterations

FIGURE 1: The Rhythm of an XP Project

CORE PRACTICES use feedback from their project to adapt, There are twelve core practices that define add, and eliminate practices as needed. A Extreme Programming. Teams new to XP number of other practices are popular on XP should focus on using and developing skill teams and some of these are described later. with these practices. Over time, as the team matures in its use of XP, it will continue to The practices can be described as a cycle of checks its proficiency with these practices, activities. The inner circle describes the but will also tailor the practices to their tight cycle of the Programmers. The outer project needs. XP teams are encouraged to loop describing the planning cycle that

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 7

occurs between the Customers and and coordinate the delivery of quality Programmers. The middle loop shows software. practices that help the team communicate

Whole Team (Sit

Collective Coding Ownership Test-First Standard Development Design Planning Customer Tests Pair Improvements (Acceptance Game Programming (Refactoring)

Continuous Simple Sustainable Integration Design Pace Metaphor

Small Releases

FIGURE 2: XP Practices and the Circle of Life

Whole Team external communication, and coordinating All the contributors to an XP project sit activities. None of these roles is necessarily together, as members of one team. This team the exclusive property of just one individual. must include a business representative -- the Everyone on an XP team contributes in any "Customer" -- who provides the way that they can. The best teams have no requirements, sets the priorities, and steers specialists, only general contributors with the project. It's best if the Customer or one special skills. of her aides is a real end user who knows the domain and what is needed. The team will Planning Game of course have programmers. The team will XP planning addresses two key questions in typically include testers, who help the software development: predicting what will Customer define the customer acceptance be accomplished by the due date, and tests. Analysts may serve as helpers to the determining what to do next. The emphasis Customer, helping to define the is on steering the project -- which is quite requirements. There is commonly a coach, straightforward -- rather than on exact who helps the team keep on track, and prediction of what will be needed and how facilitates the process. There may be a long it will take -- which is quite difficult. manager, providing resources, handling

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 8

There are two key planning steps in XP, done next is so complete, that XP projects addressing these two questions: tend to deliver more of what is needed, with less pressure and stress. Release Planning is a practice where the Customer presents the desired features to the Customer Tests programmers, and the programmers estimate As part of presenting each desired feature, their difficulty. With the costs estimates in the XP Customer defines one or more hand, and with knowledge of the importance automated acceptance tests to show that the of the features, the Customer lays out a plan feature is working. The team builds these for the project. Initial release plans are tests and uses them to prove to themselves, necessarily imprecise: neither the priorities and to the customers, that the feature is nor the estimates are truly solid, and until implemented correctly. Automation is the team begins to work, we won't know just important because in the press of time, how fast they will go. Even the first release manual tests are skipped. That's like turning plan is accurate enough for decision making, off your lights when the night gets darkest. however, and XP teams revise the release plan regularly. The best XP teams treat their customer tests the same way they do programmer tests: Iteration Planning is the practice whereby once the test runs, the team keeps it running the team is given direction every couple of correctly thereafter. This means that the weeks. XP teams build software in two- system only improves, always notching week "iterations", delivering running useful forward, never backsliding. software at the end of each iteration. During Iteration Planning, the Customer presents Small Releases the features desired for the next two weeks. XP teams practice small releases in two The programmers break them down into important ways: tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on First, the team releases running, tested the amount of work accomplished in the software, delivering business value chosen previous iteration, the team signs up for by the Customer, with every iteration. The what will be undertaken in the current Customer can use this software for any iteration. purpose, either for evaluation or even for release to end-users (which is highly These planning steps are very simple, yet recommended). The most important aspect they provide very good information and is that the software is visible, and given to excellent steering control in the hands of the the customer, at the end of every iteration. Customer. Every couple of weeks, the This keeps everything open and tangible. amount of progress is entirely visible. There is no "ninety percent done" in XP: a feature Second, XP teams release software to their story was completed, or it was not. This end-users frequently as well. XP Web focus on visibility results in a nice little projects release as often as daily, in-house paradox: on the one hand, with so much projects monthly or more frequently. Even visibility, the Customer is in a position to shrink-wrapped products are shipped as cancel the project if progress is not often as quarterly. sufficient. On the other hand, progress is so visible, and the ability to decide what will be

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 9

It may seem impossible to create good It does take some practice to do well, and versions this often, but XP teams all over are you need to do it well for a few weeks to see doing it all the time. Seethe section on the results. Most programmers who learn Continuous Integration for more on this, and pair programming prefer it, so we highly note that these frequent releases are kept recommend it to all teams. reliable by XP's obsession with testing, as described here in Customer Tests and Test- Pairing, in addition to providing better code Driven Development. and tests, also serves to communicate knowledge throughout the team. As pairs Simple Design switch, everyone gets the benefits of XP teams build software to a simple design. everyone's specialized knowledge. They start simple, and through programmer Programmers learn, their skills improve, and testing and design improvement, they keep it they become move valuable to the team and that way. An XP team keeps the design to the company. Pairing, even on its own exactly suited for the current functionality of outside of XP, is a big win for everyone. the system. There is no wasted motion, and the software is always ready for what's next. Test-Driven Development Extreme Programming is obsessed with Design in XP is not a one-time thing, or an feedback, and in software development, up-front thing, but it is an all-the-time thing. good feedback requires good testing. XP There are design steps in release planning teams practice "test-driven development", and iteration planning, plus teams engage in working in very short cycles of adding a quick design sessions and design revisions test, then making it work. Almost through refactoring, through the course of effortlessly, teams produce code with nearly the entire project. In an incremental, 100 percent test coverage, which is a great iterative process like Extreme Programming, step forward in most shops. (If your good design is essential. That's why there is programmers are already doing even more so much focus on design throughout the sophisticated testing, more power to you. course of the entire development. Keep it up, it can only help!) It isn't enough to write tests: you have to run Pair Programming them. Here, too, Extreme Programming is In XP, two programmers, sitting side by extreme. These "programmer tests", or "unit side, at the same machine, build all tests" are all collected together, and every production software. This practice ensures time any programmer releases any code to that all production code is reviewed by at the repository (and pairs typically release least one other programmer, resulting in twice a day or more), every single one of the better design, better testing, and better code. programmer tests must run correctly. One hundred percent, all the time! This means It may seem inefficient to have two that programmers get immediate feedback programmers doing "one programmer's job", on how they're doing. Additionally, these but the reverse is true. Research on pair tests provide invaluable support as the programming shows that pairing produces software design is improved. better code in about the same time as programmers working singly. That's right: Design Improvement two heads really are better than one! Extreme Programming focuses on delivering business value in every iteration. To

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 10

accomplish this over the course of the whole Infrequent integration leads to serious project, the software must be well designed. problems on a software project. First of all, The alternative would be to slow down and although integration is critical to shipping ultimately get stuck. So XP uses a process of good working code, the team is not practiced continuous design improvement called at it, and often it is delegated to people who "refactoring". 10 are not familiar with the whole system. Second, infrequently integrated code is often The refactoring process focuses on removal -- or usually -- buggy code. Problems creep of duplication (a sure sign of poor design), in at integration time that are not detected by and on increasing the "cohesion" of the any of the testing that takes place on an code, while lowering the "coupling". High unintegrated system. Third, weak integration cohesion and low coupling have been process leads to long code freezes. Code recognized as the hallmarks of well- freezes mean that you have long time designed code for at least thirty years.11 The periods when the programmers could be result is that XP teams start with a good, working on important shippable features, but simple design, and always have a good, that those features must be held back. This simple design for the software. This lets weakens your position in the market, or with them sustain their development speed, and, your end users. in fact, generally increase speed as the project goes forward. Collective Code Ownership On an Extreme Programming project, any Refactoring is, of course, strongly supported pair of programmers can improve any code by comprehensive testing that ensures that at any time. This means that all code gets the as the design evolves, nothing is broken. benefit of many people's attention, which Thus the customer tests and programmer increases code quality and reduces defects. tests are a critical enabling factor. The XP There is another important benefit as well: practices support each other: they are when code is owned by individuals, required stronger together than separately. features are often put in the wrong place, as one programmer discovers that he needs a Continuous Integration feature somewhere in code that he does not Extreme Programming teams keep the own. The owner is too busy to do it, so the system fully integrated at all times. We say programmer puts the feature in his own that daily builds are for wimps: XP teams code, where it does not belong. This leads to build multiple times per day. (One XP team ugly, hard-to-maintain code, full of of forty people builds at least eight or ten duplication and with low (bad) cohesion. times per day!) Collective ownership could be a problem if The benefit of this practice can be seen by people worked blindly on code they did not thinking back on projects you may have understand. XP avoids these problems heard about (or even been a part of) where through two key techniques: the the build process was weekly or less programmer tests catch mistakes, and pair frequently, and usually led to "integration programming means that the best way to hell", where everything broke and no one work on unfamiliar code is to pair with the knew why. expert. In addition to ensuring good modifications when needed, this practice spreads knowledge throughout the team.

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 11

Coding Standard projects are neither productive nor produce XP teams follow a common coding quality software. XP teams are in it to win, standard, so that all the code in the system not to die. looks as if it was written by a single -- very competent -- individual. The specifics of the OTHER COMMON PRACTICES standard are not important: what is The core practices of Extreme Programming important is that all the code looks familiar, do not specify all of the activities that are in support of collective ownership. required to deliver a software project. As teams use XP, many find that other practices Metaphor aid to their success, in some cases as Extreme Programming teams develop a significantly as some of the core practices. common vision of how the program works, The following are some of other practices which we call the "metaphor". At its best, commonly used on successful XP teams. the metaphor is a simple evocative description of how the program works, such Open Workspace as "this program works like a hive of bees, To maximize communication amongst the going out for pollen and bringing it back to Whole Team, they work together in an Open the hive" as a description for an agent-based Workspace. This is a large room, with information retrieval system. tables in the center that can typically seat Sometimes a sufficiently poetic metaphor two to four pairs of developers. Figure 3 does not arise. In any case, with or without for shows an example of an XP workstation vivid imagery, XP teams use a common for 3 pairs of developers. By sitting system of names to be sure that everyone together, all of the team members can understands how the system works and establish instant communication when where to look to find the functionality you're needed for the project. Teams establish their looking for, or to find the right place to put own rules concerning their space in order to the functionality you're about to add. ensure that everyone can work effectively. The walls of the Open Workspace are used Sustainable Pace to display information about the project. Extreme Programming teams are in it for the This will include big visible charts of long term. They work hard, and at a pace metrics like passing acceptance tests and that can be sustained indefinitely. This team productivity. There may be designs means that they work overtime when it is drawn on whiteboards. Project status will is effective, and that they normally work in displayed so that any participant or such a way as to maximize productivity stakeholder of the project can always see week in and week out. It's pretty well progress. understood these days that death march

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 12

FIGURE 3: Extreme Programming Workstation12

Retrospectives Self-Directed Teams The XP practices provide feedback to the A practice that is common amongst most of team as to the quality of the code and its the agile methods is self-directed teams. alignment to the Customers needs. The The best people to make decisions about the team also needs feedback on how it is project are those closest to the details, as performing. Is it following the practices long as they have an understanding of the with discipline? Are there adaptations to the overall goals of the project. Open practices that would benefit the team? The communication allows team members to practice commonly used for this is the have the information required to make Retrospective13. After each iteration, the decisions. Managers are part of the team does a short reflection on what went communication loop, but are not bottlenecks well during the iteration and what should be in the decision making flow. improved in the next iteration. After a release of the product, a more in depth Customer Team Retrospective is performed on the whole As XP is used on projects with more project. complex requirements, a team performs the Customer function. For larger or more complex projects, the Customer team may even exceed the Programming team in size. Some of the challenges faced by the

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 13

Customer team include communicating with Simplicity and balancing the needs of multiple Is the team comfortable with simple stakeholders, allocating resources to the solutions? Can the team implement without appropriate projects or features, ensuring a complete design the system prior to feedback to ensure that the requirements coding? Is the team comfortable with some implemented achieve the stakeholders’ ambiguity as to the exact requirements and goals. The specific Customer Team designs? Can the team adapt often to practices are still emerging in the agile changing requirements? Is the team community. The practices are guided by the working new code or code that is well same values as the other XP practices. designed and refactored?

Feedback Can the team get feedback on its tasks and FITTING XP TO YOUR PROJECT deliverables often? Does the team accept feedback constructively? When there are Is My Project A Good Fit For XP? problems, does the team focus on the Probably the most commonly debated process to identify root causes (rather than question regarding Extreme Programming is the people)? How often does the team whether it can be used successfully on a integrate, build, and test the complete particular type of project. Experience is software system? proving that, as with other approaches to software development, the limitations often Courage include both the characteristics of the Does the organization encourage individuals project, the people on the team, and the to not fear failure? Are individuals and organization in which they work. To teams encouraged to show initiative and evaluate whether the XP practices can help a make decisions for their projects? Are team achieve greater success on their organizational boundaries easily crossed to project, consideration must be given to the solve problems on the project? project characteristics, the people on the team, and the cultures of the organizations Typically, The greater the degree to which involved in the project. the team can answer, “YES” to these questions, the fewer changes are required The XP Values can be used as a template to and the easier it is for the team and test the fit of XP to a project, team, and organization to adopt XP. Some specific organization. Simply evaluate the degree to project and team guidelines for getting which each value is current held by the team started are provided next. and the organization. GETTING STARTED Communication When selecting an initial project on which to Does the team communicate constantly and try XP, consideration must be given to the effectively? Does this communication challenges of using the new practices. New extend to their customer? Is the team’s practices introduce risk to a project. Care software readable and understandable (i.e. is must be taken to select an initial project that it easy for Programmers to communicate is not burdened by all of the most difficult with the code)? obstacles to using XP, but does address enough typical obstacles such that the

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 14

success of the initial project can provide the The simplest way to reduce risk on an initial basis for expanding to the rest of the project is maximize the skill of the team as organization. quickly as possible. This can be achieved through recruiting team members that are Although most initial XP projects are not already skilled in XP, training, or this fortunate, ideally, the initial project will experienced coaching for an inexperienced have many of the following characteristics: team. ? Primarily new code versus legacy updates ? An identified and available source of ADAPTATIONS requirements and feedback (i.e. on- site customer) As teams begin adopting the XP practices, ? Delivers important business value numerous obstacles and constraints must be and has management visibility confronted. The team may have trouble ? Uses an OO language/environment having access to the Customer everyday. ? Is typical of the projects the The team may have trouble co-locating to an organization will be doing in the Open Workspace. The team may be so large future that communicating without formal ? Has a co-located team in an open documentation is not feasible. How do we workspace adjust? Must we abandon XP? The XP ? Can be delivered to the end-user Values guide teams in solving these process incrementally, at least every 4-6 problems on their projects. weeks The Courage value guides us to aggressively In selecting the initial XP Project team, the confront and remove any obstacles that main attribute of the team members should would add steps, artifacts, or complexity to be a strong commitment to delivering the the process. This often means letting project and achieving its goals using the new common sense outweigh bureaucracy. For practices. Some healthy skepticism about example, teams some times do not feel XP is acceptable, as long as it the team empowered to change the physical work members are willing to use the practices and environment to have an Open Workspace let data and experience from the project (i.e. change the cubicles). Often, a little guide any adaptations. The team ideally will courage, negotiating, and a power have a few technical leaders familiar with screwdriver will remove this obstacle. other projects in the organization, but it is Some teams struggle to have a Customer not desirable to have a team full of the most sitting with the team. The programmers senior people. XP is a collaborative develop from a requirements document and approach to development and as such, the have never spoken to a Customer. Although initial project will benefit from members the thought of having a customer present is with strong “soft” skills, who prefer desirable, the logistics can seem impossible, collaborative work environments. Beyond particularly if the best person to sit with the these characteristics, the team should be team does not live near the team or is representative of teams that the organization constantly traveling. Often, with a slight will use in the future. reorganization and a modified communication infrastructure, a customer

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 15

can be identified that can sit with the team by the team might yield the ideas in the on a frequent basis. Impact column of Table 2. The team discusses ways to adapt the process that is Of course, courage can only take us so far. guided by the values, yielding something There will be constraints that interfere with like Adaptation Alternatives column. our ability to implement the practices as described. A common example is legacy Each alternative that the team considers is code. Many teams work with large code checked for its alignment to the values. As bases that do not have tests and are in dire misaligned example, an alternative that need for Design Improvement. We want to states “all legacy code changes must be aggressively move to the state where all of approved by a Change Control Board (CCB) the code has passing tests, is understandable prior to implementation” may be viable, but and well designed. The initial attempt is to it is not Simple to implement; it reduces the rapidly get the code up to our new standard. frequency of feedback while we wait for the Can we toss it and rewrite it? Would it CCB to meet; and takes empowerment away really be that expensive and time consuming from the programmers, reducing their to fix it? Is there other, cleaner code Courage. Other alternatives that address the available that we can replace it with? Very constraint that align closer to the XP Values often, the answers are NO, YES, and NO, are preferred. leaving the team no choice, but to live with the smelly code and improve as they can. By using this simple technique, teams adapt the XP Practices to their project and team The XP Values give the team a helpful, needs. The importance of starting with simple tool to deal with this difficult, yet Courage cannot be overstated. Many teams inevitable challenge. The constraint that have been able to achieve a level of causes a practice to be modified or simplicity in their practices beyond what abandoned is reviewed against each of the was thought possible. Although this may XP Values, using the following question: appear to introduce risk, Retrospectives after ‘‘how will the influence of this XP Value be each iteration mitigate that risk by helping diminished as a result?'' In the case of our the team understand where additional un-testable legacy code, a quick brainstorm adaptations are required.

______

SUMMARY The pace of change in the software development industry remains at a high rate. People continue to push the boundaries of known techniques and practices in an effort to develop software as efficiently and effectively as possible. Extreme Programming and Agile Software Methodologies have emerged as an alternative to comprehensive methods designed primarily for very large projects. Teams using XP are delivering software often and with very low defect rates. As the industry continues to evolve, we are likely to see additional insights on how to leverage collaborative work on more and more types of projects.

______

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 16

Constraint: Legacy Code Prevents Test-Driven Development Value Impact Adaptation Alternatives Communication Difficult to * Wiki14 pages to document the team’s communicate the understand of the code code’s’ intent and ∗ Reverse engineering tools to create design models of the code * Change pair partners at least twice a day. Simplicity Complexity restricts ∗ Target areas of the system that warrant some simple design simplification alternatives ∗ When changes are being made in a complex area, ensure that one of the pair partners is new to the code. Feedback It will take longer to be ∗ Ensure that what tests exist are run aware of and fix errors everyday ∗ Add at least one automated test every time a defect is fixed Courage Cannot proceed as ∗ When stories require changes to legacy aggressively with code, increase the amount of design certain simple design discussion during the Iteration Planning Meeting

TABLE 2: Adapting XP

1 Kent Beck, Extreme Programming Explained, Addison Wesley Longman, 2000. 2 www.agilemanifesto.org 3 Carol Sliwa, Agile programming techniques spark interest, Computerworld.com, March 14, 2002 4 Jim Highsmith, Agile Software Development Ecosystems, Addison-Wesley, 2002 provides a comparison of these methodologies. 5 Ron Jeffries, et al., Extreme Programming Installed, AddisonWesley Longman, 2001,Pg. 172.

6 It is likely true that skilled practitioners of most methods are guided by a set of values, perhaps dictated by the culture of the organization, perhaps dictated by the leadership of the team. It is the expression of the values as integral to the practices that makes XP unique. 7 Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, Prentice Hall, 2002 8 Mary Poppendieck, Lean Development: A Toolkit for Software Development Managers, Addison-Wesley, to be published in April 2003. 9 Rob Thomsett, Radical Project Management, Prentice Hall, 2002 10 Martin Fowler et al., Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999 11 for more information on good software design principles and their application on agile software projects, see Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Pearson Education, 2003. 12 Table design courtesy of The Oobeya Group, LLC www.oobeyagroup.com/collabriture 13 Norm Kerth, Project Retrospectives, Dorsett House, 2001 14 A Wiki is a web-based collaborative repository popular with XP teams. See www.wiki.org for more information.

Want to learn more? See www.oobeyagroup.com or www.xprogramming.com 17