If you want fast functionality from your software, then feature driven development (FDD) could be the key. Feature driven development revolves around quick development cycles and provides businesses with feature-rich systems because they are constantly developing.

What is the history of feature driven development?

The idea of FDD was created by Jeff Luca in 1997 to meet the software development needs of a Singapore bank. His solution was a group of five processes designed to cover the model’s development and also its listing, design, planning and the building of its features.

Why is feature driven development popular?

Since its original implication, FDD, and its five basic activities, have continually been used to develop enterprise software because it is seen as both agile and pragmatic.
It takes key advantages of eXtreme Programming and Scrum and combines them with model-centric techniques including Domain-Driven Design by Eric Evan and modelling in colour by Peter Coad. In addition, it is easily scaled to large teams due to its concept of just enough design initially (JEDI), as well as peer reviews and dynamic feature teams.

When it is produced well, FDD can offer timely status reports and accurate progress tracking based on all levels of leadership in the project.

So what are the five processes of feature driven development?

• Process one – develop an overall model: The FDD model insists that teams exert the adequate amount of effort at the start of the project in order to build an object model highlighting the domain problem.
  Modelling with feature driven development is time-boxed and collaborative. Domain models should be created in detail by small groups and then presented for peers to review. It is hoped that a proposed model – or potentially a combination of them – will then be used for each area of the domain. They will then be merged over time to produce an overall model.
• Process two – build a feature list: From the knowledge that is obtained during the modelling process, a list of features is established by dividing domains into subject areas that contain information on business activities. The steps that are used for each business activity represent a categorised list of features. Features are expressed in the form of: “action, result, object”. The expectation is that they will not take more than two weeks to complete: if they do, they should be broken into smaller sections.
• Process three – plan by features: Once the feature list has been established, the following process involves assigning the various feature sets to the programmers.
• Process four – design by feature: Programmers then produce a design package for each feature with a chief programmer selecting a group of features that should be developed within a two-week period. The chief programmer will also establish detailed diagrams for each feature while refining the model. When this is complete, prologues are produced and a design inspection is carried out.
• Process five – build by feature: Once design inspections are complete, designers plan an activity for each feature and develop the code for their respective classes. When the inspection is complete and a unit test carried out, the feature is then pushed to the main build.

Feature driven development: best practices

At the heart of FDD are a number of best practises designed for software engineering: all of which are formed from a client’s perspective. Some of the best practices that should be followed by developers include:

• Domain object modelling: Explores and explains the problem that needs to be sold and provides a framework from which features can be added.
• Developing by feature: Functions that cannot be implemented within two weeks should be divided into smaller functions: with each sub-problem to be small enough to be labelled as a feature. This should make it easier to modify the system and ensure that the correct functions are offered.
• Individual class ownership: Groups of code should be assigned to individual owners.
• Feature teams: A dynamic small team that focuses on individual activities. This ensures that multiple minds are used on each design decision so that several options are always explored. Typically roles will include – a project manager, chief architect, development manager, domain expert, class owner and chief programmer.
• Inspections: They should be carried out regularly to ensure there are no defects.
• Configuration management: Identifies source code for all features and maintains a history of the changes that are made so that the feature teams can enhance them.
• Regular builds: Ensures that the system is always up to date.
• Visibility of progress: Progress reporting should be carried out on a regular basis to ensure that managers can steer the project in the right direction.

Feature driven development: the pros and cons

One of the questions that is often asked about feature driven development is how it compares with Scrum development. When assessing feature driven development vs Scrum, it is clear there are a number of common points: both are collaborative; both offer improved communication; the emphasis is on quality components; while features are developed in short iterations with progress constantly tracked.

Where they are different however, is that Scrum does not specify any particular engineering practice. Instead, it focuses on vertical slices of functionality with short feedback loops. By contrast, FDD places the focus on specific engineering practices with longer feedback loops and with a feature team that takes clearly recognisable roles.

It could be argued that FDD was formed by taking into account the natural strengths and weaknesses of humans. It has proven to be a highly effective way to rescue complex projects because it addresses so many of the problems that so commonly afflict developers. The entire feature list is built to the priorities of business users and its fast approach – using two-week increments – even gives businesses the chance to use the application before it has been finished.