Feature Driven Development vs Scrum
Agile software development was created in opposition to Waterfall by encouraging small cross-functional teams to work in iterations. Each iteration is usually short (one to two weeks). And by the end of an iteration, the team should have completed some design, development and testing work.
This ensures that errors are found early on in development, rather than at the end of the project. It also means that product increments are built, tested and shown to stakeholders early and frequently.
Feature Driven Development and Scrum are two examples of agile software development philosophies. This article will compare the use of both frameworks and their main features. So you can know when to use Feature Driven Development, or Scrum. Depending on your context and background.
Before we do that, we will look at a short summary of them.
Feature Driven Development
Feature Driven Development (or FDD) is a software program development methodology by Jeff De Luca and Peter Coad. It has even more official activities as well as roles than Scrum, from a development point of view.
FDD includes five high-level tasks:
Develop an overall domain model
FDD supporters light designing up-front of the domain, to recognize the shape and purpose of the application. High-level domain modelling helps hte team understand the business context. Which is required for building up features.
Build up a list of features
The team then constructs a feature list. Each feature should represent about one to ten days worth of effort.
A function is a tiny piece of client-valued functionality. For example, calculate the total amount of a sale.
Plan by feature
Features are then assigned to releases. Developers are also assigned to own particular features identified in the domain by a primary programmer. These features usually map to classes.
Design By Feature (DBF)
Each feature now gets a design package, including sequence diagrams. The overall model is refined as these feature designs are built up. Teams or developers are then assigned one or more features to build.
Build By Feature (BBF)
The teams then carry out the development, integration and testing of those features. So you could say this approach includes feature-driven testing too. Ideally, all the features put into an iteration can be finished in that iteration.
When the chief programmer, is happy then completed functions are pushed to the main build.
FDD makes use of a chief programmer, for code inspections as well as course correction.
The principal developers function as group leaders, advisors, and also stakeholders. Scrum certainly has no developer hierarchy, such as a “chief” or “lead” or “senior”. So this is one major difference between FDD and Scrum.
You can also measure and report on progress with some precision. This is done by appointing a weighting per step in a DBF/BBF iteration. The chief developers show when each action has been finished for every attribute they’re creating.
This means you can get a view on just how much of a particular feature has been done. The cycle repeats itself either by refinement of the initial domain model and subsequent activities, or until all the features in the list have actually been developed.
Scrum
Scrum is an iterative, incremental framework for product development that is very popular in agile software development, an approach to software engineering. Basically Scrum comes down to following these points:
- A product owner builds and owns a prioritized wish-list called a Product Backlog
- In a sprint planning event, at the start of a sprint, the group pulls a small amount of work from the top of that backlog, which becomes the sprint backlog, and plans how to implement those items
- There is a Scrum Master, who keeps the team focused on its goal and removes impediments
- The team has a timebox, a called a sprint, to finish its job – generally two to four weeks – yet meets each day to examine its progress (daily scrum).
At the end of the sprint, the the team should have a potentially shippable product increment. The final events for the sprint are a sprint review (where the product increment is shown to stakeholders) and a retrospective (where the team discusses how they went).
As the next sprint starts, the team picks more items from the product backlog and the cycle begins again.
The cycle repeats until sufficient things in the product backlog have been completed, the spending plan is depleted, or a deadline has been reached.
A large false impression with Scrum is what it in fact is. Scrum does not specify how the software is to be built. It is not a software methodology. It doesn’t talk about technologies or architecture or code reviews or automated testing.
Scrum is essentially about communication, learning, inspection and feedback. It is based on the philosophy of empiricism, which says that learning and knowledge come from experience.
This is contrast to the traditional plan-driven approach of Waterfall.
So now we understand what the advantages and disadvantages of feature driven development and Scrum are, we can compare both methods:.
FDD and Scrum Similarities
They are both collaborative, and focused on teamwork and interactions. They emphasise interaction and transparency – in fact, transparency is one of the three core Scrum pillars.
Progression can be easily tracked in different ways and at different scales or granularities.
They both have an emphasis on creating high quality components. There should be no shortcuts or shoddy work.
FDD vs Scrum Differences
Scrum:
- Does not define any particular design or development techniques, although parts of XP are often used by teams.
- Focus on generating small product increments that can be quickly delivered to a customer
- Much shorter feedback loops
- Self-organizing teams, with a simple structure and set of roles – e.g. no “senior” or “chief” roles.
FDD :
- Detailed design methods
- Domain driven design
- Roles that are more likely to map to an organization’s existing roles, e.g. “chief programmer”
- Longer feedback loops.
Why use FDD?
FDD might be a good choice if scaling and domain design rather than agility is a priority for the organisation. FDD also works well if the team has strong modelling skills. Since domain design and modelling is crucial for FDD.
It also helps if the majority of needs are understood in advance and are pretty stable. FDD doesn’t have very good mechanisms for changing requirements.
Why use Scrum?
You might want to use Scrum if you have changing or unclear requirements. The separation of Product Backlog and Sprint Backlog enables the team to be laser-focused on a small slice of work, while giving the product owner flexibility to adjust and change scope.
Scrum is also good if the organization is ready to allow groups to self-organize. Scrum teams are empowered and self-managing (the Scrum Master is not their manager!).
Scrum is also good if you are looking for a product management or product development framework, rather than a bunch of engineering techniques. Scrum doesn’t have anything to say about specific engineering techniques (unlike say FDD).
Summary
I feel that Scrum with XP and FDD are corresponding agile methods instead of opposites. Both methods supply agility but in different ways.
Scrum is more about moving quickly and swarming around risks and blockers. FDD is more about modelling, design and development. So it depends on what is a priority for your organization and stakeholders. And where the organization is up to in terms of its agile journey.
Scrum may be an easier fit for more agile organizations which can easily split into small, self-managing teams. FDD has a more complex hierarchy of roles. Which might be painful for some but an easier change for some older and slower firms to make.
