Agile Modeling and Feature-Driven Development

Thinking Big
FDD was first introduced in 1999 via Peter Coad, Eric Lefebvre and Jeff De Luca's book, Java Modeling in Color with UML (Prentice Hall, 1999), a combination of the software process followed by De Luca's company and Coad's concept of features. FDD was first applied on a 15-month, 50-person project for a large Singapore bank in 1997, immediately followed by a second, 18-month, 250-person project.

Who says agile techniques are only for small projects? Earlier this year, a more substantial description was published in Stephen R. Palmer and John M. Felsing's book, A Practical Guide to Feature-Driven Development (Prentice Hall, 2002).

As the name implies, features are an important aspect of FDD. A feature is a small, client-valued function expressed in the form: for example, "Calculate the total of a sale,", "Validate the password of a user" and "Authorize the sales transaction of a customer". Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to XP: They're a primary source of requirements and the primary input into your planning efforts.

Five-Step Process
The five main activities in FDD are performed iteratively. The first is Develop an Overall Model, which initially results in a high-level object model and notes. At your project's inception, your goal is to identify and understand the fundamentals of the domain that the system is addressing, and throughout the project, you'll flesh out this model to reflect what you're building.

The second step is Build a Features List, grouping features into related sets and subject areas. Next, you Plan by Feature, resulting in a development plan, the identification of class owners (more on this in a minute) and the identification of feature set owners.

Roughly 75 percent of the effort on an FDD project is spent in the fourth and fifth steps: Design by Feature and Build by Feature. These two activities are exactly what you'd expect, including tasks such as detailed modeling, programming, testing and packaging of the system.

An FDD project begins by performing the first three steps in the equivalent of the RUP's Inception phase or XP's "iteration 0," aiming to identify the scope of the effort, the initial architecture and the initial high-level plan. Construction efforts occur in two-week (or shorter) iterations, similar to XP, although a little compressed for most RUP projects, with the team iteratively working through all five steps as needed. As with other agile software development processes, systems are delivered incrementally by FDD teams.

FDD Role-Playing
TFDD projects are staffed by six primary roles: Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner and Domain Expert. As you might expect, an individual will take on one or more roles on a project. FDD differs from XP in its concept of an individual class owner. XP includes a practice called Collective Ownership, in which any developer can update any artifact, including source code, as required. FDD takes a different approach in that it assigns classes to individual developers, so if a feature requires changes to several classes, the owners of those classes must work together as a feature team to implement it. FDD also defines a collection of supporting roles, including Domain Manager, Release Manager, Language Guru, Build Engineer, Toolsmith, System Administrator, Tester, Deployer and Technical Writer.

FDD's five steps are supported by several best practices. The first is domain object modeling, the creation of a high-level class diagram and supporting artifacts that describes the problem domain. Developing by feature and individual class ownership are also best practices, as is grouping developers in feature teams. Inspections are an important aspect of FDD, as they are with the RUP. Similar to XP, FDD also insists on regular builds and configuration management. Finally, FDD promotes a best practice called reporting/visibility of results, similar to XP and AM's philosophy of open and honest communication.How would Agile Modeling (AM) be applied on an FDD project? The principles and practices can be clearly applied to FDD's two modeling-oriented steps: Develop an Overall Model and Design by Feature. The only apparent mismatch between the two processes is FDD's practice of class ownership and AM's practice of collective ownership, but I would argue that this isn't a discrepancy: FDD's practice pertains to coding, not to modeling. On an FDD project, people work together in teams to model along the lines of AM's Model with Others practice, and therefore, several people will be working on your shared collection of modeling artifacts. From the modeling point of view, you effectively have shared ownership of your models, but the way you manage source code is another issue.

Feature-Driven Development is a proven agile software development process, clearly a viable option for your organization, and one that you may wish to enhance with Agile Modeling.

Recently on the Agile Modeling Mailing List:
Working with Less Experienced Modelers. A conversation ensued about the issue of novices being involved with modeling. In reality, most teams comprise people with a wide range of modeling skills, so this issue is pertinent to almost every project. To involve novices in modeling, consensus is necessary: Follow AM's practice, Model with Others, to help beef up their skills. Providing people with training is a good start, but it isn't sufficient in itself: They'll still need mentoring by someone with experience in the techniques.

When to Hold a Model Review. This is a conversation that I started, a topic for a future AM newsletter, upon realizing that several of my company's clients struggled with this issue. Opinions varied widely. On communication-rich projects, Extreme Programming (XP) projects stand out, and reviews were seen as providing less value. For communication-deficient efforts, such as those where the customer isn't co-located or the team itself is distributed, reviews were considered quite valuable. Good rules of thumb to help you determine when to hold a model review include: You're at a major milestone, such as the initial identification of your project's scope, you believe you need an outside opinion (for example, an architecture review) to validate your approach, or you need to validate your work to date with a wider range of project stakeholders than those who are actively involved.

Process tailoring. Common advice from process gurus is to tailor your process to meet the needs of your situation. In fact, because the scope of AM is only modeling and documentation, you must tailor it into another process such as FDD, XP or the RUP. The difficulty of tailoring a process when you don't have any experience in it was noted. In fact, the XP community suggests that you first apply XP "straight out of the box" on a project and then consider tailoring it on future projects. One of the principles of the Agile Alliance is that you regularly hold retrospectives to learn from your experiences and to modify your software process accordingly.

Recommended Online Resources:
Agile Alliance Articles.
www.agilealliance.org/articles/index

"Agile Development Joins the 'Would Be' Crowd, by Alistair Cockburn.
www.cutter.com/index.shtml

Agile Modeling Mailing List.
www.agilemodeling.com/feedback.htm

Agile Modeling Training Resources.
www.agilemodeling.com/training.htm

Feature Driven Development.
Peter Coad.
www.togethersoft.com/

Java Modeling in Color with UML: Enterprise Components and Process.
Peter Coad, Eric Lefebvre and Jeff DeLuca. (Prentice Hall, 1999).
www.amazon.com/exec/obidos/ASIN/013011510X/ambysoftinc/103-7190775-8163854

A Practical Guide to Feature-Driven Development.
Stephen Palmer and John M. Felsing.(Prentice Hall, 2002).
www.amazon.com/exec/obidos/ASIN/0130676152/ambysoftinc/103-7190775-8163854