Understanding XP through FDD

This is an attempt to understand Extreme Programming (XP) better by studying Feature-Driven Development (FDD). I have read a little about FDD and although I believe more in the XP style of development, I admire FDD; there’s lots of impressive things in it.

When reading about FDD, you sometimes get the feeling that it is very close to XP. For example, features in FDD and user stories in XP have much in common. But as you read more, you realize that the two approaches are fundamentally different, that they are based on different assumptions.

FDD as a process is very simplistic. Much more simplistic than XP, in fact, and yesterday when I did laundry, I began to think that XP isn’t a process or methodology at all. FDD is described as consisting of five processes representing stages in the course of a project: (1) Develop an Overrall Model, (2) Build a Features List, (3) Plan By Feature, (4) Design By Feature and (5) Build By Feature. In describing FDD they use a format they call ETVX, with sections for defining entry criteria (E), tasks (T), verification (V) and exit criteria (X). I felt that it was an effective format, but found it difficult to describe XP this way. Perhaps this is a hint of in what way FDD and XP differs?

You would either have to describe XP as consisting of two major processes: Plan and Develop. Both of these processes will have lots of tasks. The tasks in FDD are not tasks that are executed sequentially: in the Design By Feature process, for example, you would execute the list of tasks at least once per feature: walk through the domain, design and inspect the design. But for XP, I feel that the tasks for the Plan and Develop processes, to a greater extent would be tasks that you execute non-sequentially and multiple times. This would be especially obvious for the Develop process, with tasks such as Refactor, Write a Test, Make Test Pass, Integrate, and so on.

The point of breaking down a process into small, intuitive and cohesive chunks is to understand it better. Only having two processes with lots of tasks isn’t very helpful to newcomers trying to understand XP. Another option would be to have lots of tiny processes: Refactor, Test, Code, Integrate – along with one bigger: Plan. I was about to write that this would in effect be a one to one mapping with the twelve practices of XP, but then I visited the Extreme Programming Core Practices page at the Wiki and realized this was not the case. Why?

Some of the practices of XP in fact represent “values” and not activites – such as the Sustainable Pace (or “40-hour week”) practice, which is something that should be honored by the team, to avoid bursts of overtime and attempt to proceed at a pace that can be sustained during the course of the project, but it isn’t something you actively do. Other practices seem to be part value, part activity – such as Simple Design. In fact, most of them are value-activity items. Is this a reason why it’s so hard to compare XP to other processes? Let’s try to “force” the practices into a set of FDD-style processes.

One process would have to be Develop By Test (that is, test-driven development), with tasks being Form a Pair, Ask the Customer, Quick Design Session, Write a Test, Make a Test Pass, Refactor and Integrate. The next process, Plan, would have as tasks the “moves” described for the Planning Game: Write Story (either presenting a story, writing a new one or rewriting an old one), Estimate Story, Make Commitment (either by scope or by date), and so on. But there’s a problem with the planning game as it’s described in the XP literature: it is effectively “played” all the time. Let’s take a look at this.

Yes, the game is played all the time! You might not be in the conference room, discussing which stories to write, but the game isn’t over just because you leave the room. Actually, implementing a story should be a “move” in the planning game, just as you sometimes “terminate” the meeting without having estimated everything, to conduct a “spike” for a story which couldn’t be estimated (perhaps because it involved a technology never used before). And, during the iteration, if it becomes apparent that a task or story won’t be completed within the current iteration, you can proceed to the Make Commitment “move”, to rearrange the scope for the iteration.

In describing XP planning as a FDD-style process, we therefore have to define “Plan Needs to be Revised” as an exit criteria for the Develop By Test process, and as an entry criteria for the Plan process. This deviates from the rule that, to quote Feature-Driven Development (PDF), the “[exit] criteria must define tangible outputs”. However, this option is better than to duplicate some tasks of the Plan process and put them in the Develop By Test process, or to allow fuzzy transitions between processes.

Funny! We’ve ended up with two major processes anyway: Plan and Develop By Test. But it doesn’t seem so bad as I first thought. The XP practices that we haven’t covered in these two processes are:

• On-Site Customer, which is more of a role than an activity;
• Small Releases, which might be a process of its own or a task within Develop By Test, but then again it’s also a value, and since releasing/deploying will be different in every project and there’s no documentation to be produced, or other activities related to releasing, as dictated by XP, I’ll treat this as a value;
• System Metaphor, which could be a task of an Explore process only conducted initially in a project: Agree On System Metaphor;
• Collective Code Ownership, which clearly is a value;
• Coding Conventions, could also be a task in the Explore process: Agree On Coding Conventions;
• and Sustainable Pace, which as said is a value, not an activity.

The Explore process seems obvious now. It would be a process that is executed initially in a project, or when beginning a new major release. Its tasks would be Make Big Plan (sketch a coarse plan for the entire project) and Conduct Spikes (or “architectural spikes”, to briefly explore, by coding, all parts of the system to be built, in order to get experience for agreeing on the metaphor, future estimation, and so on) – along with the already mentioned tasks Agree On Coding Conventions and Agree On System Metaphor (I like the “agree on” part, which I feel is essential to XP: that the entire team is involved).

Now we’ve covered all practices except On-Site Customer (which would be one of the roles), Small Releases (which we deemed to be a value) and Sustainable Pace (value), and we’ve ended up with these FDD-style processes:

• Explore – Make Big Plan, Conduct Spikes, Agree On Coding Conventions and Agree On System Metaphor;
• Plan – Write Story, Estimate Story and Make Commitment (perhaps overly simplified);
• Develop By Test – Form a Pair, Ask the Customer, Quick Design Session, Write a Test, Make a Test Pass, Refactor and Integrate.

Besides this, FDD lists the roles: Chief Programmer, Class Owner and Feature Teams (formed and disbanded many times during a project). For XP, you would have Customer (on-site), Programmer, Coach, Manager and Tracker, as described in the literature.

This effort to understand XP better through studying an alternative has been valuable for me. I have explored FDD a little before – see here – and here – and one thing I’ve thought about is that the coach perhaps should act more like the chief programmer in FDD, conducting additional code reviews and supporting the development as well as the process. This would suggest a coach that is not only a “people person”, but a skilled developer.

Anyway, I suggest reading a little about FDD. I find it appealing although I think that they do too much modeling before starting programming. I also think that for some organizations that require a more formal approach than XP, FDD might be an excellent choice. I hope this walkthrough has made you learn something new – I know I have.