The waterfall method is what the majority of the world thinks of when they think of the process of getting anything done across almost every industry.
Waterfall & Agile
Waterfall
The waterfall method is a traditional, linear approach to project management, often associated with industries like construction and manufacturing. It can be summarized as follows:
- Detailed Planning: Create comprehensive requirements and specifications.
- Fixed Quotations: Obtain cost estimates based on those specifications.
- Sequential Phases: Complete project milestones in strict order (design, development, etc.).
- Final Review: Evaluate the finished product.
- Revisions (if needed): Make changes based on feedback.
This approach works well when requirements are clear and unlikely to change, and where the cost of errors is high.
Agile Development: A Flexible Alternative
Agile development is an iterative approach, particularly well-suited for software development, where flexibility, speed, and efficiency are crucial. It can be summarized as follows:
- Collaborative Planning: Work with the client to define essential features for a Minimum Viable Product (MVP).
- Rapid Prototyping: Create basic wireframes and a clickable prototype.
- Sprint Planning: Organize features into short development cycles (sprints) for better budgeting.
- Iterative Development: Begin development, releasing testable versions frequently.
- Continuous Feedback: Gather user feedback early and often, adjusting features and priorities as needed.
Agile development prioritizes adaptability, allowing teams to respond to changing needs and incorporate user feedback throughout the project.
Why the Difference?
The waterfall method originates from industries like construction, where detailed planning and adherence to specifications are essential due to the high cost of changes. Agile development emerged as a response to the unique challenges of software development, where requirements often evolve, and the ability to adapt quickly is key to success.
Flexibility
Flexibility is important is because the tech industry is constantly evolving. As investor Fred Wilson puts it: “starting requires… the ability to iterate on the MVP and find product market fit” in his blog article “Starting and Finishing”. There is a distinction between getting something out and what he calls “finishing” and what we’re specifically talking about is how to get started. There are even critical changes in the tech environment that happen during the period from when we start and finish an app and startups need to be able to respond accordingly. Another assumption is that it’s hard to know much about your users until you get them a product to test.
Because agile focuses on flexibility, as soon as you learn about your customer the process is fit to quickly pivot.
Efficiency
Efficiency is key. We avoid wasting time on extensive RFPs and scoping phases, focusing instead on building your product. Most website and app components have been built before, readily available through frameworks like Ruby on Rails. This means we don’t reinvent the wheel on features like logins.
Some clients believe waterfall development squeezes more value out of agencies, but this is a misconception. Agencies target similar profit margins, and if they can’t meet that margin, the project isn’t viable. Agencies aren’t VC-funded, so cash flow is essential for payroll and attracting top talent. Lengthy proposals ultimately increase the overall project cost.
Speed
Speed means trying to get to a version 1 or a prototype as soon as is reasonable or as investor Paul Graham puts it, “launching too slowly has probably killed a hundred times more startups than launching too fast” in his blog entry titled “Startup Mistakes”. This allows you to test your original hypothesis as mentioned previously. Apps for example can be finished in as little as 3 months, a feat that only a few years ago took would take 6 months to a year. The faster we can get out a product, the faster our clients are able to test their products with their customers.
No matter how much budget our clients have we always do our best to deploy the agile development method (with few exceptions) because we believe that this has been shown to save time and money for our clients, and because we believe this process creates the best products.
Key Questions
Here are some key questions that we get about agile:
How do you use agile when we have a fixed budget?
Every client we have has a fixed budget to some extent. We understand that agile can be a huge stress point for our clients because no one wants to go over budget. Understanding this, we always scope out a project before starting and give an estimate as to how long we think it will take to get out a good application. That being said, if budget is fixed in an agile development environment, then features MUST BE variable. Meaning we are not going to be able to always get in all the features that a client wants, but we can stick to the original timeline and budget and get out a strong product, it just may not include all of the original features that a client wants.
Doesn’t agile put all of the risk on the client?
No – the reality is that the client takes a risk whenever they hire any vendor. Given a typical waterfall scenario, if a timeline seems unrealistic for the amount of features that are proposed (which is often the case), engineers will typically take shortcuts to get the job done at the minimum quality level. This creates technical debt that will come back and bite the product down the line. With agile, engineers and their managers can spend the necessary time that they think it takes to build a good and sufficient product, which is what our clients want. The last thing that our clients want is to create a product that just meets the minimum requirements of an RFP. If a given client doesn’t trust us (or anyone else) they shouldn’t be hiring them. There’s a lot that can be hidden and manipulated, even in a waterfall environment.
What if I know exactly what I want? Doesn’t waterfall make the most sense in that case?
Almost every one of our clients thinks they know what they want. We are ultimately getting hired though for our expertise and what we know to be true in every project that we work on, is that we learn things along every step of the way no matter how much research or up front work has been done. By its very nature, no project can have every question answered, and the ones that have most questions answered, still need to pivot to account for customer feedback and environmental changes.
