Variations on a Theme of XP

Why Buy a Methodology?

To help answer these questions I think we have to back up a bit and ask ourselves: what is a Methodology for? Why would anyone want to use a Methodology? I'll posit that the answer to this is because the customer of the Methodology is someone who is concerned about how to develop software properly and expects that by following a Methodology they are taken a proven path that increases their odds of success.

One might also say that by following a Methodology they are protecting themselves from the consequences of failure by saying “I did everything I could - I followed a respected Methodology”. Although it's common to decry that latter reason, it's true that in many disciplines you are expected to follow a certain process for doing a task, and if you don't follow the consequences you may well be more liable for problems down the line.

In either case people want some steps to follow to increase their chances of success. This is reasonable. After all we've been developing software for a few decades now. Surely we should be able to learn from the experience of others.

The Variability of Methodologies

To be brutal about it most methodologies are statements that a methodologist makes based on what he did once. That is if he's lucky - I suspect most of them are based on what they wished they'd been able to do. At best you might have a few people combining ideas: but whether anybody has actually done the resulting set of things is another matter.

Software is also incredibly variable. For a start one of the key variables in software is people. Different methods will work differently with different people. Company cultures also have a big effect. There's also the style of the software. I don't belive a process designed for telephony is appropriate for information systems, is appropriate for games.

To be fair a large proportion of methodologists do recognize this. They know that they can't give a simple sequence of steps that people should follow and get perfect results. There is always some adapting, some tailoring to be done. But how do we guide the tailoring? How does the customer of a methodology know what's reasonable tailoring and what breaks the methodology?

This is particular a question for those who follow Agile Methodologies. One of the key features of these Methodologies is that they are what I call self-adaptive: that is you are expected to change the methodology as you use it over time. In this state the boundaries of acceptable variation are even more fluid. Not just is there variation between one project's use of a methodology, there is variation in a single project over time.

This is the methodologists dilemma. How do you describe the variations within a methodology so you can be comfortable that people who really try to follow your advice will get the benefits you are expecting, yet allow them to adapt your advice to better match their specific circumstances?

Variability and Methodologies

As we look at the issue of flexibility with methodologies, it's worth bearing in mind that there are various styles of methodologies out there. Each of these bring a different set of issues to the matter of variations. So here's a set of methodology classifications to think about. Bear in mind that the terms I use here are ones I'm coining for this article and that the lines between them are very fuzzy.

First off is a concrete process. A concrete process gives you a fixed set of practices that you should follow. A concrete process will allow for little or no variation. The strength of a concrete process is that makes it very clear what you should do to follow it. The obvious limitation of a concrete process is that you can't change it. Well actually you can. All the time people take a concrete process and adopt it with local modifications. The problem is that the methodology gives you no guidance in how to do that. Furthermore as soon as you start varying you are strictly outside the process, although you may well be close enough that a fan of the process would say you are within a process - particularly if you are successful.

Since a concrete process is so fixed, a lot of processes come with explicit guidelines of how to vary it. I'll call such a process a tailorable process. Tailorable processes usually have a significant part of the process description that addresses what variations are acceptable and when it's appropriate to use those variations. As such they gain over concrete processes because they do provide advice on variations. However it's not perfect because it's often very hard to understand how to do this correctly. You have to understand both the base process and all the variations before you can decide what to do.

At this point it's worth thinking about the size of a process. It's not easy to understand what size means in a process, but one way is to think about how much stuff you have read to get a handle on the process. A common pattern is to have large tailorable processes. The idea is to tell you everything you should do, and then tell you what you can leave out. However to do this you need to understand the large process before you can figure out the small. If you need a smaller process, this can be a lot more work than you'd want to do.

There's many processes that are tailorable like this, perhaps the best known one out there at the moment is the Rational Unified Process. This is more tailorable than most, so much so that it's referred to as a process framework. The way this is explained is that anyone who uses RUP will use a particular process that is an instance of RUP, and need not use or understand the full flexibility of RUP. So it's quite possible to use a concrete process and RUP (a tailorable process) at the same time. In my view if you do that, and don't really look at RUP, then it's the concrete process that you're using. But RUP may help with advice on variations that the concrete process lacks, as well as helping you communicate with folks who use other concrete instances of RUP.

Some processes don't give you very concrete steps at all, rather they concentrate on teaching a philosophy of software development that underlies process. Such a philosophical process is inherently flexible because there are many ways you can carry out a project that fits the philosophy. Because they don't go into details on steps and variations, they can do this without being as large as a tailorable process or process framework. However because they lack the concrete steps they are often harder to follow, they don't clearly tell you what you need to do on Monday. Jim Highsmith's ASD is an excellent example of a philosophical process.

Although folks would often not call them a process, a relevant group of knowledge is collections of best practices. A good example of a best practice collection is McConnel's collection of best practices in his excellent book Rapid Development. Such a collection is a group of relatively independent good things to do that you can apply pretty much in any order. Unlike philosophical processes they are concrete pieces, but it's very much up to you decide which best practices to apply on your project.

The nice thing about best practices is that you don't have to understand a complicated web of steps to take advantage of them. Instead you can pick the practices that you think will give you the most value. Since I've always distrusted Methodologies, I liked this approach. But one of the things that XP made clear to me was the fact that practices are not independent pieces. XP's power comes not so much from individual practices, but the interaction between the ones that Kent chose. If you look at the XP practices as individual practices you miss much of the point of XP. From this I learned that the interaction between practices is every bit as important as the practices themselves, and it is that interaction that a concrete or tailorable process is good at capturing.

So all of these approaches have are imperfect in some way. A concrete process is in theory not variable at all and in practice gives you no guidance on varying it. Tailorable processes work well in theory, but to tailor them you have to understand an awful lot of material. Philosophical process give you a good underpinning, but don't really give concrete advice on what to do. Best practice collections tell you individual things to do, but don't talk the interactions between the practices.

What is XP?

To look at variability and XP we have to first recognize which of the categories XP fits into. For many it's clear that XP is a concrete process. It has twelve practices that must be followed and if you spend much time on any XP discussion group you'll quickly see that the advocates of XP put a lot of effort getting people to do all twelve practices. As such many have picked up quite a reputation for excessive zealotry in putting forth their view.

But much of XP's appeal has come from people who are drawn to the underlying philosophy of XP rather than the concrete practices. XP's attention to adaptivity, people-orientation, light weight, and emergent behavior is a compelling mix. There are plenty who want to use XP, but are outside of the bounds of the concrete process.

One of the unusual things about XP that I particularly like is the fact that it does set itself very definite bounds. It assumes a co-located team of up to a dozen or so developers. These bounds are pretty clear, but there is much about XP that appeals to projects that fit outside these bounds. What happens if you have a project with thirty developers or a project with a lot of people telecommuting? The principles of adaptivity and people-orientation are still valid. Why not get as close to XP as possible?

So you get debate, debate between those who prefer the narrow view of XP and those that prefer the wider view. The debate is intensified by the fact that XP has gained a lot of brand awareness. People are keen to say they use XP because they know that saying that communicates a lot about the values and principles that underlie their work, values that matter even if you have a large or distributed team.

XP does not have a steering committee that makes official pronouncements on what is or isn't XP. It is more like a community with only informal arrangements, and the community is still somewhat undecided on this question. Kent has stated he prefers XP to be a concrete process - a “stake in the ground”. As he is the accepted alpha male of the XP community that preference carries a lot of weight. So the predominant view is that XP means the concrete process.

XP and Self-Adaptivity

So we take XP as the sharply defined process, the stake in the ground. How do we square this with the need for self-adaptivity?

The clue to the answer comes with a statement made by Kent Beck when someone posed a question to him about setting up maturity levels for XP.Most people reacted to this question with horror that there could be any notion of CMM-like maturity levels for XP. Kent, as he often does, replied with a thoughtful seriousness that frequently surprises people. He said that there were three maturity levels for XP:

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

Here we see the self-adaptivity coming in- you must adapt XP to still be doing XP. As I put it: if you're still doing XP in iteration 6 the way you were in iteration 1 then you're not doing XP.

But notice the maturity steps here. The levels assume that before adaptation, people do XP by the book. The point here is that its hard to see how XP works without doing it. The combination of practices that makes up XP work in a way that is very difficult to appreciate unless you've done them together so you can see how they interact and work together. Reading and surmising about the effects is a poor substitute for actually being there. I can certainly attest to the fact that there is a big difference between how I thought XP would work, and what I saw when I worked on C3.

This is why so many of the advocates of XP put so much emphasis on doing XP by the book before engaging in speculation as to how XP could be improved. Often this comes over, with some reason, as closed-minded zealotry. But a lot of the time it is because XPs advocates remember their own early skepticism and their inclination to do things differently. Only when they did XP did they realize that it works in ways that surprised them. Once you've been surprised yourself, you're inclined to think that others will be surprised, and thus reluctant to listen to someone who hasn't gone through that experience.

Varying the Concrete XP

This implies a different way to thinking about how to make a process be variable, one that uses a concrete process as its basis. Rather than begin by figuring out how to use complicated yet tailorable process, begin with a concrete process even if it's clearly not the best for your needs. Run with this sub-optimal yet concrete process. Doing this will lead you to learn important things about the process that otherwise you'd miss. Once you've done that, then start varying. Use tips from other processes to help you do that.

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

But the hard part of understanding how XP, in particular, works is that it's very hard to really understand how XP works without doing it. As such you've got to be very careful about tailoring XP until you've done it enough to get a feel for how it works.

The best solution is to begin a project by doing XP by the book, letting it settle in for a few iterations, and then tailoring it. However in most cases, folks aren't able to do that. Instead they need to apply practices piecemeal, in order to solve the various problems as they can. I think that latter approach, while easier to do, also carries a greater risk as you can miss how the practices interplay. So I think that with the latter approach it's proportionately more important to have someone around who has seen XP click, and can thus guide you from a position of knowledge.

Thus with XP you are still getting a set of practices and experiences to start with. But it is still only a start. You'll need to adapt XP to your circumstances, but it's important to do that in the context of understanding how well XP works. To my mind this means you should try XP as close to its book form as you can get for a while, even if you don't think it will work as effectively as some modification might make it. Treat that stage as a learning phase. After a few iterations, start adapting. I'll be surprised if your adaptations then are the same as the initial set of adaptations that you first thought of.

XP and the Boundaries

So what's the future for XP and beyond its boundaries? At Thoughtworks we've been using XP as the basis for a project with around 60 people, half of whom are developers. This is clearly too big to be XP. Yet we call it XP because XP has been the guiding philosophy behind what we do. There's a contradiction there that I cannot deny. Perhaps it's better if we don't call it XP. Certainly we've had to vary the practices a good bit to make it work, and due to the size we were never in a situation where the whole team had experienced the “by the book” XP process.

Despite this I would prefer it if XP stays the stake in the ground behind its well defined boundaries. What we are doing may be XP-influenced, but it's a different process. We may not name it, after all it's now highly adapted to the particular project and will continue to adapt that way, so we hardly care whether or not it is XP any more. I think other processes will and should appear that way and we'll see a flowering of XP influenced processes grow. Maybe the best way of thinking about XP is that it's a seed, not a tree.

So when we choose to “buy” XP (there's no purchase cost after all), what we get is the seed. We can start and take advantage of the experience of the XP community with a process that is small, concrete, and therefore easier to understand that something that needs tailoring. For a few iterations we follow that advice. But soon we have to build on it, adapting to our circumstances. As such we are still building on experience, but we cannot consider using XP as a “cover your ass” defense. I don't think XP, and other agile methods are suitable for that. and I don't see this as a problem. Agile methods don't work anyway unless you have a truly empowered team that in the end will take control of its process. A seed is an important part of any tree, but as any gardener will tell you, it's no guarantee of success to just throw one in the ground..