Why (and how) you should use feature-driven development

When thinking about agile methodologies, you probably think about scrum. That makes sense because scrum has been cited as the most popular methodology used by product managers and development teams for the past 13 years.

While scrum is the most popular methodology, a quick perusal of the yearly State of Agile reports shows that other methodologies, such as Kanban or some hybrid of scrum mixed with other methodologies, have gained popularity. One of those other methodologies is feature-driven development (FDD).

Feature-driven development may not be talked about or used as much as other agile methodologies, but it’s worth taking a look at—especially if you need to scale your agile development to a long-term project with a large team.

What is feature-driven development?

In 1997, Jeff De Luca was working as a member of a 50-person team on a 15-month software development project in Singapore. In an effort to help the development team be more adaptive and responsive to customer needs, he devised a development model that uses five steps that focus on developing features in short iterations.

Scrum, XP, and other agile methodologies all use an iterative approach to deliver software. By contrast, the five steps in FDD require the team to follow a set of engineering best practices as they develop small feature sets in one- to two-week iterations. These five steps ensure that development remains consistent so that the project can grow and new team members can come up to speed much faster.

Best practices for feature-driven development

We'll get into the five steps of the FDD project life cycle later in the article, but first, it's important to understand the core principles that were established as part of feature-driven development.

• Domain object modeling: Teams build class diagrams to describe objects in a domain and the relationships between them. This process saves time by helping you uncover what function to add for each feature.
• Developing by feature: If a function cannot be implemented within two weeks, it should be broken down into smaller, manageable features.
• Individual class (code) ownership: Each class or group of code is assigned to a single owner.
• Feature teams: Although one person is responsible for the performance and quality of each class, a feature may involve more than one class, so everyone in the feature team contributes to design and implementation decisions.
• Inspections: FDD teams perform inspections to detect defects and ensure the best quality.
• Configuration management: This practice involves identifying source code for all features and documenting changes.
• Regular build schedule: This best practice will make sure that the team always has an up-to-date system that they can demonstrate for the client.
• Progress reports: Project managers should provide frequent progress reports of completed work.

Members of the FDD team

The FDD modeling team includes the following main roles: 

• The project manager oversees the entire project.
• The chief architect is in charge of the overall design and modeling of the system. The chief architect works with other skilled developers in the planning phase of the development cycle.
• The development manager leads and mentors the development team and oversees the day-to-day programming activities.
• The chief programmer helps with analysis and design and may also be assigned to manage small development teams.
• The class owner is a member of the smaller development teams that are led by the chief programmer. Responsibilities include designing, coding, testing, and documenting features.
• The domain expert is a member of a team that understands the problem that the customer needs to be solved. The developers rely on the domain expert’s knowledge to ensure that they are working and delivering what is most important to the customer.

Why use feature-driven development?

You may want to consider using FDD methodology if your project grows too large and complex for smaller scrum teams to effectively handle the amount of work. This agile feature-driven methodology is well-suited for long-term projects that continually change and add features in regular, predictable iterations. 

FDD is very scalable from small teams to large cross-functional teams because it is designed to always focus on what the customer needs and wants.

Advantages of feature-driven development

• Gives the team a very good understanding of the project’s scope and context.
• Requires fewer meetings. One of the frequent complaints about agile is that there are too many meetings. Scrum uses the daily meetings to communicate. FDD uses documentation to communicate.
• Uses a user-centric approach. With scrum, the product manager is usually considered the end user. With FDD, the client is the end user.
• Works well with large-scale, long-term, or ongoing projects. This methodology is very scalable and can grow as your company and the project grows. The five, well-defined steps make it easier for new team members or new hires to come up to speed on the project very quickly.
• Breaks feature sets into smaller chunks and regular iterative releases, which makes it easier to track and fix coding errors, reduces risk, and allows you to make a quick turnaround to meet your client’s needs.

Disadvantages of feature-driven development

• FDD is not ideal on smaller projects and does not work for projects where there is only one developer because it is hard for one or very few people to take on the various roles without help.
• Places a high dependency on a chief programmer who needs to be able to act as a coordinator, lead designer, and mentor to new team members.
• Provides no written documentation to the client, although there is a lot of documented communication among team members during the project development cycles. Therefore, the client is not able to get a proof for their own software.
• Emphasizes individual code ownership instead of a shared team ownership.
• May not work well with older systems because there is already a system in place and no overall model to define it. You may need to start over and work from the ground up. 

5 steps in the FDD project life cycle

Now that you understand the benefits that feature-driven development can provide, let’s dive into the development process steps so you can start implementing them with your team.

Step 1: Develop the overall model

This step is where you write your outline to define your domain model—the business problem you want your software development project to solve. The team works closely with the chief architect to define the scope and context of the system. Multiple domain models should be merged into one overall model as an outline for your system.

Step 2: Build a features list

The features list is similar to the scrum product backlog. Identify the features that are important to the client. Features are expressed as action, result, and object (for example, “validate the account number of the user”). 

It should not take longer than two weeks to develop any given feature. If a feature will take longer than two weeks to build, it should be broken up into smaller features.

Step 3: Plan by feature

Determine the order in which the features from your features list will be developed and implemented. Consider potential risks, dependencies, team and individual workload, and any other obstacle that could hinder feature development.

Then assign feature sets to the programmers who are most capable and have the bandwidth to develop them within the specified timeframe. 

Step 4: Design by feature

The chief programmer determines which features will be designed and built in a two-week iteration. This person also defines the feature priorities and determines who will be involved on the feature team. A design review needs to be completed by the whole team before moving forward.

Step 5: Build by feature

In this step, all of the items necessary to support the feature design are implemented. The user interface is designed, and a feature prototype is built and tested. If the feature passes the test and is approved, the completed version can be added to the main build and made available to customers. 

If you work at a large company and will be tackling large, complex processes, using a feature-driven agile approach may be right for you. FDD is designed to grow as your company and your project grows, and it works well if your product requires long-term, ongoing development. Focusing on features helps you address customer needs more quickly and helps you identify and fix and problems that may come up.