Waterfall is not Agile. So What?

I was exploring twitter as I sometimes do in the morning when I came upon this interesting post.  It is true, to paraphrase Rudyard Kipling, waterfall is waterfall and agile is agile, and never the twain shall meet[1].  So?

 

Agile is not warerfall

Agile is not waterfall

The goal of any project is to successfully deliver the objectives of that project and the customer (sponsor).  Does it matter that adding stand-ups and increasing the iterations does not make a conventional approach to product development agile? Agile is not the end itself.  In other words, we do not adopt agile because the goal is to adopt agile. We adopt an approach to our project endeavors that we believe will achieve the goals of our project endeavors.

There are times when an agile approach adds more risk to the project success then improves the odds of success.  Other considerations such as project scope, regulation, risks, industry type, organization structure and probably a host of others that must be considered when determining the approach.  Those that say the agile approach is the only way; are essentially saying I can use a hammer to unscrew a Phillips head screw.

 

When you nee a hammer....

When you nee a hammer….

 

The truth is there are many ways to accomplish the goals of the project and it requires an understanding of the risks associated with the product as well as the environment in which the project operates.  This includes, but is not limited to the available talent for the project.  Defective implementation of an agile project will produce poor also so agile is not a panacea for product development.  However, there are aspects of agile that can help any project approach, and two of those are iterations and communication.  There are many studies (for example, Standish Group and Capers Jones) that show an incremental and iterative approach helps improve our likelihood of success.  The same is true for quick recurring communications with the team.  This is where the project manager understands the rate of actual progress and is able to compare to the planned progress (Earned Value Management) and can take immediate action to either improve the situation or manage expectations of the sponsors for the project.

Okay, so adding more increments and improving the communications and monitoring in our conventional projects do not make our conventional projects agile.  Why does that matter anyway?  The goal is not to adopt agile. The goal is to successfully deliver and reduce risks.



[1] The Ballad of East and West by Rudyard Kipling

Post by admin