Waterfall, RUP, and Agile: Which is Right for You?

Posted by Robert Merrill on December 17, 2009 under Agile Methods, Waterfall (SDLC) | Be the First to Comment

Serhiy Kharytonov published a fine summary of software methodologies for non-technical leaders at Executive Brief. He makes several excellent observations, but he also perpetuates a destructive myth. I’ve worked with all three of Waterfall, RUP, and Agile, and here’s my take.

Excellent observations

Then, stay agile in the approach to the process itself, constantly looking back, re-evaluating and revising the development process until it fits your current circumstances most successfully.

If you learn nothing else from Serhiy and I, learn this. Change from a culture of blame-fixing to a culture of continuous improvement, with no political unmentionables, and you will get a lot more value for your software-development money, and everything else besides.

Then, if you want to learn one more lesson the easy way rather than from a painful and expensive experience,read the Destructive Myth.

Here’s another excellent observation by Serhiy:

At the end of the day, the best method or blending of methods for you depends on a thorough understanding of all three processes and how they fit your software project, business culture, and development environment

Business sponsors and subject-matter experts, you’re a part of the team, too. Don’t just take the technical staff’s word for it. Waterfall, RUP, and Agile are about how the work is defined and managed, not about programming languages and other technical stuff. You can and should understand them, know which one you’re using, and why you’re using it.

RUP also defines the roles and activities of team members in depth…All team members have access to the same large knowledge base of guidelines, templates, tools, and other items to ensure that they share the same language and perspective on the project.

RUP™ stands for Rational Unified Process, a packaged set of tools and templates for running the Unified Process. The Unified Process is in turn a 1990s synthesis of several different processes designed to work well with object-oriented languages (e.g. Smalltalk, C++, Java, C#). Out-of-the-box RUP™ is all-encompassing. What often happened (and still does) is that RUP™ consultants “install” it without the buyers really understanding it. People are assigned “roles” they don’t understand and produce “artifacts” because the process says to, not because they help the team ship software and deliver value to the business.

RUP addresses many of the criticisms of Waterfall development

In particular, the UP (remember, RUP™ is a commercial brand of UP) explicitly focuses on exposing and reducing the risky parts of waterfall development, namely misunderstood requirements and failure of technologies to work as expected. It also introduces Use Cases, an easier-to-understand way of expressing requirements than “the system shall…” flavor of the old IEEE 830 standard.

Destructive myth

One dwarfs all the others, and it’s repeated throughout Kharytonov’s otherwise fine survey of methodologies. Of Waterfall, he writes,

“The goal is to gather all your detailed requirements early in the process and provide a single complete solution with results that are highly predictable.”

He then goes on to say that Agile lacks predictability and isn’t the best choice for

“Clients who want contracts with firm estimates and timetables”

The seductive, destructive myth is that , “The more detailed planning you do, the more accurate your estimates will be.” Rather than repeat myself, I’ll just refer you to my earlier post on Diminishing Returns—A Key Agile Principle and my Wisconsin Technology Network articles, Software sanity: Accurate estimates and other myths and A tale of two processes.

No matter how bad we all want it, the predictability’s just not there, and no methodology can change that. Neither can a fixed-price, fixed-scope, fixed-schedule contract. That’s just overpriced insurance for a risk you can manage yourself with a little bit of up-front learning and planning, followed by staying involved in your Agile project and managing for value within a budget and schedule you can still specify.