A Practical Guide to Feature Driven Development

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.

In the spring of 2001, Peter Coad asked Mac Felsing and myself to write a book about Feature-Driven Development for his new Coad Series published by Prentice Hall.

The book was published in 2002, translated into Chinese, Japanese, and Russian, and is still the only book solely about using FDD. It would have been far, far better if Jeff De Luca had written it but he has always been too busy on other projects. Therefore, with Mac's help, I had a crack at writing up my understanding and experiences of FDD at that point in time.

You can ask questions about and discuss FDD at Jeff De Luca's FDD Community website.

Jeff's company, Nebulon, also provide workshops, mentoring and certification in FDD .

Table of Contents:

• Introduction
• Chapter 1: Process Pride
• Chapter 2: Projects and People
• Chapter 3: Practices
• Chapter 4: Processes
• Chapter 5: Progress
• Chapter 6: Packages
• Chapters 7-11: Five Processes in Practice
• Chapter 12: Technical Architecture
• Chapter 13: Testing
• Chapter 14: Other Surroundings
• Chapter 15: All Change
• References

Some Comments from readers

• I've just finished reading your book. Great reading. It only took me 3 days to devour the information contained in it. We will start implementing FDD right away in my organisation.
  Evanndro Reis, de Software Development Center at Convergys Latin America
  

• I'm finishing reading your book (A Practical Guide...) and already trying some of the processes in a customer. Very useful!
  Adail Muniz Retamal, Professional Services Organization Borland Latin America

• I just finished reading Stephen's and John's book about Feature Driven Development cover to cover as part of my leisure & learn. I found it not only a profound read but also a fun one ... a rare quality in a book dealing with a dry topic like processes.
  Klaus Wenger, Senior Developer, Borland Software Corp.

Book Outline

Introduction

The introduction describes the origins of the Feature-Driven Development process and introduces the key people involved with its beginnings. Read more on this...

The introduction also introduces the example used throughout the book and explains why the authors slip into role playing dialogues every now and again.

The foreword expands a little more on the history and the people involved. The foreword is written by Peter Coad who is also the series editor.

Chapter One: Process: Pride and Pain

Chapter one seeks to answer the question, "Why do we have to manage software development?".

The first half-dozen pages seek to describe how we arrived at where we are today in terms of software development processes. It looks at the rise of so-called heavyweight processes and methods, contrasting that with the recent popular rebellion against them in favour of what we now call agile processes.

The chapter then proceeds to explore the major challenges facing significant software development projects and derives a mission statement and list of values for a good software development process.

The chapter also contains a strong warning about concentrating on process definition and process compliance at the cost of real results.

I actually regret making this the first chapter. If I had my time again, I would probably start with chapter four and work back to the material in chapter one. This way the reader could quickly become immersed in FDD without having to wade through a largely theoretical chapter before doing so.

Being the first chapter I wanted to have a little fun so Tolkien's Lord of the Rings and my favourite poem from my high school days are put to good use to describe process extremes that I have unfortunately experienced both before and since writing the book. Incidentally the Crimea War, of which the Charge of the Light Brigade is a part, is a fascinating subject for those who like military history.

Managing communication, complexity, and quality are the three major challenges listed in the chapter. I have recently added the more nebulous project momentum or, conversely, project inertia to my list. I frequently encounter projects stalled in certain activities unable change gear, or change direction without disproportionate amounts of effort. Analysis paralysis is probably the most infamous, where a project does not seem to be able to get beyond the writing of use case descriptions or functional specifications. Conversely, projects where development succeeds in making it through the first few iterations build a momentum that makes it harder to knock the project off course. In other words, another argument for short value driven iterations like those used in FDD.

An early draft of part of this chapter was published as CoadLetter #84, now archived at the Embarcadero Developer Network.

Chapter Two: Projects and People

This chapter seeks to address the question, "Who do have to manage in software development"?

The chapter first discusses project roles in general.

More on FDD and projects...

It then takes a step back and explores the impact of people on process. It criticises project management approaches and tools that treat people as interchangeable software producing machines. A large sidebar introduces some ideas for attracting, recognising and keeping good developers because good developers can be many time more productive than average developers.

I remain firmly convinced that an organisation is better off working on attracting, recognising, and keeping good people than spending enormous amounts of money and effort on defining and enforcing a mandatory, all encompassing process.

This is not to say that every developer needs to be some sort of superhero-programmer. Often, superhero programmers are poor team players and cause as many problems as they solve. A good developer understands that he or she is incapable of developing the software on their own, values being part of a successful team, and can channel their talents into achieving the success of the team.

More on people and process...

Finally, the chapter reaches its ultimate goal of introducing the roles played in a FDD project.

More on the roles in a FDD-style project...

An early draft of part of this chapter was published as CoadLetter #85, now archived at the Embarcadero Developer Network.

Chapter Three: Practices

Any good process is the cohesive blend of a number of industry best practices, techniques, strategies and patterns. FDD is no exception. FDD includes the use of the following best practices:

• Domain Object Modelling
• Developing by Feature
• Component/Class Ownership
• Feature Teams
• Inspections
• Configuration Management
• Regular Builds
• Visibility of progress and results

Most, if not all, of the best practices in the list have had whole books written on them. Chapter 3 in A Practical Guide... is intended to very briefly introduce each practice and explain just a little why that practice is part of the FDD processes. It is also the first really contentious chapter in the book because it advocates upfront domain object modeling and class ownership; practices that eXtreme Programmers reject, sometimes vehemently. Use case fans may also be disturbed by the lack of a mandatory use case writing activity and the emphasis instead on a hierarchical list of tiny client-valued functional requirements (features).

An early draft of part of this chapter was published as CoadLetter #86, now archived at the Embarcadero Developer Network.

Chapter 5: Progress

Covers the progress tracking built into FDD and the status and progress reporting opportunities that it makes available.

To steer a project, a manager needs to know the current status of a project (where am I), the ultimate end of the project (where are we going) and the velocity of the project (how fast are we moving forward). FDD enables a manager to:

• Define a set of sharp milestones for the development of each feature.
• Assign a percentage weighting of effort to each milestone.
• Add up percentages of milestones complete to calculate the percentage complete for a feature.
• Roll up the percentage complete for all the features in a set, area and project to summarize status.
• Compare with previous results to show progress.
• Collect results regularly to calculate rate of progress.

Some of this chapter was based on CoadLetter #70, now archived at the Embarcadero Developer Network.

Chapter 6: Packages

This chapter explores the principles and practice of tracking and recording low-level requirements, designs and decisions in FDD.

This is my main FDD claim to fame. It was my idea to use card folders to store all the output of a feature team iteration with a cover sheet to make sense of it all. I also worked with our toolsmith, Herman, to produce an initial electronic version. Chief Programmer work packages were especially handy when working on multiple feature teams at one time.

Some of this chapter drew from ideas discussed in CoadLetter #72.

Chapters 7-11 Feature-Driven Development in Practise

Each process in FDD is examined in detail in turn, one process per chapter.

The processes are shown as a UML activity diagram and hints and tips given for every role involved in every step.

Why 3 and only 3 layers in the feature list hierarchy? Well, 20 feature areas each containing 20 feature sets, each containing 20 features is 8000 features or in other words, a very big system by today's standards. Ten areas, each with 10 sets, each with 10 features is 1000 features, a very significant system of the order constructed by the 20+ developers in Singapore over a period of 18 months (total project team size including domain experts, testers and tech. writers, system admins. data conversion team, peaked at about 50). So I think 3 levels is more than good enough in the vast majority of cases. This is especially true if you split features out into UI, PD and SI features as described in A Practical Guide... chapter 12 on Technical Architecture.

Lessons Learnt from Fred was first published as a CoadLetter #40 and I have learnt since writing the book that the forming/storming/norming/performing cycle is orignally the work of Bruce Tuckman.

Chapter 12: Technical Architecture

Seeks to at least partially answer one of the most frequent questions about FDD ... what about architecture?

The software components purchased by the project, any wrapper, adapter and interface code created to reduce the dependency of the system on a specific purchased component, and the patterns used to translate analysis results onto those components.

This needs to be largely in place before starting feature design and implementation iterations. It may be already defined externally to the project or it may need to be defined by a task performed before,  immediately after or in parallel to the initial modelling, and listing and planning of features.

For non-trivical, enterprise system development, FDD projects divide developers into 2 or more sub-teams according to the logical layers required in the architecture.

Chapter 13: Testing

This chapter takes on another of the frequently asked questions about FDD ... Why does FDD not talk about testing?

The aim here is to make formal system and customer acceptance testing a formality recognising that true delivery of a piece of software does not occur on entry but on exit to formal testing.

The idea is to consider quality-assurance throughout the process with an emphasis on making done truly mean finished to the required standard of quality to pass formal testing.

This emphasis enables testing to move earlier into lifecycle and look more like what some are starting to call agile-testing.

Part of this chapter also talks through another favourite topic of mine, the difference between software failures and software defects, the relationship between them and between them and software fixes.

Chapter 14: Documentation, Data-Conversion and Deployment

Requirements Change Management: If features increase by 10% either scope, schedule or budget will have to give by 10% to compensate.
Up to 10% can usually be absorbed without too much extra effort.

End User Documentation:

Look to:

• Embed helpful information into spare space and panels in the user interface so that it is immediately available to a user.
• Use tooltips/flyover help to display truncated information in full, to explain icons and to briefly display more pertinent details of items quickly.
• Ensure information/warning and error messages are helpful and have an easy to use mechanism to display further explanation of the message including examples.
• Check context sensitive help is written at a useful level of granularity.
• Enable on-line guides and tutorials to easily be published as printed manuals.

Data Conversion:

Look for:

• Business data
• Reference data
• Configuration data

Clean data at the source; do not propagate data errors and omissions.
Convert paper-based data into an intermediate electronic form in parallel with feature development and create programs to convert to final electronic form once all required features are complete.

Deployment:

Start it early. Practice on partial systems, creating pilot schemes. Repeat training at regular intervals adding new training on new features.

Chapter 15: Adopting Feature-Driven Development

Briefly discusses handling change. Change is emotional, causes stress, and is often introduced based on a naive mental model of change. Much of this final chapter is the work of my co-author, Mac.

Knowing more about introducing change enables us to introduce FDD more easily.

References

The usual list of books and web sites referred to within the book. Browse a hyperlinked version here.