Agile or Waterfall ?


Is waterfall not suitable for modern product development practices? I am especially talking about IT, Software and Digital. When do you prefer waterfall over agile ?

Project Management
Project Planning
Agile Methodologies
Agile & Waterfall Methodologies
IT Management
Software Project Management
Software Development
QA Engineering
Software Documentation
Hitesh Mathpal
24 months ago

9 answers


Waterfall is not necessarily a slow, fat document-heavy process, and, if mismanaged, Agile can be a slow expensive process too. Waterfall simply means a linear pass through the development process (and in actual practice it almost always has iterations); Agile means letting the requirements evolve as the project goes along and getting partial products into place early so as to begin delivering some value as early as possible. So, ironically, if you are running very small, quick projects to produce a low-cost item, you won't have the time or the money for Agile: you'll just have to get it done and get it pretty close to right the first time. Another question would be whether it is possible to sell/deliver the product in increments. If not, or if about 85% right is the minimum acceptable, then you're into one-pass territory again. Having said that, note that at the task level, producers should be checking their work and should not be releasing material that doesn't meet the standard, so you will see iterations within a task if needed.

Douglas M. Brown
24 months ago
Agreed Douglas. You made some really good points. - Hitesh 24 months ago
While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies. - Dr. David E. 11 months ago

If you look closely at Agile/Scrum then you see mini or micro waterfalls.

The notion of trying to determine ALL requirements in once step and then building it entirely over a course of months/years has proven to be flawed because business requirements aren't ever complete, there are unforeseen changes that impact requirements, some element of trial-and-error needs to be judiciously used during the course of the project, etc.

As such think of Agile/Scrum as a technique to break a project into many smaller phases and constructing each of them as a micro-waterfall. This allows for regularly scheduled priority reviews to allow reality to creep into the product development process.

Jay Hemmady
24 months ago
Though many will tell you waterfall requires all requirements up front, that is simply not true. In my years of working from what many would refer to as waterfall, I have never seen one where all requirements were required.The truth is, both of these approaches can work, but you must consider available talent, level or risk (and regulatory) and management philosophy to determine which is best. - Jon M. 24 months ago
Agree - Dr. David E. 12 months ago

Waterfall, especially for bigger projects, has a lot of flaws. It assumes that you can guess all of the twists & turns that will occur during the course of the project which is never the case. As more information becomes available the team needs the flexibility to make those course changes quickly instead of going through a laborious Change Request process.
The main challenge in Agile is that leadership is stuck in a Waterfall mindset. They want to know exactly how the project will play out and the correct answer is "I don't know", but that is never acceptable so I have to make some wild assumptions based on almost no information and leadership takes that as a commitment. It puts the Project Manager in a terrible position.

Kier O'Neil
24 months ago
I totally agree and I have seen/faced the same. In many implementations leadership doesn't understand agile. They still want waterfall type reporting and answers. - Hitesh 24 months ago
Nobody says the waterfall approach should plan out several months of work, knowing that planning is likely largely waste. It is possible to execute in non-agile ways and not have planning horizons 1 to 2 years out. There are a good many other factors that play into the decision as to which is the better solution than this less than accurate portrayal of waterfall that seems so pervasive. - Jon M. 24 months ago
Agree - Dr. David E. 12 months ago

An agile like approach is always preferred -- but many go overboard with agile ... agile without some form of longer term direction is chaos :-)

Jim Fletcher
24 months ago
Yes Jim, Agreed. One argument that goes against agile is chaos. And, managing chaos is very important in Agile. How this can be done effectively? Your thoughts ? - Hitesh 24 months ago
Waterfall and agile are at opposite ends of the spectrum -- waterfall attempts to pre-plan every possible detail and generally is overly conservative to do so. But what I have found now is that many agile sprints are also padded in order to assure success. A balanced approach that recognizes risk and the unexpected is an appropriate balance. - Jim 24 months ago
Jim Fletcher Thank you ! - Hitesh 24 months ago
Also thanks - Dr. David E. 12 months ago

Waterfall really is a structured, documented and heavy process. Agile is not only a way of working (it is not a “techniqiue” or “methodology”), that shifts an organization and its cultural to a more inclusive, team-inclusive approach.

Waterfall is more suited to a project with very specific expectations for final outcome and when there is a hard and fast deadline.

Agile is more appropriate when there is room for a collaborative contribution to the outcome, and flexibility for the end product is a given.

i suggest starting with the Agile Manifesto and the affiliated 12 Principles to gain additional perspective on the differences, to then better envision other instances where Waterfall might be more appropriate.

Best of luck in your research!

Sherry L. Hall, CSP, SAFe (SA)
24 months ago
Thanks for your views. Nice explanation. - Hitesh 24 months ago
Agreed - Dr. David E. 12 months ago

There are more things to consider here. For example, waterfall does not really require planning things out for the 1-2 years. Waterfall does not say have all the requirements up front, though many have interpreted it as thus. The word progressive elaboration applies here, plan what you know, learn from that in the development work, adapt and adjust, then plan the next section of work. Beware the false choice and of those that deride one solution though seldom have done it or done it correctly. Any approach, poorly executed will lead to poor results.

  1. What is your organization's management philosophy - command and control or push decisions down to the talent executing?
  2. Are there legal and regulatory structures for your industry?
  3. What is the level of risk associated with the product? What risk does this pose for the company?
  4. What about trace-ability of the work and potential product litigation?
  5. What is the level of competence of your staff? Considerable new people? Mostly long term and well trained?
  6. What level of product management skill (technical) is within your organization?
  7. What level of customer knowledge is available within your company?
  8. What are the communications channels like (distributed team or co-located)?

These questions are better to ask when considering which approach in my humble opinion. Nobody says waterfall requires all of the requirements, nor must plan out the entire project as if you know everything. It is better to consider the attributes of your organization and of your project rather than berate one poorly executed over another approach which, if poorly executed will deliver the same unsatisfactory results.

Jon M. Quigley, MS PMP CTFL
24 months ago
Very well placed Jon. - Hitesh 24 months ago
Good thoughts - Dr. David E. 12 months ago

I think the optimum approach is a hybrid - depending on compexity

  1. Force the domain expert to create a Complete Vision. This is an typical attribute of Waterfall.
  2. Force the domain team supporting the export to create a Complete Functional UX. This is an typical attribute of Waterfall.
  3. Force the Product Marketing team to write the Press rRelease that describes the new product: what is it, what does it do, why is it better, and what are its benefits.This is an typical attribute of Waterfall.
  4. Acknowledge that it is completely acceptable to break up the effort into small task chunks with MVP (very small part of the Complete Vision/Function/PR) as the initial deliver goal. (Agile)
  5. It is also completely acceptable to change the Complete Vision/Function/PR as the feedback loop becomes operational - but they must be changed not abandoned. (Agile and Waterfall)
  6. The entire development team understands the Complete Vision/Function/PR and leverages it to create a flexible domain driven model framework can be drastically changed while en-route. (DDD)
Steve C
24 months ago
Thanks for your views Steve. Can you please place some light how to manage documents, compliance and other project management practices in the hybrid. - Hitesh 24 months ago
Never did like splitting the baby = hybrids - Dr. David E. 12 months ago

Agile Wins

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).

It advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement, and it encourages rapid and flexible response to change.

Dr. David E. M
12 months ago
There is no reason why stage gate would not do the same, in other words, there is no admonishment to adaptive planning, evolving development and my experience with both suggests conventional approaches may value empiricism more than agile (though that need not be the case by doctrine). Also continuous improvement can be a conventional approach. - Jon M. 12 months ago
OK - Dr. David E. 12 months ago
Agree, - Hitesh 11 months ago
Me too! - Dr. David E. 11 months ago

I think now most of the projects are turning into agile only. Also, with new approches like Microservices, DevOps and CI-CD ( Again I am only talking about software development industry) there is no role left for SDLC. SDLC can still be used at program level.
Do you agree ?

Hitesh Mathpal
11 months ago
Even the programs can be devided - Scrum of Scrums ? - Charu 11 months ago
Scrum of Scrums = I like it - Thanks - Dr. David E. 11 months ago
Yes. Its actually in practice. Thanks Charu Gulati and Dr. David E. Marcinko MBA - Hitesh 11 months ago
Your welcome. Scrum of Scrums is pretty popular at big project level. - Charu 11 months ago
I looked it up; many thanks - Dr. David E. 11 months ago
Scrum of Scrums. Definition. A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. - Dr. David E. 11 months ago
AKA: Cross functional or Cross PM teams - Dr. David E. 11 months ago

Have some input?