Building software is a complicated process. Especially when it comes to large scale projects, more complex platforms, or mission-critical systems. The stakes are high in such cases, and any mistake or oversight can be costly.
For that reason, numerous approaches have been created to make the whole process easier and more streamlined for everyone involved. Feature Driven Development is one of the newer approaches that simplify the process, whether it is building a website for your local grocery store, a banking system to replace an outdated one, or building the next Instagram!
This post borrows from our many years in the software development space to break down the FDD methodology, making it easy for software development teams of any skill level to grasp the concept and apply this method accordingly.
Feature Driven Development defined
Feature Driven Development (FDD) is a software development process that organizes work around features. A feature, in this context, is a small piece of functionality that can be delivered to a customer. FDD defines five core activities for managing and delivering features, which we’ll see shortly under the stages of development.
This is one of the most well-received approaches, and for a good reason, as it takes the best parts of «Waterfall» & «Scrum» and blends them into one new and improved whole.
FDD’s uniqueness derives from its unique approach to product development, as its main focus is creating new «Features» and developing them from start to finish. These completed features get delivered to the client at a higher frequency than what other methodologies would recommend or are used to. (2–10 days).
Clients love this unique approach because they can see tangible results delivered often (usually every 2 weeks), with feature after feature added.
At the same time, developers also love FDD because a single person or small development teams get to develop and maintain a particular feature from start to finish. This makes the entirety of the software development process simpler and more enjoyable.
How is Feature Driven Development different from other methodologies like Scrum?
There is a common misconception that Feature Driven Development and Scrum are the same thing, which they are not, but we can’t blame you if you thought the same thing too.
With both approaches being agile frameworks that follow the same agile philosophy, they inevitably have a lot of similarities.
One of the main areas where Feature Driven Development differs from Scrum is its center of focus.
Scrum is a process that has continuous delivery in mind, running (mostly) two-week sprints at the end of which, all the work that had been done is delivered to the client, keeping a constant stream of deliverables which may consist of anything from new features, to bug fixes, to documentation updates, to unit tests. All for separate parts of the system.
On the other hand, FDD, as the name implies, is driven by features. There is a feature list (think of it almost like a bucket) from where developers or development teams pick whichever feature is at the top and develop it fully, from start to finish. At the end of the work cycle (could be two weeks like a sprint, or sometimes even shorter) they bundle up all the completed features and deliver them to the client. This means that each feature must be small enough to fit this window of 2 to 10 days.
Another, less obvious, differentiation is that FDD is more customer-centric, as everything is developed with the end user in mind. Actually, end users and domain experts are often involved in the process themselves.
On the other hand, Scrum teams communicate with the product owner, who represents the client, but there is no real communication with the actual end-user to get feedback and/or information about the requirements.
At the same time, FDD shares a lot of similarities with the waterfall method, as Feature Driven Development has drawn a lot of inspiration from the “grandfather” of project management approaches.
Both of these two popular approaches begin with a good amount of planning, deciding beforehand what virtually every part of the entire project will look like and what functionalities will or will not be there.
And this is where most of their similarities end, as FDD is much more agile and way more friendly to the end user. The constant stream of features and updates sounds heavenly compared to the complete silence of waterfall methods that can often last for years on end.
Stages of Feature Driven Development
The FDD approach is split into five stages ever since the first time it was executed, way back in 1997, by a team of 50 people that worked on a piece of software for a Singapore bank.
These five stages are also divided into two separate phases. First comes the more theoretical “planning” phase, followed by the “constructing” phase, where the actual development occurs.
Let’s see what the five stages are and what is the scope of each one.
1. Develop the overall model
This is the stage where the project management and the developer teams create an “outline” for the initial domain object model. Domain experts (e.g. potential future users of the software) and the chief architect usually take part in the model development, aiding with their knowledge and insights.
It is during the overall model development phase that it’s decided what the program will do (what is the problem we are solving?), what the target audience is (which people benefit the most from this program? What are their common characteristics?) and what is the general context in which they would use it (how and when are they using it?)
The outline must remain rather abstract. Not a lot of details should be given at this point as by doing so, the team is running the risk of narrowing the project’s scope and harming its future success by missing potential opportunities.
2. Build the feature list
Next up is the feature list, one of the most fun parts of the entire process. This is the point where the entire project is split into many small features which will then be completed separately.
These features are similar to what User Stories represent in Scrum. They are little blocks of work that the development team will, later on, pick up and execute.
Each feature/story consists of 3 parts.
- The action: what the user is doing. E.g. The user presses the ‘login’ button
- The output: what happens because of the user’s action. E.g. Credentials are checked and the user logs in
- Story/Feature points: A number that represents how valuable a feature is for the overall project. For example, the ‘login’ process is a must and thus is worth 5+ story points. On the other hand, showing confetti on the screen after each successful login, while looks really cool, is not as valuable and could be worth just 1 or 2 story points.
While building the feature list, it is important to keep in mind that features must be small.
A feature is small enough if it can be completed from start to finish in 10 days at most. If the estimation says that a particular feature needs more than 10 days, then it’s split into more minor features that fit the above criteria. For example, while the whole login functionality may normally be considered a single feature, the ‘forgot password’ part could be split into its own feature to make them small enough.
3. Plan by feature
In the ‘Plan by Feature’ phase, we take each story and add details to it. This means splitting the feature into comprehensive tasks that lead to the feature’s completion. This also means estimating the number of hours it will take until completion.
Then, the team plans the order in which the features are going to be developed. This is based on two factors:
- What is the most important feature for the current state of the project?
- What is the feature with the highest ROI (Return On Investment)? Meaning, what is the feature that brings the most value to the product in the least amount of work hours?
The first factor is applied before the second one to ensure the project stays cohesive and each feature can be used immediately upon completion.
For example, while setting up a payment gateway might have a huge ROI, it is more important in the early stages to build a login screen or a landing page.
These above stages conclude the “planning” phase. The final two are more hands-on and, together, they create the “construction” phase.
4. Design by feature
In this first stage of the “construction” phase, visual representations of each feature are created by the development team along with domain experts. This is done by utilizing the power of flow diagrams, state diagrams, and other Unified Modeling Language (UML) techniques. The chief architect and chief programmer are usually present to lend a helping hand if needed.
The goal here is for everyone to have a common understanding of what the feature will do and how it will do it. It also helps catch potential overlaps or inconsistencies between features that would otherwise be overlooked.
5. Build by feature
Each team starts working on its assigned feature/class from start to finish. Once the feature is assigned, the team gets complete ownership.
The chief programmer is responsible for forming the teams and deciding which members are assigned to which features. It isn't uncommon for the chief programmers to switch out one or more team members for the next feature, ensuring that the team has all the necessary skills to get the job done.
Since each team has all the skills it needs to do everything the feature requires, all parts of the feature start simultaneously. Writing the code, designing the UI, creating & running the tests, and writing the documentation are all completed by the team in the duration of the allocated days.
Once every part of the feature is complete, then the entire feature gets delivered and added accordingly.
As you progress through the various stages, it's essential to consider the overarching Agile lifecycle management concept for a more solid process.
Best practices to guide the FDD framework
You cannot go wrong so easily if you follow the steps above for the FDD method. But on top of that, the following best practices will make your experience even better:
1. Deliver often
Having frequent deliveries (ideal frequency seems to be 2-week cycles) forces the development team to split features into smaller parts that will fit the time-span, making things simpler and often revealing issues and caveats that were not visible beforehand.
Regular deliveries make it possible for the end users to see progress, providing earlier feedback and demonstrating to clients that progress is being made.
2. Quality assurance
A quality piece of software needs to come with its own tests (especially unit tests). It is just as essential, however, to have the features tested by individuals outside of the development team to guarantee that everything functions as planned and nothing was overlooked in the initial testing stages.
Further Reading: Best practices in Agile implementation
3. Version control
Tracking changes in the software, be it a newly added feature or a change to an already existing one, makes it easier to go back to an older version of the project and pinpoint the root cause of a problem. For example, if something goes wrong, you can easily access an older version of the project and figure out what code caused the issue.
Version control also facilitates collaboration among teams by ensuring changes are made appropriately and conflicts are avoided when two developers are working on the same file.
4. Single point of ownership
Each class/feature is developed, tested, documented, and maintained by the same person or group of people.
Individual class ownership ensures the quality remains consistent throughout the entirety of the feature and the team/owner has a sense of importance and accomplishment, making the process more satisfying.
Pros of Feature Driven Development
If we could sum up all the wonderful benefits of FDD into just one word, it would be 'simplicity'. Feature Driven Development is an approach which requires a few straightforward steps yet is powerful enough to tackle complex projects.
Let's have a look at its most prominent advantages:
1. Frequent feature delivery keeps clients happy
Delivering complete features frequently allows the end users to access them earlier, making them more satisfied with the whole process. It also allows for better, earlier, more frequent feedback — which allows developers to address potential concerns or add improvements faster.
This both ensures a better user experience and also helps reduce development costs as issues are quickly identified and solved.
2. Feature ownership empowers developers
The development team is entirely responsible for developing and maintaining the feature, which makes them care more about the quality and the result.
The feature essentially becomes “their baby” so their pride in the work is increased, which naturally brings an overall better outcome for everyone involved.
3. Simple process that is proven to work
Feature Driven Development is a simple process with only five steps. It is easy to understand and implement in your project and has provided great results to numerous teams over the course of almost three decades
Cons of Feature Driven Development
It's hard to think something as trusty as FDD could have any drawbacks. But, nothing in life is perfect, and FDD has its own shortcomings. Here are the most frequent disadvantages that we often come across.
1. Overkill for smaller projects
If a project is on the smaller/simpler side, using Feature Driven Development may be unnecessary and cost time without bringing any significant benefits to the team.
2. Requires too much expertise
Chief programmers, chief architects, and domain experts are needed in more than half of FDD’s stages. If just one of these experts is missing, the quality and flow of the process can be severely compromised.
3. Lacking in “secondary” areas
The development team is in charge of completing every part of the feature. This can often lead to lackluster testing and documentation which can result in future confusion and bugs.
Conclusion
Feature Driven Development is an incredibly powerful, time-tested software development methodology that makes features the center of attention. Its practical approach to software development borrows the best parts from both agile and traditional approaches, creating an effective five-step process that makes the development of complex systems simple and streamlined.
FDD is the ideal methodology for projects that are too big and complicated and its value is harnessed best by larger teams with numerous experts at their disposal.
