Feature Driven Development: Evolution vs Revolution
-
By Marjan Venema
- 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.
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
How Does It Work
Planning Phase
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:
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).
Step 4: Design by Feature
Step 5: Build by Feature
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
Hierarchy, top-down execution, and teams
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.
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
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.
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.
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile