Flavors of Agile - Feature Driven Development

 

Unlike some of the other flavors of Agile, Feature Driven Development (FDD) is intended for larger teams, anticipating that team members will have disparate experience and maturity levels.  The latest FDD processes can be found here, if you don't mind reading ten pages of process reminiscent of the PMBOK.  Or you can keep reading, here. I can't promise it won't be dry, but it's less than ten pages.

FDD is built around five processes, the first three are done before development work begins (shh, don't say Sprint '0'), while the last two cover design and development:

1. Develop an overall model - don't let the name fool you; this is not big up front design.  The model is a living artifact that identifies tasks and quality checks, and is used to discuss, challenge, and clarify requirements.
2. Build a features list - features are small, client valued functions that typically take 1-3 days to implement.  They may take up to 5 days, but never 10 or more.  The Features List is organized into three levels, broken down by Areas, Activities, then Features.  Between you and me, this sounds a little bit like a work breakdown structure.
3. Plan by feature - Sequence the work, create an initial schedule, and assign responsibilities.
4. Design by feature - collaborative analysis and design of the features for an iteration, concluded by a design review.
5. Build by feature - Coding, unit testing, feature testing, code inspection, and build

Primary FDD Roles are:

• Project Manager - the administrative lead for the project
• Chief Architect - owns overall design of the system, responsible for collaboratively facilitating the system design
• Development Manager - manages day-to-day resource assignments and development activities. May be combined with Project Manager or Chief Architect.
• Chief Programmer - experienced developers who lead feature teams and facilitate iterations.
• Class Owner - experienced developers
• Domain Experts - people with deep business knowledge who provide input into tasks the system is required to perform.

There are also several supporting roles that may, or may not, be needed based on the size of the project.

In addition to having a Project Manager (gasp) and a hierarchical team structure, there are more practices of FDD that make it different from other flavors of Agile:

• Feature teams consist of 3 to 5 people who own the classes they are working on, so that there are no dependencies between teams.  You can expect there to be multiple feature teams on an FDD project, unless it is a small project.
• Team members (or Class Owners) may be on more than one team at a time.
• While iterations may last up to two weeks, they may only last a few days.  They are not fixed length, and the start and finish of one iteration by one Chief Programmer may not line up with the start and finish of an iteration being run by another Chief Programmer.
• The Chief Programmer chooses the work that will be included in the iteration.
• Tests may be written before or after coding is complete.
• There should be a "regular" build, but this could be weekly, daily, or continuously.

I won't argue whether or not FDD is scalable for large projects.  The literature says it was built for larger projects; who am I to argue.  I will say it comes across as development centric; however, this is not necessarily a negative point.  It is not the only flavor of Agile that is development centric, and FDD processes could be a fit for your organization. 

Transitioning to FDD may be an easier transition than Agile flavors with a flat organization structure simply because of how your organization currently works.  It's not about how the process looks on paper; it's about how it fits your organization. 

Keep in mind that if you fail to adopt one flavor of Agile, you may not get a second chance to pursue another.  There is still a large knowledge gap, when it comes to Agile and its many flavors.  If one flavor leaves a bad taste in the company's respective mouth, it may not want to try another even if it knows there are other flavors.  This brings us back to why I am reviewing flavors of Agile.  It's a learning process for me, and it hopefully gives you a resource to help you determine which flavor of Agile will be best for you.