I have been reading a lot of discussion recently regarding the use of different methods for planning, implementing, and managing projects. Many methodologies exist in the industry; two of them are:
- Traditional Waterfall (some would say PMI PMBoK but not necessarily) model
- Agile (SCRUM, Extreme, etc.)
I read a really good article last week in the Harvard Business Review Blog — A Better Project Model than the “Waterfall” by Jeff Gothelf. In this post he talked about needing a better model than the traditional waterfall model.
Here is a summary of Jeff’s post:
The main argument is that waterfall methodologies, which have been around for a long time, have a fatal flaw–they depend on accurate requirements. The problem with this dependence is that requirements are often wrong. He discusses giving teams the ability to work with clients to find out what the real requirements are. One of the quotes from his post that I really like was from Josh Seiden, who said, “In software development, reality bats last.” What he means is no matter how much planning or optimism there is about the software product being built, the only true project success is the reality of customers using it to solve real problems.
He goes on to share examples of Agile methods, in which teams use lists of features that are prioritized by product owners (not developers) to drive the project. In addition to prioritized lists, he suggests that each project team should be handed specific success criteria. These criteria must be quantifiable and directed to specific outcomes that meet customer’s needs.
My own opinion of this conversation is that it is not either black or white–waterfall vs. Agile. As both as PMP, certified in waterfall methods, and a PSM, certified in Agile Scrum methods, I contend that a blend of both methodologies is often the right answer. Agile requires small, bite sized “sprints” with smaller teams in order to produce results. However, many projects are quite large, with as many as 300 people working at any one time. In these cases, running lots of small teams with sprints can become a project management nightmare. Using an approach that allows some portions of the project to use a more traditional waterfall method, and other parts of the project to use Agile, can make the overall project more management while still achieving the desired outcomes.
As I’ve stated in prior posts, requirements are not easy to capture, especially in complex software products. There are many techniques today (including Agile) which allow us to work with real users and discover the true requirements and needs and the measurable outcomes that must be produced. One such technique, Performance DNA, is used by my organization to ensure that all requirements are identified and linked back to prioritized outcomes.
In closing, as an experienced project manager who is certified in both methodologies, I am suggesting that “either/or” is not the right discussion. Instead, I propose that a combination of waterfall and Agile is more likely to be the right approach.
Do you have experience using a blend of waterfall and agile, or do you prefer one over the other?
Fear No Project Blog - Focusing on the Management Side of Projects 
July 18, 2012 at 1:12 pm
You’re certainly right that both have their place, and that you could use the methods in combination.
One of the important distinctions I have seen between waterfall and agile methods is which two of the three properties time, budget, features/quality are absolutely fixed, and which of the three is a little more relaxed. In agile, the PM will prefer to let /features/ slip if the project does not go according to plan, and in waterfall it is normally either /budget/ or /time/ that slips, or both….
It may be that this choice will dictate which parts of a large project have to be treated with what methodology.
July 28, 2012 at 7:05 am
It’s been aptly summarized on the necessity of having a combination of Waterfall and Agile methods in Project management and delivery. I have managed projects predominantly in the Waterfall model, because of being part of a Services organisation, where, the processes demand that each phase has to be signed off by the customer, before proceeding to the next one. However, in reality, I know, there was an element of Agile in it, where, the activities pertaining to the next phase would commence while the previous phase was in its last lap. Based on that experience, I believe that, the waterfall model is suitable during the initial period of the Project phase, where requirements, dependencies and constraints need to be identified and sorted out. Once these are clearly laid out, the subsequent part of the phase can follow Agile model, unless, you have to revisit the requirements (and dependencies, constraints as well). An iterative process with a combination of Waterfall in the initial period followed by Agile in the subsequent part of the project phase can help in meeting the users requirements in a better way.
August 5, 2012 at 5:11 pm
Waterfall is preferred in contrained software development, like medical devices, automotive. But agile methods bring their advantages to software development project, as long as agile methods are used with a well maintained documentation and a post-phase of formal verification and validation. More explanations here: http://blog.cm-dm.com/post/2012/05/12/How-to-develop-medical-device-software-with-agile-methods
August 10, 2012 at 6:36 am
I agree with Sanjiv that an iterative approach can work well – I have predominantly worked on software development projects many which ostensibly had PRINCE2 as their PM methodology but in practise used an iterative method because of the difficulty in capturing what the client/user really wants first time around. That’s not to say that the requirements weren’t fully documented and in plenty of detail but sometimes clients/users don’t know what they really want until they see something (then they know what they don’t want!). Major software development projects cannot always work well by delivering bite-sized chuncks because those chunks do not make sense in isolation or because the efficient way of creating anything is to create a library of s/w functions first, which can be very time-consuming but deliver little for the client to actually see.
But the best approach is undoubtedly a blend of methods combined with a large dose of commonsense and practicality.
August 17, 2012 at 7:46 am
[…] Project methods – Waterfall versus Agile (fearnoproject.com) […]
December 26, 2013 at 3:23 am
Yeah its a good article about agile methodology.Scrum is also an agile methodology.As a project manager, I use Scrum in my projects. The Guide to Scrum Body of Knowledge by SCRUMstudy provided a complete reference for the Scrum project I am working with. It is a very good book and extremely readable. I really liked sections on risk and quality. The tools mentioned in the processes were very helpful. I highly recommend this book if you are planning to implement Scrum in your organization. You can go through the first chapter available on http://www.SCRUMstudy.com
January 17, 2014 at 6:37 pm
Thanks Alexia… is Scrum study another Scrum certifying organization? I generally rely on Scrum.org as it was founded by Ken Schwaber. Just wondering why there is a need for another org?