Project Management

Agile versus Waterfall in Software Projects

From the Pro*Blog Blog
Covering all things Pro: problems, products, progress, projects, process, programs, professions, proposals, provisioning, and more! Analysis and commentary on yesterday and today, and prognostications, prophesies, and projections for the future.

About this Blog


Recent Posts

Agile versus Waterfall in Software Projects

Collective Knowledge

Last Responsible Moments

Donald Rumsfeld and Project Management

Kaizen or Kaikaku?

Agile versus Waterfall in Software Projects

By John Herman   PMP, CQE, MPM

A complete discussion of the pros, cons, and other aspects of using agile, waterfall, or hybrid approaches is too much for a blog column.  Indeed, it might be worthy of a short book!  What follows is a short recap of what I’ve had success with across the past decade.  I’ll concentrate on Agile versus Waterfall and defer discussion of Hybrid methods for a future posting.  

A fairly universal rule of thumb is that the Waterfall method works well when requirements are well defined.  Agile thrives for projects where requirements are not well defined, are expected to change, or evolve based on each iteration such as with R&D activities. 

Agile is usually very good for customer service or customer facing applications, where user feedback contributes to requirement changes, early and often.  In addition, applications that interface with customers often need to rapidly incorporate innovations similar to those being used successfully by competing companies. 

Agile is also great for marketing applications, another area of the business where change is common.  Again, needs to respond flexibly and/or rapidly to changes in the economy and marketplace are a common factor in the marketing and sales functions of the business.

Waterfall is usually the best choice for compliance projects, where requirements are usually firmly based on laws, regulations, policies, or audit findings; both from internal and external sources. In addition, compliance activities are usually constrained by a date by which the compliance should be achieved.

Accounting and finance applications are also suitable for Waterfall.  These business functions usually have exact requirements and face continuing efforts to meet standards for reporting to management, shareholders, and overseeing organizations. 

It has generally been accepted that the choice of methodology for any particular project should be based on that project’s needs.   That said, the above summary reflects some real-world experience with projects across companies of varying size with varied products and services. 

Posted on: January 26, 2019 11:14 AM | Permalink

Comments (10)

Please login or join to subscribe to this item
Nicely explained.
Thanks for sharing!!

Thank you for sharing. Please let me say that Agile and waterfall are not matter of comparison. Agile is an approach that can be used with any type of project life cycle process, for example waterfall. Waterfall is a project life cycle process based on predictive project life cycle method.

You make some good points John but there is much more to this and sometimes you would be surprised that some accounting and financing applications can be best delivered through Agile or Hybrid but like you said, it is a very wide and open ended subject.

Thanks John!

I've discovered that iterative/agile approaches can work wonderfully when the customer (or internal SBU) isn't really sure what they want. In the past I worked with a team that was only assembled for 12 weeks to build a training program for an IT department. Rather than delivering the package on week 12 we worked in 2 week sprints and demo'ed portions of what we thought people might like every 10 business days.

We got feedback that we never anticipated (nor got at the beginning of the process when I went to talk with the department managers) through this process. The end product was the best training system that they'd seen in 10 years in the IT department.

It works!

John, nice explanation.
Thanks for sharing

Thanks John,
This is a good attempt at mapping the type of project management method generally successful in various domains.
I think it should not be taken too literally though. In my opinion, whatever the domain, a key element for enabling agile usage is whether the client is interested in (Or accepts) using it, and is ready to organize accordingly: dedicate a business aware PO (and all associated support depending on the size of the project) to drive the implementation resources.
I have seen many situations where agile can work, and ends up being sub-optimal because some of the basic aspects of agile are misunderstood or simply ignored.

Good Point, Thanks Sharing

@Sergio - I understand your point of view from a purely theoretical perspective. However, I believe the agile and waterfall comparison is akin to comparing Kaizen (agile) and Kaikaku (waterfall). Kaikaku is revolutionary change at a single point in time, occurring suddenly, such as at the completion or release date of a waterfall project. Kaizen is evolutionary - incremental change or gradual improvement via cycles like agile sprints. Kaikaku is sometimes improperly referred to as Breakthrough Kaizen, when it is really a separate approach. Please see my blog entry "Kaizen or Kaikaku?" for more detail.

Is not theorical. Is purelly practice. I am appling it from 1995 up to date. The problem is people who do not understand what Agile really is think it is theorical.

Please Login/Register to leave a comment.


"From the moment I picked your book up until I laid it down I was convulsed with laughter. Some day I intend to read it."

- Groucho Marx