Agile vs Waterfall: Which Software Development Methodology is Best for Modern Projects?

What is a software development methodology?

A software development methodology is a structured framework that guides the planning, design, development, testing, and deployment of software. Its primary goal is to ensure that software is delivered in accordance with project specifications, on time, and within budget.
The Agile Methodology refers to a collection of methodologies that aim to improve the flexibility of software development. It focuses on the idea that requirements may shift and change during development. This can only be dealt with by producing software in an iterative way, so sections of a problem are developed in parallel, meaning that different sections are at different stages of development.
The Waterfall methodology is a series of stages that are completed in sequence from start to finish. Like a waterfall, each process phase cascades downward sequentially. A slight evolution of the waterfall model allows users to move back to previous stages.
This essay argues that Agile methodologies, due to their flexibility and adaptability, are generally better suited to modern software development than the traditional Waterfall model.

What is the Waterfall method?

The methodology comes from the computer scientist Winston Royce’s research paper on software development, although he didn’t name the model. Royce is credited with creating the linear and rigorous process method.
The phases of the Waterfall methodology are as follows: requirements, design, implementation, testing, and maintenance. The requirements phase provides an overview of the entire project, and due to the rigid nature of the waterfall methodology, it is best that these requirements are as specific as possible to reduce the risk of a low-quality end product. A requirement may be a statement that the system must do or a constraint that the system must work under, writes Steven Zeil.
Design helps to develop solutions to meet the requirements; this can be determining the exact deliverables or laying out the project schedule. Once the design is finalized, we move on to implementation. To do this, you would create a plan, do your research, and assign specific tasks within your team. After the product is made/coded, then it needs to be tested to ensure that the code is bug-free and works in different environments/under stress. Finally, the last step is to maintain the product to ensure it remains bug-free. For example, if a stakeholder wants to add a requirement when you're in the verification phase, you'll have to re-examine the entirety of your project. That could mean tossing the whole thing out and starting over.

What is Agile?

The Agile method of project management came about in the late 1990s and early 2000s as a response to the limitations of traditional, rigid software development processes like the Waterfall model. It was formalised in the Agile Manifesto in 2001, which outlined the core values and principles as: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The Agile methodology is used as an umbrella term because it encompasses a variety of frameworks, practices, and mindsets. Various frameworks like Scrum, Kanban, and Extreme Programming (XP) operate under the umbrella of Agile, each offering specific practices and tools for managing projects and development.
The Agile methodology uses incremental, iterative sequences of work that are commonly referred to as “sprints.” This allows an allotted time for a specific phase of development and runs through each of the phases until the project is complete.

Comparison: Agile vs Waterfall

The Agile methodology welcomes changing requirements even in the later parts of development. Its process allows the developers to embrace the change and allow the customer to gain a competitive advantage; instead of swimming against the current of change, it allows developers to take advantage of it. Whereas with the Waterfall method, one small change in the requirements can cause a rift and make the project take two steps back. Instead, Waterfall favors a more clear project structure, leaving little room for confusion due to rigorous planning.
When it comes to customer involvement, Agile requires its business people and developers to frequently come together throughout the project as collaboration is key and stresses that the best method to avoid miscommunications is through face-to-face conversation. However, with the Waterfall methodology, it has limited/no opportunity for client feedback as after the initial requirement phase is complete the project is out of the hands of the client. It is best for a project with set time frames as customer feedback may delay when the product is available by. This method makes it difficult for customer involvement and in a society of constant and rapid change it creates an environment that limits innovation.
Agile delivers working pieces of software from each iteration allowing essentially a functioning prototype to be presented and tested. This also allows the developing team to reflect on how to become more effective, creating space to adjust their behaviors accordingly. Therefore, Agile is able to adjust to problems as they arise, reducing risk, and the scaffolding to this is communication and collaboration. The Waterfall method somewhat equally allows for reduction in risk as thorough planning is completed before development, allowing the programmer to catch the problem before writing any code. However, due to the linear structure of the Waterfall method, there lies a risk that unaccounted flaws are discovered later, causing the project to fall back stages.
As the Waterfall method delivers the product at the end of development, the maintenance can be very demanding because clients have little say about the project when it is being built; there may be a lot of feature changes after launch. This can create maintenance issues and prolong the launch. On the other hand, the Agile methodology gives working prototypes as the project is developed allowing a faster delivery in increments.
Documentation in the Agile methodology is limited and “just enough” as it values simplicity in maximizing the work not done, allowing excess work to be trimmed keeping the flow of the project. However, this may lead to misunderstanding down the road if communication is also faltered. Here is where Waterfall excels as it prefers more extensive and upfront documentation providing you with a blueprint of the project from start to finish; this would be favourable to a less experienced team.

Case study: Spotify

Spotify's Agile approach, often called the Spotify model, follows the key principles of Agile methodology. It is more regarded as a mindset than a model as it focuses on teams that are organised to increase effectiveness as opposed to being confined to a set structure. The reason the Spotify model is seen to work so well is due to the empowerment given in their squads, allowing the teams to choose their own methods of navigating issues and providing a sense of ownership and accountability. Instead of strict hierarchies, Spotify utilises a structure of Tribes (groups of related squads), Chapters (groups of people with similar skills), and Guilds (communities of practice). This tactic resembles a game-like environment and almost deploys the methods that game developers use to keep their audience engaged into a working environment. Due to this structure, it allows for faster decision making and risk handling, thus decreasing the size of bottlenecks.

Case study: J.P. Morgan

J.P. Morgan’s use of Agile highlights more than just a change in process; it’s more of a fundamental shift in mindset. In a similar manner to how Spotify restructured around empowered squads, J.P. Morgan focused on flattening traditional hierarchies and giving more control to the teams actually doing the work. The organisation moved toward autonomous, cross-functional teams that are trusted to make decisions and drive value. This empowerment has led to higher motivation, a stronger sense of ownership, and faster, more innovative delivery. As Matt Winn put it:
“We believe that in development, if we empower the people who are actually doing the value work to make a lot of the decisions, they’ll make them better than somebody who is two or three levels up the ladder could.”

Instead of relying on top-down control, the Agile setup creates an environment of collaboration across engineering, legal, and product teams. Projects like the Connect Advisor mobile platform, a quantum-secured crypto-agile network, and an e-gifting service that launched in half the usual time all show how this approach has paid off in real, measurable ways. What stands out is how J.P. Morgan scaled Agile in a complex, highly regulated environment without losing the core idea: trust the teams, support them with leadership, and measure what matters. Tools like burn-down charts and frameworks like Large-Scale Scrum (LeSS) help track progress and keep things transparent. Ultimately, J.P. Morgan’s Agile transformation echoes the same principles seen in successful tech companies: give teams the autonomy to own their work, and they’ll deliver faster, better, and with more innovation.

Waterfall Model Planning for Rock, Paper, Scissors Shoot (Python)

Requirement Specification

• The game must allow a player to input rock, paper, or scissors.
• The computer randomly selects rock, paper, or scissors.
• The game compares choices and declares the winner.
• The game allows the player to play multiple rounds until they choose to quit.
• Input validation for correct choices.
• Display of scores after each round

Design

Flow chart

Functions to implement

• get_player_choice()
• get_computer_choice()
• determine_winner(player, computer
• display_result()
• main() – control the game loop

Data

• Player_score
• Computer_score
• Input as strings (rock, paper, scissors)

Implementation

To model how implementation would be when following this methodology I have broken down the code into 6 steps:

1. Set up the Environment

     

2. Import required libraries

      

3. Define valid choices

     

4. Create functions
   1. Function to get player choice

2. Functions to get computer choice

3. Function to Decide winner

5. Implement the game loop

6. Run the program

Testing

To model the testing of the waterfall methodology I will:

1. Test valid inputs
2. Test invalid inputs
3. Test scoring behavior
4. Test quitting behavior

Error 1

In this error there was a syntax error where I had spelt a variable name wrong and the picture underneath shows the code after the error has been fixed.

Testing all valid inputs:

Error 2

In this error the program wasn't able to detect the invalid input. The code bellow is what tried after:

Testing Invalid Input

Test scoring behavior

• "rock" vs "scissors" = Player should win
• "rock" vs "paper" = Computer should win     
• "paper" vs "paper" = Draw
• "scissors" vs "paper" = Player should win

Test quitting behavior

I found that testing after completing all the code, as required by the Waterfall model, was somewhat inconvenient. If this had been a larger or more complex project, identifying and fixing errors at the end could have been far more difficult and time-consuming.However, because this was a very small and simple program, the delayed testing phase didn't have a significant impact on the overall development time. From this experience, I believe the Waterfall model can be effective for short, well-defined, or low-risk projects where requirements are unlikely to change. In such cases, the structured nature of Waterfall provides clarity and efficiency.

Maintenance

To model the maintenance of the waterfall model, I have asked a friend what sort of enhancements they would want and they said the following:

• “Display the final score when the player quits”
• “Add score reset option”

After testing with the valid input there was a logic error:

I needed to add the following to get the code working:

Review

I found that adding the components after the whole code was made was quite inefficient as if i precisely followed the waterfall methodology I would have to go all the way back to the design stage, modify the flow chart, modify the code then test it and then go to the next requirement. This method was rather tedious as if the improvements were given alongside coding I believe it would give room for more innovation and allow the process to be less time consuming.

Agile Methodology Planning for Rock, Paper, Scissors Shoot (Python)

Creating User Stories

• As a player, I want to input “rock”, “paper”, or “scissors” so I can play the game.
• As a player, I want the computer to make a random choice.
• As a player, I want to know whether I won, lost, or drew.
• As a player, I want to play multiple rounds in a loop.
• As a player, I want to quit the game when I choose.
• As a player, I want to see the score after each round.
• As a player, I want the game to handle wrong inputs properly so I don’t crash the game accidentally.
• As a player, I want the game to allow me to reset the score

Creating Sprints

To model the Agile methodology I will be breaking down the design into sprints and highlighting what needs to be done at each sprint showing the goal, what part of the user story it correlates to, features to implement and the deliverables. I will set this up so that I write the code for one section and then hand it over to one of my friends (or in a real world scenario “colleague”) to amend my code if need be and then it will be reviewed by another friend (who in a real world scenario would act as the customer)

Sprint 1

Goal: Build a working single round Rock, Paper and Scissors

User Stories:

• US1: As a player, I want to input “rock”, “paper”, or “scissors” so I can play the game.
• US2: As a player, I want the computer to make a random choice.
• US3: As a player, I want to know whether I won, lost, or drew.
• US4: As a player, I want to play multiple rounds in a loop.

Features to implement:

• Accept user input.
• Validate the input (rock, paper, scissors).
• Generate computer’s choice randomly.
• Compare results and determine winner.
• Print winner message.

Deliverable

• A multiple-round working game that runs once and exits.

Code:

Testing:

• Test valid inputs

• Test invalid inputs

Colleague check:

After my colleague had checked the code she had changed the variable names and improved the def_playersChoice and def_computerChoice to make the code more efficient

However after checking the code I realised there was a line of code that needed to be added back in to ensure that the code runs

Customer/Client Feedback:

"The game works well and is fun so far"

Learning points

One important aspect I initially overlooked was the importance of commenting on the code in a collaborative environment. Adding clear comments helps other programmers understand the purpose of each section, especially when changes or enhancements are made. To reduce the risk of miscommunication, I made sure to go back and add comments to my code and also asked my “colleague” to do the same. This ensured our intentions and logic were clearly documented for each other. Another challenge we encountered was the difficulty in communicating effectively while working remotely. Misunderstandings could easily occur when we weren’t in the same space. To address this, we agreed that for more complex problems, we would switch to video calls. This provided a faster and clearer way to explain issues and work through solutions together, improving collaboration overall.

Sprint 2

Goal: Allow the game to run for multiple rounds, track the score and quit.

User Stories:

• US5: As a player, I want to quit the game when I choose.
• US6: As a player, I want to see the score after each round.

Features to implement:

• Create a loop that runs the game until the player types 'quit'.
• Add scoring logic for both player and computer.
• Print updated score after each round.

Deliverable

• A multi-round game with working scoreboard and quit option.

Code and testing:

There was an error when I tried to run the code and i fixed it by moving where the player variable was defined to be above the quitting function

The sections of code that was modified:

Colleague check:

There was a logic error when running the code and fixed it by adding the quit option to the def get_player_choice()

Here is the results after modification:

Customer/Client Feedback:

“I would like to see the final score when I quit the game ”

Code after client feedback

Sprint 3

Goal: Improve usability, input safety and allow the user to reset the game.

User Stories:

• US7: As a player, I want the game to handle wrong inputs properly so I don’t crash the game accidentally.(This had already been implemented when the code was being tested)
• US8 : As a player, I want the game to allow me to reset the score

Features to implement:

• Check if input is valid and prompt again if not.
• Add user-friendly messages (start, exit, separators).
• Polish print formatting and logic messages.

Deliverable

• Final polished version with clean code and bug-free execution.

Code:

Colleague check

My colleague realised that there was a logic error as the user wasn’t aware that you would be able to reset the game score so that was added into the code

Testing:

All outputs where correct and incorrect inputs were handled well so that the program ran bug free and didn't crash.

Customer/Client Feedback:

“I really like the new reset feature and score tracking—it makes it feel more like a real game.”

Review

Agile was a great fit for this project. Its iterative structure helped you build, test, and improve continuously, keeping both the development team and the client engaged. Compared to Waterfall, Agile made the process more dynamic, more creative, and more user-focused, which would especially pay off in larger or more complex projects.

Conclusion

Overall, while the Waterfall method can be useful for small, clear-cut projects, Agile is much better suited to the fast-paced and ever-changing world of modern software development. It encourages flexibility, regular feedback, and collaboration, which helps teams adapt quickly and improve their work as they go. From real-world examples like Spotify and J.P. Morgan to my own experience building a simple game, it’s clear that Agile makes it easier to spot and fix issues early, stay creative, and deliver better results. It’s a more realistic and efficient approach for most projects today.