Before the Agile Manifesto came to life, some tools ruled the management world. And of them is the Feature Drive Development, as known as FDD.
The FDD was first of all created by Jeff de Luca in 1997, based on the Coad method, created by Peter Coad in the 1980s, and on the interactive and lean processes already used by Jeff de Luca.
Seeing the progress of the methods that could work better in most of the companies, FDD incorporates many of the best development practices already recognized by the industry into a cohesive package.
These practices are all feature-oriented, which is a value concept from the customer’s point of view. FDD’s main objective is to deliver a tangible and functional piece of software to the customer in space’s regular time slots.
In this article, you will figure out what are FDD’s main characteristics and objectives and how you can use them in project management.
GitScrum helps your team perform better with the best features for any project. Get all of our features with the best lifetime deal to sign now!
What is Feature Driven Development?
FDD seeks development for functionality, that is, for a functional requirement of the system. It’s handy for working with initial projects or projects with existing encodings.
Although having some differences between FDD and XP, for example, it is possible to use the best practices of each methodology. FDD works very well in conjunction with Scrum, as Scrum acts in the focus of project management and FDD acts in the development process.
One of the objectives of FDD is to present such functionalities to the customer
in a fixed period of time, usually two weeks or less.
FDD has a short lifecycle and is best suited for systems that can change requirements quickly; it incorporates many of the best development practices already recognized by the industry into a cohesive whole.
These practices are all feature-oriented, which is a value concept from the customer’s point of view. The main objective of FDD is to deliver a tangible and functional piece of software to the customer in regular time frames, typically two weeks or less.
FDD roles in Scrum
1) Project Manager / Product Owner
The project manager is the one who handles the administrative issues of the project, where he has the autonomy to decide what should be done, prioritizing any functionality that delivers value and manages to be performed during that pre-determined period of time.
He is also responsible for a small team, ensuring good working conditions to increase the performance of everyone involved, as well as for deciding what will be done during the defined sprint.
2) Development Manager / Scrum Master
The development manager is responsible for removing any impediments that the team may have, in addition to making the necessary meetings happen.
He must also evaluate if the code carried out by the development team is in the project standards, and if not, he must point out improvements or suggestions that collaborate in the team’s maturity, in question to the code and also to the team.
3) Design Team / UX Team
The design team, based on the analysis of the architecture and documentation of the project and/or product worked, will be responsible for all the visual issues to be carried out, including usability issues.
4) Class Owner / Developer
The class owner is a member of the development team, where he will be under the command of the development manager. He is responsible for issues related to architecture and testing, but his main activity is the implementation of features defined by the project manager.
5) Technical Writer / Requirements Analyst
The technical writer is responsible for understanding the product, having to know the area of operation of the project and/or product worked and must be involved in a large part of the product decisions, as it is he who ensures that the system follows the business rules of each functionality.
FDD’s Best Practices
To flow correctly, there are some good practices in FDD usage. However, FDD preaches adaptability in the development environment:
- Domain object-oriented modeling: Modeling should be basic, just something illustrative for those involved in the project.
- Feature development: feature-oriented implementation.
- Proprietary code: the code must be performed only by one developer, that is, started and terminated by the same developer, however, it does not prevent the pair programming from being performed with another developer on the team.
- Team: team designed to develop features necessary for the project.
Inspections: code review must be performed to ensure that what is being sent to the usage environment will not result in future bugs and problems.
- Regular integration: in a fixed period of time, the finished features must be integrated, allowing for error checking and also creating a current version that can be demonstrated to the customer.
- Configuration management: having different environments with versions of the functionality developed, currently a development environment is widely used, one for approval and another that is the stable environment for customers to use.
- Report/Visibility of results: everyone involved must know the development status of the features that were developed, as this is a way of learning.
FDD’s Basic Processes
Some processes to be developed for the basic functioning of the FDD are as follows:
- Comprehensive model development (Object-oriented analysis);
- Construction of feature list;
- Incremental planning for functionality;
- Projection by functionality;
- Build for functionality.
The team’s progress is made through each item added to be carried out at the beginning of development planning. There is a level of effort and a priority level of the functionality in question that must be estimated and the meetings that will be held daily are monitored.
When the feature’s development status must be changed, they can be symbolized by colors of “in progress”, “delivered” and “delayed”, or simply carry out the estimation in hours that still show the task to be delivered.
The most common these days is to split the feature into development days, for example, if you committed to developing the feature. You should split it into smaller features that will fit in 8 hours of development, so your monitoring will be easier. It is common to split the feature as follows:
- Application domain survey ;
- Functionality knowledge ;
- Project inspection ;
- Development ;
- Code inspection;
The FDD documentation is not very different from the documentation that is common to be used in agile methodologies. The main idea for the documentation is that the feature must deliver value to the customer, follow good practices and basic processes. Each process must be described in a maximum of two pages, following the structure: Input, Tasks, Verification, and Outputs.
Documentation of Features
The structure of feature documentation follows the following pattern:
Check the number of characters;
Check if the password has a number;
Check if the password has a capital letter;
Check if the password has a lowercase letter;
Check if the password has a symbol.
The inspections on the documentation are carried out to prevent future bugs in the development, allow the transfer of correct knowledge, give the developer the standards that must be followed, and allow extracting metrics for improvements in both the documentation processes and the development processes.
FDD is an extremely adaptable agile methodology, which can be easily coupled to the SCRUM agile methodology as well, which has its advantages for the events that must be held during the development sprint.
The main advantage of FDD is to consider the whole bigger than each part separately, as this encourages team spirit, and makes everyone understand what the product is, to carry out the development of the feature, avoiding future problems in the implementation.
The FDD is oriented to the product’s needs, and I believe it can add a lot in the development of the same because the responsibility for the product prioritizes the tasks that will add value and, in parallel, the correction of problems that may appear.
GitScrum supports your team to better and understandable self-organization!
Set your workflow and board to guide your Agile team, assign Tasks, Subtasks and keep in charge of the whole process evolvements. Allow your Agile team to collaborate.
Test our User Stories features to do like these companies and satisfy the customer, first of all, communicate constantly to respond to their expectations ASAP, with collaborators easily interacting at the workboard.
Be able to adapt to workflow changes, use Kanban boards and Gantt Charts to monitor vital information and team performance.
Reach higher levels of efficiency, productivity, and deliverability with GitScrum. Work focused on prioritizing what’s valuable and tracking your flow to overcome results.
Sign up now and make your team grow together!