FDD: Processes and Comparisons to Other Agile Methodologies

We’ve talked about Test Driven Development and Behavior Driven Development, so I figured, why not cover Feature Driven Development? Actually, not many people talk about FDD and we may say that Extreme Programming, Scrum, and Test Driven Development are definitely the most popular Agile methods at the moment, but here at Apiumhub, we also value FDD quite a lot.

Starting off With the Obvious, What Is Feature Driven Development?

First, I would like to mention that FDD was created by Jeff Luca in the late '90s. He was actually trying to provide a software development solution for a bank.

FDD is a development process that, as all Agile methodologies, is iterative and incremental with the objective of delivering working software. FDD mixes best practices that are all driven by what is important to the client. This means that the developers focus on the features that the client values and the functions they expect.

Let’s say that with FDD, features are as important as user stories are for Scrum. It’s what will help developers when it comes to planning their work.

As I mentioned earlier, Jeff Luca was the creator of FDD. He proposed a solution which is a mix of 5 processes that would cover the development of the model, and its listing, design, planning, and, finally, the building of its features. So to get a better understanding, it obviously helps to have a look at those 5 basic processes of FDD.

A More Detailed Overview of the 5 Processes of FDD

Once we go over the whole processes, you will quite quickly realize that the Chief Programmer has a very important role in Feature Driven Development. Almost comparable to a lead developer, the Chief Programmer needs to have technical skills as well as leadership skills to be able to lead a cross-functional development team. Another very important role is the Domain Expert, as he/she has very similar responsibilities as the Product Owner in Scrum, although not totally the same.

1st Process: Developing an Overall Model

In this first process, FDD pushes teams to build an object model of the domain problem. Differing from others, FDD modelling is a cross-functional, iterative, and collaborative activity. The team members (development, domain experts, and chief programmers) work together to compose a model for the domain area and are guided by a Chief Architect. The idea is to have different teams proposing different models, and, later on, after getting reviewed, choose an option, or mix them up. Finally, the domain area model will be merged into the overall model.

It’s actually a great way to start the project as it enables the team to get a strong understanding of the project as well as lay the foundation for solid communication.

2nd Process: Building the Feature List

Here, you could compare the features list to the product backlog in scrum, and the feature would be some sort of user story. After having the overall model ready, based on the knowledge got during that phase, we will have to identify the features which are valuable to the client and which will basically guide the project. Features shouldn’t take longer than two weeks to be completed, and if they do, then it should be put into more than one feature. They are usually expressed as an action, result & object.

3rd Process: Planning by Feature

In the third phase, as its name says it, its more or less about planning in which order the features will be implemented; it’s about organizing. Feature sets are then assigned to programmers.

Obviously, while planning we take into consideration different aspects such as risks, complexity dependencies, team workload, etc.

4th Process: Designing by Feature

As with all the processes, we use the knowledge we get from the first modeling process. The chief programmer takes responsibility to select a group of features that should be developed next. He will also have to determine the domain classes that will be involved. After the feature team is formed, they all start working together in order to get the job done, where the domain expert will be in charge of analyzing and designing a solution to each feature. 

5th Process: Building by Feature

Once the domain expert is done and based on the work done in the design by feature process, the class owners will have to implement all the items that are necessary to be able to support the design. Therefore, we work on the code that has been developed, i.e. unit test it and inspect it, to ensure that it is all correct and approved by the chief programmer. They will then give the OK to start building.

What About Comparing FDD, XP Programming, and Scrum?

On my team, we use Scrum, we use XP programming, FDD and more. So I thought it would be interesting to do a brief comparison of these three prominent Agile methods. Feature Driven Design takes a bit from Xtreme Programming as well as from Scrum, but it adds to them by implementing Domain-Driven Design techniques. What is great is that it is very easy to work in large teams using FDD. It’s actually extremely scalable.

Communication: Verbal and Written

We all know that Agile methodologies have a strong focus on communication between the team and other stakeholders.

In XP programming and Scrum, documentation is important, but it also doesn't place a huge emphasis on it. Rather, they techniques push team members more towards verbally communicating with the rest of the people involved in the project. With FDD it’s a bit different because they actually believe that documentation should be worked on quite often.

User-Centric Approaches?

Software is, or at least should be, designed and developed with a user-centered approach. With XP programming, for example, you need the user’s participation during the development process to enable the short interactions of the development cycle that release customer-centric products.

In Feature Driven Development, the end-user is also involved in the process but in a different way; FDD draws on customer insights during the reporting phase. And in Scrum, the end user is not really involved, it’s the product owner that is seen as the voice of the end-user. 

The Sprint’s Length

This is not a general rule of thumb, but, as we mentioned, for FDD the shorter the better. Let’s say that a Sprint would last somewhere between two to ten days. This differs to Scrum, as Scrum Sprints typically last two to four weeks, and XP programming Sprints can last up to 6 weeks!

What About the Meetings?

As communication is important, obviously, meetings are important with Agile methodologies. With Scrum and XP programming, there are the daily meetings where all the team members are involved and where they talk about the project and decide together how the project should go on. Those meetings are, in general, quite informal and quick.

With FDD, it's quite different because the information is typically communicated via the documentation.

How Big Can the Project Get?

When choosing Agile methodologies, it really all depends on the project requirements. For example, for small projects that are not complex, you could easily go with XP programming. Scrum and FDD, however, would be recommended when it comes to software projects that are bigger more complex

So What Is So Great About FDD?

• FDD is amazing for big projects and is actually quite scalable.
• FDD is very effective in helping with complex projects that are in a critical situation.
• The 5 processes mentioned earlier help when it comes to getting new members to join the team, especially in short periods of time.
• Feature Driven Development is built around best practices that are recognized by the industry and it considers the strengths and weaknesses of developers.
• The fact that, with FDD, you do regular builds ensures that the system is always up to date and it can be shown to the client. You can easily identify errors in the source code of the features.
• Throughout all the processes mentioned above, you have a high visibility of progress and results due to the fact that there are frequent progress reports that are made at all the levels of the project.
• The first process, developing the overall model, give us a deep understanding of the scope and the context of the project.
• By having a deeper understanding of the requirements and the expectations, developing in small iterations, and building small parts, one by one, we greatly reduce the risks involved in creating large-scale software projects. Less unwanted surprises are always good!