A brief story of the origins of Jeff De Luca's Feature-Driven Development (FDD) process.

Like many of the early agile development approaches, Feature-Driven Development (FDD) evolved out of a real need on a real software development project. The project in question was a significant project automating the application for, approval and implementation of consumer, commercial and corporate loans in a leading regional banking group in South East Asia. The project included compliance with stringent regulations on lending and exposure to groups of borrowers, integration with multiple, back-end, legacy systems and the provision of high-level, management information functions, in addition to front and back-office process automation.

It seems a long time ago now but back in October 1997 in an office block in Tiong Bahru, Singapore, the development team had just finished an awesome month with 1990's object-oriented analysis and design expert, Peter Coad. During that month, we had built an initial, overall object model of the complex problem domain for the system. Now the team needed a process to guide them through the low-level design and implementation of the required system features. A small committee comprising some of the business analysts/domain experts and lead developers on the team had a crack at defining one. However, this failed to reach consensus on an approach. Therefore, Jeff De Luca, the project manager and project's technical architect, took on the task himself.

Both Peter and Jeff agreed that the best way to develop software like this was iteratively, feature by feature. Peter advocated a particular template for naming features. He also had a catalogue of some strategies on the topic in his books, Object Models: Strategies, Patterns, and Applications and Java Design: Building Better Apps and Applets. These ideas gelled with Jeff's extensive experience with all sorts of software development teams and projects.

What Jeff came up with was a set of five processes, each described very simply, covering:

  1. the building of an overall domain object model to understand the problem domain and establish a vocabulary and conceptual framework for the project
  2. creating an initial overall list of features for the project
  3. creating a high-level, initial overall schedule and resource allocation for the project
  4. designing a feature from the feature list>
  5. implementing a feature from the feature list

The modelling process (#1) described the approach Peter Coad had used during the initial object modelling session. Jeff had set Peter the unenviable task of not only producing a good initial, overall model of the problem domain but also teach and coach a group of us in object modelling strategies, patterns and technique so that we could absorb and continue to develop the model. However, that was not all. In addition, Jeff wanted Peter to transform the recently-formed group into a cohesive, effective team. The iterative workshop style sessions Peter used to achieve these three goals remain a significant highlight of my career. The format of the workshops and the 'modeling in color' technique that originated from them was 'bottled' (turned into a product) and offered as the 'How To Build better Object Models' course by TogetherSoft until it was bought by Borland in 2002.

The second process incorporated Peter Coad's feature naming template. The template combined with the vocabulary (ubiquitous language in DDD terms) established by the object modelling, provides strong hints on the placement of responsibility and the naming and parameters of operations in object-oriented or service-oriented software.

Quality, both behavioural and compliance with best practise, is provided by a combination of testing and peer inspections. Unit and feature level testing is almost assumed with ample room within the process definitions to apply Test-Driven Development concepts and automated testing frameworks like JUnit. FDD mandates peer inspections but theses are more effective than I have ever experienced because they are applied within the context of a feature team.

Like most of the team, all of the above practises, I had experienced in some shape or form previously. What was completely new to nearly all of us on the project was the idea of feature teams. FDD uses feature teams to organise project members in a dynamic and fluid way. Feature teams design and implement software feature by feature but retain the benefits of code ownership. In contrast, extreme programming projects practise collective ownership instead of code ownership to achieve the same goal.

Paul Szego, Phil Bradley, and I helped add and refine one or two small details as we applied the processes on a day-to-day basis over a period of nearly two years. Paul refined the thinking behind feature team areas and I refined the ideas behind Chief Programmer work and design packages . Phil's unique insights and thinking changed my perspective on more than one occasion, helping me to look at problems differently as we tried to apply FDD each day.

Given the above, I am not happy with the marketing blurb that ended up on the back cover of my book, A Practical Guide.... The statement listing myself as one of the creators of FDD overstates my role. I would not call myself an inventor or creator of FDD. That accolade belongs to Jeff De Luca with full acknowledgement of Peter's contributions and influence. Jeff and Peter's kind acknowledgement of my 'significant contribution to the development of FDD' in their book, Java Modeling in Color with UML is closer to the mark but, if I am honest, still an exaggeration.

Jeff and Peter collaborated on the 'modeling in color' book to include the first description of FDD in print in Chapter 6. To fit more tightly with the 'modeling in color' technique that forms the subject of the rest of the book, Peter tailored a little the versions of the five FDD process descriptions in that chapter. As a result, they are not quite as generic as the original process descriptions. Prentice Hall published the book in 1999.

In 'A Practical Guide to ...' I returned to a more general description decoupled from 'modeling in color' (although still fully recognising 'modeling in color' as an unsurpassed technique that complements FDD beautifully).

Jeff maintains the definitive set of FDD processes on his Nebulon website. Whichever precise wording you prefer, the overall intention is the same.

Since the Singapore project, FDD and FFD-inspired processes have been used on significant projects all over the world, in all sorts of business domains from telecommunications to banking to software tools. The parking lot chart has popped up in Mike Cohn's book, Agile Estimating and Planning and FDD has clearly been an influence David Anderson's Kanban approach. This is not surprisingly because David was the user interface design lead on the Singapore project and part of the initial object modelling group with Peter Coad. David has introduced FDD-style processes at Sprint and 4thPass (now part of Motorola), and worked on the agile process framework at Microsoft, before devising his Kanban approach at Corbis.

While extreme programming, scrum, lean, and kanban slog it out for the limelight in the conferences and on the web forums, Jeff and Paul Szego have continued quietly to apply FDD successfully on projects around the world in Australia, New Zealand, the UK, Germany, and the USA.

After teaching and applying FDD at TogetherSoft for a couple of years, and subsequently working on a couple of projects under the influence of extreme programming, I now find FDD increasingly informing my work with scrum-based teams in UK and continental Europe.

Disclaimer: the preceding is accurate to the best of my knowledge and memory. I have not been party to all discussions between Jeff, Peter, Paul and David then and since. Nor was I inside Jeff's head as he put the original FDD processes together. Therefore, I sincerely apologise to all involved for any errors in attributing credit and any other inaccuracies or misunderstanding on my part.

Follow me on Twitter...