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 can be summarized as follows:
1. Prepare the requirements of what you are trying to build with detailed specifications
2. Get a quote for those specifications
3. Milestones are created and are completed by each phase (design, development phase 1, 2 and 3, etc.)
4. Review the product after it is finished
5. Make comments on the finished product
6. Revise the product accordingly
Our agile development process can be summarized as follows:
1. Work with the client to decide on features for big picture features for an MVP based on the problem that the client is trying to solve
2. Design basic wireframes that we use to build a prototype (using InVision)
3. Scope out the features and the wireframes and organize those into two week “sprints” in order to come up with a rough budget
4. Start the development process
5. Send out builds once a week and start testing with users as soon as possible. Adjust features, scope and deadline considering the risks for the deadline.
6. Add new features as you learn from your customers and what is important to them
7. Reprioritize sprints accordingly to customer feedback and to fit the budget
The waterfall method was taken from the real estate development industry. In this industry an architect draws up detailed specs that need to be perfect. Then those specs go through multiple levels of approval before a building is ready to begin construction. This makes a lot of sense as it can cost a fortune to make a small change (the aeronautical industry is another industry where bugs and mistakes cannot happen so specs that are perfect are important).
Agile development was created as a response to waterfall development not being appropriate for building most types of software. Software developers started to realize that software was very different than real estate development because of the focus on 3 key priorities: flexibility, speed and efficiency.
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 is focused on not wasting time on huge RFP’s (requests for proposal) and scoping periods and spending as much time as is possible in actually building out products. Nowadays, most of the elements that we need for websites and apps have been built before and are readily accessible via programming frameworks like Ruby on Rails. That means when we create something like a login, we usually don’t need to spend time thinking through what the architecture for a login looks like. The lie is that as a client you can squeeze more out of an agency by using waterfall development. The reality is that all agencies target a similar margin and if they can’t hit that margin, then the project is not one that is feasible. Agencies are not VC funded and therefore in order for them to make payroll and attract good engineering talent, cash flow is critical. Therefore, if an agency spends a lot of time working on lengthy proposals, that all gets baked into the overall cost of development in some form or fashion.
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.
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.