Together with Crystal and the Dynamic System Development Method, the Feature-Driven Development approach (FDD) is less popular as a methodology per se.
This is largely due to the fact that FDD tends to be associated and annexed to some of the more popular methods, instead of functioning as a standalone methodology in its own right.
This is not to say that Feature-Driven Development is not important or that it cannot function on its own, on the contrary, actually. It can and you can definitely try it out.
Rather than debating whether or not FDD is popular or relevant, or whether or not you should actually implement it as a pure methodology, we want to be an informative one that will set things on a clearer path for you and help you understand not only what FDD is and where it stands in the world of agile but also how you can incorporate it in a unique and personalized approach to agile project management in general.
At its very core, Feature-Driven Development is not much different than many other agile project management methodologies. The one quality that differentiates it from the rest of the agile methods is the fact that, as the name suggests, it focuses on making progress on each feature.
Basically, the importance of the “story” delivery you know from Scrum is transferred to the importance of each feature. Sometimes, a story might coincide with a feature, but this is not a must.
Developed at the end of the 1990s for a project that aimed to deliver a short time-spanned project for the banking industry in Singapore, FDD is nowadays used quite widely. Many people automatically incorporate it in their Scrum or Kanban approaches, but it is important to note that just because this is common, it doesn’t mean FDD and Scrum are one and the same (or that FDD and Kanban are, for that matter).
Feature-Driven Development is one of the more prescriptive agile methodologies out there in the sense that it works based on a clearly defined life cycle, and it assigns clear roles among the different team members.
The FDD life cycle is defined by five main stages at which the product is developed:
- Developing the overall model. At this stage, the team gets familiarized with the high-level scope of the entire project and system, as well as the context it comes from. Further on, the team will split into smaller groups, and each area of the system will be modelled then presented for peer review. The model(s) that are deemed a better fit will be selected to act as a domain area model. In time, all the domain area models will be merged into the larger model.
- Building a feature list. Once the knowledge has been collected throughout the first stage of the development, all the information will be used to identify the list of features. The domain area will be split into multiple subject areas, according to the functionality of the features representative of the area. It is important to note that each feature should be identified through the prism of the value it provides the user with.
- Planning by feature. Once you have the entire list of features at hand, you will be able to start planning the development per se. During this process, you will assign the feature sets as classes to the programmers in your team.
- Designing by feature. Each feature of the product comes with a design package that will be handled during the fourth stage of development. This will be handled by a chief programmer in a team, who will initially select a set of features to be developed over the course of two weeks. Together with the class owners associated with these features, the chief programmer will create sequence diagrams for each of the selected features and use them to refine the model.
- Building by feature. Once the prework has been done and once the design inspection is ready, it is time for the team to move on to the actual programming, then test and inspect the code to ensure the feature is complete. Once that happens, it can be incorporated into the system.
As for the roles encountered in FDD, they are quite clear, and they may include the following:
- Domain Manager
- Language Guru
- Build Engineer
- Release Manager
- System Administrator
- Technical Writer
In some respects, FDD and XP are quite similar to each other. It is very important to note, however, that the major difference between the two comes with the introduction of a “class ownership” concept. Collective ownership is one of the particularities in Extreme Programming. In Feature-Driven Development, however, this ownership is transferred to the class owner who becomes responsible for its functionality.
The most notable tip of information you should keep in mind when it comes to how FDD functions are that instead of focusing on more or less random chunks of the project, it approaches development on a feature-by-feature basis.
Same as in the case of the other agile project management methodologies, Feature-Driven Development is associated with a series of best practices too.
Domain Object Modeling
Domain Object Modeling is one of the most important best practices associated with FDD. This practice basically consists of both exploring and explaining the domain of the problem at hand. Once the domain object model is generated, the team will have an overall framework to use when adding features, one by one, as they are developed.
Developing by Feature
As mentioned before, this is one of the main tenets of Feature-Driven Development (as the name of this methodology suggests a well). There is one important rule associated with the concept of developing by feature: if a function is too complex to be developed and implemented in two weeks, it will be split into smaller functions until each of the resulting subproblems is small enough to be considered a feature in the full sense of the word.
This allows for better control of the changes that might appear along the road, be they related to changes in product requirements or changes related to bugs and/ or lack of functionality.
What class ownership means is that different pieces or groups of pieces of code (called “classes”) are assigned to specific owners. Each of these owners is responsible for the code on multiple levels:
- conceptual integrity
Same as most agile methodologies, Feature-Driven Development prefers working with small teams. As such, feature teams will be assigned for the development of each feature.
A feature team is a small team formed dynamically to develop a small activity. Together, they work for each design decision, and they evaluate their options before they choose a particular one.
As you can see, there’s quite a lot of trust placed in each and every member of these teams, as well as in how they can work together and cooperate for the success of the entire project.
According to FDD’s best practices, you should run regular inspections of the design and code, so that you can detect any defects in due time (and so that you can apply the changes necessary to improving these defects).
Configuration management is quite important, especially when new team members join in or when you are adopting FDD for the first time. However, it is a best practice that should be maintained regardless of where in your journey to Feature-Driven Development you may be.
Basically, configuration management will allow you to identify the source code for everything (all the features) that have been developed to date. This will also allow you to keep track of the class changes while feature teams work on their enhancement.
The concept of “regular builds” is similar to that of “continuous delivery” in the general Agile Principles. What this concept refers to is ensuring that your system can demonstrate, at any time, that integration errors have been fixed early on in the process. This allows the customer to maintain trust in you and your team, and it allows you to actually keep track of all the issues, whether or not they are repeat offenders, and whether or not they have been successfully fixed.
Visibility of Progress and Results
This concept is quite similar to the Scrum and/ or Kanban board in the sense that the progress and the results of your team’s efforts should be visible at all times. FDD may not employ an actual board for this, but the FDD project manager needs to ensure that all reports are frequent, accurate, and appropriate both from the internal point of view (team, internal stakeholders, higher management, etc.) and from the external point of view (customer).
Feature-Driven Development is a less common methodology on its own. However, it is quite essential to remember that it can be easily integrated with other agile methodologies.
In fact, the first two stages of the FDD development cycle are almost entirely congruent to the initial envisioning model of Agile Model-Driven Development, showing that FDD belongs in the agile family just as much as Scrum, Kanban, or Extreme Programming.
Indeed, there is less focus on people in FDD (as compared to Scrum, Kanban, XP, or Crystal, for example), as the main centre of this approach lies on the actual feature and how the people around it help with its harmonious development.
However, this doesn’t make Feature-Driven Development any less agile in nature. At the end of the day, FDD abides to the general Agile Principles just as much as any other methodology.
It is easy to dismiss the lesser popular agile methodologies out there, including FDD, especially since there seems to be less information and a smaller number of tools that are designed specifically for this approach.
However, what you do have to keep in mind is that methods like these are more of a supporting system to the more popular methodologies that focus on mindset more than a specific approach.
FDD can work in combination with most of the project management methodologies we have described so far, with the exception of Extreme Programming (where the concept of class ownership and that of collective ownership will clash).
Same as in the case of Crystal, we thoroughly encourage you to learn more about FDD as well. Aside from the five main stages, we have described here, each of them is associated with specific substeps that will allow your entire plan to be more structured. For this reason, FDD is one of the agile methodologies that seem to be more of a better fit for very structured businesses (like large corporations, for example).