Agile, Waterfall, and Scrum are all buzzwords in the project management field and particularly in software development. But what are these project management methodologies exactly? What is the difference between Agile and Waterfall and Scrum? And what value does knowing this information provide you, the budding software entrepreneur?
If you are considering joining the thousands of people taking a shot at becoming the next big thing in the app world, to succeed in reaching that status you need to start with a solid foundation.This means pursuing an appropriate project management method. How is the process of building your investment being managed, what are the benefits and disadvantages of each approach, and how will this impact in whose hands you place your trust to end up with a winner.
The following guide will address the most common questions regarding traditional project management approaches. We’ll explore the difference between the Agile and Waterfall methodology. We’ll also look at Scrum and how it has its place as a form of Agile testing. Hopefully, by the end of it you will have a better idea of where to start:
Waterfall Project Management – Where It All Began
Waterfall
Waterfall is the oldest form of project management method currently in use. It is a sequential model of delivering projects of all kinds, where one deliverable must be finished, verified and approved before commencing the next in a linear fashion until the product is completed. The waterfall project management methodology gets its name from the one-way (downward) flow of the project which is much like a waterfall.
Waterfall has its place in project management methods and it is best suited to well defined, small projects which usually are constrained by tight deadlines or budgets – in other words, the parameters are set and there is no room for deviation.
Subscribe to our Guides to continue your learning.
Get new guides sent directly to your inbox so you can stay up-to-date with everything related to mobile apps.

Putting the Waterfall Methodology Into Practice
Waterfall management has its benefits, which is why at Glance we apply it to our Discovery and Design phases. This is due to the shorter nature of these phases and the certainty of the process. Some of these benefits are:
- We can say with certainty: what will be delivered, when, how much it will cost and what is required from our clients. This makes it very popular with clients as they know exactly what to expect upfront.
- Waterfall processes have been extensively documented which minimises risks due to staffing issues – sick staff member? No problems, the documentation will ensure the replacing staff knows exactly where to pick up from.
Agile vs. Waterfall Comparison: When NOT to Use a Waterfall Methodology
When it comes to building software though, and comparing the difference between Waterfall and Agile, Waterfall project management is often not the best approach due to the rigidity of its sequential manner. This is why at this point we move into Agile management. More specifically, we advance into Scrum, which provides the flexibility to deliver the right product to our clients (more on this in the next section!).
Changes in the market, political environment, and even within the enterprises commissioning the software (i.e our clients) are some of the biggest disruptors in a project. When following the Waterfall project management methodology, input from these emerging factors is almost impossible until the end. At this point, it can be quite a costly exercise. If using the Waterfall management method for software development, we can possibly end up with a potentially obsolete product by the end due to these unforeseen changes. In terms of the difference between an Agile and Waterfall model, this is the major flaw within the Waterfall project management approach and its application in complex and lengthy projects – such as building an app.
Agile Approach To Project Management – The Younger, More Flexible Model
Agile
Agile project management dates back as early as the 70s. It began when the need for a more flexible approach than Waterfall started to emerge with the rise of software. During the 90s various methods of providing this flexibility started to arise such as Scrum, DSDM and XP. All of these are now considered frameworks to deliver Agile, which came into its current form in 2001.
Agile itself is an ideology which proclaims the following set of values labelled the ‘Agile Manifesto’ which states:
We value these more than the items on the right | We value these, but not as much as the items on the left |
Individuals and Interactions | Processes and Tools |
Working Software | Comprehensive Documentation |
Customer Collaboration | Contract Negotiation |
Response to Change | Following a Plan |
What the above describes emphasises the major difference between Agile and Waterfall testing. This is the innate flexibility and collaboration that Agile facilitates over other project management approaches such as Waterfall.
The Difference Between Agile and Waterfall: Agile Advantages
The Agile project methodology is an iterative, overlapping approach to software development projects. What this means is that the product goes through multiple consecutive cycles of planning, building, and testing functionality. In leveraging Agile testing, we can acquire acceptance from the client as we go rather than at the end when the product is finished. Doing so at the end tends to result in a costly reworking of the entire app.
What Agile enables as an approach to project management is:
- Flexibility to allow for changes that naturally arise from seeing a product come to life. These changes can be made throughout the process rather than at the end of the project.
- A sense of collaboration and rapport between client and supplier as they work together to develop a built-for-purpose product.
Within the Agile project management methods, there are tools that allow for the delivery of its values. After all, Agile management is aimed at describing what to deliver but not how. This is where the frameworks described earlier like Scrum come in.
Ok, So What Project Management Method Is Scrum Then?
Scrum
Scrum and its terminology is derived from its comparison to a play in Rugby. The aim is for the team to work together to get the ball across the line by passing it backwards and forwards between team members.
As mentioned in the previous section, Scrum is a project management methodology used to deliver projects in an Agile way. So if Agile is a lesson to be learnt, Scrum is the book that will enable this.
The Scrum team and their associated roles, events and artefacts all work together and are essential to the success of Scrum and its proper usage in software development. The rules of Scrum then bind all of the above together and help shape the relationships formed within the Scrum Team.
The Scrum Team consists of:
- The Product Owner (usually the client or Project Manager from the client side)
- The Development Team
- The Scrum Master (at Glance this role is fulfilled by our Project Manager)
Scrum Events are put in place throughout the development cycle to facilitate communication between the team and at the same time minimise unnecessary meetings.
- Sprints – these are the development cycles which generally vary between 1-4 weeks depending on the project.
- Sprint Planning – sessions, where the work to be performed in the sprint, is planned
- Daily Scrum – daily meeting to share progress and concern with the rest of the team
- Sprint Review – demonstration of work completed for the sprint at the end of that cycle, this is shared with the client
- Sprint Retrospective – internal meeting held at the end of the Sprint with the Development Team to discuss what went well and what can be improved on based on the last cycle
Scrum Artifacts are the products of each Sprint and provide a measurable way of assessing a project’s health. They are:
- Product Backlog – a collection of all tasks to be performed by the end of the project
- Sprint Backlog – selected tasks from the Product Backlog to be completed in the current Sprint
- Increment – the sum of all tasks completed in a Sprint plus all work completed in previous Sprints packaged into a build that can be demonstrated to the client for approval
The Development Team work in conjunction with the Product Owner and Scrum Master to deliver a shippable product Increment by the end of each Sprint. The product is presented to the client and any changes required are noted and agreed with the client with regards to schedule and the next sprint is planned. This cycle continues until the end of the project.
Comparing the Difference Between the Agile and Waterfall Model
Methodologies
Summarised below is a comparison of the two methods:
Agile | Waterfall |
Relies heavily on its people | Relies heavily on its documentation |
Works better with ambiguous scope | Works better with a defined scope |
Allows change but at the expense of time, cost or scope | Changes are limited ensuring adherence to a pre-agreed schedule, budget or scope |
More extensive client involvement is required | Client involvement generally only at milestone points |
Suitable for Time and Materials type agreement | Suitable for fixed budget project |
Details in Requirements and Design emerge with the development process | Requirements and Design defined up front |
So… What Is Ultimately The Best Method For Project Management?
Well, the answer is it depends
Neither method is perfect nor superior to the other. As you look at the difference between Waterfall and Agile, they simply serve different purposes in different contexts. We’re here to help you figure that out.
Here at Glance, we believe each project is unique, which means each product will have different requirements. Most of our projects use a hybrid of project management approaches depending on things like:
- Budget/schedule constraints
- Length of the project
- Complexity of the product/features
The key takeaway is that one size does not fit all when it comes to a project management method. Just knowing the answer to a question like “what is the difference between agile and waterfall?” doesn’t actually help you determine which is best for your needs. The right approach needs to be tailored to the project, much like communications need to be tailored to our clients.