Feature Driven Development or FDD is an Agile development method that I had the pleasure of using on a project.

The methodology you choose depends on:

• Your organizations experiences.
• Your team dynamics and skills.
• And of course how much confidence you have on the selected methodology.

Often I have worked with teams that follow home-grown methodologies that are lite and tuned to what that organization believes is the best way for them to get work done. Fair enough.

I worked on one project a while back that used the Feature Driven Development (FDD) agile process. Personally to me the success of a methodology depends on how simple it is to understand. Software development happens in three main areas: requirement gathering, coding and testing. Everything else is done to support these three related tasks. FDD is a relatively simple process; which is what attracted me to it. And I am living proof that it worked when we used it. Though in hindsight we did not formally follow every step as prescribed.

So what is FDD. FDD is an agile iterative development process. The dictionary defines agile as ‘moving quickly and lightly’. When you hear agile look for that meaning. If you look in your process and you do not see that then you are not in an agile process. Seems obvious ah! You need to change your mindset and work culture to fit agile.Organizations that are not agile often have difficulty moving towards agility. Then there are those that are agile since many years before the buzzword agile development even came along.

Being agile to me does not mean you do away with traditional requirements gathering procedures and mechanisms. You still have to gather detailed requirements. I often see Ruby On Rails developersprescribe that framework as the framework to choose for agiledevelopment of web projects. Look up on that on your own. They have achildish view of the development world where there is no corporatepolitics, there is no need to gather requirements upfront (gather asyou code…best of luck), the business users seem to have all the timeto sit with the developers, etc. The real world is often quitedifferent. Dont get me wrong. I like Ruby and Ruby On Rails. I thinkJava has a lot to learn from there.

FDD is divided into 5 main activities. Each activity encompasses a set of steps that seem so obvious in software development. It does not do away with requirements gathering or any other step. It just places them in the right activity. Here are the five activities and what I think are some of the things

• Develop Overall Model: Work with analysts/business users to get the application domain model defined. Based on the complexity of the application you may divide the project into many sub-domains and create a domain model for each area. You would gather high level requirements and may even be doing some use cases in this phase, though I doubt that will happen this early. Lot of interaction with business users during this phase.
• Build Feature List: Work with project management to define and create the feature list for the current release. The feature list should reflect business users priorities. Features should be as small as possible to implement in terms of time.
• Plan By Feature: Organize your features in terms of priority(related to client needs as well as development). For every feature we capture LOE (level of efforts). Drop your features into interations,each no longer than 4 to 6 weeks in duration. LOE should include design, coding and testing (if possible include reviews). Plan fordropping each feature into a QA test environment. For subsequent iterations (after the first) keep aside some time to fix defects andchanges to earlier iteration. You can even increase by a week or sosubsequent iterations. This filler time you can adjust as needed based on outstanding defect count and change requests.
• Design ByFeature: Developers get your hands dirty now. Draw upclass diagrams, sequence diagrams for current iteration.
• Build ByFeature: Code it and drop iteration into QA enviornment.

One step I feel is missing is a ‘TestBy Feature‘. This is so that the QA teams work can getrecognized as a critical part of development and can be planned inadvance.