Although many hardware and software companies rely on some variation of Agile to build new products, the methodology has received its share of criticism over the years. This month, Andy Hunt, one of the developers who co-created the Agile Manifesto, argued that development teams’ implementation of Agile often failed to live up to the promise. But what are the alternatives? Waterfall Methodology—which some old-school folks sometimes call the “traditional” method of development—requires its teams march through a preset series of steps, each of which must be completed before the next can commence. While those steps sometimes differ from company to company, in broad strokes they go something like this:

• Establish Requirements
• Design
• Code
• Test (and Test Again)
• Fix Bugs and Issues
• Integrate With Other Platforms/Technology Stack

In theory, Waterfall works because it establishes the parameters and design of the project from the very beginning, and allows for careful and methodical progress. But according to Waterfall’s critics, anyone relying on the methodology needs the following things to occur:

• A (Reasonably) Well-Defined Set of Requirements Having a set of requirements from the outset is an important factor in Waterfall. However, people have ideas—and sometimes those ideas occur midway through a project, and force a radical change in the project’s goals. It happens in both the hardware and software worlds. And when those ideas occur in midstream, it can prove devastating for the project’s budget and timeline.

• Any Changes to Requirements and Goals to Be Small As anyone who’s ever worked in tech can tell you, sometimes the changes to a project are radical. When Apple released the iPhone, for example, it forced Google’s Android team to chuck its existing work on smartphones and start from the very beginning.

• Testing and Integration to Go Smoothly Virtually all software projects involve lots and lots of code, and not a lot of time to review said code if the team wants to make its release date. With hardware, it’s a similar conundrum: Lots of things work very well in controlled conditions, only to break once they hit the real world. And then there’s the small matter of integrating the project with the other elements of the company’s technology stack: If the amazing smartphone you produced doesn’t play well with your cloud service, you have a problem. Waterfall depends on everything related to testing and integration proceeding as smoothly as possible—and oftentimes, that just doesn’t happen.

With Waterfall, if things go very wrong, the team not only fails to deliver the project on time, but the project itself is a hash of elements that don’t play very well with other software and systems. Still other companies have tried for a hybrid approach, one that relies on Waterfall methodology to set requirements and goals, but then reverts to Agile’s flexibility in order to get the job done. Such innovations can fail, however, without a solid manager at the helm. All of which culminates in the ultimate point: Whether a company opts for Agile, Waterfall, or some other development methodology, the most important element is a manager or stakeholder who can keep the project on the rails. No process is a silver bullet; without the right people at the helm, any effort can implode.