Agile and Waterfall: More Different Than You Think

This is a mostly-verbatim post from a LinkedIn forum.  I thought it was worth sharing with the audience here, so you can help me refine my thinking.

In the forum, another member suggested that agile and waterfall are opposite ends of a spectrum. He further suggested that a team can choose its own position along the "sliding scale" between the two extremes.  This is when it dawned on me that maybe I understand why this is not true. 

Please pipe in with your insights, extensions, or corrections.

---

It is possible that agile and waterfall are not two approaches to the same thing. If they were two approaches to the same thing, I think mixing them would make sense and the sliding scale makes sense.

If, however, they are two different systems with different axiomatic bases, then the reasoning that is productive in the one will be surprisingly counter-productive in puzzling ways in the other.

I suggest that the systems are axiomatically different. Agile values continuous delivery of value and responsiveness to market. Waterfall values a comprehensive plan and compliance to the plan until the final delivery.

These are very different axioms, from different places, and I'm not sure you can do much more than borrow practices from each other and repurpose them to entirely different goals and values.

• Not having a long-term plan in waterfall is sheer madness. 
• Having a long-term plan in agile is pathology people are cured from. 

• Not knowing the scope of a waterfall project before you start it is inviting failure. 
• Not knowing the scope of an agile project is perfect -- you have a basis for collaboration. 

• A month pre-worrying and developing docs for waterfall? Not remotely enough. 
• For agile, a month without producing anything but documents? Abomination! 

• In agile, refining the software model and structure is the way you become successful. 
• In waterfall, changing the structure and model mid-project is disastrous. 

• Agile keeps planning short and shallow to protect market responsiveness. 
• Waterfall is about "controlling" change to protect the plan. 

• Agile tends to find its home in product development. 
• Waterfall tends to find its home in project deployment. 

• Agile deploys every day, or every week if it can't. Or bi-weekly as a fallback. A month is forever. 
• Waterfall deploys at the end of the contract. 

• Agile is about customer involvement and delight through innovation. 
• Waterfall is about contractual obligations and proving compliance. 

Go ahead and pursue it, but I think this is not the first attempt (see SAFe and ScrumFall and ScrumBut and a host of other attempts to blend) and I think there is a reason those other attempts are unsatisfactory.