Feature-Driven Development: An Agile Alternative to Extreme Programming

Many people today judge all of "Agile development" based on what they know about Extreme Programming (XP), quite possibly because that is all or most of what they've heard about agile development. I wish all of those folks (especially agile skeptics) would take a close look at Feature-Driven Development (FDD) if for no other reason than because it is an example of an agile method that is very different from XP. FDD is quite agile while still employing many of the traditional practices that agile skeptics are probably more accustomed to seeing.

For example, FDD has the more traditional progression of a systems-engineering lifecycle model. It uses distinct phases in its iterations while still being highly iterative and collaborative. FDD does conduct up-front planning, design and documentation and relies very heavily upon domain modeling (including "Color Modeling " with UML ). FDD also uses feature-teams with chief architects/programmers and traditional code-ownership and code-review (as opposed to pair-programming and refactoring).

A Whirlwind Tour of FDD

Feature-Driven Development grew out of the method initially described by Peter Coad and Jeff DeLuca in chapter six of the book Java Modeling in Color with UML . It is a highly iterative and collaborative agile development method that focuses on:

• Delivering "frequent, tangible, working results" (about every 2 weeks)
• Domain-driven modeling and design
• Building-in quality at each step
• Producing accurate and meaningful progress/status with minimal overhead and disruption for developers
• Being useful and desirable to managers and clients (in addition to developers)

DeLuca and Coad first employed FDD with great success on a large (1M+ lines of code) Java project for an international bank in Singapore. Since then it has been increasingly used in other parts of globe with increasing success (including parts of large companies like Sprint and Motorola) and is described in more depth in more recent books like a A Practical Guide to Feature-Driven Developmen t and parts of Agile Management for Software Engineering .

The Five Processes of FDD
FDD is composed of five processes :

1. Develop an Overall Model
2. Build a Features List
3. Plan By Feature
4. Design By Feature
5. Build By Feature

 

So FDD can start with the high-level system requirements in place, or it can begin with the domain modeling to build the initial shared understanding of what the overall system is and must accomplish. In either event, FDD has more roles that are formally defined than many of the other agile methods, employing a chief architect, chief programmers, project managers (along with domain experts, developers (who serve as class-owners), and several other supporting roles (like build & release managers) to create an overall domain model, partition the system up into features, feature-teams and objects, and develop, build and deliver the results in an incremental and iterative manner.

Develop an Overall Model
To develop the overall domain model, the chief architect collaborates with the domain experts and developers to create an overall object-model using Color Modeling techniques and patterns. This is produced after a number of hi-level walkthroughs of the scope and context of the system for each area of the problem domain.

After a walkthrough, they split up into small groups of 3-4 people to