Feature-Driven Development (FDD) is one of the agile processes not talked or written about very much. Often mentioned in passing in agile software development books and forums, few actually know much about it. However, if you need to apply agile to larger projects and teams, it is worthwhile taking the time to understand FDD a little more.
Feature-Driven Development (FDD) invented by Jeff De Luca is different. While just as applicable for small teams, Jeff designed FDD from the ground up to work for a larger team. Larger teams present different challenges. For example, a small team of disciplined and highly skilled developers by definition is likely to succeed regardless of which agile method they use. In contrast, it is unrealistic to expect that everyone in a larger team is equally skilled and disciplined. For this and other reasons, FDD makes different choices to Scrum and XP in a number of areas.
What this is
Feature Driven Development (FDD) is an iterative software development methodology intended for use by large teams working on a project using object-oriented technology. The methodology description includes some prescription about what tasks should be done and what roles should be doing them, so many do not consider it a truly agile methodology. FDD is good for organizations that are transitioning from a phase-based approach to an iterative approach but are not comfortable getting rid of all task and role assignments.
Why it’s useful
FDD is useful because it demonstrates that you can focus on domain modeling on an iterative and incremental project, and because it demonstrates that agile-like methodologies can scale. FDD shows that teams can spend a short amount of time at the beginning of the project to establish a clear understanding of the domain in which they are working and use that understanding to formulate a rough plan without getting stuck in analysis and design paralysis.
The fact that FDD was created on a project that was larger than recommended for most agile projects is a sign that methodologies taking an iterative and incremental approach can be used for large projects. The founders of this method chose to facilitate use by a large team by prescribing some tasks and roles, but they also took an approach used by many teams to scale using agile approaches—break the large team into smaller feature-focused teams, instead of small teams organized by role or skill set.