(and XP is "rugby") by Brad Appleton

Download [FDD is Football-Driven Development in PDF 143KB]

On the agilemanagement YahooGroup in early December, Ron Jeffries posted a lengthy treatise describing his knowledge of FDD and where it seemed not very agile to him in numerous places

In part of it, he wrote:

1. So far, what you have been talking about lately sounds to me to be indistinguishable from waterfall: analyze, then design, then code. Yet we have heard over here here where I am that waterfall is not agile. There must be something in this discussion that either you're not saying or that I'm not getting. Please explain how the process uses and responds to change. To my aging ears "right first time" and "responding to change" don't sound the same at all.

I thought the exact same thing when I first heard FDD described by someone from Peter Coad's company (Tom Gullion of Togethersoft) and read the initial description from Chapters 6 of Peter Coad's book Java Modeling in Color with UML

It strongly resembled waterfall, with apparent elements of CMM and ETVX process descriptions. I thought the only "agile" part of it was the iterative development, and the rest was still very waterfall. 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".

I believe that FDD is one of those agile methods that is more like "American Football" than "Rugby". I think that is why there is a LOT of it that still seems very waterfall, document-heavy, and command-and-control as opposed to “barely sufficient”, self-organizing, and emergent.

I think XP, Scrum, Crystal, and most other agile methods (except possibly DSDM) are more like Rugby. I also think they are code-focused rather than model-focused. By that, I mean they treat the 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. (This naturally makes FDD fit in well with MDD/MDA).

Think for a moment, and pretend you were willing to suppose that the model could truly serve as "THE" center of system knowledge ... how would practices from a method like XP be different if that were true?

• Test-first coding would be test-first modeling (how might we do that?)
• Pair-programming would be Pair-modeling
• Refactoring would be behavior preserving transformations of a model's structure rather than of the code (and in fact, the Color Modeling patterns do just that - see Coad’s book or David’s Advanced Modeling paper)

I believe this is what FDD does manage to accomplish in its own way (though the mapping aren't quite exact). Modeling in FDD is not merely a two-person activity. As I understand it, it is in fact more collaborative in that it involves the entire feature-team led by the chief architect/programmer.

So I think that what FDD does to develop the model is indeed highly iterative and very collaborative with many feedback loops at several levels of scale during the entire process.

For XP-ers and Scrum-ers (and others) that would all be fine and dandy if it was the code and not the model for which we did all these things. But since it’s not, and since XP values the source code as the primary knowledge ("Use the source Luke" ), it makes little sense because that is where the fundamental clash in value systems resides between FDD versus XP (& others).

The waterfall-like part of FDD comes into play when the model is translated into code:

• code inspections
• strict code ownership
• little or no refactoring
• so called "chief" programmers
• no apparent TDD of the code

I think this is the "tradeoff" 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: the process of elaborating the code from the model looks very heavyweight and waterfall-like and is much more controlled rather than "emergent".

And while it may seem agile when producing the model, it will seem very assembly-line-manufacturing-like when producing the code from the model (it’s not quite that bad - there is still a LOT of communication and collaboration that is guided and mentored/coached by the chief architect/programmer).

It's a different way of getting there, and it is very "agile" in how it develops the model, but looks "un-agile" in how it transforms domain models into source code. And I think 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.

If you can allow yourself to accept that premise as a "given", then the rest of FDD will start to make a lot more sense. Once it does, then you can go back and challenge the initial premise with one's newfound understanding of how/why FDD is intended to work.

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.

--

Brad Appleton www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost