Delivering Real Business Value using FDD - Page 3

By Grant Cause, IT Project Services Pty. Ltd.

As the name suggests FDD is "Feature Driven", meaning it makes use of the concept of a "feature".

The term feature is very specific; a feature is a small, client valued function expressed in the form: <action> <result> <object>.

A feature is:

• Small; 1-10 days of effort are required to complete it. Most are 1-3 days. But they are designed and built in batches. The batch is the workpackage. A workpackage cannot take more than 10 days.
• Client valued; it is relevant and has meaning to the business; in business systems this usually relates to a step within some business activity within a business process.
• Named; <action><result><object> naming template with appropriate prepositions between them <action> the <result> <by|for|of|to> a(n) <object>

Feature examples:

• Calculate the balance of an account
• Validate the PIN number for a bank account
• Authorise a loan for a customer

The use of a naming template for the features helps when you are discussing these features with business people. The business people can understand this language and there is no technical jargon for them to have to decipher. They also understand that anything that makes it onto the feature list is going to have some real value to their business.

FDD places importance on "ownership". It makes use of "class owners". When a Chief Programmer (a role within FDD) schedules features for design and build, he puts them in a workpackage. A Workpackage cannot run longer than two weeks but they could be less. At a single point in time there will be multiple workpackages active, each at different stages.

Each feature is assigned to a team member who then becomes a "class owner"; this means they take ownership of that feature. Each feature the developer is given ownership of now forms part of their workpackage. It is now their responsibility to deliver that feature and in doing so become the expert on that feature. If another team member needs information on that feature this person is whom they would turn to first.

Teamwork is an important part of FDD. It has a concept known as feature teams. Feature Teams form dynamically. These teams represent people working on a single feature or group of like features. At any point in time a developer may belong to one or more feature teams collaborating as needed with other project team members within a feature team.

Figure 2 - Feature Teams / Copyright © 1997-2004 Jeff De Luca

FDD tries to prevent problems before they happen. One of the ways it does this is through the use of Inspections. Inspections have been proven over time to be one of the most highly effective yet under utilised methods for preventing errors in software. FDD has two types of inspections. The first is a design inspection. As designs are done they are inspected. This is more of a sanity check than anything to see if the team agrees with the chosen solution. If not the design is scrapped or modified until the team is satisfied with the chosen solution.

The second type of inspection is a code inspection. Code is chosen for inspection and checked for such things as adhering to coding standards, potential bugs or logic errors. Inspections are also great learning opportunities particularly if your teams are made up of a mix of both senior and junior developers. They can be a great opportunity to share knowledge across the team as well as help to identify potential problems before they happen.

FDD is a highly iterative and incremental methodology. One of the most powerful concepts of FDD is the production of regular builds of working software. This concept really represents the use of continuous integration that can prevent many problems that might normally only show up later in a project by identifying these problems early in the projects lifecycle so they can be corrected earlier.

Another powerful concept of FDD is high visibility and reporting of results. FDD provides a complete reporting mechanism for all stakeholders in a project as part of its process. The project reporting happens by default. You no longer have to worry about how you are going to collate all the necessary information in order to know if the project is on track. FDD will accurately record this information by default and provide a simple, easily understood reporting mechanism. To provide this reporting by default FDD makes use of a number of milestones within each feature and assigns each certain weightings as indicated in Figure 3. At its simplest you just sum the weightings for each of the completed milestones in order to get your percentage complete for that feature. So there you have it instant reporting.

Figure 3 - Feature milestones / Copyright © 1997-2004 Jeff De Luca

The first three milestones above form what is known as the Design by Feature milestone and the last three milestones are known as the Build by Feature milestone.

FDD again makes use of colour to show progress status, White is not yet started, Blue or Yellow is work in progress, Red is needs attention (behind schedule, etc) and Green is complete. Each feature is colour coded to show its progress status on what is known as the Plan View report as shown in Figure 4. When the plan view reports are printed out they quickly give you a sense of how your project is progressing. These can be put up on a wall to give the big-picture view of the project from 30,000 feet. If you want the details on a particular area you can quickly zoom-in (i.e. move closer to the wall).

Figure 4 - Plan View report / Copyright © 1997-2004 Jeff De Luca

Another innovative reporting mechanism is the summary reporting through the use of the car park or parking lot report. The business activities are shown as if they were the lines in a car park on the concrete with a progress bar and other summary information. Again the same colours the plan view report uses are used to quickly highlight progress status information see Figure 5.

Figure 5 - Car park or Parking Lot report / Copyright © 1997-2004 Jeff De Luca

Page 2   Page 4    Back to the archive list