So you rounded up a crew of first class developers and some fortune 500 company commissions you to build an app that will change the game but you don’t exactly know how to go about building it?
Well, you’ve come to the right place. And even if your case is more low-key the same practices apply.
There are two main development methodologies that we use in the app development industry: Agile and Waterfall. The end goal of each is the same, to create an application, but the way they go about this feat is different.
Agile, what is it?
Agile is a development methodology that emphasizes the rapid delivery of an application. It is defined by “sprints,” a period of time allocated for a particular project component to be completed. The completed sprint results in a deliverable which in our industry is referred to as a “build.” A build is a pre-release version of an app; it is a portion of an app.
The features in the app are prioritized from most important to least depending on the business value the customer places them.
As work is completed and a deliverable is pushed, it can be reviewed by the project team as well as the customer.
Waterfall, what is it?
The Waterfall model or “traditional” approach emphasizes a logical progression of steps; it is a linear approach to software development. Unlike Agile which boasts its adaptability, one stage of development must end before the other commences and there is no going back to previous steps.
Below is a basic model of logical progression using the Waterfall method:
Project traits and Development Methodologies
Next, we will look at how these models act in accordance with common project traits as well as point out a pro and con of each.
Agile: The customer will be weighing in on many aspects of the project. Due to the greater number of deliverables (builds) in the development process, the customer develops a strong sense of ownership by working directly with the team to progress the project.
- When the customer is invested in the project themselves they are likely to provide more assistance or capital as they feel like most of the success of the project rests on their shoulders.
- Since the nature of Agile relies so heavily on customer involvement if they do not have the time to test or discuss certain features this can pose problems.
Waterfall: When project requirements are defined it’s as if they’re set in stone.
- Developers and customers agree on what is to be delivered before any of the actual development begins. This makes the planning phase more straightforward and progress is more easily measured.
- As all deliverables are based upon requirements documented before initial development, a customer may not see what is being delivered until it’s almost finished.
Agile: The most essential features get developed first. As the scope in many cases is undefined this is practiced so at least a basic version of the app gets produced when funding gets low.
- Say for some reason funding for the project has dissipated. With a basic version, you’ll at least be able to reach out to friends or investors that may be able to help progress your vision.
- It’s hard to see the full picture without all the features included. This may lead the customer to make poor decisions before everything is said and done.
Waterfall: The customer gets what was agreed upon. There is no partial package; it’s all or nothing with this approach.
- This eliminates dilemmas and speeds up project time.
- Customers are not always able to visualize an application from a requirements document. The app might not turn out as they had hoped.
Agile: Since the fate of Agile’s effectiveness rests upon the cohesiveness of a team, a smaller team is preferred. There is a high degree of coordination and synchronization required using this method and increasing the size of your team naturally reduces the strength of these traits.
- What is being done and should be done is clearer due to the small nature of your organization.
- It takes longer to implement features since fewer individuals are working on them.
Waterfall: With this methodology, it’s like passing a baton to the next runner on a track. Coordination and synchronization are limited to handoff points.
- Progress is more easily measured; the full scope of work is known in advanced.
- May be difficult to follow the narrative of a project. You might end up with a bunch of pieces that simply don’t fit together.
Agile: Since this methodology welcomes changes with open arms, fixed-funding is risky. Customer involvement is so high that if you don’t stand your ground as the developer you’ll become the slave to the increasing wants, needs, and changes. That’s why Pay-as-you-go is the name of Agile’s game.
- If the customer is excited about how the project is turning out, they will likely call for additional features to be built. This gives you more work.
- If you choose fixed-funding, an argument may ensue between the customer about what/what-not was included in the original scope.
Waterfall: Fixed-price contracts work well here. Since the project requirements are so rigid, the scope must be defined in advance and remain steadfast.
- What you earn is dictated beforehand. There shall be no ambiguities once the project begins.
- The customer may feel that they did not get what they paid for once all is done.
Which methodology comes out on top?
The simple answer is: it depends.
Across the board, Agile is implemented in projects more. A 2015 survey done by Hewlett-Packard survey puts this into perspective:
Agile principles seem to fit the current digital landscape better. Evolving needs and change seem to be present throughout all projects.
But what we would recommend is developing your own hybrid methodology. Don’t look at these methodologies as commandments, look at them as recommendations. Take the flexibility of Agile and mesh it together with the rigidity of Waterfall. You are unique and so should be your methodology. Tailor it to what suits your environment best.