Fear of Non-Progress

<< Introduction

Page 2: The Waterfall Effect

Here's an interesting paradox: managers and customers of software projects, particularly in larger companies, appear to love the waterfall process because it offers a formal, seemingly low-risk approach that can easily be planned. Waterfall projects fit very neatly into Microsoft Project. However, management are at the same time wary of the waterfall process because it's high risk - they don't get to see evidence of real progress until late in the project.

We all know this, but project teams still sail over the waterfall, sometimes without even realising it. Any project which goes "Step 1... then step 2... then step 3..." has an element of waterfall. Step 1 provides the input into step 2, and so on. Different methodologies provide alternative approaches, but this basic pattern is mostly inescapable (you even see it in agile methodologies). Why? Because it always pays to know what you are doing before you do it - to look before you leap.

One of the biggest problems is this: if Step 1 is delayed, so is the rest of the project. That's one uber-critical path. Worse still, there is a risk that Step 1 might not be sufficient for Step 2 to begin. Step 2 (and all subsequent steps) are entirely dependent on the previous step being completed, and having been done well, i.e. flawlessly.

If your software process needs to be re-engineered, the primary goal should be to reduce risk.

Part of the answer is, of course, to break the project into smaller iterations, or mini-waterfalls. RUP takes this approach, albeit with a big up-front inception and requirements gathering exercise. This initial phase is still important, as it helps to get a bigger picture of what you are trying to achieve, and to make sure you and the customer are both on the same page before you set out to do anything else. The high-level architecture should also be created in one go (but fleshed out in more detail in later iterations). Then the project can be confidently broken into its constituent sub-systems. With well defined interfaces, sub-systems can be developed in parallel, virtually quashing the evil critical path (in theory, at least).

Extreme Programming (XP) takes the approach that customers are afraid even of these initial phases, and that we should leap straight into programming (with a small amount of warm-up analysis, and some hand-written user stories). The design then "evolves" as the project progresses. The theory is then that the customer gets to see "progress" throughout the project, as small amounts of the project are released on a regular basis. A nice idea in theory, except that this progress, however tangible it might seem, is illusory - first, because it is impossible to say precisely how much more needs to be coded, and second because any code that has been written will probably need to be redesigned and rewritten (refactored) many times over (click here to see what I really think of XP).

This brings us to our first and most important answer to the problem of perceived slow development: communication.

>> Page 3: Increase Communication

<< Back to Lifecycle