By this point, most software-development teams have embraced some variation of Agile methodology. Waterfall methodology, which had its heyday when the majority of software came in a physical box, is on the wane. However, some organizations still have a hard time fully embracing the leaner, meaner aspects of Agile—allowing some Waterfall-like thinking to creep back into the production process.
Welcome to “AgileFall.”
That imaginative term comes from Steve Blank, a senior follow at Columbia University and lecturer at the University of California, Berkeley, who recounts in a new Harvard Business Review piece how a “Fortune 10” company he was helping convert from “traditional waterfall project management process into Lean” ended up with the aforementioned “AgileFall.” In his words:
“I realized the head of product was still managing his project managers using a Waterfall process. Teams only checked in—wait for it—every three months in a formal schedule review. I listened as the client mentioned that the teams complained about the volume of paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review. How, he asked, could he get even more measures of performance and timely reporting from the project managers?”
Fortunately, the solution was pretty straightforward: he shifted management’s thinking so that the team built incremental Minimum Viable Products (MVPs) as opposed to trying to launch fully featured products (and getting bogged down too early in creating documentation); the teams also had greater latitude to pivot in order to meet the best possible outcomes. The communication loop was sped up. (For those who want more details on the process, but run into HBR’s paywall, Blank has also posted a version of the article on his blog.)
Agile vs. Waterfall
For those who are new to the “Agile vs. Waterfall” debate, here’s a very simplistic breakdown: Agile puts the emphasis on flexibility, with development broken into “sprints” and smaller goals/checkpoints (such as the launching of a MVP), all of it fed by frequent team feedback loops. As the name implies, Agile is meant to be super-reactive to the circumstances—which is great in office environments in which project requirements can change in a very short period of time, even after a product has been launched (such as a service or mobile app). Many companies have modified Agile to their own unique specifications.
By contrast, Waterfall is a relic of an era in which software shipped in a finished state. Project requirements are set in the beginning, and the final product generally aligns with those requirements. If the requirements shift in mid-stream, it can be difficult for the Waterfall-based project to adjust accordingly.
Nonetheless, a number of companies and projects continue to rely on this intensely plan-driven methodology; for example, a defense contractor might rely on a modified version of Waterfall when developing guidance software for a fighter jet, because a process based on MVPs and short sprints might be dangerous and not viable. Hardware is another instance where Waterfall can work effectively, although some engineers argue it’s easy enough to include frequent prototyping and focus-grouping in such a project.
The Right Mix
Many companies need to find the balance that works for them—some might choose a modified version of Agile with more infrequent sprints, for instance, or a higher benchmark for an MVP. With bigger companies, there’s often another issue: layers of gatekeepers (and sometimes lots of regulations, depending on the industry) that insert numerous bottlenecks to reporting and production; a “pure” Agile team often has a harder time successfully navigating those kinds of environments.
If an Agile-based project is delivered late, or experiences some kind of disaster, it might drive a company to adopt something closer to Waterfall for the next version or product cycle (“Waterfall… with daily Scrum-style meetings!”). That’s not necessarily the best solution, as Waterfall isn’t always the best way to handle nuanced or error-prone projects; and the issues that doomed a project during the first go-round might just as easily crop up again. Agile or Waterfall won’t magically fix a bad project manager, for instance.
In any case, AgileFall, which seems to merge all the potential roadblocks of Waterfall with the pace and milestones of Agile, sounds like a recipe for disaster. Every organization is different, but it’s a manager’s job to make sure that the project methodology fits the team’s actual needs (and goals).
