Feature Driven Development

What is it about the white paper on uidesign.net that you do not consider "concrete"?

I also covered this same material, but in short form, in my book, "Agile Management for Software Engineering". It's been an on-going piece of work over the last 4 years.

For the most recent rendition of this material see my paper presented at Larry Constantine's ForUse2003 conference, "Lean Interaction Design and Implementation: Using Statecharts with Feature Driven Development". The paper is available in PDF from agilemanagement.net.

As the "UI guy" on the original "Singapore Project" I very much consider what I publish on UI Features to be "concrete". These techniques are in use at Sprint (a large telecom company in the USA) and Motorola (a large cellphone manufacturer). The examples in the ForUse2003 paper are real examples from a real product sold by Motorola and installed at 7 mobile phone operators around the world.

I understand that approaches to UI Features used in Australia may differ. It's a big question whether we view FDD as a museum piece - a documentation of the process used on a large banking project in Singapore - or as a living breathing thing which is actively evolving in some of the biggest commpanies in the world. If it were the former then the original UI processes from Singapore have never been documented. There is a reason for this - Jeff and I agreed that the UI processes were not mature enough when we parted company in 1999. The "High Level Design" (the UI design) and "Low Level Design" (the UI code design) processes were not sufficiently mature - just look at the names. I later matured these processes to my satisfaction working with Brian O'Byrne in Ireland on a project for what is now Vodafone Ireland during the summer of 1999. That led to the uidesign.net white paper and directly to the JStateMachine framework now sold by Statesoft. JStateMachine is to UI Features what Together is to PD Features.

FWIW, I feel that my ForUse2003 paper represents state-of-the-art material on how the principles of FDD are being used for UI design, UI development and implementation - whether or not this community considers it "part of FDD" or not.

Regards,

David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/

The feature naming template, first suggested by Peter Coad, is gold and we've taken it and found several ways to get great benefit from it (communicability and value, method placement and method naming). The feature naming template is important. The templates for subject areas and business activities (major feature sets and feature sets in the books) are not that important. They were last minute suggestions when JMCU was written since we felt it was better to offer something since we had a template for feature naming. So, I wouldn't be concerned that you see some naming differences for these - it is not important.

Regarding FBSes for other application layers, these four layers represent the way applications are architected and separated. Prior to hiring Pete Coad I called these presentation, logic, data and comms. Pete used HI, PD, DM and SI. When I hired Pete I chose to use his notation and naming etc. for everything. It didn't matter what it was just that there was only one across the project. I've used those names ever since except for changing HI (Human Interface) to be UI (so I don't have to explain what HI is all the time).

Now, the DM layer we never build anymore - we buy a solution. Toplink is a good commercial one (now owned by Oracle) and there are some open source ones also such as Hibernate.

So, the operational reality is that we only have three FBSes for three layers. UI, PD and SI.

Let's look at PD and SI first. The approach for these two is the same. The FBSes are constructed in the same way using the same feature naming templates. There is nothing you need to do differently regarding an FBS for PD or SI. Note that this flows directly from our approach to the nature of the interface between PD and SI which is described here.

Now, there's a lot of things going on here in FDD. The processes are very simple, clear and concise. They have what Phil Bradley calls "transmissability." What that means is that people are able to "get" them easily. This is more important than something that might be technically more accurate or complete but is not as easily "gotten" by readers.

The FDD processes have very high transmissability because they came from a real project. Then, they were (slightly) genericised to remove specifics from that project (such as tool names and platform names, etc.).

Basically what I'm saying here is that if you try and describe every detail, every corner case, every everything, you most certainly lose transmissability (processes like these are tedious to read) and you also become prescriptive rather than well-bounded, which is a value that is core to all the Agile methods.

So, in FDD there is quite a bit more to things both in the way the processes interrelate and to their abstractions.

Once you get what the processes are about, it becomes easier for people to abstract and adapt.

A common project management pain point is an accurate and meaningful baseline. That is, being able to answer how far along you are and how far there is left to go. The Develop an Overall Model process for example can be abstracted to some form of informational/analytical activity that must take place in order to get the knowledge necessary to develop the baseline (the baseline coming from the Features List and Planning processes).

I've consulted to projects where they were already in progress. In one case, the PM was tired of always being 20% done no matter how much "good faith" analysis they did, every time the answer was the same. He saw the reports and tracking in FDD and asked for help. I was only there 2 days (that's all it took). They were already coding and the project had been running about a year. They didn't have a model and they were using use cases. Not all the use cases were finished.

The last thing in the world I would do is drag them back to do an object model as the Develop an Overall Model process calls for. Instead what I looked at was an informational/analytical activity that would give them the knowledge to create an FBS. Once they had that, then they could track and report using the FDD approach.

This informational/analytical activity was the use cases. I asked them to see if they could produces features from their use cases. They went away and worked on this and the results were very good. So, we did two things. First, we got the use cases consistent in terms of granularity and then we made it a priority to complete all the use cases and thus create the FBS - their features list. Then, they used the FDD milestones and reports and etc. as-is.

Ok, that's a long example but that's what I mean about abstraction, adaptation and also transmissability. That is, if all such considerations are written into the FDD processes they would be voluminous and prescriptive. And, they would be useless.

There's a similar abstraction with the Develop Features List process. Producing an FBS is gold. Breakdown structures that are oriented around client terms and not tasks is a powerfully different approach to projects. Much more so than would seem intuitively so.

Now, whether each feature is absolutely written using the FDD feature naming template, and in fact even whether each feature is absolutely client-valued is not what this process is really about. It's really about the fundamental difference in mindset and approach that describing and tracking projects with FBSes intead of WBSes delivers. Hence naming templates, client-valued versus client-comprehensible, and where in the FBS hierarchy such communicability and value is "scored" are subject to adaptation.

When it comes to UI, I don't have a reliable system. There's the Cooper camp, the Constantine camp, Raskin and others. There's task oriented, goal oriented, and so on and so forth. I don't have a reliable system here nor do I see any of the above as the one way to always do UI. What I do as a project manager on any project, in the absence of a process or tool solution is look to people. That is, I hire a UI person that "gets it." Sure, I shape things, but I primarily solve this with a person.

However, having described a bit about the processes and their abstractions I hope you can see what should be obvious now. For the contents of the UI FBS all that matters is that it is an FBS and not a WBS.

What tends to happen most of the time on my projects is that the subject areas of the UI FBS represent the major application areas. e.g. customer management, account management, search, etc. This is usually pretty easy to partition. Underneath that, most of the time these days the list is broken down by the forms and underlying structures. I'm not advocating this - just describing what teams have done over the last several years (presuming web apps).

In FDD the PD is prioritised and emhpasised as it is the greatest risk and is the best way to communicate and show value to the client (after all that layer is describing the client's domain).

Generally, the PD is the only layer that detail is communicated to the client (directly) and even then that is usually only at the start so they see where the summary report numbers and parking lot numbers come from.

When I present status to steering committees or top management I'll use a slide like this one which is a real status slide from the Singapore Lending project and then I'll show the parking lot chart for each layer - PD, SI and UI.

Notice how for top management I call PD - Business Logic. You will also notice the User Interface is called Items and not Features as that is what the contents of that FBS really represented (screens, panels, widgets).

I hope it is clear now that it really does not matter that the features in a UI FBS may not be written using the feature naming template. But... I am open on how things are done here, as long as the goal of the UI FBS and its relationshiop with the rest of the FDD processes is maintained.

Thanks for the question.

Jeff