Managing the Transition - Web Development Methodology

The next step was to work out how to actually apply FDD to our work. There were many projects in production and we couldn't simply change our approach midstream. Nor could we expect all new projects to start using the new methodology, as not everyone on the team had had training. We were going to have to take a staged approach to implementing the methodology.

We decided to tackle the problem from a number of angles. Firstly, we would slowly introduce a few of the key aspects of FDD into new projects:

• Define projects using features (customer-focused)
• Plan development based on features
• Implement new team structure, design and code reviews
• Conduct weekly project status meetings

Secondly, we would run an internal test project. Our intranet needed redevelopment and we thought this would be a good opportunity to give FDD a go, as well as a chance to try to work out how to deal with the interface and testing areas not covered. Thirdly, although it wasn't planned, a developer and project manager that had been through the training decided to use FDD on their next project for a paper merchant.

The intranet project didn't go well for many reasons, none of which had anything to do with FDD. The project suffered from the same problems that many internal projects face: it lacked buy-in and a dedicated stakeholder. Even though we went through a fairly comprehensive requirements gathering process, the project lacked clarity of purpose. It didn't matter what development process was applied, that project was destined to be difficult. But what it did indicate is that FDD works best when there are clear requirements to start with.

The paper merchant project, on the other hand, went extremely well. The developer, one of our best, did an excellent job in modelling the domain and the project manager was able to track the project easily. The team experienced some challenges, though. In defining the overall model, FDD uses a modelling technique called colour modelling (as explained in the book Java Modeling In Color With UML).

Normally, modelling is not completed in collaboration with the client; in FDD it does involve the client and, therefore, the client needs to have an understanding of the technique. That doesn't mean they need to be UML experts, but they do at least need an idea of what's happening. Explaining this to the client was the only real challenge. With most clients, we anticipated that this would be fairly straight-forward and, once they understood it, they'd actually find it fun!

As the project had a small project team of just one developer, one designer and one project manager, it went smoothly. There was no need to create work packages, assign features to individuals, track progress of each individual, and so on. One of the issues that arose in the FDD post-training workshop was the process's reliance on the chief architect. This project had only one developer, who played chief architect, chief programmer and developer. This was risky: if he was not good at his job, the project would be in big trouble. However, this is the case with all small projects: if you don't have a decent programmer, you're in trouble!

Overall, we saw a significant improvement in the project's progress on a number of levels, some of which were quite unexpected. The goal was to find a way to deliver projects more effectively, but what we found was that the effect on morale was much more positive. The simple fact that we had decided to improve the way we worked had a positive effect. The team was happier because we were doing something about the problems. The new approach also helped to bring together the different disciplines (development and project management in particular) who had previously not always worked closely. There was a palpable sense of focus and direction.

In terms of projects, there was also an improvement. Although most projects still had issues, the problems were lessened and easier to manage. It was much easier to get a real idea of where each project was at, and how much work had actually been completed. For instance, asking a programmer how they were going with database optimisation can lead to one of many responses, some of which don't necessarily answer the question the client asked: when will it be finished? That's not to say that programmers deliberately try to avoid answering questions, it's just that sometimes the questions are hard to answer: often, it's not easy to say when something will be finished.

This was a key benefit of the feature-driven approach. When a project is defined in terms of "features", some of the complexity is removed from the questions the client asks. A feature should require no more than two weeks' work, so when asked how long it will take the developer to finished a feature (assuming it's been started!), the developer should answer with a figure between 1 day and 2 weeks. This approach actually helps developers to manage themselves, and avoid trying to make project managers happy by telling them what they want to hear, rather than the truth.

Unfortunately, we were unable to monitor the long-term impact of the introduction of FDD. Within 6 months of the training, the dotcom collapse hit the company and we saw a number forced redundancies.

FDD for Small Teams

One of the main criticisms of agile methodologies is that they don't scale up. For Web development, it's often more important to see if a methodology can scale down and still retain its advantages. It's understood that the impact of any methodology will decrease as the team size drops, and FDD is no different. However, I have been able to successfully apply FDD to small teams and projects, for example, a project that used 4 staff members (a project manager, developer, and designer) 3 weeks to complete. FDD can scale down and still provide value to the Web development process.

The two aspects of FDD that are of most value in small projects are:

• defining the project in features
• tracking the project by features

This seems very simplistic, but it's that simplicity that makes FDD so effective. Fail to define the project up-front as features, and chances are that the client and team will be on a different page from day one. Usually, this problem will only reveal itself once work is delivered. For small projects, correcting such errors is not a big task, however, a few days' extra work on a small project can mean a considerable percentage of extra work, and can quickly eat into the profit margin.

Like most things in life, getting started on the right foot is the best way to make Web projects work out well. Using the simple technique of defining the project in features using the client's language will make a big difference to small and large projects alike.