Almost any time that there is a discussion about project management life cycles it quickly and inevitably comes down to talk about “Waterfall versus Agile”. That’s a real concern because the selection of project life cycle is a crucial one. Let me explain why I believe that the over-promotion of “Agile” by comparing it with Waterfall is not just wrong, it can positively be dangerous.
Misconceptions about methodologies
When people talk about “Agile versus Waterfall” they mostly mean “Iterative versus step-by-step”, which is not quite the same thing.
When I hear people talking about Waterfall and its disadvantages when compared to Agile, I usually hear is the concerns about the “one-step-at-a-time”, linear nature of the Waterfall approach. What they often don’t know is that there are other life cycle models besides these two. There is no “one-size-fits-all” approach.
There are circumstances where a Waterfall approach may be the right approach for you
The main drawback with Waterfall is that a change in requirements midway through the project means going back to the square one. However, there are times when you may want, or even need, to impose such a level of control over all or part of your project.
The most common Agile method is Scrum, but it’s not the only one
There are other Agile methods, including Crystal Clear, Extreme Programming, Feature Driven Development and Test Driven Development. There’s no “one size fits all” approach; some agile approaches will be better for your situation than others.
Your choice of Agile approach should depend on your circumstances
Any Agile approach is pretty much dependent on giving users autonomy and the freedom to design what they believe is right. If your organisation can’t provide that freedom, under the direction of a product champion or key user, then none of these approaches are likely to deliver the results you want.
Agile does not eliminate the need for Analysts or Designers
With the advent of Agile methods some people have questioned the need for Business Analysts, Systems Analysts and Designers. The switch away from more formal methods doesn’t replace the need for Analysts or Designers; it just changes how they do their job.
Agile is a software development method, not a project management method
If think you can use Agile safely for your entire project you’re in for a very rude awakening, especially if you’re running a project that:
- involves a mix of software, hardware and services
- requires procurement of third party products and services or
- involves multiple suppliers where they are using different project methods.
If you’re new to Agile and think you’ll master it in one go, you’re wrong
You should think about developing your organisation’s capability to use an Agile approach as a long term strategy. It is not a quick fix. Plan for your migration to a more Agile approach.
So, if you are intent on using Agile, what should you do?
If you are planning to use Agile, here are five tips that will help you to do so safely:
- Decide whether you’re ready to use Agile at all and decide which form of Agile is right for your circumstances
- Develop your Agile adoption strategy – include training, education, awareness and support to development peoples’ understanding and skills
- Decide which parts of your project could best benefit from an Agile approach and start there
- Start small – don’t try to convert everything and everyone to Agile overnight
- Review and improve – expect to make mistakes in the early days but know that you will get better as you go on
So the next time the subject of Project Management Lifecycles comes up in conversation, you’ll know that there is more to life, and to the success of your project, than Agile versus Waterfall.
“Project Management Lifecycles – Why We Need to Think Beyond Agile versus Waterfall” © 2014 Bryan Barrow