focusreports from the field Launching Extreme Programming at a Process- Intensive Company James Grenning, Object Mentor his is a story about starting a project using an adaptation of XP in a company with a large formal software development process. De- fined Process Systems is a big company (the name is fictitious). The T division I worked with was developing safety-critical systems and A company that was building a new system to replace an existing legacy product. The project has traditional was an embedded-systems application running on Windows NT and was part formal of a network of machines that had to collaborate to provide services. processes launched a Through a systems engineering effort, DPS What we were facing project using divided the system into subsystems, each of The standard practice in the division was many Extreme which was later designed by a development created in response to past and current Programming team. I was brought in to help one of the problems. Most of the developers had one practices. The teams start its part of the project using iter- to three years’ experience. The more senior ative development, use cases, and object- developers had the role of reviewing and author covers oriented design techniques. approving the work of the less experienced how XP was Shortly after starting this project, I spent developers. To their credit, the review team proposed to a week in XP Immersion I, a one-week in- took the formal review process very seri- management, tensive training class in the techniques and ously. They were good at it: they captured philosophy of Extreme Programming.1 En- issues and defects on the Web, prepared re- how the project thused by XP, I talked to the DPS team viewers, and held crisp review meetings. seed began and about applying some XP practices to our In the world of Big Design Up Front and grew, and some work. The company had already decided to phase containment, these guys were good. I of the issues try iterative development and OO tech- could end this article right now except for niques, departing from the division’s stan- one problem: all this process added over- the team faced dard process. They were game for some- head to the development of software. To de- during its first thing different, but how different? We sign something, they needed to figure out six months. decided to take the idea of incorporating the design, document it in Rose, schedule a XP practices to the director of engineering. review meeting, and distribute materials to 0740-7459/01/$10.00 © 2001 IEEE November/December 2001 IEEE SOFTWARE 27 review. Then reviewers had to review the dex card. We decided to choose our battles. materials and enter issues on the Web, have We needed to get some of the beneficial The need for a review meeting, document the meeting practices into the project and not get hurt outcome, repair the defects and then close by leaving other practices behind. We did documentation them on the Web, fix documents, and have not omit practices that we didn’t feel like was ingrained the changes reviewed again. doing; we tried to do as many as we could. in the culture, However, all this process work was not We used the practices and their interactions keeping bugs out of the product. Unrealistic as ways to sell around the objections. so we expected deadlines and surprises late in the project We started by identifying the project’s concern over were taking their toll. Products were deliv- goals—to build a working product with re- ered late. Engineers were just getting their liable operation and timely delivery, with XP’s lack skills to a decent technical depth, but they enough documentation to enable effective of formal were also burning out and heading for sys- maintenance (no more, no less), and with documentation. tems engineering or management. understandable source code. This was as The team struggled with how to begin the objectionable as motherhood and apple pie. new project. Its requirements were in prose The standard process would identify the format and fully understood only by the per- same objectives. son who wrote them. We all agreed that a reliable working To summarize: the existing process had a product was a critical output of the project. lot of overhead, deadlines were tight, engi- This was particularly important, as this was neers were running away, requirements were a safety-critical system. A tougher question partially defined, and they had to get a project was, what was enough documentation? This started. With all these issues, something had to was where it got interesting. This applica- change. Did they need something extreme like tion was not your typical XP target applica- XP? I believed and hoped XP would help. tion—it was part of a larger system that mul- tiple groups were developing at multiple Choosing your battles sites. These other groups were using the The DPS culture values up-front require- standard, waterfall-style DPS process, not ments documents, up-front designs, reviews, XP or short-iteration development. We had and approvals. Writing the product features a potential impedance mismatch between on note cards, not doing any up-front de- the XP team and the rest of the project. sign, and jumping into coding were not go- ing to be popular ideas. To people unfamil- How much documentation? iar with XP, this sounded a lot like hacking. Proposing no documentation would end How did we get by these objections? the conversation. We decided to keep the Having been introduced to XP, the group conversation going and answer a question understood what the main objections would with a question. What did we want from be as we tried to sell XP to the management our documentation? We needed team. Like good lawyers, we prepared an- ticipated questions along with their answers I enough documentation to define the for our presentation. We expected that the product requirements, sustain technical decision makers would consider some of the reviews, and support the system’s main- practices dangerous and unworkable at tainers; DPS. The need for documentation was in- I clean and understandable source code; grained in the culture, so we expected con- and cern over XP’s lack of formal documenta- I some form of interface documentation, tion. Can the code be the design? Can we due to the impedance mismatch be- really build a product without up-front de- tween groups. sign? What if there is thrashing while refac- toring? What about design reviews? These answers did not all align with XP out of To paraphrase Kent Beck, one of XP’s the book, but they kept the conversation go- originators, “do all of XP before trying to ing. XP is not antidocumentation; it recog- customize it.” I think that is great advice, nizes that documentation has a cost and that but for this environment we would never not creating it might be more cost-effective. have gotten the okay to mark up the first in- This, of course, violates conventional wisdom. 28 IEEE SOFTWARE November/December 2001 After acknowledging and addressing the given to the maintainers describes the state project’s objectives, I led the team through of the software at the time it was shelved or the cost-of-change pitch from Beck’s Ex- transferred. This document can and should Documentation treme Programming Explained.1 The direc- be written in a way that avoids needing fre- tor, the manager, and some senior technol- quent modification. As maintenance pro- and reviews ogists agreed that XP addressed many of ceeds, the document will likely be neglected. were going to their current development problems. They Make the document high-level enough so be the big also thought XP right out of the book that the usual maintenance changes and bug would not work for them. What did we fixes do not affect it. Let the documentation roadblocks. want to do differently? guide the future developers to the right part Documentation and reviews were going of the code—then they can use the high- to be the big roadblocks. We heard, “Re- quality, readable, simple source code to quirements on note cards!?!” “I can’t give a work out the details. stack of note cards to the test team.” “Bob Following this strategy will not result in a in firmware needs the cards too.” “Someone huge document. Remember, you have some will lose the cards.” I noticed that the com- of the best detailed documentation available pany’s “standard” process allowed use cases in the form of automated unit tests—work- in the form described by Alistair Cock- ing code examples of exactly how to use burn.2 This is a text-based method, similar each object in the system. XP does not pro- to user stories but with more details. Other hibit documentation; just realize it has a cost DPS groups needed to look at the use cases, and make sure it is worth it. You can plan so we decided not to fight that battle—we documentation tasks into any iteration. The had enough lined up already. We decided to advice here is to document what you have use use cases. built, not what you anticipate building. Another objection was “We need docu- The next follow-on objection was that mentation for the future generations of en- we’d never do the document at the end of gineers that will maintain the product we the project. My reply: So, you would rather are building. We need our senior people to do a little bit at a time, and have to keep look at the design to make sure your design changing and rewriting it? Doesn’t that will work.” Our answer was that a good sound like it would take a lot of time? It way to protect future software maintainers does! So the management team must stick to is to provide them with clean and simple its guns and do the high-level documenta- source code, not binders full of out-of-date tion task at the end of the project.