Why Methodology Definitions Matter

Suppose I create a methodology—Martin's Methodology, or MM. Someone else claims to be doing MM. How do I tell if they are? And does it even matter? With XP's rigid set of practices and sharp boundary conditions, this old process question is especially pointed. People at Thoughtworks and elsewhere are applying XP outside its stated boundaries, which begs the question: at what point are you no longer doing XP?

Then there's a deeper tension. A key feature of agile methods is self-adaptivity: you change the method as you apply it. How does that square with XP's rigidness?

Why Follow a Methodology at All

The useful starting point is to ask what a methodology is for. People adopt one because they want a proven path that increases their odds of success. They also want to shield themselves from blame if things go wrong: I followed a respected methodology—I did everything I could. In other disciplines, following an accepted process is often an expectation, and ignoring it can increase your liability. People want steps to follow, which is reasonable, since decades of software development experience should be transferable.

The Variability Problem

Most methodologies are statements a methodologist makes based on what he did once—or, more likely, what he wished he'd done. Beyond that, software is incredibly variable. People differ, company cultures differ, and the nature of the software differs. A process for telephony is not necessarily right for information systems, and neither suits games.

Most methodologists acknowledge this. They know no simple sequence of steps yields perfect results, so tailoring is inevitable. But how do you guide that tailoring? When does the customer of a methodology know what variation is reasonable and what breaks the methodology entirely? For agile methodologies, the questions are sharper because self-adaptivity is a core feature—and thus you need to preserve the integrity of the process while leaving room for inevitable, ongoing adjustments. The methodologist's dilemma is how to describe acceptable variation clearly enough that people who genuinely follow your advice get the intended benefits, yet still leave them room to adapt.

Styles of Methodology

A helpful way to think about this issue is to consider the ways methodologies differ, since each brings different answers to the variability question. The lines here are fuzzy, but a few categories help.

Concrete Processes

A concrete process gives you a fixed set of practices with little or no room for variation. Its strength is clarity: it is obvious what you must do. The limitation is equally obvious: you cannot change it—or rather, you can, but only by stepping outside the process. The methodology gives no guidance on local modification. Fans of the process may still accept a modified version as reasonably close, especially if it succeeds, but you're strictly off-process.

Tailorable Processes and Frameworks

A tailorable process includes explicit guidance on how variations are allowed and when it's appropriate to use them. That is a genuine improvement over a concrete process, but correct tailoring requires deep understanding of both the base process and all its variations. The process size matters here: large tailorable processes, such as the Rational Unified Process, typically tell you everything you should do and then tell you what you can leave out. The problem is that you must understand the large process before you can figure out the smaller one. If you need something lightweight, that's a lot of work. RUP is tailorable enough that it's commonly called a process framework: each user runs an instance of RUP without needing to grasp the full flexibility. You can simultaneously use a concrete process and RUP, but if you do not engage with RUP, you are really just using the concrete process.

Philosophical Processes

A philosophical process skips concrete steps and instead teaches the philosophy that underlies the development approach. This is inherently flexible, because many project styles can fit the philosophy—and you get that flexibility without the bulk of a tailorable process. The tradeoff is that philosophical processes give little practical Monday-morning guidance. They are often harder to follow precisely because they do not spell out your next actions.

Best Practice Collections

A best practice collection, such as McConnel's Rapid Development compendium, puts a group of relatively independent good practices in front of you, you choose and apply them in any order. The appeal is obvious: no complicated web of steps to understand. But XP made clear to me a key limitation: practices are not independent. XP's power comes neither from the individual practices nor from any single one, but from the interactions between the set Kent chose. The interactions are every bit as important as the practices themselves—and that interaction is what concrete and tailorable processes capture best.

No style wins cleanly. A concrete process does not vary at all in theory and offers no guidance if you need to change it in practice. Tailorable processes sound good but impose a steep learning curve. Philosophical processes give you grounding without telling you what to do on Monday. Best practice collections hand you parts without explaining the whole.

Where XP Sits

For many people, XP is plainly a concrete process. The twelve practices all work in concert, and anyone who spends time in XP discussion groups sees the considerable effort advocates put into getting newcomers to adopt every one. The zealotry reputation follows naturally.

But much of XP's allure comes from people drawn to its underlying philosophy—adaptivity, people-orientation, lightweight process, and emergent behavior make a compelling mix. In this view, plenty of projects want XP's beliefs but operate outside the concrete process's stated bounds. XP defines itself with unusual clarity around specific assumptions: a co-located team of up to a dozen developers. What happens when you have thirty developers, or a majority working remotely? Many XP principles still look valuable at that scale. Why not get as close as you can?

The resulting debate is intensified by brand awareness. People want to say they use XP because doing so communicates a lot about values and principles, even when their team size or distribution falls outside XP's intended scope.

XP has no official steering committee issuing pronouncements on what counts as XP. Kent Beck, the community's accepted alpha figure, has said he prefers XP to stay a concrete process—a "stake in the ground"—and that preference carries considerable weight. The governing view is that XP means the concrete process.

The Seed, Not the Tree

Kent Beck has offered a useful way to think about how XP relates to the teams that adopt it. Asked about maturity levels for XP—a notion that horrified many in the community—he proposed three, in a characteristically thoughtful response:

  • Level 1: you are doing all of the practices exactly by the book
  • Level 2: you have adapted XP for your local conditions
  • Level 3: you don't care whether you're doing XP or not

Self-adaptivity is built into this progression. To still be doing XP, you must eventually tailor it. Or, put another way: if you're still doing XP in iteration 6 the way you were in iteration 1, then you're not doing XP.

But notice what sits underneath these levels. They assume that adaptation comes only after a period of doing the process strictly by the book. This matters because XP's practices form a combination whose effects are genuinely difficult to appreciate without seeing them work together. Reading about them and surmising about their effects is a poor substitute for being there. The author's own experience on the C3 project confirms a big gap between how he thought XP would work and what he actually saw.

This is why so many XP advocates stress following the practices literally before speculating about improvements. That emphasis can come across as closed-minded zealotry, and sometimes it is. But often it reflects the memory of their own early skepticism and their inclination to do things differently. Only after doing XP did they realize it works in ways that surprised them. Once you've been surprised yourself, you are inclined to believe others will be too—and thus reluctant to listen to someone who hasn't had that experience.

Varying the Concrete

This suggests a different approach to process variability, one that starts not with a general, tailorable framework but with a concrete process. Begin even with a process that is clearly not the best fit for your needs. Running with a sub-optimal yet concrete process teaches you important things that you would otherwise miss. Only after that should you begin varying, drawing on tips from other processes to guide you.

That is the crux of how variation works in XP. You can only understand how to tailor a methodology if you understand how it works—and for a complex, heavy methodology, that takes a lot of work. An agile methodology, with just a few practices and a strong leaning toward incremental development and learning in the cycle, makes this much easier. Fundamentally, it is easier to change a small thing by adding bits than to change a large thing by taking bits away.

The hard part with XP in particular is that you cannot really understand how it works without doing it. So you must be careful about tailoring until you've done it enough to get a feel for it. The best path is to start a project by doing XP by the book, let it settle in for a few iterations, and then tailor it. In most cases, however, teams cannot do that. Instead they apply practices piecemeal to solve problems as they arise. That latter approach is easier, but it also carries greater risk, because you can miss how the practices interplay. If you do take that route, it is proportionately more important to have someone around who has seen XP click and can guide you from a position of knowledge.

So with XP you get a set of practices and experiences to start from—but it is only a start. You will need to adapt XP to your circumstances, and it is important to do that in the context of understanding how well XP works. This means trying XP as close to its book form as you can for a while, even if you suspect a modification would be more effective. Treat that stage as a learning phase. After a few iterations, start adapting. Do not be surprised if your adaptations then are not the ones you first thought of.

Beyond the Boundaries

At Thoughtworks, XP has served as the basis for a project of around sixty people, half of them developers. That is clearly too big to be XP, yet the project is called XP because XP has been the guiding philosophy. There is a contradiction there that cannot be denied. Perhaps it is better not to call it XP. The practices have had to be varied considerably to make it work, and because of the size, the whole team could never have experienced the by-the-book XP process.

Still, it is preferable that XP remains the stake in the ground behind its well-defined boundaries. What that large project is doing may be XP-influenced, but it is a different process—one that is now highly adapted to the particular project and continues to adapt, such that it hardly matters whether it is XP anymore. Other XP-influenced processes will and should appear, and we should expect a flowering of them. Perhaps the best way to think of XP is as a seed, not a tree.

When you choose to “buy” XP—and there is no purchase cost—what you get is that seed. You start by taking advantage of the XP community's experience with a process that is small, concrete, and therefore easier to understand than something that needs tailoring. For a few iterations, you follow that advice. Soon you have to build on it, adapting to your circumstances. You are still building on experience, but you cannot treat XP as a “cover your ass” defense. Agile methods in general are not suitable for that, and this is not a problem. Agile methods do not work unless you have a truly empowered team that will, in the end, take control of its process. A seed is an important part of any tree—but as any gardener will tell you, just throwing one in the ground is no guarantee of success.