Waterfall or Agile? Or both? In this article, we examine both strategies and discuss our preference for a hybrid agile waterfall approach.
Waterfall
In a traditional Waterfall methodology, a project goes through several phases: requirements, design, implementation, verification, and maintenance. The problem with using Waterfall primarily consists of time to market, and the amount of bloat that plagues projects. Each phase is a gut-wrenching effort to extract all possible scenarios and outcomes before moving on to the next phase, thus impacting schedules and milestones significantly.
Couple a Waterfall strategy with a “let’s invite all the managers and directors to the requirements meeting at 3pm” and no wonder so many projects fail before they even launch.
Agile
On the other hand, Agile methodologies pride themselves on quick time to market, but often forget significant details. The core focus of Agile is development cycle time. The downside is, Agile projects often end up becoming a patchwork of code and technologies. Scope creep and unidentified requirements can be a nightmare in an agile process.
Wait a minute, you want us to add what feature? That changes everything!
Hybrid Agile Waterfall
Our process consists of a hybrid Agile Waterfall methodology, which allows our clients to see results as quickly as possible while mitigating risk from poor, premature decisions that often plague Agile processes.
We leverage the best of both methodologies, employing a waterfall-like approach to gathering requirements and determining scope, which allows us to optimize architecture decisions. Then, we use an Agile process to develop and deploy your minimum viable product (MVP), and continue to iterate as we add in new features based on the initial set of requirements, as well as any feedback from the users of the product (i.e. product pivots).
Summary
The upside of this hybrid Agile Waterfall approach is simple: for a little more time at the beginning of the project understanding requirements, you iron out most of the possible scenarios that might come about during the product lifecycle. Sure, there are always surprises, but you’re much more prepared for these pivots, because the architecture and requirements have been stress-tested with an extensive amount of discussion about possible long term strategies with the product.
Need to get your project back on track or need to discuss an upcoming project, contact us!