Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”. Interestingly enough what many never read in his writings on SW development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970) Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?
While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client. I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. I’ve heard some waterfall purists sum agile up to a bunch of people who want to get out of documentation and commitments to timelines. Ouch. But I also hear a lot of criticism from agile truthers about anyone who leverages waterfall as being clueless and archaic. Can’t we all just get along? Yeah, we can actually. But we have to start to recognize that Agile and Waterfall have value in different ways.
I’d love to have some discussion about what is seemingly a great divide between Agile and Waterfall methodologies. To help those in each “camp” understand why a specific method has value towards solving their business problems. What are some examples where you think a Waterfall process was truly the best solution for a project? What were some of the identifiers you had to come to that conclusion? Have you had success with using a “ScrumerFall” model where the Requirements, and design is all done up front, but Execution is done in sprints?
The AgileSphere 
This is a great discussion and there is certainly more to it than my broad response but I generally use it when starting this conversation. If you are working in chaos space where the work is not well understood, the technology is unpredictable and the requirements may be emergent then you may benefit from an agile approach. If the work is well understood, predictable and repeatable you may benefit from a plan driven approach.
These ideas are highly influenced by Michael James’ work.
What Dana stated above certainly is correct, but the problem lies a little deeper when you have a fixed cadence for SW releases (monthly, half-yearly, yearly or whatever), yet the underlying development method is Agile. How then do you measure success of the release if the original functionality that was envisioned at the beginning of the sprint is not done?
The individual sprints may be successful, by virtue of “we provided value during the sprint”, but
the combined sprints for the release do not provide the originally expected value. In this case the sprints may be successful, but the release is not, as it does not contain the functionality advertised.
What metrics will we use to control an initiative such as described? Surely the Waterfall concepts of measuring expected scope (features) against actual will support the release cycle.
The problem is further exacerbated in that grooming is done with a 2 or 3-week window into the future, rather than being able to size the entire release (combined sprints) at the beginning of the release.
If you’re building software, the data is clear: Waterfall is *never* the right answer. On average, any form of Agile practice will reduce risk and improve delivery over a plan-driven, sequential-work program. (I documented some of the available data in a white paper: https://aimconsulting.com/insights/insight/agile-myths-costing-business/).
There’s an argument to be made that in the physical world – say, building construction – that Agile doesn’t bring the same benefits. I’m even skeptical of that, but haven’t actually investigated current practices in those industries to find data.