The New Methodology

　　Feature Driven Development

　　Feature Driven Development (FDD) was developed by Jeff De Luca and long time OO guru Peter Coad. Like the other adaptive methodologies, it focuses on short iterations that deliver tangible functionality. In FDD's case the iterations are two weeks long.

　　FDD has five processes. The first three are done at the beginning of the project.

　　Develop an Overall Model
Build a Features List
Plan by Feature
The last two are done within each iteration.

　　Design by Feature
Build by Feature
Each process is broken down into tasks and is given verification criteria

　　The developers come in two kinds: class owners and chief programmers. The chief programmer are the most experienced developers. They are assigned features to build. However they don't build them alone. Instead the chief programmer identifies which classes are involved in implementing the feature and gathers their class owners together to form a feature team for developing that feature. The chief programmer acts as the coordinator, lead designer, and mentor while the class owners do much of the coding of the feature.

　　Until recently, documentation on FDD was very skimpy. Finally there is a full book on FDD. Jeff De Luca, the primary inventor. now has an FDD portal with articles, blogs, and discussion boards. The original description was in Peter Coad et al's UML in Color book. His company, TogetherSoft, also does consulting and training on FDD.

　　DSDM (Dynamic System Development Method)

　　DSDM started in Britain in 1994 as a consortium of UK companies who wanted to build on the RAD and iterative development. Starting with 17 founders it now boasts over a thousand members and has grown outside its British roots. Being developed by a consortium, it has a different flavor to many of the other agile methods. It has a full time organization supporting it with manuals, training courses, accreditation programs, and the like. It also carries a price tag, which has limited my investigation of the methodology. However Jennifer Stapleton has written a book which gives an overview of the methodology.

　　Using the method begins with a feasibility and a business study. The feasibility study considers whether DSDM is appropriate to the project at hand. The business study is a short series of workshops to understand the business area where the development takes place. It also comes up with outline system architectures and project plan.

　　The rest of the process forms three interwoven cycles : the functional model cycle produces analysis documentation and prototypes, the design and build cycle engineers the system for operational use, and the implementation cycle handles the deployment to operational use.

　　DSDM has underlying principles that include active user interaction, frequent deliveries, empowered teams, testing throughout the cycle. Like other agile methods they use short timeboxed cycles of between two and six weeks. There's an emphasis on high quality and adaptivity towards changing requirements.

　　I haven't seen much evidence of its use outside the UK, but DSDM is notable for having much of the infrastructure of more mature traditional methodologies, while following the principles of the agile methods approach. There does seem to be a question on whether its materials encourage more of a process-orientation and more ceremony than I would like.

　　The Manifesto for Agile Software Development

　　With so much similarity between these methods, there was a fair bit of interest in some form of collaborative work. As such representatives from each of these methodologies were invited to a two day workshop at Snowbird Utah in February 2001. I tagged along, without much expectations. After all when you put a bunch of methodologists in room, civility is usually the best you can hope for.

　　As it turned out I was surprised. Everyone was conscious of the fact that there was a lot of common ground, and this recognition was much greater than the differences between the processes. So as well as some useful contact making between the process leaders, there was also the idea to issue a joint statement - a call to arms in favor of more agile software processes. (We also agreed to use the term "agile" to refer to our common ideas.)

　　The result is a Manifesto for Agile Software Development, a statement of the common values and principles of agile processes. There's also a desire to collaborate further in the future, to further encourage both technologists and business people to use and require agile approaches to software development. There's a software development magazine article that is a commentary and explanation of the manifesto.

　　The manifesto was just that, a publication which acted as a rallying point for those who shared these basic ideas. One of the fruits of the effort was to create a longer lived body, the Agile Alliance. The Agile Alliance is a non-profit organization that seeks to promote knowledge and discussion of all the agile methods. Many of the agilist leaders that I've mentioned here are members and leaders of the Agile Alliance.

　　Context Driven Testing

　　From the beginning it's been software developers who have been driving the agile community. However many other people are involved in software development and are affected by this new movement. One obvious such group is testers, who often live in a world very much contained by waterfall thinking. With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear.

　　As it turns out, several people in the testing community have been questioning much of mainstream testing thinking for quite a while. This has led to a group known as context-driven testing. The best description of this is the book Lessons Learned in Software Testing. This community is also very active on the web, take a look at sites hosted by Brian Marick (one of the authors of the agile manifesto), Brett Pettichord, James Bach, and Cem Kaner.

　　Is RUP an agile method?

　　Whenever we start discussing methods in the OO arena, we inevitably come up with the role of the Rational Unified Process. The Unified Process was developed by Philippe Kruchten, Ivar Jacobson and others at Rational as the process complement to the UML. RUP is a process framework and as such can accommodate a wide variety of processes. Indeed this is my main criticism of RUP - since it can be anything it ends up being nothing. I prefer a process that tells you what to do rather than provide endless options.

　　As a result of this process framework mentality, RUP can be used in a very traditional waterfall style or in an agile manner. So as a result you can use RUP as a agile process, or as a heavyweight process - it all depends on how you tailor it in your environment.

　　Craig Larman is a strong proponent of using the RUP in a agile manner. His excellent introductory book on OO development contains a process that's very much based on his light RUP thinking. His view is that much of the recent push to agile methods is nothing more than accepting mainstream OO development that's been captured as RUP. One of the things that Craig does is spend the first two or three days of a month long iteration with the whole team using the UML to outline the design of the work to be done during the iteration. This is not a blueprint that can't be deviated from, but rather a sketch that gives people a perspective on how things can be done over the iteration.

　　Another tack at agile RUP is Robert Martin's dX process. The dx process is a fully compliant instance of RUP, that just happens to be identical to XP (turn dX upside down to see the joke). dX is designed for folks that have to use RUP, but want to use XP. As such it is both XP and RUP and thus a good example of the agile use of RUP.

　　For me, one of the key things that needs to happen with RUP is that the leaders of RUP in the industry need to emphasize their approach to software development. More than once I have heard people using RUP who are using a waterfall style development process. Due to my contacts in the industry I know that Philippe Kruchten and his team are firm believers in iterative development. Clarifying these principles and encouraging agile instances of RUP such as Craig's and Robert's work will have an important effect.