Agile vs Waterfall Approaches To Project Management

Here at MindK, we have experience in managing Agile and Waterfall projects and have firsthand knowledge of the whole software development process, as well as the strengths and weaknesses of both approaches. So, to help you understand the major differences between these two methodologies, we decided to compare them based on six characteristics, namely:

• workflow;
• project planning;
• project requirements;
• leadership style and communication;
• client involvement; and
• suitability.

Key differences between Agile and Waterfall software methodologies

Project workflow

Waterfall

Waterfall is one of the oldest approaches to development. It comes from the construction industry, where it’s typical to build houses one step at a time, from laying foundations to raising the roof. The whole building is commissioned in one go and workers rarely have to go back to rework the foundation once they’ve built the walls.
Waterfall follows the same principle. It divides the development process into 6 distinct phases:

1. Discovery – the team gathers a complete list of requirements for the whole project.
2. Design – software architects decide how to build the application and how it’s going to work. Waterfall projects require large upfront planning and extensive documentation.
3. Coding – developers implement the design according to the requirements.
4. Testing – QA engineers check the whole codebase for bugs or inconsistencies.
5. Deployment – developers integrate various pieces of the final product and organize a demo for stakeholders.
   Maintenance – the team provides support and fixes bugs discovered by users.

As there’s no way to go back, each phase must be 100% complete before the team proceeds to the next stage. Each phase has a clear list of deliverables and review criteria, which simplifies project management. The whole product is designed, built, and tested in one go. All business value is delivered at the end of the project.

Agile

Agile product management was born as a lion-hearted answer to challenges of the traditional Waterfall approach. Instead of completing one phase after another, Agile methodology breaks the whole process into smaller parts called iterations.

Iteration is a time-boxed period (usually one to three weeks or more, depending on
project needs) when the development team works over the selected features and converts them into working software.

Each iteration includes the key phases of the software development life cycle, namely, analyzing, planning, coding, and testing. The result of each iteration is working and tested software.

With Agile, the team has an opportunity to validate product quality much faster than compared with Waterfall. Short development iterations allows product testing sooner, then improving it based on the feedback received.

Here is where you can see the fundamental difference between Agile and Waterfall workflows – business value is delivered, not at the end of the project as with Waterfall, but after each iteration. In such a way, the team delivers parts of the functionality step by step, iteration after iteration.

This is exactly how we developed a melody search engine for Grammy Award winning producers. In just 5 weeks we created a basic version of the solution called a Proof of Concept. After the app was highly praised by the public, we developed a feature-rich web app together with mobile applications for iOS and Android. Today, we keep on improving applications and creating even more pleasure from melody search.

Project planning

Waterfall

As far as Waterfall presupposes developing software by means of a sequential, linear process, the right planning phase is a key success factor of the whole project.

First, because if planning is done wrong, a phase risks being late and will thus push every other subsequent phase. This means the project won’t meet deadlines and likely exceed the budget. This is exactly why the Waterfall methodology doesn’t allow changes during the development cycle. Changes will likely affect both the project timeline and budget in a negative way.

Second, everyone in the team needs to have a crystal-clear idea of what the project needs and how to reach the goal before moving to the next stage. Until both the requirements and plan are well-documented, the project cannot move forward.

To plan the processes, control deadlines, and progress in a Waterfall model, we at MindK use a Gantt chart or horizontal bar chart. The Gantt chart is one of the types of bar charts that illustrates a project schedule. It consists of blocks located on two axes: horizontally – tasks, vertically – time spent on their implementation. The chart shows what tasks are included in the project, who is responsible for them, and how long each place lasts.

Source: teamgantt.com

Among the key benefits of using Gantt charts as the main tool for planning in Waterfall are:

• Ability to visualize the project plan across time: it allows creating a project plan and getting a visual representation that can be shared with the entire project team and all the stakeholders.
• Possibility to identify relationships between tasks: it enables documenting and understanding task dependencies. In case the dependent tasks change or deflect, it is possible to see the impact of changes.
• Better resource management: it helps track the workload of team members and reassign tasks if someone is overburdened.

Such detailed and upfront planning in Waterfall has two sides. The good side is that the project begins with a detailed analysis of the customer’s requirements and a detailed plan on how to meet them. The plan and stages are approved in advance and well documented, so the project team just needs to follow them.

However, the problem with using the Waterfall method is that such upfront planning is very tricky.

Planning is still guesswork. It’s almost impossible to foresee all the problems of a project in advance. Anything can happen – business requirements may change, the development team may bump into unforeseen technical challenges during the process, the testing phase may uncover integration, security, or other critical issues, and so on. As a result, the project may need additional iterations or even the need to start over, which means extra time and cost.

Agile

Compared to Waterfall, Agile presupposes a more flexible approach to the software development process. Agile teams find responding to changes more valuable than following a plan. A plan for them is just one of the possible variants for the future. Teams are more focused on delivering the highest possible value to the client and users as soon as possible.

Team members start working without knowing all the requirements upfront – it is possible that a particular set of features will appeal to users more than expected, and some features initially considered critical may become useless.

As a rule, planning for Agile teams works on three horizons: release, iteration, and the present day.

Release planning is focused on answering the questions of scope, schedule, and resources for a project. Release planning usually takes place at the start of a project. A good release plan is updated during the project (often at the beginning of each iteration).

If the release planning looks forward to the product release, that is often about three to six months out from the beginning of a project, iteration planning takes into account only the duration of a single iteration.

Iteration planning takes place at the start of each iteration and is aimed at prioritizing user stories (a short and simple description of a feature written as if the person is the one who needs it) for the next iteration, splitting them into tasks.

As a matter of fact, you can even make a release after each iteration, if required. That is the beauty of iteration that each time is aimed at creating a working production-ready piece of software. Lastly, daily planning is designed to coordinate work and synchronize daily efforts.

Planning across three-time horizons and different levels — release, iteration, and day — has two important advantages.

First, it emphasizes that plans are created for different reasons. The daily plan is very precise, the iteration plan is less precise and lists user stories for each iteration, while the release planning is the least precise of all and only contains a prioritized list of desired features for the project.

Secondly, such three-level planning helps view the project from different perspectives. You see, the development process is not amorphous, it is filled with planning throughout each phase and each level, instead of a long and
all-or-nothing plan from the start.

You may wonder whether the splitting into small tasks shades the long-term goal of the project. No, even vice versa. By focusing on short-iterative releases, Agile actually benefits the long term. When you get an intermediary result to be tested as soon as possible, it allows you to make better long-term decisions.

Project requirements

Waterfall

Requirements analysis on the Waterfall project is the foundation for project planning. The more precise the requirements, the better plan you get, and the more chances for the project’s success.

The requirements gathering starts at the very beginning of the project – in the Discovery phase. The phase requires a lot of research, analysis, and documentation effort, so it is lengthy. It can take approximately four to eight weeks and more (everything depends on the project complexity) and may consume around 10-15% of the total project costs.

At this stage, all requirements for the future software are gathered and documented. It involves discussions with stakeholders, interviews, questionnaires, and so on. The main goal is to extract requirements for future software, including business requirements, user requirements, and system requirements (functional, non-functional requirements, risks, uncertainties, possible roadblocks, and similar).

When the product discovery process is finished, the team and the client receive valuable deliverables to use as a springboard to start the development, namely:

• project scope & vision statement;
• software requirements specification (or SRS) that outlines all possible system behaviors under different conditions, data requirements, requirements for external interfaces, and so on.
• project schedule (can be illustrated in terms of the Gantt chart we discussed above);
• project budget estimates; and
• wireframes/mock-ups/interactive prototypes (when required).

Template of the specification document we use at MindK

Agile

There is no separate discovery phase in Agile. As follows from the Agile project workflow, Agile, in contrast to Waterfall, is focused on delivering pieces of the working and tested software after each iteration to validate the ideas, collect user feedback and iterate.

Hence, in Agile the requirements gathering runs in parallel with the delivery. It is not a phase, but a continuous loop of discovery and delivery – you give a piece of functionality to users, receive feedback and decide what to do next.

But how to decide what to build from the very start? This is where prototyping, mockups, and wireframing comes into play. All these “tests” help the client and the development team answer the questions of whether they are moving in the right direction.

Leadership style and communication

Waterfall

The project management methodology significantly influences the way your team works. The Waterfall methodology presupposes a “top-down” approach to leadership.

In the Waterfall environment, the software teams move through phases of product development in a step by step manner, the team members work on their own part and don’t cooperate much with each other. The interlink between the team members and the stakeholders is the project manager.

In that light, the top-down approach means that management tells the project team exactly what to build and when to build it. The deciding power resides with team leadership, instead of being distributed among team members – the project manager delegates the tasks and controls so that the team remains on track with the project plan.

Here at MindK, the number of Waterfall projects has decreased over the years due to changes in the business environment. To stay up to date in the current climate and improve communication on the projects, we modified our Waterfall process with some of the elements we like about other approaches, such as daily meetings, frequent demos, and early testing.

We found that regular demos help us manage client expectations. By showing off small parts of the product, we can start testing much earlier and discover bugs when they’re easier to fix. And daily team meetings help us keep everyone in the loop and discover any unexpected issues.

Agile

Agile doesn’t recognize top-down management approaches. The creators of the Agile Manifesto considered the traditional Waterfall leadership style and methods too bureaucratic. Thus, one of the core values of the Agile Manifesto is individuals and interactions over processes and tools.

Agile mindset presupposes that tools and processes are not able to respond to changes on the go, but people do. That’s why if we focus more on people instead of the tools, there are better chances to create an adaptable, collaborative team that brings out the best in each team member.

This results in Agile project teams that are cross-functional and self-organizing. Cross-functional teams are formed to avoid the drawbacks of traditional Waterfall development, where stakeholders dictate the requirements which then pass to different teams to execute on various phases of the project life cycle. Cross-functional teams are mostly small teams that involve people with a variety of complementary skill sets who work together.

Apart from this, the Agile team involves a so-called Facilitator. In Scrum, one of the most popular Agile frameworks, for example, this role is called Scrum Master. Scrum Master is mostly focused on the team and the project schedule, rather than the product itself.

Facilitator does anything possible to help the team perform at their highest level and often is regarded as a team protector. They protect the whole team from outside interruptions or distractions, ensures a healthy relationship between the team and Product owner (we’ll talk about this role later too), and establishes an environment where the team can work as effectively as possible.

This approach to leadership and collaboration is very close to our values at MindK. We believe that by giving teams more responsibility and autonomy, they are more likely to be more dedicated to the project success than when they are simply coding or testing separately.

Client involvement

Waterfall

The client doesn’t have to keep an eye on the project progress all the time when using the Waterfall approach. Because of the huge amount of work done in the planning phase, clients are only involved in limited stages – at the very beginning when the requirements are gathered, and at the end of the project to check out the result.

Aside from the fact that customer involvement is rather low, it is also limited to certain milestones like status meetings, reviews, and approvals. As we’ve already mentioned before, at MindK we try to involve the client more than the methodology requires. Let us explain with a life example.

One project we developed was an enterprise recruiting system for a company in Europe. For this project, we used a hybrid approach that combined Waterfall and Agile methodologies.
The project presuposed developing a complex enterprise platform which required detailed documentation, high transparency of all the project phases, and a predefined plan of actions.

The project duration was around a year and a half, and according to Waterfall, the client would see the result at the end of the project. It was quite risky both for us as a vendor, and for the client – everybody risked that the project wouldn’t meet the client’s expectations.

To mitigate this risk and increase the client involvement in the project, we split the development into four parts called releases or iterations. Each release lasted for 3 months. After each iteration, we demonstrated the intermediate result to the client, collected feedback, and improved. Such client feedback during the development process helped us to build a high-quality solution that completely satisfied all the stakeholders.

Agile

Customer input and involvement are heavily emphasized in Agile. Based on our experience, projects with engaged customers have better chances of success than those with little or no client interaction.

The stakeholders should be open for communication, available and powerful enough to influence the project outcome. Stakeholders should be involved in the process as early as possible and stay involved throughout the whole development process.

This is because the needs and decisions of the client drives the product development, while their feedback guides the process in the right direction, leading to the desired outcome. Without people from the client’s side, who iteratively contribute to the process together with a development team, there is no Agile development.

Quite often the client introduces the Product Owner (PO). PO is a strategic role representing a person who promotes the interests of the customer for the development team and takes responsibility for managing the product backlog to reach the desired outcome.

Oftentimes, PO is introduced by C-level executives who are more than passionate about the final result and know exactly why the product should exist. The more important the project is for the company, the higher the PO’s position in the business. Simply put, the Product Owner is a bridge between the project team and stakeholders and has to be involved throughout each iteration.

Source: productplan.com

Suitability

When Waterfall is a good fit

As discussed above, the Waterfall methodology has a strictly linear nature. At MindK, we believe that it works best for projects where:

• the project’s requirements are clear, can be collected before work before the project starts and won’t change on the go;
• the client prefers limited involvement in the project after the requirements phase; and/or
• the project is short and risk-free (for example, Proof of Concept or Minimum Viable Product (MVP)).

Moreover, the Waterfall model is transparent and predictable enough, so it’s ideal for establishing trust with a new partner or modeling productive internal workflows.

For example, we used Waterfall for building CHOO, a member management system for Norwegian associations. When we established trust with the client and created effective internal workflows, we moved to Agile development for system redesign and product improvements.

When Agile is a good fit

The MindK team uses Agile to develop most projects, starting from innovative startups to large enterprise products. Based on the experience we’ve got from more than 100 software projects, there is no black-and-white borderline on which projects can be Agile and which cannot. It may happen that at different stages of product development different methodologies are used. However, we can say for sure that Agile is effective when:

• the project requirements are vague and changes are likely to be implemented through the development process;
• the project needs a fast time-to-market;
• the client needs a basic version of the app to attract investors and raise money in investment rounds;
• the project is huge and large-scale; and
• the market is changing at a great pace.

To see projects that we’ve delivered using Agile, take a look at our case studies – for most of them we used Agile.

For another example, take the Bridge project. It is a US-based company with an idea to build a SaaS solution able to cover a full cycle of services for opening remote R&D offices. We are sure that the Agile development approach, namely Scrum framework we chose, was one of the key factors for success because the product was developed during the pandemic in high business uncertainty.

Wrapping it up

Agile and Waterfall methodologies are both effective in terms of project management. They each have their strong and weak points, so you should choose the one that specifically suits your project. It means that trying to manage projects with clear-cut requirements using Agile methodology makes no sense, and vice versa – managing projects with uncertain requirements with Waterfall is risky.

At MindK we use Agile methodology for most of our projects, and we’ve collected a huge amount of experience in Agile management. And we know for sure that running a software development project from the customer side is not an easy job.

That’s why we’ve created a simple and straightforward Decision Maker’s Guide to Agile Product Development on how to build software products effectively and stress-free applying Agile principles. We hope the content of this book will help you create not only top-quality software products but also run any other project in your life more conveniently.