Feature-Driven Development (FDD) is an agile approach that does not receive the same amount of attention as the likes of Scrum and eXtreme Programming. While Scrum and eXtreme Programming are very similar in many ways, FDD differs quite significantly to both. What is interesting … well interesting to me as an author of a book on FDD … is the gradual acceptance of ideas similar to those found in FDD as agile teams using Scrum and eXtreme Programming scale up and grow in maturity.
Parking Lot Chart
The first one I encountered was FDD’s so-called ‘parking-lot chart’ popping up in books like Agile Planning and Estimating by Mike Cohn. This is an intuitive, color-coded, snapshot view of the status of a larger, multi-team project or portfolio of projects. It communicates well to the senior management level and nicely compliments the usual release-level burn-down charts.
Architecture is not a sin
Then there is the growing acceptance that it is not necessarily an agile software development sin to have some initial, overall idea about the architecture of the software being developed before starting development iterations. This is especially important when there are multiple teams working on producing a single product or set of integrated products.
Scarce Skills and Feature Teams
Often times a group of teams requires a specific skill for some part of their work - maybe it is knowledge of a specific API, programming language, or a technology. However, sometimes there are fewer people with that skill than there are teams making it impossible to have that skill available on each team full-time. This is something that I have experienced recently.
One way to solve this would be for the team who needs this skill but doesn't have it present to submit a user story to another team that does have someone with that skill. This should set off much needed alarm bells because of the cross-team dependencies such an approach would create, and the delays in waiting for one team to finish work before another could complete theirs. Despite hiding behind agile terms, this approach is no different in essence to the traditional approach of raising change requests for another team.
This situation is somewhat analogous to the code ownership delays that eXtreme programming sought to eradicate by implementing the practice of collective code ownership (balanced by pair-programming and automated unit testing). However, we cannot solve the problem of a scarce skill using collective ownership if there are simply too little of that specific skill in the collective group to have enough for each team.
FDD proposed a different approach to reducing code ownership delays by recognizing that it is not code ownership per se that cause the delays, but the availability of the code owner. FDD’s simple solution was to change from rigid team composition to a more dynamic model it called ‘feature teams’. In this model, team composition changes after each iteration. A feature team is composed of the code owners required for a specific set of features (user stories) in that iteration.
The solution to the recent skills constraint problem on my own teams has been similar. Instead of rigid Scrum teams, at the start of a sprint, those with the scarce skill can transfer to another team that requires their skill during that iteration. This changes the nature of problem. Now instead of having user stories in one team that are dependent upon user stories in another team, we have team compositions dependent on particular resources. This can be resolved by teams coordinating sprint commitments so that only a small enough subset of the teams have work requiring that scarce skill set in any particular iteration.
You can read more about FDD at www.featuredrivendevelopment.org
Comments