In an eight-page interview with Stefan Roock, Jeff De Luca, who created and documented Feature Driven Development, discusses developing an overall model, code ownership, choosing an agile method, and more.
Developing an Overall Model
Contrasting feature-driven development with other Agile methods, Jeff says the initial phase of FDD (Develop an Overall Model) allows project teams to come to grips with the overall project such that they can answer questions like, "How much of the project is left?":
If we are too pure in our iterative/incremental approach - that is we are also slicing through requirements and analysis - then of course it is hard for us to answer the questions "How far along are you?" and "How far is there left to go?" because we haven't even looked across the rest of the requirements yet. So, there has to be some informational/analytical activity at the start to give us the knowledge to set a baseline that we can track and report against so that we can answer those questions. FDD is the only agile method that gets this part right.
Addressing the idea that this phase can be seen as Big Design Up-Front (BDUF):
Not "all of the design up front" as the pejorative use of BDUF has come to mean - but "just enough design" and note that this first activity in FDD is as much about requirements and requirements analysis as it is about high-level design.
Code Ownership
Jeff De Luca also takes a strong stand against collective code ownership:
Collective ownership is code for "no ownership". It's not a structure I believe in.
And in favour of individual code ownership:
The concept of module or component ownership has long been practised and long been known to be a best practice. That's how all professional development at scale is done. Everyone can't know everything about everything - that is brittle and it can't scale.
And what's especially ironic about this is that one of the fundamental principles of OO is encapsulation; how a class does what it does is private and internal to that class and those implementation details can vary wildly as long as the class presents a consistent interface to the rest of the world (the other classes). Well, humans naturally encapsulate. If you practice class ownership you get much better consistency of implementation and interface.
Although he tempers that stance with:
Class ownership is not a life sentence. If you get the Customer class you're not stuck on Customer forever. These owners can and do change throughout a project.
Choosing an Agile Method
Jeff De Luca takes a pratical approach to choosing an agile method, when talking about the different agile methodologies and their suitability to different kinds of projects:
I don't think the Agile methods classify ... by project type. When it comes to this sort of thing I tell people to get Jim Highsmith's Agile Software Development Ecosystems book. That's the only book that talks about all the Agile methods, in some detail, in the one book. You read that book, and one or two of the methods are going to resonate with you and your team. And whichever methods those are, they are the ones you should explore. In other words I'm saying that the Agile methods are more suited to types of people and organisational cultures than types of project.
The interview ends with references for further reading on FDD.
For more information these topics, consider reading InfoQ's coverage of agile methods, feature-driven development, and modeling.
