Waterfall vs Agile Project Management. How Can You Quickly React to Changes When Creating Apps?

Waterfall vs Agile Project Management. How Can You Quickly React to Changes When Creating Apps?

Change is the only constant in life. Although it’s been ages since Heraclitus has said these words, they are still up to date. And they well describe the app development process.

Changes in the market, new trends and technologies often enforce making adjustments to the original plan. We also can’t forget about the changes within the company that come up from time to time. How can you deal with all this?

The solution is agile project development that allows you to quickly react to changes and optimize the work of the team. That’s the reason why we follow this approach at Holdapp.

Find out what agile app development looks like in practice and what should you remember when you’re a product owner.

A brief story of the agile methodology

Not every revolution begins on the streets of the big cities. The change that revolutionized the IT world took place among the snowy slopes in Utah. That’s where several software specialists met in 2001.

They all knew perfectly well how to create waterfall projects. Back then there was a widespread belief that it was the only right approach. So the Project Management Institute, SEI, and Rational Unified Process were saying. The biggest companies in the world worked like this.

But our specialists were different. In their opinion, projects should be developed in an adaptive way. So apart from skiing, they spent their time on heated discussions. As a result, a list of their values and principles was made. It was called the Agile Manifesto.

It was the first step that lead to a revolution that went beyond the realms of the IT world.

The main idea behind the agile development

The Manifest values the most:

  • individuals and interactions
  • working software
  • customer collaboration
  • responding to changes.

Less important are:

  • processes and tools
  • comprehensive documentation
  • negotiating contracts
  • following a plan.

That’s the general idea that the 12 principles explain in detail. They tell us exactly what agile app development looks like.

Find out how we apply these rules at Holdapp.

12 principles of the Agile Manifesto and their practical use


Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.*

Practical use in a project
We get to know your business – its goals, customers, and industry. It allows us to deliver valuable solutions. If you have prepared KPI or OKR, persona profiles, or competitor analysis, then show us your materials.

Be honest and open. We are partners, so we need to know the obstacles your company’s dealing with. We also need you to systematically feedback our work, so we could efficiently add changes.


Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Practical use in a project
Oftentimes, creating the minimal viable product (MVP) takes several months. Publishing new versions usually means implementing new features, fixing the bugs, making UX/UI tweaks, or withdrawing bad ideas.

Thanks to the agile methodology, you can react to changes in a way that doesn’t block the entire software development project.


Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Practical use in a project
We organize periodic meetings when we present the progress we’ve made. Keep in mind that not everything will work and look perfect. What’s really important is for us to understand what direction we want to follow.

Pro tip When a new version of the app is released to tests, install it to check if it is what you’ve expected. This way you can quickly prevent the potential misunderstandings. There’s no risk that the product we’ve been developing for a year doesn’t meet your requirements. When you often carry out a progress verification, the worst case scenario is to waste maximum of a week or two.


Business people and developers must work together daily throughout the project.

Practical use in a project
We value open communication a lot. Our teams should be responsive. After all, we share the same goal. We all want to launch the best version of the product as soon as possible. That’s the reason why we need a streamlined communication flow. We exchange some of the information via emails but when we need a quick answer, tools such as Slack are the best.


Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Practical use in a project
With us, you work with professionals. Our developers have from 4 to 12 years of experience; QA testers have at least 3 years. So, we know what we do when we recommend certain solutions or advise against them. We do it to make your product better.

Don’t try to speed up the process. The pressure to launch the app in shorter time will have a bad impact on the app’s quality.


The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Practical use in a project
We mostly work remotely, but we still want to have direct contact with you. So, remember to be active during the meetings. Turn the microphone and camera on. Our team will do the same. We’ve even prepared some tips that make the meetings more effective.


Working software is the primary measure of progress.

Practical use in a project

The main goal is to create an app that works flawlessly. That’s the reason why we invest time in QA testing. This way, we can make sure the product answers the requirements.

Pro tip Don’t create artificial percentage metrics. Quite often 20% of features result in 80% of outcomes. Not every change is equally important from the business point of view. So, how can you measure the success? After the release of the next version of the app, check what impact a new feature has on people’s behavior. Do they use it? Does it result in an additional income? Do you attract more users? Find that out with analytics tools.


Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Practical use in a project
Lack of enforced deadlines helps us keep a constant work rate. Set up the version release dates with us. This way, the software development team won’t be overwhelmed with tasks and it will be more effective.


Continuous attention to technical excellence and good design enhances agility.

Practical use in a project
During the agile development process, we care not only about delivering new features but the entire app’s code. So, it’s necessary to, for example, save some time on code refactoring (which means rewriting some parts of the code). It often becomes essential when new technologies come up (if they can simplify the code) or when we need to change an old library to a new one.

Although the results of such actions aren’t visible at the first glance, they allow us to create new versions faster. They also optimize making changes.


Simplicity – the art of maximizing the amount of work not done – is essential.

Practical use in a project

In the beginning, we don’t talk too much about the features you want to see in the next versions of the app. It usually only makes the solutions more complicated.

Truth is that many concepts for the extensions never get implemented. “Done is better than perfect” – that’s the rule we live by. There will always be time later to polish the solution.


The best architectures, requirements, and designs emerge from self-organizing teams.

Practical use in a project
Our software developers are free to choose the architecture that suits your solution best. If we cooperate with technical-oriented members of your team, let the developers directly contact each other. It helps us build digital products faster.


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Practical use in a project
Project teams regularly take part in meetings when they come up with ideas to optimize the app development process. As a result, we change some arrangements. So, keep in mind that in the course of the project we might recommend new solutions.

Why agile approach instead of waterfall?

The adaptive model, which goes also by the name of iterative or agile, states that we don’t know everything, at the beginning of the project. Hence, we need to discover new requirements gradually. That’s the reason why we deliver the app in short cycles – to quickly react to new information that we receive from our clients as feedback.

In the business environment, this approach works well with complex development projects when the number of unknowns is high. It is usually related to building new products (including the software), solving complicated problems, or scientific research (R&D).

Pros of the adaptive model

  • Quick delivery of values to users (e.g., a new feature).
  • Possibility to send/receive feedback (remarks, comments, etc.).
  • Openness to changes.
  • Fast responses to feedback (e.g., by changing the direction of the development, priorities, or ceasing the work).
  • Focus on the value we deliver instead of completing the plan according to the schedule.
  • In case of the complex projects, such as app development, the working product itself passes more information compared to the percentage of the completed work.
  • A smaller number of dependencies among the tasks facilitates planning.

Cons of the adaptive model

  • It constantly requires keeping an interdisciplinary team.
  • Focus on the effectiveness of the entire team instead of using the full capacity of some members.
  • Processes and engineering practices must enable delivering a product in short cycles. If testing takes three weeks then it’s not possible to deliver a new version in two weeks. It’s the same case when a director must accept every decision to apply changes. It decreases the chance of working in an iterative model.
  • Software development can last endlessly, so a clear vision of what you want to achieve is essential. So are the tools that show whether the team goes in the right direction.
  • Fixed price agreements don’t allow us to adapt to changes. With that in mind, the  Time & Materials contracts are more practical in the case of agile methodology (even though they are more difficult to enforce). They give you more control over the app. Also, you don’t need to be afraid of the additional costs – contrary to the fixed price model. With the latter, you have to pay more when something unexpected happens.

Waterfall methodology – an alternative to agile?

The waterfall model assumes that you can foresee most of the potentially risky situations and prepare for them in advance. In other words, if you take enough time for analysis, you can create a plan that guarantees success. However, practice shows that we cannot foresee everything.

Unfortunately, a thorough analysis takes a lot of time. And it’s the only way you can create a detailed schedule, and estimate the exact time and budget. It significantly delays the start of the project.

This model is functional only in repetitive, predictable projects when you can manage the risk and the number of unknowns is small. It usually applies to simple apps with only a few features.

Pros of the predictive model

  • A thorough analysis of the matter and risks allows you to make the best decision on whether to finance or end a project.
  • Possibility to plan the availability of the key people and resources.
  • Documentation is created which facilitates passing the information about the product inside the organization.
  • Possibility to cooperate based on a fixed price contract.

Cons of the predictive model

  • It heavily relies on the fact that all the information can be collected at the beginning of the project (as requirements). You must meet this condition to estimate the cost and time of the development process.
  • Processes are defined upfront and oftentimes, they aren’t adjusted to a project’s specification.
  • The goal is to create the project according to earlier defined requirements. It often leads to focusing on completing the plan, instead of answering clients’ and business needs.
  • Changes make it necessary to plan the project all over again. They’re expensive and difficult to apply. So, it’s a standard practice to avoid them, even if they can bring potential benefit to the client.
  • Problems are visible only at the final stages of the project timeline. That’s because, in a fixed price model, the relations between the budget, scope, and schedule are permanent (it’s called an iron triangle). So, solving the problems is the procedure that takes place soon before the product launch. It has a great impact on the final quality of the app.
  • Teams responsible for certain stages of the product development pass the tasks between each other. As a result, some information gets lost, and specialists work on many big bundles of requirements at the same time. And it’s not rare to see them shift the responsibility for the errors.
  • Completing the project often takes more time than needed.

Agile vs. Waterfall. Which one should you choose for the project?

When it comes to solving complex problems (such as mobile app development), you discover many insights. The environment evolves, new people work on a project, and new business and technological possibilities come up. If you want to keep up, you need to constantly respond to changes.

In order to do that, you must adjust the solutions to the possibilities and problems that appear on your way. Ultimately, that’s what allows you to build a product people actually want to use. For your business, it means more conversions and a chance to make a profit.

I’ve prepared a table to show you what results can you expect at different stages  of the project.

predictive model vs adaptive

Main conclusions

The adaptive approach gives you full control over the product the team creates.  You can observe the work rate, change the priorities and the scope, or edit the requirements.

In a predictive approach, you see the product when it’s already too late for most changes. It usually leads to disappointment.

Agile or waterfall management - chart

Product management in a predictive model.

This model also decreases the chance that the app will make it on the market. Why? You need to remember that changing one element of the iron triangle (scope-schedule-budget) always has an impact on the other elements.

Limitations and predictions in agile vs waterfall model

The matter of the settlement model

The settlement contract is also important when you choose the project management methodology.

In a waterfall model, the entire scope is known from the very beginning. Based on that, the development team estimates the final cost and time of the project. So, you can easily settle the services with a fixed-price contract.

But in an adaptive approach, when you sign a Time & Material contract, the team defines the scope of work based on the available time and budget. It increases flexibility and allows the team to adjust to potential changes easily. No wonder this approach has become so popular.

At Holdapp, we prefer this variant and recommend it to clients, because it’s mutually beneficial. If you want to see how we apply it to our projects, let us know.


*You can find all the principles on the official Agile Manifesto website.

PM portrait - Anka

Anna Szymanek

Project Manager

Learn more

Project estimation

Let us know what product you want to build and how we can help you.

Why choose us?

Logo Mobile Trends Awards

Mobile Trends Awards 2021

Winning app in

Nagroda Legalnych Bukmacherów

Legal Bookmakers Award 2019

Best Mobile App

Mobile Trends Awards logo

Mobile Trends Awards 2023



client reviews

Clutch logo