Feature-Driven Development: An Agile Alternative to Extreme Programming

symmetrical shape, and occurs at all levels of scale within a system (fractal-like in nature).

These Domain-Neutral Components are the higher-level building blocks (components) of the system: they represent business-flows and "plug-in" to each other in predictable ways. They also embody a traceable and transparent mapping between features, designs, and code in an FDD project. When a particular instance of a domain-neutral component is created for a particular part of the system, it is sometimes called a Domain-Specific Component . Numerous kinds of domain-specific components recur throughout many different products and programs within the same domain, and their essential essence may be catalogued and reused as a domain-specific component patterns.

Domain-specific components can themselves be connected to other such components in commonly recurring ways, and the result can be called a "compound component". Each component takes on a characteristic shape and the commonly recurring object types and extension points. The Java Modeling in Color with UML book defines 60+ "enterprise component models" and 10+ "compound components" representing patterns that can be used, extended, tailored, and applied to a variety of systems and domains.

It should be noted that Color Modeling is not explicitly required in order to do FDD. There are however those who feel it is an implicit part of FDD as originally put forth by DeLuca Coad; they would liken doing FDD without consistently applying Color Modeling, to doing XP without consistently applying refactoring. The color modeling patterns impose a structure and semantics on the model that encapsulate and separate concerns, and isolate and insulate features for parallel work and integration. The resulting code often needs little or no significant refactoring (restructuring). See the following for more resources on Color Modeling:

• Wikipedia page on UML Colors
• Arguments about Color , by Daniel J. Vacanti
• UML Color Modeling with Archetypes

FDD is Football-Driven Development (and XP is Rugby) When I first heard about FDD and saw an overview presentation, my initial reaction was that it didn't look very agile to me at all. Other than the fact that it used iterative development, everything else about it resembled more traditional plan-driven approaches with Waterfall/V-model phases, apparent elements of CMM, and formal ETVX-based process descriptions . I asked if others had the same impression. Several did, but Jim Highsmith chimed in saying he has seen it "live and in person" and that it is indeed agile; he said that, what makes it agile for him (besides the iterations) is the intense focus on collaboration when he has seen FDD practiced.

Bill Wake has a nice review of Nonaka and Takeuchi's book The Knowledge Creating Company . He describes how the book compares a "Relay Race" with what we call "Waterfall" and how something else they describe (that is very Scrum-like) is more like "Rugby". (This is the book which inspired the Scrum method after all!) The book also goes on to explain how the authors feel it is possible to combine the best of both, and liken the result to "American Football".

From this perspective, FDD is an agile method that is more like American Football than like Rugby. This explains why many proponents of other agile methods perceive FDD as very waterfall-like, document-heavy, and command-and-control as opposed to "barely sufficient", self-organizing, and emergent.

XP, Scrum, Crystal, Agile Modeling and most other agile methods (except possibly DSDM) are more like Rugby. They are also predominantly code-centric rather than model-centric in that they regard the source-code as the primary artifact for disseminating system knowledge; whereas in FDD, the domain model is the primary artifact for disseminating knowledge of the system. From