Nimble Work Management
Kairon - Gen AI Solutions
AKT/ AKC Access
→ Agile Methodology
→ Agile Software Development
→ Agile Program Management
→ Scrum Methodology
→ Kanban Methodology
→ Extreme Programming (XP)
→ Behaviour Driven Development (BDD)
→ Feature Driven Development (FDD)
→ Adaptive Software Development (ASD)
→ Dynamic System Development Method (DSDM)
→ Sustainable Pace
→ Story Mapping
→ Test Driven Development
→ Acceptance Test Driven Development
→ Iterative & Incremental Development
→ Pair Programming
→ Unit Testing
→ Acceptance Testing
→ Agile Planning
→ Refactoring in Agile
→ Burndown Chart
→ Lead Time & Cycle Time
→ Agile Velocity
→ Definition of Done
→ Backlog Refinement
→ User Stories
→ Scaled Agile Frameworks
→ Large Scale Scrum (LeSS)
→ Scrum of Scrums
→ Agile Release Train
→ Is SAFe Agile?
→ SAFe Implementations
→ Enterprise Agility With SAFe
→ What is Project Management Lifecycle?
→ What is a Project Management Office (PMO)?
→ What is Agile Project Management?
→ Importance of Project Management
→ What is a Project Roadmap?
→ What is Resource Management?
→ What is Work Management?
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.
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.
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.
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.
Factors to consider, are:
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 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.
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.
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.
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.
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.
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.
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.
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.
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!
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile