A comparison of FDD and Scrum

FDD and Scrum are two examples of agile development methodologies. Agile development tries to avoid the main weakness of "waterfall" by doing iterative development. Each iteration is meant to be short (1-2 weeks) and includes all of the following steps.

• Gathering user requirements
• Design and documentation
• Development
• Testing
• Deployment

This guarantees that design errors are discovered at early stages of development. I've had experience on working on projects using both methodologies and it was interesting to compare the salient features of both approaches.  Before the comparison, a short overview of each practice is given.

Feature Driven Development
Feature Driven Development, FDD  is an agile software development methodology by Jeff De Luca and Peter Coad.  It has more formal requirements and steps than Scrum from a development perspective.

 

FDD consists of five high level activities:

• Develop an overall domain mode
• FDD advocates light modelling up front to understand the shape and scope of the application.
• Build a list of features
Team builds a feature list.  Each feature represents 1-10 days worth of effort.  
A feature is a small piece of client-valued function expressed in the form: <action> <result> <object> i.e. Calculate the total of a sale
• Plan by feature
• Features are then assigned to iterative release cycles.
• Developers are also assigned to own particular classes identified in the domain model by a chief programmer.
• Design By Feature (DBF)
• Feature teams are assigned to a set of features and proceed to the design in detail i.e. sequence diagrams 
• Build By Feature (BBF)
• Those teams then carry out the code development and testing of those features.
• When chief programmer is satisfied then completed features are promoted to the main build.

FDD utilizes chief programmer, inspections, and class ownership. The chief programmers function as team leaders, mentors, and reviewers. While the term chief programmer may suggest micro-management and control, FDD teams stress the collaboration and knowledge sharing roles.


Progress and can be tracked and reported with accuracy by assigning a percentage weighting to each step in a DBF/BBF iteration The chief programmers indicate when each step has been completed for each feature they're developing. This enables a view on how much of a particular feature has been completed.  The cycle repeats itself either by refinement of the original domain model and subsequent activities or until all the features in the list have been built.

Scrum

Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering. Essentially Scrum boils down to the following points (from Scrum Alliance):

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

A big misconception with Scrum is what it actually is. Scrum will not tell how to do things. It is not a development methodology. Scrum is essentially about communication and reacting to feedback.

This original statement from Schwaber and Beedle, the creators of Scrum states:
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies, or standards

So now we know what FDD and Scrum are, let's compare the two practices:

FDD and Scrum Similarities

• Collaborative.
• Improved communication
• Completely developed and tested features in short iterations
• Progress can be tracked at different granularities
• Emphasis producing quality components

FDD and Scrum Differences

Scrum:

• Does not specify any particular engineering practice although parts of XP are frequently adopted.
• Focus on producing vertical slices of functionality acceptable to product owner.
• Shorter feedback loops
• Self-organizing teams
• Shared code ownership

FDD:

• –Specific engineering practices i.e. design/code inspections, tests
• –Domain driven
• –Longer feedback loop
• –Feature team have recognized roles i.e. Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner, and Domain Expert
• –Class ownership

Why choose FDD?

• Willing to trade some agility for well-defined way of scaling
• Team has solid modelling skills
• Most requirements are known in advance and are stable.

Why choose Scrum?

• Requirements are changing or emergent
• Willing to let team self-organize
• Need a management framework more than a set of engineering practices.
• Better manage risk
• Proven scalable agile process

Conclusion

 I feel that Scrum with XP and FDD are complementary agile methodologies rather than opposites. Both approaches provide agility but in different ways. I find when practicing Scrum, I may perform some up-front design before I delve into code which is similar to what's advocated by FDD.  However I find feedback loops in Scrum are much quicker than in FDD. The loop between design and development phases can be much shorter and it's easier to change tack if you find the direction you following is incorrect.  I frequently work on greenfield projects and as such find that having to work on a domain model before I delve into code slows down the momentum of a project somewhat. In these occasions,  I find spikes or mini POCs are more rewarding. Conversely for those projects where the requirements are well known and stable then FDD can be a more suitable.

Some links for futher investigation

FDD

• –http://www.nebulon.com/fdd/ - Jeff De Luca
• –http://www.featuredrivendevelopment.com/
• http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment

Scrum

1. http://www.scrumalliance.org/learn_about_scrum
2. Scrum Development Process by Ken Schwaber
3. http://www.mountaingoatsoftware.com/scrum
4. http://en.wikipedia.org/wiki/Scrum_(development)