Feature Driven Development

Hey Koz,

sure all this is very do-able. In fact it's common. I'll try and tackle all your different issues.

Reviews/Inspections.

First, it's not that hard to do reviews across different geographies. There's a lot of technology ways to approach that; even just basic technologies and a process will do it.

If you can, go for real time. That is, all the different parties are connected and are doing the review at the same time. There's a lot of technology options here - although I must say NONE are great. IBM had something out for OS/2 2.x (a long time ago) that was good and I've not seen something as good since. Sadly, I can't recall the name of that software right now... anyway it was a shared whiteboard, shared screen, chat and also multiple realtime pointers (hands pointing they were) with each person's name labelled. Anyway, there is a ton of similar online stuff around but nothing I've seen that has got the feature mix right (and that especially includes the overhyped Groove). Scaling down from a so-called integrated tool that does all this, a multi-party audio iChat (audio conference using your favourite chat software or skype or similar) along with a text chat is a solid base to work from. I find you definitely need both so someone can copy/paste a code fragment into a text chat window to illustrate a point.

You could even easily mimic what Paul does with paper. i.e. print the code out 2-up with line numbers and then highlight the changed line numbers. That you could easily replicate by printing to a PDF and then annotating the PDF with highlighter.

Finally, you could even do the review disconnected. i.e. e-mail the review materials to the participants and collect their review comments independently and then you do the consolidate and merge.

I know that might sound not so good but you'd be surprised how well it can work. Richard Gabriel in his excellent Writer's Workshop book talks about (of course) Writer's Workshops which are highly interactive and all people are in the same room at the same time. I took that process and adapted it for a review by e-mail to multiple people and it worked BEAUTIFULLY for me. Of course, it wasn't a straight mapping from a real writer's workshop to this e-mail review (and that is the art) but it did work out really, really well for me.

In all cases you need to think about the process for making this work and then document and communicate it to the rest of the team. i.e. the reviewers need to prepare slightly differently - in tune with the way you will do the review. i.e. in a face-to-face meeting I can get away with making all my comments on my copy of the review materials. For a review via iChat or e-mail I want to type in any code fragments or examples I want to use to illustrate a point and have them ready BEFORE I attend the online review. Then I can just copy/paste into the chat window from my "code fragments" file. Anyway, I'm sure you get the idea by now.

Shuffling Priorities

But also, unlike the bank, we shuffle priorities around quite a bit, based on user feedback.

Hmm, well ignoring that specific customer as they're not a useful baseline, it's my experience that shuffling priorities is the norm. I don't even think this fits the "product development" vs. "in-house development" models as it depends on what sort of product development (for example). e.g. doing product development at an IBM programming lab on operating system and associated program product work, there's very little change to features once you get to the stage of feature breakdown. However, there are other firms doing product development that are much more exploratory or reactive or unplanned and in those cases there can (and will be) a lot of change. Anyway, the point of all that is to say that unless you define better what you mean by re-prioritisation I don't immediately see it as being different; I see it as the norm.

Custom Milestones

We'd also need some custom milestones. Something like Design, Code, Unit Test, Commit, Deliver.

Easy. Custom milestones are the norm anytime you're using an Aspect other than PD or SI or you want to modify the milestones for those Aspects.. Search here for threads on Project Aspects. Here are two: link1, link2. Simply define what you want to track, what milestones make sense for those trackable items and then plug in the percentages for the milestones. If you don't know what the percentages should be, then measure for the first few weeks and then plug them in. Of course, you MUST have FDD-style granular features to be able to measure and get numbers in such a short timeframe.

Adding Unit Test as a milestone (as you've written) is easy and not uncommon. It's something that is often misunderstood about FDD. Unit Test is FULLY part of FDD and is a MANDATORY step in Build By Feature. It isn't used as a tracking milestone because they must be strictly sequential for the percentages and reporting to work. Since they must be sequential I did not put Unit Test as a tracking milestone because I don't want to mandate WHEN unit test should be performed. IOW - some do it before coding, others after, others overlapping with, and so on. I don't want to lock in one and only one way to approach this so that's why it isn't a milestone. However for any organisation or team that have standardised on when they do Unit Test then you can very easily make it a milestone. There's a comment here that discusses a company in the USA that did just that.

Coarse vs. Granular features

I'm a bit confused by your post. Here you say

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.

Which talks about features that are more granular. And then here you ask

Any guidance for me? Has anyone used FDD with slightly more coarse features...

Which talks about coarse features.

Anyway, granular features is the key and you always want the features to be as granular as possible. i.e. FDD-style.

Hope that helps,

Jeff