Feature Driven Development (FDD) is an agile methodology specifically applied to software development.
This post explores what FDD is, FDD best practices, implications of FDD for strategy, and how FDD is implemented with other agile methods while managing a project.
What Is the Agile Feature-driven Development Methodology?
Feature-driven Development (FDD) is one of several agile methodologies or approaches (some other popular ones include Scrum, XP, DSDM, and Crystal).
The figure above illustrates the concept behind FDD. Here is some explanation of each of the five steps:
- Develop an overall model – What is the scope of the system? What is the context? What function does the system perform? What are the parts of the system, and what function(s) does each part perform? This is in large part a system architecture effort.
- Build a feature list – This is an effort in disaggregation, or decomposition, of the overall model. The first level of decomposition is into general subject areas. Each of these areas then needs to be decomposed further into small chunks of functionality – features – that provide value to the customer. The features should be formulated at a level that allows developers to build them – ideally user stories.
- Plan by feature – With a list of features in hand, planning includes: prioritization, grouping according to skill set, and other considerations specific to the situation. The result should be an ordered and organized list from which to extract features, broken into user stories, to be developed during a sprint or iteration.
- Design by feature and Build by feature – Design and build are iterative steps and repeat for each feature. For a given set of features planned for a sprint, the team will design and build the features until complete by the end of the sprint.
The concept is consistent with overall agile concepts. I think what differentiates FDD is the keen focus on the process above – which is, in fact, driven by the list of features.
What appears to be missing from the process is a feedback loop to the customer. Agile best practice includes frequent cycles of delivery and feedback – potentially adjusting the features list. I think the omission in the diagram is simply to illustrate the method’s focus on features. I would say that feedback is implied or assumed.
As is common with agile practice, the sprint (or iteration) should end with a demo and feedback with the customer. The feedback may alter the feature list and development plan.
The following video by David McLachlan nicely captures these concepts of FDD in the following video:
Feature-driven Development (FDD) Best Practices
FDD best practices are derived from good software engineering practices. These core FDD best practices include:
- Domain object modeling – The team needs to work closely with the customer to define the domain of the problem to be solved. That includes the overall model, as well as sub-models exploring detailed functionality contained within the overall model.
- Developing by feature – The team needs to determine how to define features. Based on the overall model (see process above), the first step would be to define high level features. These might be at the level of an epic, or even higher. The team will need to disaggregate these high level features down to the user story level. User stories can provide the ideal set of features from which to design and develop, as they can be planned for short deliverable cycles (sprints).
- Individual class (code) ownership – Unlike paired programming, FDD emphasizes ownership of the code by the individuals that produce it. However, I don’t see why paired programming – and shared ownership of the code – cannot be done in FDD, if desired. Either way should fit nicely into the FDD framework.
- Feature teams – The team can break itself down into groups or sub-teams that focus on specific feature sets. This can produce efficiencies from familiarity with common technical and user-facing challenges.
- Inspections – The team will need to identify an effective approach to testing features for each sprint deliverable. In addition, it will need to devise a system for inspecting and cleaning up code to make it most understandable, efficient, and ‘atomic’ in functionality.
- Configuration management – Usually there are DEVOPS tools that aid with this. The team needs to determine how it will configuration manage its code to maintain a manageable process.
- Regular builds – Some say that using FDD, deliverables should be more frequent even than the typical 2-4 week sprint cycle. That of course is up to the team to determine the needs, benefits, and what it can realistically deliver.
- Visibility of progress and results – This is where tools like kanban boards and burn down charts help to visualize and communicate progress on feature development.
FDD focuses on the development of the features, but the above supporting best practices in agile are also part of FDD.
Feature-driven Development and Strategy
As a project management capability can be a strategic capability, excellence at any value-driven agile method can also be a strategic capability.
If one of the key deliverables produced by the organization is software, then developing a strong capability for software development can be achieved by adopting a method such as FDD.
—————————————-
I recommend these strategy resources (paid link):
—————————————-
FDD can go beyond that. It can help build a strategic advantage in a couple of ways:
- Lean agile strategy – It can be part of a lean agile strategy, where the organization is trying to innovate its way to build the product or service that the customer wants.
- Customer experience – With strong feedback loops, the team reduces or even eliminates the risk of building something that falls short of what customers want. If the team can incorporate a strong customer experience focus into the process, it can build strategic advantage.
Opportunities in today’s digital landscape can come from mixing and matching combinations of advantages – products offered, value produced, cost saved – in a nearly infinite number of ways.
Feature-driven Development and Project Management
The Feature driven development methodology focuses on developing software features, but it works nicely with other agile methods. More specifically, it works in conjunction with lots of other agile best practices and tools:
- Scrum – Scrum roles and scrum processes are a lot about the norms and ways of working that the team adopts. Scrum practices such as daily scrum meetings, retrospectives, sprint planing, and others blend perfectly with FDD.
- Kanban – Kanban boards can provide a clear picture of the status of the development of features by an FDD team, especially when broken down into epics and user stories.
- Paired programming – Paired programming, or extreme programming (XP), can be part of the approach that the development team takes to build the features.
- Sprints and iterations – Short and consistent time frames for developing, demonstrating, and obtaining feedback on the latest features fits perfectly with FDD.
- Burndown charts – Like kanban boards, burn down charts provide a clear visual of the progress an FDD team is making.
- Product backlog – This is just nomenclature – ‘Feature list’ = ‘Product backlog’. The two are synonymous.
Like many of the specific agile methodologies, FDD is consistent with agile best practices, core concepts, and core beliefs.
—————————————-
I recommend these PM templates (paid link):
—————————————-
The key challenge for a project manager is to adopt the methods that will work best on the specific project. Using FDD combined with some agile methods listed above provides a starting point. As the project progresses, empower the team to do retrospectives and enhance the process each sprint or iteration to continuously improve your own customized method.
Conclusion
This post has explained what the agile Feature Driven Development (FDD) methodology is, FDD best practices, implications of FDD for strategy, and how FDD is implemented with other agile methods while managing a project.
David McLachlan followed up the video listed above with the following, “Agile Feature Driven Development Revisited”: