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 that 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. In FDD, the domain model is the primary artifact for disseminating knowledge of the system. From 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: Many of the color modeling patterns do just that.
Those parts of FDD are actually highly iterative and collaborative and, indeed, quite agile. The seemingly less-agile aspects of FDD comes into play when the model is translated into code using 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