Why Agile, Not Waterfall? Best Approach to Product Development Management

Miłosz Lisiecki - PMO Team Lead
7 minutes read

Creating any kind of application, no matter if it is a web application, desktop application, or native application, is a challenging task. Once you define problems that you want to solve for your users with your application, and after you define strategic goals and the way you want to monetize your upcoming product – it is time for the development phase. It may be found as a more accessible part because now you just need to follow the plan which you have already envisioned, and put some time or money into development, depending on if you want to code yourself or be helped by professional developers.

Your intuition will probably bring some kind of step-by-step plan that you would like now to follow though, so you will probably start with designs for all planned features, do the analysis, create the user interface, and plan your users' experience. Later you will code the features around the defined ideas and the values your product is going to provide to the market, and in the meantime write proper documentation for each of them. Later it will be tested by you, then by quality assurance specialists, and finally you are ready to launch the product to the market. It is perfect... until you start collecting feedback from your users.

There are some bugs to cover, some functionalities are not understood by the users, and maybe they do not know how to use them. The function which was supposed to be a market changer is not gaining as much interest as you thought. And you have already spent the money that you had for development, and you wanted to start to get revenue now to cover your expenses. You did proper research, you had a perfect vision for the product, you created a perfect plan – it had to work! Yet, something went wrong.

Maybe you have planned too much and you have not thought about testing your assumption enough on the live product developed in an iterative way. In the IT world, we call those two management approaches waterfall and agile. The first one is more-less what was described above and it really looks like you follow the water in the waterfall, you do it one by one, and you cannot turn back, you follow the plan like the water is falling over the vertical drop. Intuitively it seems like a proper approach, but…

The Waterfall Model

The waterfall approach was first presented by Felix Torres and Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956. The first detailed diagram of the “waterfall model” process was introduced by Winston W. Royce, however, even those brilliant individuals described that model as risky. The classic model has defined 6 phases that are filled in order:

  1. System/software requirements
  2. Analysis
  3. Design
  4. Coding
  5. Testing
  6. Operations

In different adaptations, some of those steps are merged or followed in a different order (for example the analysis phase might be held as the first one), but the general idea is this: you go to the next phase after the one before has been completed. Usually, it also generates comprehensive documentation, so the people involved in the previous phase could communicate ideas to the ones working on the other. Sometimes it is also accompanied by the GANTT chart (or similar, like the milestones) that illustrates the project schedule.

The Risks of the Waterfall Approach

It all looks promising, although we have already mentioned that it may not really work well, so let’s look at the risks this approach generates. The most important seems the fact that the possibility to verify assumptions comes after the whole development process is completed. Any needed changes cause additional costs at this stage or result in issuing a product that is unfriendly or full of bugs. The development itself is not flexible and the business value is being tested at the end of the whole process.

The waterfall model is based entirely on following a set of certain steps. The methodology, in its traditional form, leaves almost no room for unexpected changes or revisions. Testers, for example, need to wait until the development is finished. At this point, the project has likely taken considerable time to complete, so large revisions could cause significant delays. As the working software is never produced until the end of the project, you would not really know where you stand until you reach the operational phase. Neither you nor the developers are completely sure whether you are going to deliver on time until the end, by which time it is usually too late even for damage control. When the project starts to run out of time and money, testing is the only phase left. This means good projects are forced to cut testing short and quality suffers because creative work usually takes longer than expected due to some unforeseen issues. Handling those unexpected issues is actually also a thing that the waterfall model has problems with. Documentation should take place throughout every phase of the process, ensuring that everyone involved is on the same page despite the sequential progression of the project.

The risk seems to be heavy and the question is…

How To Reduce It?

The solution here might be using an agile approach. You have probably heard about it – but what makes it a better choice when you are still working on the same problems with an idea that may not exactly fit the market as planned, and when you can still face problems in the development or budget limitations that may reduce the effort you would like to put into testing (and here one disclaimer: every tester will tell you that there is never enough time for testing)? The key to success might lay in the magical word: iterations. You can develop your product in portions, with each update providing one or a set of additional values to your product after you complete work on a value provided in the previous “generation” and you collect feedback about it. Then you plan the next iteration with other values you would like to add to your product and again validate your assumptions with little effort, so in case they were wrong – you can abandon or validate another solution to the problem.

The Agile Model

We could basically finish here because that is the key to agile software development – the client feedback loop connected with (or being actually at the heart of) the Agile Model. But what really makes it work that well? Imagine the waterfall model, but as compressed and as repetitive as possible.

Picture 1: The comparison between the waterfall and scrum

All the agile adaptations follow a few very simple rules, described in a paper called "Manifesto for Agile Software Development"[1]. The authors of the manifesto declared that they valued:

Individuals and interactions over processes and tools;

Working software over comprehensive documentation;

Customer collaboration over contract negotiation;

Responding to change over following a plan.

This means that they proposed that each time when you need to choose between people collaboration and processes or tools, you need to choose the more humane way and let people work and talk, and adjust processes or choose the tools that will fit them. It doesn’t mean that the processes, for example, are not important – we all know that processes help people to organize, especially in a repetitive environment. As it has already been stated in the paper – software development is a creative process, you often do something in a specific, innovative way and you need to listen to your people. Similarly – documentation is important, especially for the people who will be working on your software in the future, but the most important thing is to provide working software to the market, as it is simply what you are doing this for, and what will earn money for your business. It does not mean that they suggest skipping documentation in Agile – it means that when you need to choose between documentation and working software, you ought to value the second thing more. I hope that it is now clear that contract negotiations are less valuable than collaborating with your customers (usually the target audience, so-called users, but not always – depending on a different business model; it is actually a thing to discuss in another paper), so you need to listen to your customers more than negotiate contracts. They will stay with you if you do so, it is as simple as that. This is why I have already mentioned the customer feedback loop, which is a powerful tool. Finally, you need to be ready to respond to changes and respect them more than following a plan. In the first chapter of this paper, I have already pointed out that being too strict with your plan may cause failure. It still does not mean that you do not need a plan – obviously, you need to have your vision and follow it. But the vision needs to be a general plan of where you intend to go at that moment, rather than being something absolute and final. Tunnel vision can be the biggest threat to your business.

Those 4 simple rules were also later covered with 12 agile principles. I will not quote them here, but they cover what to focus on while gaining customer satisfaction, as well as continuous delivery, attention focus, changing requirements, ways of communication, simplicity, or self-organizing teams. Those principles are a vast topic that would need a separate article. Follow our blog, more on this topic coming soon.

Agile Methodologies

So basically, there is nothing more you can find in terms of the fundamentals of agile. It is that simple and this simplicity really works, but often there are additional frames to build them up over Agile (we call them frameworks), that help to manage developers, yourself (as a product/business owner), and the development process itself. Therefore, there were different Agile methodologies developed, among which are worth mentioning Extreme programming, Lean, Kanban, and Scrum. Especially the last two of them are the most famous in the software development world, that are Kanban, Scrum, and a mix of them, called Scrumban.

Kanban – A Visual-Based Agile Framework

Kanban is especially well-known for its boards, which show the current status of the topics held by the team in a simple, graphical way. It is divided into a few columns, showing different statuses of the work progress, just like we had them in the waterfall, but each topic is going through those columns separately, and none of them needs to wait until the whole bunch is completed at once. It is like walking in the city – you are not waiting for all green lights to turn on throughout the whole road, but you rather go from one to another. We call it “workflow management” and it is usually supplied with the user stories (short descriptions of the new features, written in the natural language, typically in a standardized way, using “As a <role> I can <capability>, so that <receive benefit>” syntax). Each user story is first stored in the product backlog, the place where we add feature ideas and develop them. Then, during the new software delivery process, they go through different statuses that are “ready for development”, “in-progress” and “ready”, usually divided into self-describing sub-categories, like “in development”, “in code review”, “in testing” and so on. The division of the columns is adjusted to the project’s or product’s needs. There is also one important topic connected to Kanban, which is the “work in progress” limitation (WIP); typically you cannot hold more than 1 user story (per developer) in each status, so the flow can go smoothly, without distractions on so many topics and being deployed in-time.

Scrum – Perfect for Scope Delivery Projects

Scrum guide (the main document describing this methodology) provides more restrictions, that are focused on the roles and responsibilities of scrum team members (also introducing a scrum master – a person responsible for adjusting projects and the company’s Agile implementation and promoting the organization’s Agile transformation), defines 4 main meetings (ceremonies) and defines its own principles, pillars and limitations. Scrum also describes that the iterations should be done regularly, in 1-4 week intervals (sprints; and yes, you are probably right – the less, usually means the better in this case). What is most important is that each iteration is focused around a specific value that you want to build up to your product, which we call a sprint goal. You organize the whole sprint around this goal, so you plan tasks for developers who would mainly focus on it, and after its completion, you could provide the product’s new functionality or enlarge the existing one (yes, after testing the minimal assumptions done before). This way of working is perfect for products in the early stages of their lifecycle, but will work well also for those that are developed further. If your product is already well-developed and there is not much to discover, or you focus only on maintaining it, Kanban or a mix of them – the Scrumban, might work better. At Polcode, we use scrum in our scope delivery projects and we work on projects together with clients. There will be a separate article discussing this topic more deeply.

Why Choose Agile?

Coming back to the problem stated in the first paragraph of this article, with problems that cause launching a product to the market that was not getting expected results, customers interest and revenue – the reason for that might be a development management case, that was too much-planned upfront, without testing small assumptions and simply not working on the development agilely enough.

Agile means managing the people involved in the product’s creation, vision, and development, but also the lifecycle of the product (using the customer feedback loop and other methods). Listening to your customers and reports coming to you from the market and your friendly users will help you to find a focus for your next little assumptions that you are going to test by developing ideas, software, and launching them to the market one by one, little-by-little, as small and as often as possible. Verify it all, correct, sometimes even cancel. Be brave, the agile transformation will never get to the finish line, but it is a fun way to work; as modern products will need your attention constantly, you need to let them live their lives a bit. The journey itself is sometimes more important than completing a goal.

And at the very end, I would like to leave some hope for the waterfall enthusiasts – there is also a place for this way of working, but in rather more repetitive environments, where you know the risks, can define and mitigate them and where you do something very similar constantly. There, where you don’t need to experiment, because you are a master and the work is not as creative as the software development usually is.

[1] created by Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick in 2001

On-demand webinar: Moving Forward From Legacy Systems

We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.

moving forward from legacy systems - webinar

Latest blog posts

See more

Ready to talk about your project?


Tell us more

Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!


Strategic Planning

We go through recommended tools, technologies and frameworks that best fit the challenges you face.


Workshop Kickoff

Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.