Feature Driven Development [FDD]

Feature Driven Development, in short FDD, is a not-so-popular and well-known agile framework. If you are dealing with a long-running, massive project, particularly in an organization where agile is still restricted to software development, FDD might be your best friend.

This framework bridges the gap between emergent processes found in agile and traditional waterfall approaches. Let's investigate further to discover the basic meaning, principles, and uses of FDD.

FDD: Definition

As we mentioned earlier, FDD is closely linked to Agile methodology — in fact, this is one of its frameworks. As the name implies, Feature Driven Development focuses on developing working software that has the necessary features to satisfy client requirements. According to the principle and values of the agile manifesto, FDD wants to ensure on-time and consistent delivery to the customer.

In Agile, this framework promotes status reporting at all levels, which helps organizations track results and progress. On top of that, Feature Driven Development ensures teams update projects regularly and spot errors quickly. This is one of the most favorite methods among development teams because, with its help, they get to avoid rework and confusion.

Now, let's back to the beginning and see how it all started! We can trace the roots of FDD back to 1997 when IT strategist Jeff de Luka developed the FDD concept. At the time, he was organizing a 15-month long project for a bank in Singapore. The project involved 50 team members, and since everything turned out right, it led to widespread acceptance of the FDD model.

FDD has two development processes, incremental and iterative. First of all, team members break down projects into small increments that are easier to manage, and then the workload is divided into short iterations. When it comes to iterations, the developers will repeat the steps until they are satisfied with the final result.

FDD teams help organizations set up progress reports and perform regular inspections to ensure high-standard services.

At this stage, we should drop another name, Peter Coad. He was responsible for research on object-oriented design. It's when teams outline the domains of the problem they are trying to solve.

When Do You Need FDD?

Compared to other agile frameworks centered around small teams of disciplined and skilled developers, FDD is mainly focused on larger teams. Additionally, smaller teams might be easier to manage and more likely to succeed, regardless of the agile method they apply.

On the other hand, not every team member is disciplined and skilled in large teams. This framework uses the so-called "just enough" technique to ensure FDD can be applied to large teams. With this technique, reviewers and planners change and review the assignment of feature sets and classes of developers.

Keep in mind that not all classes are signed simultaneously, only just enough, and as the project grows, the classes keep increasing.

To sum up, you will require FDD agile if you work on long-term, complex and large projects. After all, it was created for this purpose. As a result, FDD is considered a functional solution designed to support the management of large projects.

Feature Driven Development vs. Scrum

While FDD and Scrum are closely related, the first is a feature-focused method instead of a delivery-focused method in Scrum. When it comes to FDD, features are its foundational pieces, while Scrum has stories - small client-valued functions.

Moreover, FDD values documentation more than other methods, creating differences in the roles of meetings. Also, in Scrum, teams meet daily, while FDD teams use documentation to transfer necessary information; therefore, they don't meet that often.

Another crucial difference is the end-user. For instance, in FDD, the actual user is the end-user, whereas, in Scrum, we have a Product Owner who is seen as an end-user.

We also have differences in sprint length. Even though we can't apply some general rule, in FDD, the shorter, the better; in Scrum, a sprint lasts between two and four weeks.

When choosing Agile methodologies, you must pay attention to your project requirements. The good news is that you can use both FDD and Scrum for big and more complex software projects.

Also, FDD has five key activities that we can't find in Scrum.

Develop the overall model – the team will determine the project scope. They will propose multiple models and create one to top them all.
Set up a feature list – outline the customer-focused features that need to be developed. For example, small functions that can be finished in a short time.
Plan by feature – the team assesses individual features and arranges them properly. Then, these features will be assigned to different team members.
Design by feature – the chief programmer will select which features to develop in the next two weeks.
Build by feature – the final stage. Developers work to develop a code for previously mentioned features. This code is tested before creating the final version.

Pros and Cons of Feature Driven Development

You may want to consider using the FDD framework if your project gets too big for smaller teams to handle. For that very reason, the agile-feature-driven methodology is more suitable for teams that continuously change and add features to their iterations.

Remember that FDD is entirely scalable from small to large cross-functional teams because this approach is designed to accommodate the customers' wants and needs. Now, let's explore some feature-driven development pros and cons.

Advantages:

FDD provides the team with a great understanding of what's expected from them and gives them insight into the project's context and scope.
You don't have to spend your time in meetings. While Scrum uses daily meetings, that's not the case with FDD. They rely on documentation to communicate.
User-centric approach, and in this case, the client is the end-user.
FDD is great for large-scale and long-term projects. This framework is scalable, and it can grow as your organization grows.
With the help of FDD, you can break features into smaller chunks, which will make it easier for you to make a quick turnaround, reduce risk, fix coding errors, and track your progress.

Disadvantages:

FDD is not suitable for smaller projects and doesn't work for those involving developers only.
It highly depends on the chief programmer who needs to act as a mentor, lead designer, and coordinator.
It doesn't offer written documentation to clients, even though plenty of documentation circles among team members.
It is more focused on individual code ownership.
It may not work well with other systems.

Download Free Materials