Reality vs. Rhetoric
First and foremost, the agile community needs to address the hyperbole. Our detractors will say, "Agilists don't write documentation." Nothing could be further from the truth. To further exacerbate the situation, some extreme agile evangelists claim that all the documentation is in the code. In reality, the goal is to store information only once, in the most appropriate place possible (see http://www.agilemodeling.com/essays/singleSourceInformation.htm). Even though a lot of the documentation is in the code, agile developers may often detail design information in unit tests, and requirement definitions in acceptance tests. But if the stakeholders insist on investing their time and money on traditional high-level models, system overviews and full support and user documentation, we will deliver them.
Other harmful rhetoric includes: "Agile teams don't need project managers, quality-assurance people or architects." Even though this is partially true, we still need aspects of all of these job functions. What we don't need are specialists who want to focus only on those specific roles. For instance, project management becomes a team function, but product managers are still needed to protect the team and obtain access to resources that are critical to project success. Quality assurance becomes a mindset that everyone on the team should have—after all, agilists are, by definition, "quality infected." Similarly, although architects are important to every system, architecture is something that we design in a highly collaborative and evolutionary manner, and we may not even have a need for comprehensive architecture documents (see http://www.agilemodeling.com/essays/agileArchitecture.htm for details).
But some of the rhetoric is absolutely brilliant: "We maximize the amount of work not done," is one of them. Agilists travel light. We've learned to discard traditionally comprehensive documentation for working software. When you travel light, you also reduce the bureaucracy surrounding those work products. For example, less documentation implies fewer documentation reviews and less need for traceability between documents.
The most interesting and controversial rhetoric is "the agile cost-of-change curve is flat." Once again, this is only partially true. In Extreme Programming Explained (Addison-Wesley, 2004), Kent Beck claimed that the cost-of-change curve for XP is flat, with the occasional bump in the production stage. The reason this claim is controversial is that the traditional cost-of-change curve is exponential—the longer you take to find a defect, the more expensive it is to fix. The reality is that agile methods occupy only the left-most part of the cost-of- change curve because agilists adopt techniques with very short feedback cycles (see Figure 2). This enables us to detect and address defects as early as possible. I explore this concept in detail at http://www.agilemodeling.com/essays/costOfChange.htm. The real message should be "Agilists follow techniques that minimize the cost of change."
Comparing the cost-of-change "curves." The agile and traditional cost-of-change curves are identical. The difference is that agilists follow techniques that keep us at the low-cost end of the curve.
