Feature Driven Development Explained with Examples

Editorial Team

Feature Driven Development Explained

Feature-driven development is a practical agile approach suitable for long-term, complex projects. It’s an excellent choice for development teams seeking a simple but structured agile method that is scalable and delivers predictable results.

If you work in a big company or deal with large-scale projects, then feature-driven development is the right choice for you. This article explores the meaning of feature development, the history of Feature Driven Development, its advantages and disadvantages, relevant example, and the difference between FDD and Scrum.

What is Feature Driven Development?

Feature-driven development (FDD) is an agile framework that organizes software development around making progress on features. FDD is customer-centric, incremental, and iterative to deliver tangible software results often and efficiently. Feature Driven Development employs status reporting at all levels, thus helps to track results and progress.

FDD allows teams to update the project regularly and identify errors quickly. Plus, it provides clients with details and substantial outcomes at any given time. FDD is a method among development teams because it helps reduce two known morale killers in the development world: confusion and rework.

In FDD, each feature is useful and essential to the client and result in something tangible to showcase. Since businesses appreciate quick results, the methodology depends on its two-week cycle.

Feature Driven Development History

The first real-world application of the Future Driven Development Methodology, was on a 50-person software development project for a Singapore-based financial institution. The first public discussion and intervention of the methodology were in 1999 book java Modelling in Color with UML. The second application was 18 months long on a 250-person project.

Jeff De Luca established FDD. He was trying to provide a software development solution to a bank. It emphasizes features that are useful to software owners. Since then, FDD became a pragmatic approach ideal for a long-term, complex project looking for a comprehensive but straightforward methodology.

While scrum and a new variation of agile are the majorly preferred techniques (especially outside of software development). FDD can be an excellent option for software development teams, interested in a focused and structured Agile methodology. That can be scaled across the product organization and will deliver precise outcomes.

Feature Driven Development Methodology

A Feature Driven Development Methodology’s primary goal is to develop real, working software and meet deadlines systematically. The methodology attempts to combine methods widely recognized in the software development industry and take the functionality(properties) of the software development necessary for the customer as a basis.

Feature-driven development methodology contains five steps, which are:

  • Developing an overall Model

In the first stage, the development team cooperates and builds an object model of the domain problem. The primary goal is to propose a model for the area domain. The chief architect follows them and gives guidance. Once the team proposes their model, the chief architect selects one of these models or a merge of models, and it becomes the model created for that domain area. As a result, the team gets a clear image of the entire project.

  • Building a Feature List

After the development team establishes an object model. They select the features that the client or user prefers. These features are used as the building barriers of the project. That help the group members to navigate the process

  • Planning by the feature

The third stage turns around managing features and the way the development team tends to implement them. It’s essential to consider the team workloads, risks, and other essential aspects to prevent any complex issues from arising.

  • Designing by the feature

Everything the team plans has a design. The chief programmer uses the knowledge from the first modeling process, to select all the team’s features and identify classes of the domain. Immediately the team starts working on the project. The domain expert analyzes and designs a solution to each feature.

  • Building by the feature

The final step is to put all the necessary items into action to support the design. In other words, once the team develops, tests, and inspects the code, they start the development of the software.

Feature Driven Development Vs. Scrum

Feature Driven Development is related to Scrum. As the name implies, it’s a feature-focused method (as opposed to the delivery-focused method). Features are a foundational Feature Driven Development piece. FDD values documentation more than other methods (Scrum and XP included), which also creates differences in meeting the roles. In Scrum, teams typically meet daily, whereas, in FDD, teams rely on documentation to communicate important information. Hence they don’t meet frequently.

In Feature Driven Development, the actual user is viewed as the end-user, while in Scrum, the product owner is seen as the end-user. FDD additionally takes a shorter sprint length than in Scrum. FDD is class ownership, while Scrum is shared code ownership.

FDD specifies the engineering practices, i.e. design/code, inspections, and tests, whereas Scrum doesn’t specify any particular engineering practices, although parts of XP frequently use. FDD is domain-driven, while Scrum focuses on producing vertical slices of functionality accepted by the product owner.

 Additionally, in FDD feature teams have recognized roles (project manager, chief architect, development manager, chief programmer, class ownership, and domain expert), whereas Scrum is a self-organizing team.

However, both Feature Driven Development and Scrum have improved communication and wholly developed and tested features in short iterations. They both emphasize producing quality components and help track progress at different granularities. Lastly, both Scrum and FDD favor complex and more significant software projects.

Feature Driven Development Advantages

With the constant growth of software, development becomes a more complicated process that requires much attention. In such a case, a team has to find the most efficient way to grab issues they come across. However, FDD is the method that lets a team successfully run a project due to its advantages.

Feature Driven Development is a simple five-step process that allows for more rapid development. It enables larger teams to move products forward with continuous success. Feature Driven Development additionally leverages pre-defined development standards so that teams can move on.

Feature Driven Development provides the team members with an opportunity to communicate more efficiently, on the other hand encouraging team creativity and innovation. It also makes it easier for a team to break the entire problem into smaller issues to cope with within a shorter period.

Moreover, FDD is an excellent solution for big and complex projects, especially in critical situations. It also offers a team an opportunity to regularly keep their projects up-to-date, observe any errors, and provide users/clients with valuable information at any time.

Feature Driven Development also works well with large-scale, long-term, or projects in progress. This methodology is very suitable and can grow as the company and project grow. The five well-defined methods make it easier for new team members or new hires to work on the project quickly.

Feature Driven Development Disadvantages

Feature Driven Development doesn’t work efficiently for smaller projects. It also doesn’t work for projects where there is only one developer. It’s hard for one developer or very few people to take on the various roles without help. Feature Driven Development has less written documentation, which can lead to confusion. Also, it is highly dependent on lead developers or programmers.

Feature Driven Development places a high dependency on a chief programmer who needs to act as a coordinator, leads, designer, and mentor to new team members. Feature Driven Development doesn’t provide written documentation to the owner, although team members document information in project development cycles. Therefore, the project owner can’t get proof for their software.

Additionally, FDD emphasizes individual code ownership instead of shared team ownership. It may not work well with older systems because there is already a system in place and no overall model to define it. Thus it requires a team to start over and work from the ground up.

Feature Driven Development Examples

During Feature Driven Development, some pre-work takes place before the development begins. The team and the developers have to agree on the general technical approach, discuss the technology, terminology, testing necessary action and create a live environment.

The common example of a Feature Driven Development is the build of a Mouse breaker. It’s a casual gaming site that utilized a mixture of Kanban and Feature Driven Development. To quickly and effectively deliver a new website with a new codebase in 28 days. In the Mouse breaker site, the primary user function is for the user to play flash games. The first feature was the user’s ability to play games on the web page.

Feature Driven Development manipulates this by redefining the requirements as features. The business owners and development team prioritize these features into a backlog of work. Then, the developers deliver these features in a manner that offers the most value to businesses.

Conclusion

Feature Driven Development is a very useful software for a large organization. The features and model present in it creates efficiency in delivering quality outcomes. An organization that employs the Feature Driven Development model is likely to succeed since FDD encourages creativity and innovation.