Feature Driven Development

De Luca on FDD Newsletter Issue 3

The Problem Word for all Programmers

Finish (n) The last stage, the termination, the conclusion, the end.

Finish (v) 1. Bring to an end, come to an end of, go through thelast stage of. 2. Bring to completion; make or do completely;complete.

Finished (ppl, a) That has been finished; ended, completed.

The New Shorter Oxford Dictionary, Volume 1, 1993.

I can't tell you how many times as a project manager or a development manager I've gone to a programmer and asked the question "Are you finished?" and I get the "Yes" response. Then I generally follow that up with a qualifier, something along the lines of "so that means you have nothing left to do then on this feature?" to which I get a reply that goes something like "well, I just have to add these last few attributes..." or "well, I just have to run these last few unit tests again..." or "well, I just have to..."

Now I don't believe it is malicious when you get this response. I believe the problem is really one of definition. It is an important task for any project manager to establish an explicit and unambiguous definition of what it means to be finished, and clearly communicate that definition across the entire project team.

"Milestones must be concrete, specific, measurable events defined with a knife-edge sharpness."

"A programmer will rarely lie about milestone progress, if the milestone is so sharp he can't deceive himself."

Frederick P. Brooks, The Mythical Man-Month.

Such a sharp milestone is much more than just a milestone name. In Feature Driven Development it is the set of processes, their focus, their explicit entry and exit criteria and the selection of the feature milestones that make for this.

In Feature Driven Development there are six explicit milestones that we track for each and every feature in the feature list. Those milestones are:

• Domain Walkthrough
• Design
• Design Inspection
• Code
• Code Inspection
• Promote to Build

The Promote to Build as an explicit milestone at the end, is our knife-edge sharp definition of finished. If the feature isn't in the build then it isn't finished and to get into the build it must have have passed the previous five milestones.

Furthermore, the first three milestones come from the Design By Feature process and the last three milestones come from the Build By Feature process. Each process has explicit entry criteria and explicit exit criteria. You can't get into the process without satisfying the entry criteria, and you can't get out of the process without satisfying the exit criteria.

Thus, it is absolutely crystal clear when a feature is finished. The definition is so sharp that a programmer can't deceive himself when asked "Are you finished?"

As a project manager, you need to go out of your way early in a project to imprint this definition on your team. There's a lot of years of "finished abuse" out there amongst your people and you need to actively imprint this sharp definition across your team and break them of this "word abuse" habit.

I teach my people about this problem before we start and then I explicitly ask the "Are you finished?" question, often, early in a project. When I get a "Yes" response that should have been a "No" I first restate the sharp definition of finished. This gets the person to see for themselves that they are not finished. Then I explain to them how it is anything but helpful to me to be told something is finished when it actually isn't. People want to be helpful. They want to say what they think you want to hear. They want to say "Yes, this is finished." As a project manager, this is a behavior you need to correct and Feature Driven Development through its processes and milestones gives you the knife-edge sharp definition that solves this problem.