Feature Driven Development: Evolution vs Revolution

  • Updated: August 29, 2023

Agile 101

Feature Driven Development: Enterprise Evolution to Agile

Feature Driven Development (FDD) is not as well-known as many other agile frameworks.

But when you’re dealing with a large, long-running project, especially in an organization where agile is still mostly confined to software development, FDD may be your friend.

Feature Driven Development bridges the gap between traditional controlled waterfall approaches and the emergent processes found in agile approaches like behavior driven development, extreme programming, and scrum.

Let’s investigate.

Custom Development Services

Table of Contents

Brief Overview on FDD

FDD is a methodology broadly regarded as based on the four agile values and the twelve agile principles as set out in the Agile Manifesto. It was one of 6 methodologies represented at the meeting that created the Agile Manifesto.

Work starts with building a domain object model and identifying all the features and feature sets (groups of features). After prioritizing the features, work proceeds iteratively and incrementally.

The combination of more traditional planning with agile build practices helps FDD fit in with traditional enterprise structures.

It works well for large teams and long, complex projects.

Brief History

The founders of Feature Driven Development were Jeff De Luca and expert modeler Peter Coad, helped by their co-workers. FDD was first applied in 1997 working on a product for a Singapore bank. The product took 15 months to complete with 50 people. After its success, it was used on a second, 18-month long, 250-person product. It grew from there.

How Does It Work

Feature-driven development defines five steps in two phases: planning and construction.
Feature Driven Development Fdd 2

Planning Phase

The planning phase is about getting to a shared understanding of the scope of the product (a new software system) between the customer and their users, and the development organization. It’s how FDD helps you start an evolution instead of a revolution towards agile development.

Step 1: Develop an Initial Model

The first step in FDD is to outline an initial domain object model.

Teams of developers and domain experts (e.g., future users in the customer’s company) each define a model that reflects their shared understanding of the important objects in the new system. The chief architect supports and guides them in this work.

When these are done, all models are reviewed to come up with the initial model for the next steps. This can be one of the models or one that is a composite of one or more of the individual team’s models.

Step 2: Develop a Feature List

Next up is the feature list — all the functionality the product needs to offer.

To do this, you split the domain model into subdomains that each represent a business function. For each subdomain, you then list all the features you require for the product to support your customer in that business function.

Features that are closely related are often grouped into feature sets. A feature set can also be a feature broken down into smaller ones because it would otherwise take more than two weeks to complete.

Step 3: Is where you plan the order in which to develop features and feature sets

Factors to consider, are:

  • Which features your customer’s users need most urgently.
  • Which features will deliver the most value soonest.
  • Development time estimates — you don’t want to leave the biggest features for last.
  • Technical dependencies between features.
  • Risks involved with features — for example compliance testing, using new technology, learning new frameworks and libraries.
  • Available people, their skills and expertise.
  • Workload.
  • Etc.
The result is a prioritized list of everything you need to implement. It’s like starting a Scrum project with a fully filled (but not refined) product backlog.

Construction Phase

In the design and build phase of FDD, you work through the feature list on a feature-by-feature basis.

Work proceeds in two-week cycles, or iterations and is thus inherently iterative and incremental. The strict two-week cycle is why FDD wants you to break up features to fit that.

In FDD, it’s okay to form and reform teams with the requirements of the features you’ll build next in mind. Generally, selecting people for a specific feature team is the realm of the chief programmer (see Key Roles and Responsibilities).

Feature Driven Development Overview

Step 4: Design by Feature

Each feature team works on the detailed design of the features assigned to them for the current iteration. Developers and domain experts, helped by the chief architect and chief programmer as needed, use UML modeling techniques such as class diagrams, sequence diagrams, and state transition diagrams to specify what the feature will do and how it’ll do it. Working on these specific designs, knowledge about the product increases and informs any changes needed to the initial domain object model. Each iteration, at the end of the design phase, a review by the entire team ensures that overlaps are identified and all the teams are aware of the overall model and design and stay within the original product concept.

Step 5: Build by Feature

Each feature team then works to turn their design into working software, test it, and gather feedback from domain experts to verify that the feature works as intended. When all’s okay, they’ll integrate their work with everything that’s been built in this and previous iterations.

Similarities and Differences

Feature Driven Development is a blend of up front design — the initial domain model — and planning, and iterative and incremental implementation. As such it’s both architecture-centric and agile.

It’s agile in its emphasis on meeting the needs of the end-users, collaboration with customer’s domain experts, and breaking down requirements into small features designed to deliver business value.

In other respects it’s much less agile.

All in all, I’d dare to posit that FDD is a good step away from the waterfall approach, but it falls short of many accepted agile practices that are better at encouraging everyone to take responsibility and activating and engaging everyone’s creativity, and deferring decisions to the last responsible moment.

Documentation

FDD insists on putting the (design) documentation into a knowledge system and extending it with construction information, meeting minutes, and decisions and issues that have arisen. It also insists on keeping that documentation up-to-date and spot on. As such, it’s a lot more documentation-heavy than most agile methodologies.

Hierarchy, top-down execution, and teams

FDD is hierarchical in nature with its use of traditional project management, hierarchical (line) management, and the roles of chief architect and chief programmer, especially in the planning and design steps. And, contrary to other agile frameworks, FDD doesn’t seek to create teams that stay together for the long haul. Teams form and disband around the features to be built next, and team composition is the realm of the chief programmer. Team members have no, or little, say in who they work with. Taken together, this means that teams in FDD are not and cannot become self-managing or self-organizing and that you won’t find teams doing retrospectives focused on their process, collaboration, and interaction as is so important in many agile frameworks.

Dealing with change

As FDD plans, designs and builds “by feature”, it’s possible to pause the construction phase and consider how to respond to changes in the new system’s environment, for example a new competitor in your market.

This means FDD is more amenable to change than the waterfall approach, but there’s more waste than in other agile approaches, as you’d essentially be re-doing the planning phase to decide which built features to scrap, which not-yet-finished features to drop, and which new features to add. And that is including all the changes needed to keep the documentation up-to-date.

We’ll cover the cycles themselves in more detail later. Now, let’s focus on the characteristics of great teams.

Code ownership

FDD is unique in its insistence on ‘individual class ownership’. Jeff de Luca says:

“Collective ownership is code for ‘no ownership’. It’s not a structure I believe in.”

In this, FDD goes against common practices advocated in the agile community. Individual class ownership lowers your bus factor to 1 — it’s somewhat compensated for by FDD’s reliance on good documentation.

Key Roles and Responsibilities

The project manager oversees the entire project, and uses traditional rather than agile management techniques.

The development manager deals with the day-to-day activities. S/he is often the developers’ line manager and also functions as a mentor for less experienced team members.

The chief architect is in charge of the overall design of the system and guides the domain experts and developers in their work during the initial and iterative design steps.

The chief programmer is an experienced developer who assists teams with analysis and design during the design and build steps. S/he helps the class owners and other developers to keep the code base consistent in its application of software design principles. S/he may also manage small development teams.

A class owner is any developer responsible for designing, coding, testing, and documenting a class that implements part of the domain object model in code.

A domain expert understands the customer’s business in general and the part that the new product (system) will support in particular. S/he helps the development teams understand how the business operates and what it needs. S/he usually comes from the customer’s organization.

Key Meetings, Cycles, Delivery Cadences

The Planning Phase is a two-week period to produce the initial domain object model and the feature list. During the Design and Build phase, the delivery of work for testing is weekly. Delivery of features to the customer is every two weeks. Teams participate in reviews of progress and performance. For example, there are regular round-table meetings for code reviews during the construction phase.

Methods and Techniques

Broken down into its five steps, FDD is more structured than other methodologies. This is reflected in the methods and techniques it uses and advocates.

Object-Oriented Design: With Peter Coad — a renowned object-orientation proponent and UML pioneer, as a founder, it’ll be no surprise that object-oriented design features prominently in feature driven development.

Features and feature sets: Features are small, client-valued pieces of a product’s functionality. They are expressed through action, result, and object — e.g., ‘Calculate the total of a sale’. Feature Sets are simply grouping of features.

Individual class (code) ownership: Each class or related set of functions in code has a single owner who is responsible for the performance and quality of that code.

Feature teams: feature teams in FDD are dynamic — they are formed and disbanded from class owners as needed by the features that are to be built next.

Inspections: FDD uses design inspections and code inspections to prevent errors — or rather to detect them before they escape into the wild.

Highly visible progress reports: FDD specifies a comprehensive and easily understood set of progress reports. It uses a number of milestones to report feature progress consistently and color codes statuses for an easy big-picture view of project progress. Two progress reports specific to FDD are Parking Lot charts and Feature Complete charts.

Common Pitfalls

Agile aspects of FDD can get snowed under because of hierarchical management and top-down design.

Dynamically forming teams around class owners needed for features often works against achieving the benefits of a tightly-knit stable team that pulls together as one.

FDD relies heavily on experienced people, like the project and development managers and the chief architect and programmer. In that respect FDD is rather top-heavy and smaller shops with only a few teams may find it hard to use it effectively.

Individual class ownership

Jeff de Luca may not believe in collective class or code ownership, but he’s far outnumbered by agile proponents who do. And the pitfalls of individual ownership are many.

  • People can build personal empires around ‘their’ classes, lowering the project’s and company’s bus factor.
  • Code inspections become the main opportunity for knowledge sharing, and as their goal is different, they’re incredibly ineffective for that.
  • Collaboration and knowledge sharing between developers suffers, lowering the bus factor further.
  • Quality and consistency in coding patterns requires active monitoring — often with the chief programmer as an ‘enforcer’ — instead of occurring as a natural byproduct of collaboration and peer-reviews.

Getting Started

All the normal advice to getting started with a new methodology applies just as much to getting started with FDD.

That means: get buy-in from and collaborate with top management; train everybody in the methodology — including people that won’t work according to it but are affected by the way it works; use coaches and mentors who’ve walked the path before at all levels; etc.

More specifically, as FDD relies heavily on object oriented modeling, it’s a good idea to get everyone trained in and comfortable with the notation used in its diagrams. After all, you wouldn’t want an architect or designer who’s unable to read blueprints, would you? So train everybody in UML (Unified Modeling Language) so they’re comfortable reading, creating, and assessing the initial domain model and all the other OO (Object Oriented) design diagrams.

Further Reading

Feature driven development was first discussed publicly in a chapter of the 1999 book ‘Java Modeling in Color with UML’.

Stephen Palmer and Mac Felsing‘s book ‘A Practical Guide to Feature-Driven Development’ (published in 2002), gives a more general description of FDD and decouples it from Java modelling.

Agile Software Development Ecosystems – Jim Highsmith (recommended by Jeff de Luca, difficult to find).

Feature Driven Development: In the beginning. 6 Youtube videos describing FDD and its differences from Scrum, given by ScrumMaster Vernon Stinebaker.

Feature Driven Development – An academic description of how feature sets work and how to integrate them into the system.

An archive of discussions around FDD: http://www.featuredrivendevelopment.com.

FDD, the Evolutionary Bridge to Agile

Introducing agile practices can be difficult in an enterprise with a top-down management structure.

Feature Driven Development mixes traditional aspects (e.g. a more traditional top-down management structure and more upfront planning) with agile practices (e.g. iterative and incremental product delivery, focus on business value to the customer and end-user).

This mixture offers a way of introducing agile in larger enterprises that is more evolutionary than revolutionary.

So, if you’re just taking your first steps on the road to agile, check out FDD in more detail. It may well be the evolutionary bridge that’ll make for an easier journey in your transition.

Signup for updates!

Medha Case Study

Speed up your Agile planning and execution!

Signup for a FREE Trial of Nimble Agile

Free Trial
Request Demo