FDD (Feature-driven development) is an agile method created by Jeff De Luca in 1997; this agile method based on incremental and iterative concepts was created for a large Singaporean bank.
This agile method FDD (Feature-driven development) much less popular than Scrum; the first publication of this agile method was in the book Java Modeling in Color with UML and not in a dedicated book.
The FDD (Feature-driven development) in a few words
For those who are in big companies, you will be surprised to discover this methodology because there are many things that we can find in our companies … And a lot of people say, it’s “no agile”.
In fact, this agile method is old and it is true that agility has actually evolved with time. However, FDD (Feature-driven development) is considered as one of the existing agile methods despite its contradictions with agile methods as XP or Scrum.
The FDD (Feature-driven development) propose:
- short and large iterations
- to have better communication throughout the development
- to make frequent deliveries with real done works
- accurate progress information
- to have processes appreciated by customers, developers and managers
The iterations of FDD (Feature-driven development) in 5 steps
An iteration in FDD (Feature-driven development) consists of 5 different steps:
- Create the system model with a UML class diagram
- List the features to acheive
- Assign features to developers
- Create the template for each of the features
- Develop each of the features
Unlike Scrum and Extreme programming, the FDD (Feature-driven development) strongly recommends assigning features to a specific developer or developers.
The 6 key roles in FDD (Feature-Driven Development)
The methodology defines 6 key roles; agile community don’t appreciate this practice in this moment.
The Project Manager (PM)
In the FDD, there is this role that is so rejected by agile communities. Its role will be to make good progress reports, to work for the well being of the team, to deal with budgets, recruitment and logistics.
If we look closely at this description, it is often the role attributed to Scrum Masters in large companies who have trouble becoming 100% Scrum Master.
The Chief Architect (CA)
The CA is responsible for the complete modeling of the architecture of the developing product.
The Development Manager (DM)
The DM is responsible for the activity of the developments. Indeed, we are in an agile method totally in opposition with Scrum; we find more or less these types of roles within large companies.
Some people will be delighted to discover this agile method to say that it’s agile to work with such precise roles strongly discouraged in other agile methods… It’s not totally wrong, agility has evolved and that coaches recommanded in a large majority the sharing of responsibilities.
The Chief Programmers
In FDD, the experienced developers will work on the analysis part and the technical specifications. They will be responsible for a group of 3 to 6 developers.
The Class Owner
These are developers who work in small groups just under the Chief Programmer with roles to develop, test and document the done functionalities.
The Domain Experts
Ce rôle est en fait représenté par les Utilisateurs clés, Sponsors et Business Analyst. Ils sont présent pour identifier les besoins et permettent aux développeurs de travailler. Leur présence est indispensable pour avoir un produit de qualité.
Key Users, Sponsors and Business Analyst represent this role. They are there to identify needs and allow the developers to work. Their presence is essential to have a quality product.
There are some transverse roles proposed by the method as the Release Manager, the Language Guru (developer trainer), the Build Engineer (responsible for application builds), the Toolsmith (developer of small tools or libraries for developers) and the System Administrator .
The FDD (Feature-driven development) also proposes to add testers, Deployers and Technical Writers (those who write the technical documents).
The FDD (Feature-driven development) practices
In FDD, there are practices that are very privileged. For example, we need to use the UML Color (colors for classes) to make the class models.
Let’s work by feature
The FDD (Feature-driven development) strongly favors the feature-based development. A “feature” must be possible to develop in two weeks like a user-story. If not, split the feature into two separate features.
Moreover, there is a classic format for writing FDD (Feature-driven development) features:
<action> the <result><by|for|of|to|><a(n)><object>
For example, we could have:
Calculate [action] the total [result] of a sale [object].
The FDD (Feature-driven development) teams are defined in Feature Team; they will be responsible for their parts of development; the feature team will also be chosen in the future for developments concerning their scope.
These feature teams will be more autonomous to work on their scope.
Developers are responsible
A practice totally in opposition to the agile methods currently used within companies is the “Class Ownership”. Basically, a class in the code is owned by a developer (or two developers) as long as he is in the company. The responsive developer will work on this code in the future, if it’s necessary.
However, we prefer when it is possible to have two Class Owner to reduce the fear to be solely responsible (felt by the developer) in case of problems.
The FDD (Feature-driven development) imposes the fact of having regular builds in order to regularly test the product advancement. The feedback recovery is an essential point in agile products.
Progress reporting tool
The FDD (Feature-driven development) imposes the fact of making progress reporting as in Scrum. It is very important in the projects to have transparency on the progress of the project in order to be able to manage the obstacles as soon as possible.
Is FDD (Feature-driven development) really an agile method?
Indeed, the FDD (Feature-driven development) responds to the values and principles of the Agile Manifesto. In fact, a lot of people do a mistake in thinking that it’s forbidden to have a very precise technical roles, to assign the work to the developers… In reality, Scrum totally refuses these practices… but it’s not forbidden in the world of agility.
Now, the way to work in FDD (Feature-driven development) is more reminiscent of old practices than recent.
Conclusion FDD (Feature-driven development)
Are the companies that do Scrum with project managers and architects not agile? In fact, some teams diverts the scrum rules but it’s not anti-agile.
For my part, I recommend having multidisciplinary technical teams. This concept works well: team motivated, turn-over without risk …. Maybe because it’s more recent.
I hope that this article will allow you to know a new agile method; Some of these practices will help you in the future.
What do you think about FDD (Feature-driven development)?