Which is best – Waterfall or Agile?

Common sense, bravery and nailing the basics. How creating your own hybrid methodology can be the best solution.

Common Sense, Bravery And Nailing The Basics.
Credit: picture by Ryan McGuire

"Which is best – Waterfall or Agile?" a client asked this week.

For me, ineffective project management, a better question would be "Which is the best methodology for THIS specific part of THIS specific project?"

You probably have many pairs of shoes ... formal shoes, hiking boots, sports shoes, slippers, etc. When you choose which shoes to wear you do so based on what you're about to do. If you were to head off on a vacation that you knew was going to include hiking in the foothills, laying on the beach, playing tennis and dancing the night away you wouldn't try to pick one 'best' pair of shoes to do it all in – you'd pack the lot.

"Best" is subjective – in choosing a project management methodology even more so. Many projects fail because project managers stick with what they know rather than adopting the best methodology for the project at that time. You may love your classy black stilettos with the killer heels but they're no good for playing basketball in.

So, what if you applied your pre-vacation shoe selection methodology when embarking on an IT project? What if, as you planned each chunk of the project you selected the best methodology for that specific element?

Take the client who asked me "Which is best? Waterfall or Agile?"

Rather than giving a one size fits all, generic response I looked at the project in terms of scope, end-user and stakeholder requirements. I considered each phase of the project individually rather than the project as a whole, breaking the overall vision and mission down into manageable interdependent chunks and considered what methodology would best serve each of them.

What emerged was that in this instance was, like with most projects, the best way forward was a hybrid of a number of methodologies.

I invented a new hybrid that, over the course of the project, borrowed from Lean, Agile, Waterfall and Six Sigma – I invented 'LAWS'!

Now my "LAWS" will work well on this specific project, but it might not be right for the next project and its specific demands.

Your next project might need a structured approach with packages of activity that lead to an end deliverable – a big bang - a fanfare finale. So far ... so Waterfall, right?

What if, as part of the project, you had to deliver an end-user software application? Sticking with your Waterfall approach your focus would be concentrated on each of the gate review stages – you'd ask "have we documented our functional and non-functional requirements," "have we developed our RFP," "have we got a development team," etc. All great but the actual application would arrive for the first time somewhere towards the end of the timeline. 

In an Agile world, smaller parts of the end solution would be delivered along the way so the project team and more importantly the business would see what they were getting, get an idea of whether or not it will work and be able to make necessary changes along the way. 

In this case, you'd get the structure of Waterfall  with the delivery approach of Agile. 

In reality, most projects are like this.

A large software initiative, for example, that needs both sequential task management and governance of complex resources – might benefit from a hybrid of Waterfall and Critical Path. Your next project, meanwhile, might need to get to market quickly and rely heavily upon data for quality control in which case an Agile/Six Sigma hybrid might work.  

I just realized what the acronym for an Agile/Six Sigma hybrid would be. That wouldn't be good!

That's kind of the point, though.

I think, as project managers, we get too hung up on names ... Waterfall, Agile, LAWS ... our focus should be on what a methodology can do for us at a given time not what it’s called (having said that I think LAWS is genius!) and most importantly we shouldn’t be afraid to mix it up.

It's like when you go to watch the game and the coach gets his tactics all wrong. Despite losing badly in the first half of the match the coach doesn't change his approach. Your team ends up with a heavy defeat but a substitution early on or a change of formation could have altered the whole course of the game.

Similarly, in business negotiations, you'll probably have an arsenal of skills to get the deal that you want. If one isn't working you switch.

It's common sense.

Actually, Common Sense would be a great project management methodology. It fits all projects, however, complex they are. Unfortunately, you can't study and pass an exam in "common sense." If there was a certificate you could hang on your wall saying that you are as proficient in "common sense" as you are with PRINCE2, fewer projects would fail.

To be fair, I'd argue that most project managers know all this already. A project manager using Waterfall because it's what they know rather than what's best for their project probably knows that there's a better way, but it's a brave paradigm shift to step out of your comfort zone and try a different methodology and even more courageous to use a mix of them throughout a project's lifecycle.

So perhaps it's less a lack of common sense – perhaps it's more a lack of courage 

However, when you accept that you don't have to be held hostage by one methodology throughout the lifecycle of your project a universe of possibility opens up to you.

Thankfully, these days, you do not have to do it alone. Try these three solutions.

1. Buy in the methodology that will work best

More than ever, elements of the project management lifecycle are now available as a service you can buy in. This means that you have access to methodologies that are not part of your previous experience and your project can realize benefits that are beyond the limits of your CV. Even the process of project management can be outsourced as a service ... leaving you free to lead your project!

2. Balance the time you spend working "on" your project and "in" your project

Projects are very demanding and spending a proportionate amount of time working 'on' the project (methodology and leadership) as opposed to working 'in' the project (management, tasks, firefighting, etc.) can pay huge dividends. You can do this yourself but often I think a trusted outsider can see opportunities that may have become invisible to you by your day to day involvement in the project.

Which leads neatly into ...

3. Get a fresh pair of eyes

You can have loads of common sense and be as brave as a lion and still not be using the right methodology – sometimes you can't see the wood for the trees. That's OK, too. Have you considered a fresh pair of eyes? Gap analysis, project management office assessment and IT advisory services can help align methodology with desired project outcomes.

Finally, whatever methodology you choose – make sure that you master the basics!

The basics of a project are like a pizza base. Think of a pizza and you probably instantly think of your favorite topping - most people do - but without the pizza base you've just got a cheesy tomato-y mess that runs through your fingers! Your list of basics of a project should consist of a clearly defined objective, allocation of resources, breakdown and schedule of tasks, budget, scope, mapped out lifecycle and deadlines, effective communication, etc. I know that you know this – but whatever methodology you use will only be as effective as your mastery of the basics.

Next time you wonder which is best ... Waterfall or Agile? Six Sigma or Lean? Consider a hybrid that works best for your project.

Apply that with common sense, bravery and mastery of the basics and I wouldn't bet against you.

This article is published as part of the IDG Contributor Network. Want to Join?

Download the CIO October 2016 Digital Magazine
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies