Successful Web Development Methodologies

Applying FDD to Web Development

Implementing a new way of doing things is much harder than it sounds. People don't like change, and even those who say they're willing to give something new a go can quickly change their minds and revert to the old way of doing things. Because of this, we knew that we as a development team would only get so far trying to apply FDD ourselves. Sooner or later, it was going to affect the project managers and eventually clients. We decided it was better to get everyone involved up-front to increase our chances.

The next step was all about internal politics and getting the key decision-makers on side. As FDD is simple to understand, it wasn't difficult for people to see that we would be better off if we used this approach. On this basis, we obtained the funding to run a training course. Attending the course were representatives of all the groups that would be affected by a new methodology: developers, business analysts, project managers, a designer and a tester.

At the end of the course, everyone was keen. In particular, the following aspects of FDD stood out as providing solutions for the symptoms we suffered:

• Excellent reporting and planning
• Disciplined and clear
• Customer-focused
• Risk reduction via:
  • iteration of design and build in small chunks
  • clarity of requirements
  • better understanding of the system to be built
  • no wiggle room, as fewer assumptions would be made

We also realised that FDD wasn't going to be the complete answer to our problems. FDD covered development well but it didn't address the tasks of gathering requirements, interface design or testing. The things that concerned us about applying FDD were:

• its high reliance on technical leads
• it didn't deal with User Interface design and build
• it was less powerful on smaller projects than on large ones
• it didn't cover testing and deployment

FDD was not a silver bullet! In the end, we were going to have to adapt the process to our situation and needs.

Managing the Transition

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:

1. defining the project in features


2. 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.

FDD for Web Development

Since this first application of FDD to Web development in 2000, I've worked to refine the process and have come up with an approach that has worked effectively on dozens of Web projects ranging in size from 2 weeks to 6 months. This refined approach uses the core of FDD, but introduces new elements to manage some of the areas that FDD doesn't cover. Below is a high-level overview of how FDD can be successfully applied to Web development.

Project Overview

Although it is not explicitly stated among the 5 processes of FDD, it is an important that every FDD project has clarity of purpose. This need be no more than a simple statement to define what the project is, and what it's supposed to achieve.

Organisation Purpose

This might seem like a redundant element of a project. The organisation's purpose should be clear but, although it might be obvious to the client, it might not be obvious to the developer. Writing a single paragraph that explains why the organisation exists is an important step. Of course, this is often easier said than done; for smaller clients, the purpose is not always clear and this question can sometimes generate a very blank look! Still, it's well worth the effort to ask, as this knowledge can really help when it comes to the next step of working out the project's purpose.

Project Purpose

Once again, this constitutes a very simple statement, but it's often much harder to define a project's purpose that it seems. Most clients have many thoughts, wishes, expectations and desires wrapped up in what they describe as their "Website". In reality, the work must be defined as a project, with a clear purpose that everyone understands and agrees to. The Purpose should be a clear, concise and measurable statement of the business outcomes that the project is intended to achieve.

Project Objectives

The specific objectives of the project must be clearly defined. A series of bullet points is fine; the act of thinking this through and getting the client's agreement is the most important aspect of this part of the project overview.

Consider this example, which suggests objectives that might be identified for ACME, an auto parts manufacturer:

"The objectives behind the redevelopment are as follows:

• Unify ACME's corporate image worldwide.
• Build a commercially oriented Website projecting a simple, sharp, professional, advanced and confident tone, and one which puts user-friendliness first.
• Ensure the design of the Website adheres to the ACME Group Website Basic Guide Version 1.0.
• Use the Website as a positioning tool to position ACMO as a technology-driven, leading global supplier of automotive parts, systems and components.
• Provide the ability for ACME to update the site in-house using a content management system (CMS).

Project Scope

Understanding and defining a project's scope is a challenging task. Once again, clients usually want to include everything and expect everything to be done for them. I'm not bad-mouthing clients -- anyone who's familiar with the concept of scope creep will understand my point here.

The key is to get an idea of what's in and what's out of the Website. I recommend the use of a technique that was defined many years ago and states simply what's in, what's out, and what might be considered. This is a great tool for getting clients to understand all the elements involved in a project. Here's how it might appear for our fictional ACME auto parts business:

Target Market

Once again, this is an important consideration. Many sites are constructed without proper regard for the target audience. To say that a site is aimed at the client's customers is not enough. We need to understand the demographics of that customer base and if we have to target one part of that customer base, we need to know which one it is.

In reality, most sites have a number of target markets that need to be addressed. What proves to be a more practical approach is to think of it in terms of primary, secondary and tertiary target markets.

Content

The main difference between traditional software projects and Web development projects is the nature of content. Most Web projects entail a large amount of content. A Website may be an application or a hypertext system (eg. pages of content). Most projects are a combination of the two, in which case both aspects must be addressed. For projects with a large amount of content, information architecture and design become important elements of the project's success.

Information Architecture

In its most simple form, information architecture can be thought of as a sitemap. IA is the logical structuring of content to suit the purpose of the site. Although this seems like a straight-forward task, the importance of this process should not be underestimated.

A well-structured site will be easier for people to use, and will be much easier to maintain. A good example of a poorly architectured Website is one in which users quickly turn to the search facility to find the information they want.

Information Design

Most people now understand the concept of a site map and many can put a reasonable one together. The next level, which is far more sophisticated, is to look at the design of information on the page: the information design. The current trend is towards the three column layout with a header and footer:

Functionality

This is where features come into play, and where the "application" aspect of the Website is defined. The key is to break the project into chunks of work that can be captured in the client's language, and to ensure that each "chunk" totals between 2 hours' and 2 weeks' work.

Features that may be required for the ACME site (each requiring no more than 2 weeks' of work) include:

• Subscription facility
• Distributor search
• Product search
• Feedback form

Project Management

An integral part of FDD is the weekly report, which I've adapted for smaller projects. In a larger FDD project, the report would provide details of how many features had been started, had not been started, were in progress, had been finished, and were late. From this, an accurate "percentage complete" figure can be derived.

In small projects, it's not always necessary to go to this level of detail. However, it is important to track progress and report this to the client regularly. I recommend doing this in the following two ways.

Daily Wraps

A Daily Wrap is a daily meeting with your team. It's a common task among agile processes. For example, in the Scrum framework it's called the Daily Scrum or Daily Stand Up Meeting.

In this short meeting, each person states what they did the previous day and what they plan to do today. The goals for this meeting are to:

• make sure no-one is falling behind
• make sure everyone knows what the rest of the team is working on
• ensure that any barriers or problems are raised and overcome quickly
• help foster collaboration within the team

From a project management perspective, the Wrap is an extremely effective tool to keep developers on track. When people promise to do something, and they know that tomorrow, they'll be asked in front of others whether it has been done, accountability results. The Wrap certainly makes team members think twice about what they promise, and about not following through! Also, the Wrap has a strong social aspect, which makes a huge difference to team work.

Progress Reports

The key here is to provide the client with progress updates on a weekly basis. There are many reasons for this, the first of which is to provide the discipline necessary to allow the project manager to review the project on a high level. The progress report doesn't need to be complex or comprehensive; it simply needs to state what has been done and if there are any issues that need to be resolved. I use the following template, which has proven to be very effective.

Achievements

What has been completed in the past week? This section helps to generate a sense of progress and satisfaction.

Dependencies
This technique is valuable in helping get things done. Often, the dependency is something the client has to deliver. By putting this down in writing, you make clear who is responsible for delays.

Assumptions

I can't stress enough how important it is to clearly state any assumptions you've made. If they're not stated openly, they can often cause major issues. For example, a developer may assume that data provided will be in a tabular, delimited format that is easy to import; the client may deliver it as a Word file, or worse: in a graphic format such as Quark or Pagemaker. Document all assumptions!

Issues

Every project has issues, which need to be captured in a written issue report.

Resolutions

Hopefully, as the project progresses, the issues that are raised are resolved. It's good form to capture those resolutions so that, should questions be asked down the track, you can always go back to the resolution noted on the progress report. In particular, this helps with clients who have a habit of changing their minds.

Project Website

This is a large part of all FDD projects and, in those projects, is called the KMS (Knowledge Management System). All information for the project -- all documentation, meeting notes, progress reports and so on -- should be captured in an online location that both the project team and client can access at anytime. This helps to ensure consistency by placing all information in a central repository.

Conclusion

There is still no silver bullet!

Adapting FDD for Web development goes a long way toward addressing many of the issues that arise in Web development, but it is not a complete answer. Areas such as requirements gathering, visual design, testing and deployment aren't covered even though they are needed for every project. But, given the lack of viable Web methodologies out there, having something that is effective, albeit incomplete, it is a big step forward.