How to Be Agile Without Being Fragile | Extreme Programming Refactored: The Case Against XP

For a process to achieve the agile values and principles ^[2] without being fragile, we believe that it must provide operations and procedures that

Provide the usual benefits of software agility (early and continuous delivery, reduced cost of communication, bringing businesspeople and technical people together, and so on)
Decrease risk
Encourage contingency
Prevent fragility

The first item makes the process agile; the other three prevent it from being fragile. Analyzing those last three items should, then, help us to come up with a process that s agile without being fragile. So let s look at each of these in turn and see how XP compares .

A Good Agile Process Should Decrease Risk

For a process to be truly agile, it must provide operations and procedures that decrease risk. A risk is a thing, event, or trend that, unless properly addressed, could impact the project in a negative way. ^[3]

XP reduces risk by encouraging the use of unit tests, pair programming, acceptance tests, constant refactoring, very short iterations, frequent code integration, and so on. However, each of these practices comes at a cost in terms of the time taken to implement and maintain it.

However, XP increases risk because . . . well, because of all the reasons we ve described in this book.

A Good Agile Process Should Encourage Contingency

For a process to be truly agile, it must provide operations and procedures that encourage contingency. This enables the project team to keep responding to change (such as changes in requirements or changes in management, market forces, and so on that could adversely affect the project) without increased risk.

With any project, XP or otherwise , a question to ask yourself is, What if something goes wrong? For example:

What if your chief programmer leaves ?
What if the on-site customer, who is essentially your walking, talking requirements spec, is forced to leave the project due to ill health? (Sure, you can get a replacement, but will he or she be as effective?)
What if you discover late in the project that you need another subsystem to be written? (If your team is already up to its many eyeballs doing constant refactoring and constant integration with the current system, you may need to bring in a team from outside the project.)
What if your targeted application server is suddenly taken off the market by its vendor? (It happens.)
What if the janitor accidentally vacuums up your pile of story cards?

XP addresses the problem of the chief programmer leaving the project by encouraging all team members to know about all parts of the design and code in enough detail to be able to pick up where somebody left off at any time. This is a pretty robust approach, but it comes at a massive cost.

We discuss some of the reasons why the XP approach is costly in Chapter 3.

Contingency isn t just about having backup plans, it s also about lessening the likelihood that you ll need those backup plans. In addition, it s good to know that the alternatives have been thought about, should it come to that (but also see the comment about embellishment in the next section).

You can t plan for the unknown (at least not accurately). But you can prepare contingency, so that when things do go wrong, they don t take your entire project with them.

A Good Agile Process Should Prevent Fragility

For a process to be truly agile, it must provide operations and procedures that prevent fragility.

A development process is fragile (or becomes fragile) if

It has no contingency plans. As we discussed previously in this chapter, if something goes wrong then it could take the whole project with it if your process doesn t provide a safety net or a backup plan.
It provides too much contingency, resulting in embellishment. The problem is that people often mistake contingency for embellishment. Embellishment is unnecessary extra complexity; contingency is simply having a backup plan ready for when things go wrong and having practices in place that prevent things from going wrong. A large part of contingency is, therefore, risk management and prevention. We like Alistair Cockburn s statement, Embellishment is the pitfall of the methodologist. ^[4] That is, it s easy to add extra practices and procedures because they might make the project more rigorous .
Its developers quickly get bogged down in analysis paralysis. Analysis paralysis means being unable to move forward due to thinking too much about alternative designs or detailed edge cases. Processes that are overembellished are more prone to analysis paralysis. XP protects against analysis paralysis by using test-driven development (TDD), pairing , and YAGNI. Ironically, as a direct result, XP is more prone to the programming equivalent of analysis paralysis: Constant Refactoring After Programming.

We discuss XP s propensity toward Constant Refactoring After Programming in Chapter 9.
Its practices are high discipline. XP takes a lot of sustained effort to keep to its practices. This would not be so bad, but the level of bite-back in such cases is too high. In fact, by stopping doing certain practices even for a short while, the whole project becomes unstable.

We discuss the high discipline aspect of XP in the section A Self-Referential Safety Net (Circle of Snakes) in Chapter 3.

Its practices are not easily tailored. Knowing which of XP s practices can be tailored and how to tailor them safely is the focus of the second part of this chapter (and the Defanged sections throughout the book). Tailoring XP is like defusing a bomb ”we need to determine exactly which practices can be safely cut.
It can t grow as the project grows. All processes are scalable, but some processes are more scalable than others. Most projects start out small and grow in size as more developers are added to the team, the customer asks for more features, and additional modules spin out to form subprojects . A good agile process should be able to take this in its stride. As the team grows or gets split into separate teams , extra procedures or documents may need to be added to the process. This shouldn t, however, require a complete reworking of the process, which in many ways XP does.

We discuss the reasons why XP doesn t comfortably scale up in Chapter 14.

A module has too many dependencies. A project quickly becomes fragile if its modules have too many dependencies. In such cases, it becomes almost impossible to change some code without affecting a separate code module in some way, so the project grinds to a halt, at least until that module is complete. XP followed to the letter helps prevent this kind of fragility, as long as the team keeps on refactoring. XP encourages clean, loosely coupled designs with no duplication of code or code responsibilities. Unfortunately, for the same reason, XP also magnifies the problem. Many of its prescribed refactorings include changes to public interfaces; therefore, a refactoring in one piece of code will almost certainly break some code in a different part of the system. XP relies heavily on plentiful unit tests, continuous integration, and crossed fingers to mitigate this particular problem.

Contingency vs. Embellishment: Why XP Gets It Wrong

Somewhere, there has to be a compromise when weighing how much contingency to factor into your project. The XP ethos is correct, at least insofar as each project deliverable must be justifiable in some way. If you re spending time producing a document, you should be able to explain how it will benefit the project. Each document should return a profit in terms of the effort invested in it. Otherwise, why spend the time producing it?

But (there s always a but ) XP takes this too far by cutting out practices that are essential to any software project.

We discuss the practices essential to any software project (e.g., sufficient up-front design, precode interaction design, and in-depth requirements elicitation ) in the Extreme Programming Defanged section in this chapter. We discuss the likely results of not using them in Chapter 3 and pretty much the rest of the book.

In fact, XP approaches contingency in the wrong areas. Specifically, all of XP s practices are geared toward making sure the software is fully functional and releasable at any stage in the entire project, just in case the project should be cancelled without warning. Although this is admirable, the result is a process that takes a lot of ongoing effort from the entire team just to keep the software releasable at all times.

SOLUTION

Our refactored process relaxes contingency around the sheer effort involved in keeping the software constantly releasable. We focus instead on making the software releasable for certain key milestones. This frees up the team s time to concentrate on other, higher risk areas.

^[2] See http://www.agilemanifesto.org.

^[3] There s a good discussion of risk management in Chapter 5 of Steve McConnell s Rapid Development (Microsoft Press, 1996).

^[4] Alistair Cockburn, Agile Software Development (New York, NY: Addison-Wesley, 2001), p. 142.