Feature-Driven Development: An Agile Alternative to Extreme Programming

an XP-based perspective this is an alien concept, and would suggest that XP practices might translate to model-centric practices as follows:

• Test-first coding would be test-first modeling -- some of the basic FDD domain/color modeling "grammar" rules serve this purpose
• Pair-programming would be Pair-modeling -- FDD actually does domain-modeling as a collaborative team-wide activity led by the chief programmer/architect.

• Refactoring would be behavior preserving transformations of a model's structure rather than of the code -- and many of the Color Modeling patterns do just that

So those parts of FDD are actually highly iterative and collaborative, and indeed quite agile. The seemingly less-agile (more heavyweight) aspects of FDD comes into play when the model is translated into code use formal inspections and reviews, strict code ownership, very little refactoring, and significant documentation for feature requirements and design (some might argue that FDD also lacks test-driven development, even though FDD places a string emphasis on testing and unit-tests).

These are the tradeoffs that FDD makes in the particular way it chooses to be more like "American Football" rather than "Rugby" when it makes the choice to treat the domain model as the primary knowledge artifact rather than the source code. It's a different way of getting there, and it is very "agile" in the way it develops the model, but looks very "plan-based" in the way it transforms domain models into source code. The first step an XP-er or Scrum-er needs to take in order to understand it is to temporarily suspend their belief that "the code is King" and imagine it might be possible if the domain model were "King" instead.

FDD is an agile method that treats the model as if it was "the source code" for nearly all but the implementation details of individual classes. In FDD, the domain model is valued over documentation, and it is also valued over the source code (which must be written under closer control/supervision than with XP/Scrum). The source code is still valued, but the model is valued more, and it is a much more visual (and to many, much more effective) way of communicating system information to more than just programmers.

For some interesting and profoundly insightful (and practical) extensions of FDD that tie it together with other process improvement methods like Lean, the Theory of Constraints, and Six Sigma, I strongly recommend taking a close look at the work of David Anderson, author of Agile Management for Software Engineering , particular his paper and presentation on Feature-Driven Development: towards a TOC, Lean and Six Sigma solution for software engineering.

Here are some further resources about FDD so folks can learn more about it and become more aware of the fact that XP isn't the only agile "game" in town when it comes to development practices (SCRUM and DSDM are focused primarily on planning rather than development practices):

• Feature-Driven Development and Extreme Programming , by Stephen Palmer -- Superficial similarities between Feature-Driven Development (FDD) and Extreme Programming (XP) hide a number of very important differences between the two processes. This article provides a short comparison of FDD and XP.
• Jeff DeLuca's FDD website including the latest description of FDD processes and an FDD Overview presentation
• The FDD Portal
• David Anderson's Channel FDD articles (scroll to the far right-hand-side)
• Implementing Cognizant Feature-Driven Development using MS VSTS (whitepaper)
• Delivering Business Value using FDD , by Grant Cause, from the Winter 2004 Methods and Tools Newsletter, pp.23-35