Exploring the Subtle Differences Between Agile Paradigms

[article]

until the project is complete. The last 2 steps are considered the "construction phase". Of course if the first three steps need to be revisited in the middle of the project, the agile spirit of FDD considers this necessary. The image below illustrates the process.

na0610-1

 

Step 1 "Develop an overall model" asserts that a project should spend sufficient time developing a domain model for the problem attempting to be solved. This borrows elements from domain-Driven design, and well as traditional object modeling. This exercise facilitates understanding between managers, business members, and developers. It also well defines the problem and domain.

The most homegrown characteristic of FDD is the concept of a feature. A feature is defined as a bite size chunk of functionality that is described in compact form, preferably in one sentence. The requirements aspect of FDD is focused on features and is most relevant in step 2 "Build a feature list." Analysis and communication must be done with a customer to generate a feature list which is of course full of features. Each feature should follow the template

[action][result][object]
Example features are:

  • Calculate the total amount of a Sale
  • Display the history of all user comments

Feature-Driven Design blends aspects of several agile methodologies to form a simple yet effective model for constructing complex software. The well defined concept of a feature breaks requirements down into manageable portions and allows for customer input on priority and feedback. Many tools exist centered around management of requirements in the form of features and can be used to effectively run a project.

Conclusion
Although the various agile paradigms may sound the same initially, there are subtle differences to each once the details are explored. In my experience, if a project has mindfull team members that are familiar with one or more of these approaches, various practices and principles are adopted within the project. Rarely does a project purely and dogmatically adopt one single approach. Most of the time various team members bring a variety expertise and experience, thus the project becomes an amalgamation of several methodologies, but still upholds the agile spirit.

To be more concrete, early in my career I was on a small project that first explored agile principles. Feature-Driven Development was the approach that most fit our goals and we followed the process. However, as we learned more about various approaches such as Domain-Driven Design and Test-Driven Development, we integrated practices such as maintaining the domain model and a test first development strategy. In fact the whole project was done under the umbrella of RUP, the Rational Unified Process, which is a more traditional methodology! Thus you can see that each project should consider its own needs and adopt what is best for success.

What practices have you used on your projects? Which ones do you find the most effective?

References
Presentation - Plano Java Mug - Sept 12, 2009
Clearing the Mudd

DDD
Layered Architecture
Domain-Driven Design Community

FDD
Feature-Driven Development Overview Presentation

BDD
What Drives Design

About the author

Nirav Assar's picture Nirav Assar

I am a software consultant in the DFW area. I specialize in web application development for enterprises, along with agile consulting practices. Grails, Groovy, Java, Spring and Hibernate are my specialty areas in technology. In the Agile spectrum I have run teams with XP, Scrum, and UP methodologies. I am interested in providing high value to business groups, with the most effective and latest technologies available.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!