Extreme Programming at the U.S. Strategic Command

The agile software development method called extreme programming (XP) has its enthusiasts and detractors, and the jury is still out on whether it is a better choice com-pared with the more popular agile approaches such as Scrum. Mindful of how important agility is for military software, the U.S. Strategic Command launched a pilot XP project.XP shares many principles in common with Scrum, including the early and continuous delivery of functionality, close collaboration between developers and end users, and responsiveness to changing requirements. XP developers are less plan-driven and do much less doc-umentation to define requirements. XP also features pair programming, in which two developers work together, often on the same computer, and frequent testing is a fundamental component.For the military projects pilot, the XP teams job was to add new search functionality to SKIWeb, the Commands strategic knowledge and information website used to share information about military operations and world events across the whole command and intelligence commu-nities. All team members were contractors, except for the government functional manager who served as user collaborator. The two program-mers sat next to one another in a cubicle, and the user collaborators office was on the same floor. Other team members were either in the same building or nearby, so no one was participating in virtual mode.The project got off to a rocky start when one of the two developers announced that shed tried pair programming before and wasnt willing to do it again. The team didnt try to enforce it but did encourage her to work closely with her programming partner to solve thorny logic prob-lems together. Other agile practices were welcomed and adopted easily. For instance, the practice of delivering frequent small releases rather than infrequent major ones was already in place. Having the customer on-site is another critical element, and the user collaborator was right down the hall.The daily meetings were very successful, but problems in work as-signments and communications arose. XP team members are supposed to be fully assigned to the project to avoid distractions, but this projects team members were often pulled off for other assignments or emergen-cies. Midway through, they found they needed someone with expertise in interface design, but that person was skeptical about joining the XP project, and communication suffered. One team member complained that there was resistance to change from a traditional hierarchy to the more collaborative XP style of communication.Research with undergraduates suggests that paired programmers do about as well as the best performer of the pair but no better, raising doubt about whether two heads are better than one for programming tasks. However, the students enjoyed the programming task more when work-ing in pairs, and the weaker member gained some confidence. Further research on XP suggests that paired programming itself may not be a key ingredient for XPs success. The factors that make XP work are really the collective ownership of the project by the whole team, the involvement of the client, and a strong focus on code standards and testing.In the U.S. Strategic Commands pilot, the team members percep-tions about the project were positive, despite the snags. They believed that the XP approach led to very good-quality software, even better than the team might have produced using the old approach. As more and more organizations switch to agile methods such as XP, we will bet-ter understand just what it is about these methods that makes them successful.

11-25. How did the U.S. Strategic Command adjust to unexpected issues as it implemented extreme programming?

11-26. What types of changes accompany the extreme programming methodology?

11-27. Why could a methodology such as extreme programming be good for a military project? What might be its disadvantages?

11-28. Does the research mentioned at the end of the case study influ-ence your view of XP?