Musings on project management: Did you remember FDD?

Thursday, August 27, 2015

Did you remember FDD?

Stuck on stories? (As a user, I want to .... etc ). Maybe you're stuck on who the user is, especially if it's a system actor.

How about features? They're not stories in the SCRUM story sense, but useful nonetheless. How about FDD as a feature driven methodology? Mike Cohn at mountaingoat software has some similar thoughts about FDD.

Recall the feature syntax:

Action ... do onto an Object
Object .... which by the Action, returns a Result
Result ... you did something to an object and this is what you have as a memorial

Oops! This is all strange stuff? Read my whitepaper on slideshare.net.

The one thing I've always liked about FDD is its emphasis on a domain model, which for all practical purposes is architecture. This is step one of the FDD process:

Do the model -- what objects, what actions, what results?
Build a features list (did someone say backlog?)
Plan the release (but not by time boxes; there are no time boxes, so more conventional planning is required)
Design by feature
Develop by feature, where develop includes all the testing steps

Unlike some other Agile methods, FDD practices are built around feature teams that are charged with delivering certain backlog (features: action, object, result). And the teams work to more conventional schedules (no time boxes) but still deliver stuff early and frequently, just like other Agile practices.