Imagine you’re building a house. Instead of building the entire house all at once, you start with the essentials, like the foundation first, then walls, roofs, and interior. This analogy can be synonymous with a modern software product development framework called Feature Driven Development (FDD) – a step-by-step approach focusing on one specific feature at a time and gradually progressing towards the complete product. As a part of Agile ideology, FDD is anchored to the core concept of iterative and incremental development, where a project is broken down into multiple manageable tasks and developed through agile iterations.
What is FDD?
Feature Driven Development (FDD) is the brainchild of two prominent software developers, Jeff De Luca & Peter Coad, looking for an adaptive development that cultivates a customer-centric approach in pre 2000s. Since then, this approach has evolved remarkably and has been widely used by development teams worldwide.
FDD, an agile software development methodology, focuses on progressive delivery, ensuring collaboration and clear feature scoping that satisfies user needs. It offers a structured, iterative and incremental approach to software development. However, one of the common misconceptions is that ‘Feature’ in FDD means a specific feature or functionality. But it is similar to ‘user stories’ in Scrum – a particular user flow to achieve a goal. Examples include creating a user profile, adding items to the shopping cart, etc.
With FDD, people usually work in small groups called feature teams, where each team is responsible for completing one specific feature. These teams collaborate closely and effectively document to ensure everything is progressing towards the goal of developing the user-centric product.
Five Stages of FDD
Feature Driven Development (FDD) involves five crucial steps spanning the entire development lifecycle.
1. Develop an Overall Model
With a clear understanding of product vision & project scope, the chief architect and team members collaborate to create an object model that caters to the domain problem. This serves as the fundamental base over which the application systems will be built, and features are developed along the way.
2. Build the Features List
The project team members collaborate and list out the ‘features’ of considering the product vision & the value it offers to the potential users. These features should be translated into small and manageable tasks for the developers, which they should be able to complete in 2 to 10 days.
3. Plan by Feature
Now, the features are assessed by considering various factors like value creation, required resource bandwidth, expected timeframes, risks and dependencies. Later, the features are organised appropriately and assigned to specific developer teams called feature owners.
4. Design by Feature
The feature-level detailing happens here; the chief programmer analyses and finalises the features that must be designed and built on high priority. Design packages for each feature will be created and reviewed for development and also help in refining the overall model.
5. Build by Feature
The complete feature-building activities like development, integration and testing happen here. Then the chief programmer reviews the feature to ensure it aligns with the goals or if it needs iterations. The feature will then be added to the main build upon successful completion and be available for client use.
What is the difference between FDD and Scrum?
FDD and Scrum are the frameworks fundamentally linked to classic Agile Principles. So both FDD and Scrum uphold some standard agile ideologies like collaboration, transparency, efficiency & iterative development. However, their differences are evident when we investigate the nuances of the development process.
- One of the polarising differences between FDD and Scrum is that in FDD, the actual product user is involved in the development to enrich the model. In Scrum, the product owner enacts as the end user.
- The FDD emphasises more on domain modelling & domain-driven designing, while Scrum doesn’t.
- In FDD, Feature must be developed in 2 to 10 days. In comparison, Scrum sprints would typically take 2 to 4 weeks.
- FDD follows a complex team structure that involves names like Chief Programmer, Domain expert etc. Meanwhile, Scrum follows a lean team structure like POD teams.
- FDD values documentation processes, but Scrum prefers daily standups and meetings.
FDD Team Roles
Chief Architect
The Chief Architect is responsible for the overall technical direction and system design. They are the ones who guide the development team on a high level, addressing technical difficulties.
Chief Programmer
The most experienced programmer who leads the development team in implementing the features and ensuring the project’s successful execution.
Feature Owners
Each feature has a designated Feature Owner who takes responsibility for its successful implementation. They collaborate with the Chief Architect and other team members to define, design, and deliver the feature.
Class Owner
Classes are part of feature development. And the Class Owners are also a team of developers responsible for a specific class of objects or components within the application system & documentation activities.
Domain Expert
A Domain Expert has in-depth knowledge of the problem domain. They work closely with the team to provide domain insights, clarify requirements, and ensure the system meets business needs.
Project Manager
The Project Manager oversees the project’s progress, manages schedules, and ensures the development team is on track. They take care of coordination, communication, and resource management to meet project goals.
Advantages of FDD
- The FDD’s idea of involving actual end-user ensures more user-centric product development.
- Domain modelling and planning provide a predictable and controlled development roadmap.
- The structured approach with well-defined steps offers more scalability, making it ideal for large-scale and complex projects.
- The emphasis on effective & clear documentation compounds into improved visibility, productivity, & efficiency for development teams.
- Breaking the project requirements into small and executable tasks makes managing code across the development cycle easier.
Disadvantages of FDD
- The complex team structure of FDD makes it less suitable for small projects.
- In FDD, team building and training could be a challenge in terms of time & budget.
- Dependencies could hinder the development lifecycle due to technological expertise and interrelated features.
- As FDD emphasizes a well-planned approach from the start, it only offers a little flexibility to make ongoing feature changes.
Best Practices in FDD
Domain Object Modelling
Start with understanding the problem domain and creating high-level sequential diagrams that aid in developing the framework with features that solve the problem. Involving domain experts and actual users in building this model eliminates assumptions and ensures the development of the most relevant solution for the target users.
Developing by Feature
Each feature represents a specific action flow enabling users to achieve their goals. If the features are becoming complex to complete in 2 to 10 days, breaking them into multiple sub-features is quintessential. This enables development teams to produce features efficiently within ideal timeframes.
Individual Class Ownership
Code/Class ownership is an excellent trait that should be instilled among the team members. This makes things easier whenever changes are incoming; so the respective class owner could jump in and execute it seamlessly. Code ownership also helps in achieving higher code quality.
Feature Teams
It is good to form small and dynamic feature teams, typically three to six in number. And they are collectively entitled to the code behind the feature. Chief programmers’ guidance and collaboration can be instrumental for them to bring the most efficient solutions to the table.
Inspections
Regular inspections are synonymous with FDD’s core idea. Inspection practices reveal potential defects to remove and garner insights to improve the overall model. Both team members and chief programmers can get into inspection activities depending on the project’s complexity.
Regular Builds
Keeping the systems up to date with the most recent changes in the features is recommended. Regular build practices with efficient documentation help demonstrate maximum value to the end-users and minimise integration errors as the overall model evolves.
Configuration Management
Implementing configuration management systems helps maintain source code for all the features, and records all the change history for respective features. This can help feature teams enhance the features resulting in better products for the end-users.
Reporting
Efficient reporting frameworks increase the visibility for project leaders to track the overall development progress, and Project team members can become well-informed about their deliverables.
Bringing in the actual users into product visioning and collaboratively developing the product is one of the idealistic ways of developing a user-centric product in this modern era. The Feature-Driven Development framework stands true to this and is mainly preferred by teams prioritising scalability, standardisation & domain modelling.
Being a digitalisation pioneer, we understand that businesses differ in many ways, and we always introspect and evaluate the frameworks that best fit with business goals and perspectives.
