Is agile better than waterfall?

Many IT teams are moving from “waterfall to agile based approaches” in their projects.

So clearly a lot of people think that agile approaches are better than waterfall approaches.  But are they really?  And if they are then how are they better?

One argument I often hear in favour of agile approaches is this one:

Is there any point in having a 100 page requirements document that nobody reads? No? Then waterfall is stupid and we need to use agile.

I often start with this statement when running project management courses because it is a great way to start a debate.  But it is not a sound argument.  In fact it is very similar to saying:

Is there any point in driving a truck to work if it won’t fit into the garage?  No? Then driving a truck to work is stupid and you should ride a horse.

There is actually no logical connection between the question and the conclusion.

So let’s take a step back and define what we are talking about when we look at “agile versus waterfall”.

What different approaches exist for running projects?

A lot of work has been done to examine the different methodologies used to run projects.  If you are interested a good summary of current thinking then I recommend reading “Manage IT” by Johanna Rothman: It provides a detailed description of different approaches, together with some pragmatic advice on how to apply them to IT projects.

But I am going to completely disregard all the sound research and advice from expert practitioners such as Johanna.  Instead I have invented my own taxonomy of project approaches.

So, based onmy not-very extensive research and consultation with no experts from any field,  I am going to claim:

• That there are four generic approaches to running projects; and
• That each generic approach can be broken into two specific approaches.

So these are the approaches I believe can be used to successfully deliver a project:

 

Cause based projects – Sharing a common belief but not dictating how each group or individual accomplishes their contribution.

Guru (or expert) based projects – Running the project on the basis of the expertise and judgement of a key individual.

Repeatable process: Compliance – Determining the standards and procedures to be used and then executing each project according to the agreed standards.

Repeatable process: Continuous improvement – Determining the standards and procedures to be used and using these, but (really) challenging and improving the standards each time they are used.

Bureaucratic waterfall – Completing documents for the sake of completing a template.

Predictive planning – Using sound engineering principles to run the project which involves performing detailed analysis at each step to predict what needs to happen in future stages.

Reactive planning – Starting the project without a plan (or only a limited one) and then creating a plan as events unfold.  Can also be described as “thinking on your feet”.

Adaptive planning – Using the scientific method to run projects.  Set a hypothesis at each stage and determine how that hypothesis can be disproven.  Compared to predictive planning this approach replaces detailed analysis with the testing of the hypothesis.

Which approach is the best?

I will explain each approach in more detail in a separate post (or posts) but generally people usually ask the wrong question when arguing in favour of waterfall or agile:

• A popular (but biased) arguement for waterfall is to compare predictive project management to reactive project management and to then ask the audience which is better;
• A popular (but biased) arguement for agile is to compare adaptive project management to bureacratic project management and to ask which is better.

A better arguement is to start with the problem the audience want to tackle and then ask these questions:

• What problem are we solving?
• What are the risks we face in implementing a solution?
• Is the problem small enough to
  • Simply use our standard process (compliance or continuous improvement)? 
  • Simply leave it to the team or an individual to implement (Thus relying on the team to understand our cause and create their own solution.  To rely on the individual we need to clarify their authority and expertise and then tell people to follow them).
• If the initiative is bigger, riskier and more complex and we are involving enough people for long enough to establish a formal project then, are we better off using predicive planning, adaptive planning or both?

Whatever the answer is – that is the best approach to this project.  Again I will expand on my views on this in some other articles.  But it turns out that no approach yet discovered is universally the best.

Of course those who know me will note I have a strong bias for cause led approaches to large initiatives, continuous imporvement for ongoing services and tasks, reactive planning for my own life and adaptive planning for projects.