Feature Driven Development

This is a recently updated set of slides I use for 60-90 minute FDD overview presentations. These replace the older set at nebulon.com and elsewhere on the web.

Hi

I'm working with an organization at the moment that is trying to apply agile software development principles across large programmes of projects. They are mainly using Scrum with a few ideas borrowed from XP and, on the whole, it is working well for them when applied to individual teams working on a particular application.

The big business win for this organization is not the development of individual applications but the ability to integrate these applications to deliver new products to the market place quickly. Service-oriented architecture and web services are seen as the technical solution to this, and where each application that needs to participates in the solution already exposes suitable services, this works reasonably well.

The latest draft FDDI spec for public review.

Context:
- Software requirements/elements (features/classes) are tipically modeled either as a hierarchical set of components (FDD: Major feature set, Feature set, Feature) or as UML diagrams. None of these models can directly expose the relation/difference between functional and non functional requirements/elements. (Note: I do not know any methodology where "technical"/"business" would be base terms, eg. first class citizens.)
- Meanwhile many software projects are dealing with key/innovative and/or complex technologies. Thus I would say that non functional- or technical requirements may be good candidates for being managed components...

Hey Guys,

I've managed to find myself in charge of a product development team. We really need to have a bit of structure to the development process, especially around Progress reporting.

I've worked with Jeff and Paul on FDD at a large bank, so I like the process, but the milestones and granularity we used there, won't really apply to our product. For instance, we're spread all over the world so sit down code and design reviews are hard. But also, unlike the bank, we shuffle priorities around quite a bit, based on user feedback.

What I could probably do is break each release (quarterly or monthly depending on the situation) into a series of 'features'. These would probably a bit more granular than traditional features, but still able to group into work packets of a week or so's work.

My company is looking at a potential project that involves converting a fairly large Oracle Forms application to J2EE. Given the size of the application what we have suggested is that we spend a week to learn their application. This will be followed by three weeks of HLD which will involve the following
- Develop an overall Feature Breakdown Structure
- Develop a high level object model of the overall application

This will be followed by a detail design phase of two weeks for the features that will be tackled in Phase-1. Phase-1 will comprise 3 iterations, each about 3 weeks long.

Does the group have any advice on how to approach the HLD phase such that we can get a high-level overall object model without trying to get into details ?

How do people manage creativity and creative types on projects? How do you identify it, capture it, encourage it, contain it, reward it? Creative people have a reputation for being difficult to manage - do you have particular experiences that shed light on this? What sort of project environment works best? How does the software process help and/or hinder creativity in your experience?

These photos show the How To Design/Deliver Better Software Using FDD workshops in Wellington, New Zealand November 21-24 2005.

Nice place, nice students, nice teacher.

Thanks a lot Jeff!

What are the books on Jeff's A-shelf? In response to possibly the number 1 FAQ from the FDD workshops I have created a new books page on the FDD website.

The Logic of Failure author: Dietrich Dorner asin: 0201479486 binding: Paperback list price: $19.00 USD amazon price: $12.92 USD

Subtitle: Recognizing and avoiding error in complex situations.

I haven't read many great books for a while and so it was a real joy when I bought this one. An excellent book with many lessons in it and again, not based on speculation but on research, measurement, experimentation and analysis. From one of the studies: "the good participants made more decisions than the bad ones," "both the good and bad participants did not differ in the frequency with which they developed hypotheses," "the good participants differed from the bad ones however, in how often they tested their hypotheses."