Feature driven development (FDD) is one of several agile methodologies for developing software iteratively. Iterative development is the opposite of waterfall development.
In a nutshell
FDD is a process that begins with high level planning to define the scope of the project, which then moves into incremental delivery. Each increment of delivery involves a design phase and an implementation phase. The scope of each increment is a single feature. Extreme programming (XP) is a much better known agile methodology. XP is often described as an emergent design process, in that no one knows what the finished product is going to be until the product is finished. FDD, by comparison, defines the overall scope of the project at the beginning, but does not define the details.
Explained by analogy
Consider the writing of a mystery novel as an analogy.
- Waterfall process. First, our author determines the major characters, the mystery, a detailed plot outline, and outlines for all of the subplots. Then she sketches out all of the minor characters. Finally she writes the novel, following her outline along the way. Immediately after typing ‘the end’ she sends the novel off to the editor. The editor replies with major change suggestions – it seems that the topic might have been in vogue two years ago, but it doesn’t sell very well today. And half the chapters are low-value rambling that are sure to lose the readers. Our author starts over.
- Extreme programming: XP. Our author decides to write a mystery novel, puts a blank sheet of paper in the typewriter and starts typing. As she writes, she realizes that she’d much rather write a romance, so she edits the chapters she’s finished and keeps moving forward. She sends early drafts to her editor of every chapter as she finishes it. The editor suggests that she change the setting from the Alps to the Amazon, and she edits again. After finishing the book, she has a three-book historical fiction series set in the rain forest.
- Feature driven development: FDD. Our author creates an outline for the story, gives names to the major characters and prepares to write chapter one. As she starts each chapter, she writes some details of the subplot, makes some notes about how the characters should develop, and begins writing. She sends her outline to the editor, as well as drafts of each chapter as she completes them. She splits her time between incorporating feedback on previous chapters and outlining/writing the current chapter. At the end of the book, she has a mystery with the same major characters that she expected – but they didn’t develop into exactly the people she expected, and she never would have predicted the sub-plots that created themselves as she wrote.
When we look at these approaches, we see that FDD tries to combine the best part of a waterfall process (good planning) with the best part of XP (continuous improvement through iteration).
More detail
There are five phases in an FDD process. The first three phases are planning phases and the last two phases are iterative phases (they are repeated for each iteration).
Planning phases:
- Develop an overall model. This is a representation of how the solution will work and what it will do. It is the high-level framework describing the big picture of how everything works together.
- Build feature list. This is the list of features needed to implement the high level view from phase 1.
- Plan. Create a rough plan of the entire project. Some proponents also talk about creating detailed plans per feature (as each feature is addressed).
Iterative phases (one feature per iteration)
- Design the feature. What Alan Cooper would call program design.
- Implement the feature. Writing code, testing, documentation.
Conclusion
There is little or no discussion about requirements in FDD. Starting with an overall model is great from a developer’s perspective. The challenge is in determining what to place in the model – what requirements are important to the users? How will users interact with the system? Good answers to these questions can make or break an overall model – and a faulty model will yield low-value software.
This approach to agile development can be very effective when augmented with the right requirements management process.
Learning more about FDD
- Brad Appleton has a good post providing several links to other sources and explaining how FDD sits between waterfall and xp processes.
- Jeff De Luca wrote the precursor to FDD (or the original version, as he explains)
- Peter Coad, author of FDD has a great 23 slide pdf presentation providing an overview of FDD.
- www.featuredrivendevelopment.com.
Check out the index of the Foundation Series posts which will be updated whenever new posts are added.
“XP is often described as an emergent design process, in that no one knows what the finished product is going to be until the product is finished. FDD, by comparison, defines the overall scope of the project at the beginning, but does not define the details.”
I believe this comparison distorts and almost parodies XP.
While it is true that XP embraces changing requirements, it includes an initial planning phase that defines:
1. A tentative overall set of user stories.
2. A release plan specifying which user stories to implement for each system release.
Thus the statement you attributed to FDD applies to XP:
“XP defines the overall scope of the project at the beginning, but does not define the details.”
Development processes generally lie on a continuum that ranges from waterfall to XP. I view XP as the most extreme of agile processes. But none of the processes – including XP – completely throws out planning and requirements.
Advocates of XP rightly argue that opponents have distorted XP.
See http://www.extremeprogramming.org/rules/commit.html for more info.
I am always amused when a “new methodology” comes to the forefront. XP started becoming popular when I was at GE in the mid-90’s. XP promised to be “a refreshing new approach” because it “emphasizes customer involvement and promotes team work. ”
And yet, this is precisely the same implementation as a multi-generational project plan (MGPP) that includes quality functional deployment (QFD). And incidentally, there is no alternative to the “waterfall” approach, and I am tired of hearing claims to the contrary. When you implement an SLDC in phases, you are still doing the same requirements-design-code steps. You just happen to be piping the water back up the waterfall a few times.
Maybe we need to start calling it the “Splash Mountain” approach.
Great visuals!
Iterative development is definitely a bunch of small waterfalls. I know when I’m writing about waterfall, I’m referring to teams that complete the entire project without customer feedback.
I think it was Alistair Cockburn who made the comment that agile didn’t invent anything new, they just repackaged the best of what they found already out there.