Methodologies Evaluated - Web Development Methodology

Rational Unified Process

We had two presentations from RUP representatives. The first was a one-hour session, the second a more detailed two-hour presentation. Both times, I was more confused after the presentation than before. I also spoke to a number of friends that had worked with RUP and had positive things to say about the process.

The scope of RUP is extremely broad. It covers pretty much everything in the entire SDLC, which is both its strength and its weakness. I was recently at a conference and attended a session by Phillipe Krutchen, one of the leading authorities on RUP. His view was that the main problem that arose when people tried using RUP was that they tried to use all of it. This was the same advice that I'd heard from friends who had used RUP. It's large and sophisticated, and the key is to use only those aspects of the process that you need for your project. This makes a lot of sense given that projects often vary and the same approach won't work in every case.

However, given the context of our team, RUP presented a number of issues:

• RUP was large, complex and sophisticated, yet our team was not! We had some team members who were still learning about the SDLC, and to try to introduce something as complex as RUP would require significant additional training.
• Even though RUP was comprehensive, we would have to review it in depth before we could decide which elements we would apply to our projects. We'd then need to trial and refine the process over time.
• The cost associated with the tools that were required to use RUP (eg. rational rose, requisite pro…etc) was high.

Overall, to implement RUP, or a scaled down version of RUP, appeared to be a potentially complex, difficult, time-consuming and expensive process that had a high risk of failure.

Process Mentor

We also received a presentation from a Process Mentor representative. The process itself was more compact than RUP, and therefore easier to get one's head around. In essence it was a Website with a series of steps, forms and templates that could be used to run a project. We felt more comfortable with Process Mentor than RUP because it was less overwhelming, but it still wasn't quite right. There wasn't anything that stood out as a major issue, as had happened with RUP, but regardless, Process Mentor did not feel like the right approach.

In-House Methodologies

Our team included a number of experienced developers who had worked with "home grown" processes from previous jobs with heavyweights such as IBM GSA. We had each of these developers talk about their experiences, explaining what worked, what they liked, and what they'd use again. There were a number of techniques that sounded useful but, when all was said and done, the overall feeling was that we weren't going to be able to "borrow" one of these in-house methodologies from another organisation.

Why Traditional Methodologies didn't Fit

There was no shortage of vendors willing to tout their processes and associated tools yet, after many presentations, we didn't feel any the wiser. Nothing seemed to address our needs. The reasons varied but the underlying problem was that none of the methodologies took into consideration the way things worked in Web development.

In comparison to traditional software development, Web development time frames are often shorter, the experience levels of employees vary dramatically, clients often have a poor understanding of what's possible, the technology changes rapidly and everything comes down to a single user interface (the browser). That's not to say these elements don't exist in traditional software development; however, the limitations are much more pronounced in Web development.

Another issue with traditional methodologies is that they failed to take into consideration the "soft" aspects of software development. A recent study of the most important factors in successful software teams (from Cutter Journal March, 2005) ranked trust as the number one factor and technical expertise as last, out of a total of 17 factors. Nowhere in any of the presentations or literature for either RUP or Process Mentor was trust mentioned; nor were any of the other soft skills that apparently have a huge impact on success.

The short answer was that we couldn't either adopt or adapt a traditional approach. This left us with the unenviable task of trying to create our own.

Going Agile

We were about to start defining our own process when I came across a lightweight methodology that's now known as the "agile" movement. The methodology in this case was Feature Driven Development (FDD); some of the other popular agile methodologies are XP, Scrum, Crystal and DSDM. (The details of Agile Methodologies and FDD are beyond the scope of this article but if you're interested to read more, visit http://www.agile.org and http://www.featuredrivendevelopment.com)

It was pretty clear that FDD was far better suited to Web development than anything else we had seen, so we decided to investigate further to see if we could adopt or at least adapt it to Web development. It didn't take long for the team to agree to give FDD a go. However, we soon realised it wasn't a silver bullet.