Agile or waterfall project management? This is undoubtedly one of the earliest and most important considerations preceding any software development project. Both methods have a myriad of successes to their names, cementing their relevance in an ever-evolving world.
Either choice goes beyond a defined project management method. It’s a mindset. Your team must be on the same page and consider the known variables (no pun intended) before coming to a consensus.
As a baseline, the agile method allows for high flexibility, while the waterfall approach is sequential. In hearing this, the question often comes up of, “why not select their approach that yields more flexibility and breathing room?”
In many other contexts, this is a fair consideration. However, as you’re about to see, the agile way is not always the best. Similarly, the predefined route, while relevant, may not always yield the best results.
Beyond the basic knowledge of what each concept means, there must be an acute awareness, so much so that the correct approach is taken every time a new project comes along.
The Agile Way
You’re going to notice that each concept is aptly named. When you think of the word “agile,” what comes to mind? You start to think of nimble behavior. There is almost a sense of continuous movement and dynamic positioning.
This approach is less concerned with managing the software development lifecycle with predefined actions and outcomes. Instead, it allows for a sense of continuous improvement. There is flexibility and iterative behavior in the mix.
As software developers know, things can often change well after work has begun. Research can tell you that most customers are disappointed in the final product they receive because they feel as if requirements were ignored.
Once the formal requirement elicitation process associated with the waterfall method is complete, that’s essentially where the questions end. The agile method is built to deal with dynamic environmental variables. A team using this approach almost expects change and thrives when it appears.
it’s about incremental analysis and getting closer to the goal by interleaving the various phases in the development process. What does the current situation demand? Whenever that query comes to the forefront, an agile team must assume that the immediate response supersedes any previously established conflicting information.
Down the Waterfall
When you imagine a waterfall, what does it look like in your head? How does the water that has cascaded to the bottom get back to the top? Weird questions, right? That’s not how gravity works! There’s no way that water is getting up again.
This is the inspiration behind choosing a name for this approach. As you likely deduced with the agile method, it’s not uncommon to revisit previous hurdles and objectives to respond to change. The same objective could be revisited numerous times before the final project is presented.
The nature of the waterfall model allows for much less spontaneity. Instead, the approach is linear. There is a heavy focus on planning at the initial phases. A herculean effort must be put into understanding the requirements and defining them correctly before any work begins. How else are you going to avoid devoting time and energy to developing the wrong thing?
As is the case with a real waterfall, previous steps of the development lifecycle are not revisited once they are complete. Phases do not run concurrently here. Instead, the current phase must be executed to completion before the next is allowed to begin. You can probably imagine that the quality assurance process is very detailed.
Requirements, design, implementation, testing, maintenance. Depending on who you ask, the waterfall model may include more or even fewer steps. What is consistent is the way the work cascades downwards, as is typical of the physical feature for which the approach is named.
Now that you understand each method, why would you ever want to go the agile way? The first glaring reason is the collaborative potential. The agile approach only works if all hands are on deck and communication is flowing efficiently.
Considering the lack of rigid planning, it takes teamwork, respect, accountability, and dedication to reach an admittedly not so clearly defined goal. You may never feel as if you are more important to an overall picture as you are guaranteed to feel as a part of an agile team. That’s why these kinds of groupings rarely struggle with morale.
Additionally, if your business model is based on customer satisfaction, this approach allows for greater user and stakeholder integration in the development process. All the changes and adjustments that are being made are not coming from the team.
It’s not uncommon for the client to view, test, and provide feedback repeatedly before the final system is presented. Meeting expectations becomes that much more likely.
You may find that projects that are more concerned with putting something out to market than completing the entire feature set at launch benefit that much more from going this route. This is especially true when the deployment allows patches and hotfixes to be applied with time. The video game industry is a testament to this model.
Why Waterfall Is Still Important
The defenders of the agile method would have you believe that it’s the best way in any context. Unfortunately, some projects require too much organization.
It is simply more feasible to have a structured approach that attempts to get you to a defined target. With quality assurance at each phase, you get to ensure you’re on track using management by objectives.
How much easier is it to track a project if you know where you’re going from the get-go? This is akin to a journey to a place you’ve never been.
Which would be better? Do you take off in your vehicle hoping to find your way, going in different directions as you travel? What about having a GPS before you even begin to drive?
Situations, such as these are not new to the software development world, and they require an extra layer of rigidity to be seen to completion.
Team members tend to have modular functions in the waterfall approach, and they are not expected to deviate. This creates a greater level of focus and increases the potential attention to detail. Sometimes, customers need only be heavily involved at inception, and the waterfall model feeds into that.
For developments that require progress reporting to the customer, creating dashboards and project tracking metrics is an easier and more accurate process here since there was a roadmap, to begin with.
Finally, you are more likely to get a complete and carefully designed system at the end when the waterfall model is used.
Potential Issues with Agile
The two pillars of the agile methodology that sit at the center of its success are high customer involvement and great teamwork. Therefore, any situation that poses a threat to these fundamentals begins to unravel the entire approach.
Some customers, while needed, do not have the time or interest that the project needs consistently. They would much rather get all the requirement discussions out of the way at the beginning.
Finally, if the relationship between team members is not in a good place, you cannot expect going this route to work out. The communication and overall team synergy are susceptible to degradation in such a context, which are enough to derail your project or highly increase its cost.
This becomes particularly concerning when the risk of people not being sure what they should be doing becomes a reality.
Waterfall Sometimes Doesn’t Cut It
Change is the biggest archenemy of the waterfall method. Unfortunately, it’s not a highly responsive approach to design, which means unprecedented differences, while possible, can have devastating effects on the project.
The effectiveness and accuracy of requirements tend to also be a major challenge. These form the foundation of the entire software development process. Therefore, if the roadmap was established incorrectly, there is going to be a lot of time spent working towards the wrong goal without any communication or indication of the path being taken.
Worse even, team members may feel as if their creativity is being stifled since they must fall in line with the rigid model established.
How Do You Choose?
Though some teams have decided to specialize in one of these approaches, the groupings that can adapt are likely to have the best experience. None of the two mindsets presents an objectively right way to go about every project that may come up.
The best course of advice you can get is to understand the advantages and disadvantages that agile and waterfall software development can bring. With this information, you can then consider the variables of the project you have at hand, electing whichever method is more appropriate.
If timelines are more forgiving, an incremental approach can be supported, the customer is willing to be involved throughout, and you have a team that’s in tune with each other, then the agile process model may not be a bad choice.
When there’s less project complexity, requirements are well-defined, customers may not be available throughout the development lifecycle, and a streamlined approach may be required for reporting reasons, the waterfall model is almost always going to be your go-to.
Regardless of the way you go, you must choose before your project gets underway. The worst time two find out that you have chosen the wrong approach is deep in development when things start going wrong.
One final pro-tip here is not to have one person make this decision. Even expert software engineers with PMP certifications can get it wrong. Engage the development team and allow its members to have a say in their shared fate.