An Overview of Feature-Driven Development (FDD)

Feature-Driven Development (FDD) is Jeff De Luca's pragmatic, agile approach to developing software. It combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership. When performed properly, it also happens to be one of the most satisfying ways of working in a software development team that I have experienced.

Feature-Driven Development comprises five processes, each described on no more than one double-sided letter-sized (A4/B4) piece of paper.

More on the Five FDD Processes...

Agile does not equal Scrum and/or Extreme Programming

Recently a number of major organisations have decided to adopt agile processes with good results. Others have found that deciding to adopt an agile approach is not a guarantee of success and can be used as an excuse by immature development teams to deliver badly designed, poorly tested, undocumented software.

Other organisations have chosen to adopt more formal, traditional, software engineering processes. While some of these organisations have had significant success, others have found their teams bogged down in the production of large specification documents, or delivering software that is not what the client needs or expected.

No process can guarantee success but the disciplines imposed by FDD can help where other agile processes are insufficient or are simply too extreme to be a good fit for an organisation. It can also help where the delivery cycle times of more traditional processes are too long or the process is simply not flexible enough. However, FDD is not a silver bullet. It can never replace a good team of people.

More about Process and People...

Project Roles on a FDD Project...

JEDI not BDUF

FDD differs from Scrum and eXtreme Programming, the two most popular agile approaches, in demanding that just enough effort be invested at the beginning of the process in exploring the structure of the problem usually by building an object model of the problem domain. This model has just enough detail to form a shared understanding, vocabulary, and conceptual framework for the project.

Rather than the derogatory BDUF (Big Design Up Front) term, I call this the Jedi approach (Just Enough Design Initially) to analysis and design. Knowing how much is 'just enough' is obviously the key and usually takes real experience (just as in the StarWars movies, you do not become a Jedi Master overnight!).

More about object modelling...

Best Practises that form part of FDD...

Code Ownsership and Feature Teams

FDD also differs in assigning ownership of code to individuals instead of the collective ownership practised in eXtreme programming. Individual code owners dynamically form small teams called feature teams to design and implement a feature under the guidance of a lead developer (chief programmer). This self-organising approach of dynamic teams addresses the problems that require collective ownership in other processes while retaining all the tried and trusted benefits of code ownership, and enabling FDD to scale to larger team sizes.

More about feature teams...

Quality by Inspection ... and Testing

While not belittling the role of testing in the slightest, FDD recognises that peer reviews or inspections are a better means of removing defects and have significant secondary benefits.

Some of the challenges of running effective peer reviews are reduced by the feature team ownership. In a design or code review in FDD it is not just one person's work being reviewed but work owned by a feature team. This is far less intimidating than being the only one on the hot seat which can prevent general acceptance of the practice by developers. Within reasonable bounds, the level of formality of the inspection is the feature team's call. For complex or high-impact features, the team's chief programmer will want to involve other members of the wider team. For straightforward and low-impact features only the feature team members need be involved, reviewing each other's contribution to the feature's implementation.

More about FDD best practices...

Park Your Progress Here

Like peer inspections, another key aspect of FDD is the ability to provide accurate, meaningful, and timely progress information to all stakeholders wihtin and outside the project. While a colour-coded status of each feature in the feature list displayed on a suitable wall communicates well within the team, the level of information is too detailed to use when communicating with the executives of a leading regional bank, for example. For this Jeff De Luca adapted a chart being used by a traditional waterfall team. It and other derivatives have become known popularly as the 'parking lot charts' which sounds so much cooler, for some reason, than the British equivalent name which would be the 'car park chart!.

More about FDD progress tracking and reporting...