Alistair Cockburn never told me about the “mother-in-law” feature in Crystal. It seems that on a Crystal Methods project in Germany, one of the developers occasionally finished new features during weekends. On Monday, he would return to work having implemented several new features that had been discussed but that no one had time to implement. Jens Coldewey, the project coach, knowing the developer had two kids at home who didn't want dad working away all the time, asked about the weekend work. “Well, my mother-in-law visited us this weekend,” the developer replied, “so I took some time with my laptop....” Jens reported that this particular mother-in-law, who probably never heard of the project, is still one of the project's most valuable team members.

Jens, a German consultant, has been working for several years on a project for the German division of the Italian insurance company Generali Group. The project was to develop a visionary, product-driven insurance system that included bid, contract management, and claims management features. The subproject that Jens consulted on, and that used Alistair's Crystal Clear method, was the product definition system (PDFS). According to Jens, with all the twists and turns that occurred as the product evolved, the project would have been cancelled using the company's standard methodology. Crystal provided the practices and the philosophy that enabled the project team and management to weather several major shifts in direction.

Normally, implementing a new insurance product takes two to three years. Market research, domain-level development, training, actuarial calculations, and inefficient organizational practices take two-thirds of that time. The remaining time is due to IT implementation of the new product—and the more innovative the product is, the greater the percentage of time IT implementation requires. The vision was to shorten the insurance product introduction period to six to eight months, a goal sought after but not yet achieved by Generali's competitors. The new product needed to support the entire insurance value chain from offer and contract management to claims management, statistics, and reinsurance, and to provide an application that insurance domain experts could use to quickly define and test new product ideas. Once the idea was verified, the new system would automatically update all the affected IT systems.

The first company to have a such a system would have enormous competitive advantage, since it could implement innovative products fast and react to competitive challenges. At this point (mid-2001), Generali appears to be the closest, in Europe, to implementing such a system. Its first system will be deployed shortly in the Netherlands.

“The whole concept of product-driven insurance applications is new, so nobody really knew what it was,” said Jens. “We started with a vision of 'a contract is an instance of a product' and tried to solve the domain questions from that. If you read the original requirements document today, it only scratched the surface—and went wrong in several aspects. On the other hand, the vision we started with proved to be quite stable; it only had to be corrected in some details.”

The project (PDFS) began as a single-user system developed in Visual Age Smalltalk. The system was stand-alone, but there was an optional repository database on a server to synchronize users. The team started in January 1998 as a group of five (one project manager, one domain expert, and three developers, with one concentrating on domain analysis) plus Jens as a coach. Currently (mid-2001), the team has ten members (one project manager, two domain experts and testers, one domain architect, five programmers, and the coach).

As with any innovative product, the project has had a checkered history. Asked if the project was successful and how he and his team measured success, Jens replied, “There was a simple measurement: survival. The project survived several severe political stands, and we finally convinced even strong opponents. We have managed to meet one of the major challenges in insurance IT today and starting production (under way) is the final step for success. Several other companies in the group have shown interest, so I think we are pretty successful.”

Part of the problem with determining success on projects like this is that conformance to plan has little relevance. “The current system has only vague similarities with the original plan,” said Jens. “We changed the technical platform and the complete architecture of the runtime components. There are some themes you find all through the project, but most things have changed. This flexibility was part of our success. A manager told me that the project, as planned originally, would have been canceled after eight months using their standard approach to projects.”

The checkered history involved two major shifts in the project's goals. The first occurred when the team dropped the idea of developing a new object-oriented contract system. The original goal was to develop a contract system in a fat-client architecture using Smalltalk. This was part of an overall initiative to switch the complete back-office software to an object-oriented Smalltalk system. After one year of work with the PDFS, the group decided not to make the transition to Smalltalk but to enhance the existing mainframe systems. This change in direction did not affect short-term work too much but caused a major shift in the long-term schedule.

The second major shift occurred when a second project team in the insurance group started to develop another product system. Although the PDFS group thought its product concepts offered the better business opportunities, there were strong political pressures to integrate with the competitive system. Reacting to this challenge, the team changed its strategy and revamped its internal product.

On the technical side, there were two significant changes: The team changed the target operating system from OS/2 to Windows, and the persistency mechanism changed twice. The team discarded the original object database—after the database vendor proved unwilling or unable to fix a high-priority bug that caused regular system crashes—and went back to an ODBC repository.

The PDFS team used Alistair's Crystal Clear method as a framework but also included elements of XP. Jens, as the OO coach on the team, proposed an incremental approach. He began with a two-day process workshop and, based on the stringent timing for the first deliverables, had the team answer two questions: “If you think of your previous projects, what enabled you to go faster? What slowed you down?” The team members took the answers from this brainstorming session and designed a process that facilitated the accelerators and avoided the slow-down practices. They repeated a “process analysis” workshop after each increment to further customize the process.

“I had proposed to work with a lightweight approach because in several extensive exchanges, Alistair had convinced me that this way might work,” said Jens. “I had bad experiences with heavyweight processes before and was quite sure that we would not succeed with a formal process. After the first increment, we called in Alistair to review the process. This approach had good support from middle and upper management.” The company had a standard, well-defined process—which called for 211 reviews of different artifacts before coding could start. “The team all agreed that using this standard process would lead to disaster.”

The team used increments of three to four months and prioritized requirements as a team at the beginning of each increment. The team wrote requirements documents for every feature but didn't maintain them after the feature was implemented. The design was done by a small team made up of the analyst, one or two programmers, and Jens. Their design tool was primarily a whiteboard, and a typical design session lasted one or two hours. The team used automated testing (using Kent Beck's testing framework and a commercial tool named TestMentor) and also did regular refactoring. In the beginning, the team used interaction diagrams in design, but as the architecture stabilized, the key question changed from “What does the design look like?” to “How should we refactor our system?”

“However, all my efforts to implement pair programming failed,” said Jens. “The team and the project manager just were not convinced that it provided enough benefit. Still, for difficult parts, sometimes a couple of programmers would pair.”

The team did regular code reviews but abandoned them at crunch times. Jens said, “Everyone thought the code reviews helped, but time was a factor. Most of the developers have a good programming style, so I didn't consider this as a threat to the project.” The team also used a configuration management tool, which Jens considers a vital ingredient to lightweight processes.

Changes to the “methodology” over time included the approach to analysis, design, and testing. The members of the team started with use case–driven analysis but over two or three increments found that they did much better by using features. The team experimented with UML, but did not find it very helpful, so the documents were text and GUI screen shots. These documents and the design meetings were used to brief the programmers, who worked in close collaboration with the analysts. As Jens observed, “When the programming is done, the solution usually is much closer to the original ideas of the analyst than the analysis documents.”

Automated testing was introduced during the first increment for a small part of the system. “I showed it to other team members, and by the end of the increment, everyone had written test cases,” said Jens. “Now we have more than a thousand test cases for the complete system. Changes rarely lead to new bugs, so the team heavily relies on the test cases—with appropriate feedback when someone forgets to secure his or her code with test cases.”

With a light, Agile process that included aspects of both Crystal Clear and XP, what factors did Jens think had the greatest impact on success of the project? “We had one of the best teams I've had the pleasure to work with so far. The combination of a flexible process and early and fast results saved our life several times. The architecture proved to be stable over all of these changes, and the technical platform allowed us to implement the architecture without worrying too much about the technical details.”

And what values and principles influenced the team? “The most important principle was always to leave the decision to the team,” Jens replied. “The process was designed by the team, and we didn't adopt any practice that the team didn't find useful. I only watched that practices the team found useful were not abandoned just because of laziness. If someone stopped using a certain practice, he or she had to justify it in a team meeting. The second vital practice were the time-boxes. The team found increments of three to four months most useful, though I would have preferred shorter increments. Anyhow, these short deliveries gave us a strong position with management. They prevented us from going off on tangents, especially in the beginning, when there were ideas that would have been extremely expensive to implement. This literally saved millions.”

This insurance project provides insights into exploratory projects. First, the business vision remained stable throughout the project, while everything else—specific features, architecture, and the product scope—changed. In these types of situations, teams need to be measured not on their conformance to plan, but on their ability to adapt to changing conditions in order to fulfill the product vision.

A second lesson from the Generali project is that methodology needs to adapt over time, while the team's ecosystem—its values, interactions, and conversations—has a tendency to stabilize. Third, Jens's experience on this project shows clearly that documentation and understanding are not the same thing and, furthermore, that conversation, not documentation, is key to understanding in a complex knowledge situation. A fourth lesson—which rigorous methodologies often try to ignore—is that stuff happens. Who, for example, would ever have anticipated mother-in-law features? More important, when stuff does happen, how do we respond? Should the mother-in-law factor—now clearly identified—be calculated into future projects? In today's turbulent world, any methodology that ignores the “stuff happens” factor is doomed to failure.

One of the standard criticisms of ASDEs—the same criticism leveled against RAD approaches in the early to mid-1990s—is that they are just excuses for ad hoc, undisciplined coding. But refactoring, design patterns, customer focus groups, test-first development, and pair programming are not the tools of cowboy or cowgirl coders. These are the tools of developers who are exploring new ways of meeting the difficult goals of rapid product delivery, low defect levels, and flexibility. For example, writing about quality, Kent says, “The only possible values are 'excellent' and 'insanely excellent,' depending on whether lives are at stake or not” (Beck 2000).

Part of the problem in our industry is the worn-out mantra, “If you do it differently than I do, you're not quality conscious.” I've been around this industry more years than I like to admit to in public and worked with different types of software developers—from software vendors to internal IT shops and many of the leaders of the Agile community. A sense of what drives these individuals can be garnered from the interviews in this book, but I can summarize their passion in two phrases—customer value and high quality.

Technical excellence is critical to high-quality software. We can debate whether or not the various approaches achieve those goals or if they achieve them in the most expeditious manner or under what set of conditions one or another approach is preferable. “You're approach doesn't create high-quality code” is a reasonable complaint. “You don't believe in high quality” isn't. One of the Agile Manifesto principles—“Continuous attention to technical excellence and good design enhances agility”—speaks directly to the goal of technical excellence and quality. So what are the technical issues that influence the debate between Agile and rigorous approaches?

Although there are overlaps in a few of these issues, each deserves our attention.

Delivering low-defect code is critical to both delivery speed and ease of change. A quick example illustrates the point. Two programmers each deliver code modules (several modules each) consisting of 2,500 lines of Java code. Each module is entered on the project schedule as “done.” However, one has a defect density of 8 defects per thousand lines of code (KLOC) and the other 27 defects per KLOC. Is the degree of “doneness” the same for these two modules? One software company I worked with estimates each defect takes about one day of testing time and one day for repair. (The numbers sound high, but the company's metrics are reasonably accurate.) In this case, the difference in defect levels translates to 95 additional days of effort for the second module. Done isn't done.

Testing and defect repair time are geometrically related to defect density. Double the number of defects in a module, and testing time more than doubles. As many developers have discovered, once the defect density rises to a certain point, stabilization of the code becomes nearly impossible—it becomes an endless cycle of testing, fixing, and then fixing bad fixes. Serial development, in which coding is followed at some later date by testing, creates a myriad of problems.

Software engineering practices emphasize two strategies for defect removal: multi-level testing and code inspections. All ASDEs call for frequent testing in order to deliver working software each iteration. XP's frequency is near instantaneous in its test-first mode of operation. Agile approaches call for constant integration testing and frequent builds. Agile approaches call for acceptance testing with customers, both with test cases (XP) and customer focus groups (ASD). Pair programming can be viewed as the equivalent of instantaneous code inspections. Code inspections are a key part of FDD and are advocated by other Agile approaches.

Agile developers may use less formal testing documentation and they may depend more heavily on the development team for testing than on a separate testing group, but they are no less dedicated to removing defects than any rigorous development group.

Traditional rigorous methodologies, and software engineering in general, focus on architecture, requirements, and design; coding and testing are considered low-value “construction” activities. In these methodologies, the high-leverage activities are the up-front activities. Agilists reverse this emphasis. This is a real difference, and one that individuals and companies will have to address when they consider ASDEs.

The equivalent of a civil engineering blueprint is a UML diagram, say those vying to make software engineering the equivalent of civil, electrical, or mechanical engineering. Another equivalent would be an electrical engineering circuit diagram. I contend that these analogies are wrong. The equivalent of circuit diagrams or blueprints is code, not UML diagrams.^[1] (Note: In the case of executable UML, the model and the blueprint are equivalent forms.)

“Yikes,” critics will say, “nobody but programmers can read code.” My undergraduate degree is in electrical engineering. Developing a circuit diagram requires electrical engineering knowledge, and even reading one requires a fair amount of training and experience. An electrical engineer analyzes the problem, roughs out a design strategy, and constructs a circuit diagram. That circuit diagram then gets translated into silicon. Although there may be senior and junior engineers, there aren't electrical analysts, electrical designers, and electrical circuit diagrammers. There are, however, technicians (or software) that “translate” the diagram for manufacturing.

To Agile software developers, code is the equivalent of an electrical engineer's circuit diagram. How many programmers actually use anything other than code to understand a piece of software? A high-level blueprint may help them understand context, but they generally depend on reading the code. For detail-level work, programmers don't trust documentation to be accurate, they trust code. By devaluating coding, software engineering has fostered the creation of architect, analyst, and design roles in which the qualifications for the job do not include the ability to code or even to understand code. This is the equivalent of an electrical engineer not knowing how to read a circuit diagram!

The problem with the emphasis on blueprints and nonexecutable models has been twofold: form rather than substance and the disconnect between models and code. I've been in companies in which the methodology police run rampant. They don't understand the content of a diagram, but they worry if the little arrow thingies are inconsistent. “I've talked to many users of modeling tools,” says Jon Kern of TogetherSoft. “There is often a huge disconnect between models and code. Modelers, specifically those in organizations in which model builders have little coding experience or skill, build illegal models—things that can't be converted into code.” So, if analysts and designers can't code, they need intermediate documentation that they can read—software engineering specialization run amuck.^[2]

Agilists believe in the restoration of programming—the actual production of working software—to a place of critical importance in the development process.

All the Agile approaches advocate high quality through the use of short iterations, frequent builds, and continuous testing, but XP goes further. XP promotes three practices, rules in one sense, that if followed, generate complex behavior whose goal is technical excellence. These practices are simple design, automated test-first development, and refactoring.

Simple designs require thought. Simple, within the XP context, takes on two characteristics: no anticipation of future requirements and easy to change. First, “no anticipation” means to develop code for the story at hand. Don't think ahead; develop a specific solution, not a generalized one. Second, a good design is an easy-to-change design—one in which the intention of the code is clear, one in which elements are minimized, and one in which there is no duplication.

If we focus on coding the features at hand and not generalizing in anticipation of the future, then once the future arrives in the form of new features or stories, we can't just add them to the code base. First, we examine the code and ask, “If the code looked like that instead of this, could we implement the new feature more easily?” To keep the cost of change low, we periodically redesign, or refactor.

Kent refers to this entire design process as an organic process, one that is generative. This is a system of practices. Pick one practice—say, simple design without refactoring—and the generative nature of the system disappears. Pick all three—automated testing, simple design, and refactoring—and emergent results, those larger than the sum of the individual practices, occur. Simple designs reduce testing work. Constant testing reduces delivery time. Interleaving testing and coding gives developers, and testers, a better understanding of the code. Having an automated test suite enables developers to refactor with less apprehension about “breaking” the system. Refactoring allows the design to emerge from the code, not be dictated by metamodels. Refactoring maintains simple designs yet enables those simple designs to evolve as functionality is added.

Does this mean no anticipatory design, ever? No, but it does mean balancing anticipatory design and refactoring. Traditional approaches place little, if any, emphasis on refactoring. Project teams may spend months and months doing anticipatory design and none doing refactoring—because, of course, they surely got it right the first time. Maybe the database and user interface designs require a slightly different balance of anticipation and adaptation. By using these three practices, though, we can learn the right balance. Are we redoing a lot of up-front design work? If so, maybe we spent too much time on it. Are we refactoring a lot of code? Maybe a little more design would have been advantageous.

Refactoring may be the single most important technical factor in achieving agility. Mechanical devices degrade with time, requiring more and more effort to maintain. Software degrades with change, so without refactoring, software atrophies. As software atrophies, changes become more difficult. As change becomes more difficult and time consuming, we are less Agile, less responsive. Our ability to move from code refactoring to data refactoring to architecture refactoring may ultimately determine our ability to respond to customer demands in a turbulent environment. At the level of technical excellence, the emphasis on refactoring may be XP's greatest contribution.^[3]

On the downside, refactoring—carried to its illogical extreme—leads to unfettered tinkering. However, coding itself can become unfettered tinkering. Other practices, including close collaboration with peers and short-delivery cycles to customers, balance against this potential problem.

Every technical group I've ever encountered wants to refactor—they just use different words for it. They want to recode some module or restructure a class hierarchy or refine a database schema in order to improve maintainability and enhanceability of the system. The problem in most organizations is that they wait (often because of an organization's short-term focus) until the system becomes archaic, at which point the refactoring job becomes a major rewrite that is expensive and risky. During a recent “methodology” consulting assignment for a software vendor, I made the comment, “No methodology is going to solve the problem of your antiquated code base. A major redesign effort is necessary to bring down the cost of maintenance.”

Everyone “refactors”—it's just the increment size and time frames that are different. Agile developers are saying, “Refactor more often and on smaller increments in order to avoid refactoring later on huge increments with lengthy time frames.” Furthermore, different components should be refactored on different timescales. Refactoring goes hand in hand with simple design.

Although incremental and iterative development has been advocated for a number of years, there is still a bias toward the big-bang approach in many organizations. For example, even though the SEI is supposedly neutral when it comes to incremental versus waterfall life cycles, I've talked to IT managers who have had difficulty convincing CMM assessors that their incremental approach passed muster.

To some, incremental and iterative development implies suboptimization, and in fact, this may be true in lower-change environments. To these individuals, suboptimization implies low technical quality and costly rework. Their argument boils down to, “IF you could do everything right the first time, up front, THEN it would be cheaper, better, faster.” It's the “if” that runs afoul of reality. The upside of increments is constant feedback and quick wins. The downside is suboptimization and costly rework.

Information engineering (IE), from the 1980s, was clearly the biggest of the big-bang approaches (at least within IT). It foundered on limited feedback and excessively long delivery cycles. Based on the fundamental belief that data was more stable than process, IE proponents slipped into the mistaken conclusion that data was stable—a dangerous extension. IE began with a strategic study of the business. First came an information strategy plan (ISP), which was followed by a series of business area analyses (BAAs). Teams then built databases from the detail plans and finally developed application code. This highly front-end-loaded process could take 18 to 36 months before useful applications would emerge.

The big-bang excesses of the 1980s, particularly those attributed to overzealous IE practitioners, helped spawn the early 1990s interest in RAD. Some RAD projects, in part reacting to IE, garnered quick wins but suffered from longer-term suboptimization. RAD methods and client/server technology blossomed at about the same time and gave operating departments the technology and a fast-track approach to bypass IT departments. Many applications went from an overabundance of front-end planning to severe ad hoc development with no front-end planning.

To the inevitable question of how to achieve quick wins and reasonable optimization, the Agile response is: skeletal modeling up front (FDD, ASD, Crystal, LD) combined with refactoring (XP). On a scale of zero to ten, with zero representing the extreme of no anticipatory architecture or modeling at all and ten representing the extreme of IE, I think most current Agilists would place themselves around two to four on the scale—just enough, but not too much.

In the final analysis, there are two questions. First, how big is the bang, or, how small is the increment? In deciding the increment size, how do we avoid the problems of poor feedback or poor optimization? Agilists think that it is easier to solve the suboptimization problem—that the path to technical excellence and customer satisfaction lies in short increments, refactoring, and “just enough” skeletal modeling.

The concept of “levels of abstraction” has been part of software engineering for many years; it is part of all engineering work. Abstractions, high-level views of a problem space that hide certain details, might be documented in diagramming models with successive refinements adding details to the model. Similarly, an outline is an abstraction of a book, and, through successive addition of detail, the abstract outline becomes a concrete book. The ability to “abstract” away from the details in order to create a good structure has been viewed as a path to technical excellence.

I was having dinner with a noted programming guru not long ago. He relayed a story about the most incredible programmer he had ever known. This programmer could sit down at a terminal and create (in a couple of weeks) a well-designed, 100,000-line program that contained virtually no bugs. He created the program—abstract to concrete—as fast as he could type. Would this programmer benefit from turning his abstract thinking into a diagram?

This illustrates the difference between abstraction, which is a recognizable talent of great developers, and diagrammatic models, which record the result of abstract thought. I like Scott Ambler's comment: “There are two fundamental reasons why you create models. Either you model to understand an issue, or you model to communicate what your team is doing.” If we want to do abstract thinking, either as an individual or in a group, jotting rough diagrams on a flip chart may enhance the process. Still, we shouldn't conclude that lack of formal modeling equates to a lack of abstract thinking.

Architecture is another form of abstraction. Trying to define what “architecture” means is far beyond the scope of this book, but I would at least like to place architecture into two broad categories—environmental and system. Environmental architecture involves decisions about the environment in which the project team must operate—from database and language to the middleware and Web server. Many of the decisions on environmental architecture are outside the scope of individual project teams. Existing systems, overall product architectures, or cross-application and intercompany integration plans may constrain individual project teams.

This leaves system architecture decisions—data schemas, program modules, class hierarchies, method placements, stored procedure usage, and other decisions—to the development team. No doubt environmental architectures change, but at different time intervals than system architecture.

FDD, for example, has five process steps, the first of which is “Develop an overall model.” Scrum defines one of the inputs to a Sprint (a development iteration) as systems architecture and plan. ASD specifies a zero iteration (a matter of weeks) in which an initial architecture is developed. In LD, Bob Charette advocates a front-end architectural component. ASDEs advocate “light” architecture, with the degree of lightness varying with project size and the degree of uncertainty about the features.

There are three key factors in doing “Agile” architecture or modeling. First is recognizing and constantly reminding ourselves that plans are just plans. Plans change and models change—constantly throughout a project. Second is to have as a constant mantra the need to keep things simple and understand that refactoring will help recovery from oversights. Third is that the best way to manage up-front architecture work is to time-box the effort—short time-boxes. I place architecture in iteration zero and define it as an iteration in which nothing useful is produced for the customer.

In today's fast-paced world, we might justify spending a couple of weeks (out of a six- to nine-month project) on working out a class structure model or a data model, but not much more. Guidelines are just that, but my experience has been that an initial time-box for iteration zero of one to two weeks per six months of project is a reasonable starting place. In the FDD chapter of Java Modeling in Color with UML (Coad et al. 1999), Jeff De Luca recommends spending ten percent on up-front model development (about 2.5 weeks on a six-month project) and five percent on ongoing model development (in reality the ongoing modeling effort should decrease in the latter iterations). In Surviving Object-Oriented Projects, Alistair discusses his guidelines for modeling: “First, create a high-level model of your business. This should take no longer than two to four weeks.... [Then] create models of the business with not more than a dozen key classes and several dozen supporting classes” (Cockburn 1998).

Scott Ambler has been working on an Agile approach to modeling.^[4] Agile Modeling (AM) practices include:

Two of the 17 Agile Manifesto signatories—Jon Kern from TogetherSoft and Steve Mellor from Project Technology—advocate modeling, when in fact the models are easily translatable into code such that the “executable” models can be considered “working software.”

Models as a communications or thinking mechanism serve a useful purpose. However, just as when coding and testing become un coupled and linearly related (coding is done by one group, testing by another, with a time delay between), modeling (as a component of design) and coding can become un coupled and linearly related. When modelers know nothing about coding, there is a problem. When programmers don't test, there is a problem. There needs to be an integration and a balance. Don't model very long before coding and don't code very long before testing.

Agile approaches are not anti-architecture or anti-modeling. A few weeks of up-front architectural planning, a few days each iterative cycle devoted to architectural planning, or a few hours sketching out blueprints can be effective in improving the goal of technical excellence of our software products.

One of the major difficulties in understanding various development perspectives is lack of problem domain recognition. For example, an email forum participant commented on XP, “I'm starting on a two million line-of-code system—XP wouldn't work.” Well, one of the things that attracted me to XP was that Kent and others defined a domain of small, colocated teams and an involved user. There are ongoing efforts to extend XP, but the bulk of practical experience has been with smaller teams of ten or so people. Using Capers Jones's numbers, a two million LOC program would, on average, require about 110 people and, best case, around 70 people (Jones 2000). I doubt that any ardent proponent of XP would tackle a 70- to 100-person project without extending or tailoring the basic XP practices. The comment about XP indicated a clear lack of domain recognition. Of course the other view is that using an Agile approach might reduce “bloat” and enable the project to be done with far fewer people.

In his Crystal Methods series, Alistair is clear about the differences between a small team (Crystal Clear) and an 80-person project (Crystal Red). He recommends additional ceremony, documentation, practices, and roles for larger projects, but always keeping in mind the primacy of human interaction. Criticality also helps define a domain. The software needed to run medical CAT scan equipment and the software that runs the latest video game fall into very different domains. Similarly, high-risk, high-change projects define a different domain from those in which requirements are anticipated to remain reasonably stable.

The failure to recognize domains, and the applicability of a particular set of technical practices for particular domains, will ensure that many debates over traditional versus Agile practices will stay firmly focused on the wrong issues.

“Zero-based documentation” is a term I remember Tom DeMarco writing or talking about, but I couldn't come up with the reference, so I queried Tom. “I do remember throwing the term around, but I don't think I ever wrote on the subject. The idea seems obvious (by extension from zero-based budgeting): It means that each document you impose on a project has to be justified as meaningful for that project. The opposite is today's norm: The set of documents required is the complete set that we required from past projects—relevant or not—plus whatever special stuff is needed for this new project.”^[5]

This is the state of much documentation today—documentation for documentation's sake. What's more, it is often justified by the sentiment, “Well, you couldn't possibly deliver technically competent software without these 47 document artifacts.” Documentation doesn't, in and of itself, convey either understanding or a quality design, requirement, or the like. For example, Chapter 20 on FDD relates a case story in which the pre-FDD team produced 3,500 pages of use cases, or as the FDD project manager quipped, “useless cases.” Should this be used as an indictment of either use cases or documentation? Of course not, but then minimal documentation shouldn't be written off either. It's the quality of the results that counts.

It's an interesting phenomenon: Technical staffs, by and large, hate to write documentation, and managers, although they talk about the need for documentation, hate paying for it. Why, then, has there been so much discussion about documentation? I logged in one Monday morning and had 60 emails from one discussion group—all about documentation, or the lack thereof, in XP. As Tom says in the first paragraph of this section, let's not do documentation that has little payback. Let's justify every piece of documentation.

If documentation were really so important, managers would be willing to schedule appropriate time into projects to produce documentation, and they would be willing to fund technical writer positions to assist in developing documentation. Neither of these happens in any reasonable proportion to all the “talking” about the importance of documentation done by managers.

In The Machine that Changed the World: The Story of Lean Production, the authors discuss the issue of generalists and specialists within the automotive industry.

A tremendous impetus to software engineering comes from the defense community, which engages in enormous projects. Large projects tend to foster specialization—process specialists, measurement specialists, database design specialists, user interface designers, algorithm analysts, quality assurance specialists. The bigger the project, the more specialists, the more specialists the less interaction, the less interaction the more documentation to counteract the lack of interaction—and, the lower and lower ratio of programmers to the total project staff. Programming work dwindles to less than ten percent of these large projects, and technical excellence becomes associated with technical specialization.

In contrast, the heart of “lean manufacturing” is the dynamic work team. What fast-moving, complex knowledge integration–oriented project teams need is constant interaction and conversation—“team” knowledge sharing and problem solving. The delivery team doesn't need a manual full of database design procedures to follow, it needs a team member who is knowledgeable about database design. The delivery team doesn't need a project office reviewing and approving its plans, it needs a knowledgeable project manager. Product excellence requires an integration of knowledge, often better accomplished by generalists than by specialists. Specialists are necessary, but as an integrated part of the development team, even if they are part time. Technical excellence requires people working closely together, not groups lobbing documents and sign-off forms back and forth.

The purpose of this section is not so much to debate the issues surrounding generalists and specialists as to point out that at least a part of the debate over technical excellence arises from this topic. Typically speaking, Agilists are generalists. Rigorous software engineers tend to advocate specialization. Although Agile developers realize that additional specialties and roles may be required, particularly as project sizes increase, Agile projects will tend to have fewer roles and specialties than rigorous projects.

Herein lies the technologist's biggest fear and greatest complaint: “We never have time to do it right.” This mantra is frequently repeated by rote as a spell against the evils perpetuated by anyone who isn't a technologist—particularly vilified are management and marketing. On the other hand, technologists use it on each other all the time—mostly to ward off new practices that they don't want to do. Three things strike me about the quality versus speed argument:

Quality may be important, but it is far from simple. Is quality synonymous with customer value or just defect levels? What does “good enough” software imply? Does all software need to be as defect free as the Space Shuttle software? As Pete McBreen (2001) reports, the Space Shuttle software has order-of-magnitude fewer defects than most commercial software, but its cost is also in orbit. For example, maintaining Microsoft Windows at a level of defects equivalent to the Space Shuttle software might cost upwards of $5 billion per year.^[6] Are we willing to pay $5,000 to $10,000 for a copy of virtually bug-free Windows?

While there is certainly a relationship between speed and defects, it is not an inverse linear one. I've been involved with some very fast, very low-defect projects—and some very long, very high-defect ones. In the end, the most important thing may not be speed, or quality, or low cost, or maintainability, or whatever—the most important thing is what the customer wants. If the customer says, “I need it by Friday,” and we say, “OK, you can have it by Friday, but you'll only get a few screens, limited testing, and only 3 of the 24 business rules,” and the customer says, “OK”—then we've been successful if we deliver that very limited function, somewhat buggy, working piece of software on Friday. Delivering buggy code may not be very satisfying to the developers, but it could be acceptable to the customer. We may laugh, but perhaps the customer is someone in marketing who needs to show a major prospect something tangible, whether it works well or not.

There is a story about a CEO who called down to the PC help desk for a loaner laptop. The technician had one, but it didn't work. “Fine, just bring it up,” said the CEO. The technician scratched his head and took it to the executive. Two days later, following the meeting, the CEO's assistant returned the laptop. Curious, the technician asked, “What good was a broken laptop?” “It was for show,” the assistant replied. “The boss just wanted to appear 'with it'; he really didn't need it to run.” Projecting our own ideas about quality—“a broken laptop is useless”—onto our customers can be a dangerous proposition.

This should not be interpreted as a pitch for “anything goes” but as a reminder that quality can be a tricky thing to nail down. Developers, for example, could turn out a piece of software in which they have fixed all the known bugs and performed reasonable tests on the hardware and software configurations available to them. How long can they afford to look for unfound bugs? There's always another one somewhere. How many hardware configurations can they afford to buy and test? At what point have they fulfilled their role as software craftsmen and professionals?

Finally, the traditional wisdom is that if we reduce defects to a minimum level, other characteristics—speed, customer satisfaction, cost—will all improve. In the early 1990s, Capers Jones reported that good things happen at cumulative defect removal rates of 95 percent and higher. Agile developers believe in the advantages of low-defect software also—witness the intensive testing and inspection processes mentioned earlier. Agile developers just do it with smaller increments.

Being newer, or at least more recently recognized, the Agile community has a definite anti-establishment feel to it, and therefore part of the “technical” debate doesn't have to do with technical issues at all.

Reading through SEI's CMM material or the Software Engineering Body of Knowledge (SEBOK) manuals, one is struck by how many of the skills are related to process, not to delivering software. Furthermore, the SEBOK is organized in classic waterfall fashion—requirements, design, construction, testing. The layout of the document, ostensibly about skill, contributes to a particular vision of process. Furthermore, the SEBOK reads like an academic journal—formal and littered with hundreds of references. The newest version of the CMM, the CMMI for Systems Engineering/Software Engineering Version 1.02, is a mere 606 pages of federal Department of Defense–speak. To those in the Agile community, these “heavy” documents epitomize establishment bureaucracy. It may be as unfair to label the CMM bureaucratic and document heavy as it is to label Agile development “ad hoc,” but the establishment versus anti-establishment biases will continue to influence the debate. Even in these labels are grains of real issues.

Agilists wish to avoid projects like the following (Goranson 1999). In 1985, U.S. intelligence agencies discovered a new Soviet air-to-air missile that was superior to any in the U.S. arsenal and presented a severe threat to U.S. planes in air-to-air combat situations. The Israelis, with primarily U.S.-supplied aircraft, responded to the threat with a new missile design and deployment process that took 6 years. The Soviet development effort was estimated to have taken 5 years. The U.S. Department of Defense “plan” is for a 17-year development cycle, which, given the nature of large projects, could stretch to 24 years!

Lean manufacturing and lean thinking admonish us to think about those activities that deliver value to the customer and those that don't. As I look at the CMM and SEBOK publications and remember that James Womack indicates that 80 to 90 percent of manufacturing steps are a waste of time from the customer's perspective,^[7] my reaction is that many of the CMM and SEBOK activities just don't add any customer value. If we divide activities into those that make direct contributions to customer value and those that don't, it seems to me that the institutions many people look to for guidance are focused on internal processes more than external results, on the illusion of control more than reality, on non-value-adding practices more than value-adding ones. Furthermore, when we let these institutions define “technical excellence” as conformance to their practices and standards, we fight a losing battle.

Technical excellence should be measured by attributes of the product—does it work, does it break, does it process the volumes required, does it integrate with other systems as specified, does it perform. The next question is, “What are the skills we need to deliver that product?” Everything else detracts from agility.

So part of the debate about Agile versus rigorous is about old versus new, or traditional versus nontraditional, or about comments like “This isn't even new anyway”—essentially, establishment versus anti-establishment. This happened during the early years of object development and during the introduction of the PC. It is an inevitable part of integrating the best of the new with the best of the established.

Some of the most vitriolic attacks on XP have been focused on pair programming. Even though, to me, pair programming seems an extension of, and an improvement on, the collaborative practice of code reviews, others feel that pairing is an outlandish, subversive, and thoroughly dangerous threat to their individuality. Many of the debates about Agile versus rigorous practices have no basis in fact—they are purely emotional and based on one's culture, one's values and beliefs. Now, emotion-based reactions are at least as valid as fact-based ones, but they do tend to create high-volume rhetoric.

The point here, to reiterate one of the major points of this book, is that values and principles are absolutely critical to one's point of view about methodology and software development ecosystems. They also greatly influence “technical” debates.

Many issues spark debate about ASDEs. In general, the debates are healthy because they promote deeper understanding. To get the most out of these debates, to extract real differences from hyperbole and misunderstanding, the individual issues need to be teased apart and analyzed. ASDEs utilize traditional technical practices, but they have fostered new ideas, new rearrangements of traditional practices, and a different perspective on how to achieve technical excellence. Separating these issues will help everyone decide what parts are valuable to them and what parts are not.

Some people may be concerned that a “barely sufficient” approach to methodology will result in lower technical quality. However, Agilists' barely sufficient approach is based on the belief that technical excellence depends mainly upon talent and skill, not methodology. Methodology forms a framework within which people can work effectively together, but it cannot, and does not, substitute for talent and skill. If a methodology provides a framework and practices that encourage skill building, then it will be far more effective than one that merely prescribes activities and documents.