FDD
Origin
Jeff De Luca designed FDD in 1997 for a software project at a Singapore bank, to be carried out by a team of 50 people over 15 months. The first formal description was published in Chapter 6 of the book Java Modeling in Color with UML (Coad, Lefebvre, and De Luca, 1999).
The five FDD processes
FDD defines five main processes:
1. Develop an overall model
The team builds an overall view of the system through group modeling sessions. The result is a domain model, usually in UML, that the whole team shares.
2. Build a features list
Starting from the overall model, the team identifies all the features of the system. Each feature is expressed using the formula [action] [result] [object]. For example: "Calculate the total of an invoice." Features are grouped into sets of related features.
3. Plan by feature
The development managers and the team order the feature sets by priority and dependency, and assign each set to a chief programmer responsible for its delivery.
4. Design by feature
The chief programmer selects a subset of features to complete over the next two weeks. Together with the owners of the affected classes, they design in detail how to implement them.
5. Build by feature
Programmers implement the design, carry out unit testing, and conduct peer code reviews. Once finished, the feature is integrated into the main build.
FDD in perspective
FDD was influential in the first decade of the 2000s because it addressed a real need: how to apply agile principles to projects with dozens or hundreds of developers, at a time when Scrum had not yet developed scaling frameworks. Its emphasis on shared domain modeling and class ownership was innovative for its time.
Today its direct adoption is limited: it has been displaced by better-documented scaling frameworks such as SAFe or Nexus. Its current value is mainly historical and conceptual.
Common mistake
Believing that FDD and Scrum are incompatible. FDD and Scrum can be combined: FDD provides the structure for modeling and feature ownership; Scrum provides the iterative cadence and the inspection and adaptation events. In practice, some teams use the Scrum sprint as the cadence for FDD process 5 (build by feature) while keeping FDD's modeling and planning in the earlier processes.
References
- Coad, Peter; Lefebvre, Eric; De Luca, Jeff. (1999). Java Modeling in Color with UML: Enterprise Components and Process. Prentice Hall.
See also
Do you want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.