Plutora Blog - Release Management
Is There a Place for the Waterfall Methodology in 2020?Reading time 7 minutes
Managing large software projects is hard. Delivering a product that meets your customers’ needs securely and safely is no small feat. Writers spill a great deal of digital ink each year about the best way to deliver projects successfully. If you’ve followed this conversation in recent years, you might feel like everyone switched to agile project management methodologies. Maybe you’ve even started using agile methods yourself but find that they’re not a great fit for some projects. It could be that your team doesn’t find value in the ceremonies of your agile approach. Perhaps management isn’t fully bought-in to iterative development styles. You wonder: “does the waterfall methodology have a place in 2019?”
Yes. Waterfall project management is alive and well. What’s more, it could be that waterfall project management is the right answer for your next project.
What Are Waterfall and Agile Project Management?
For starters, a bit of introduction. Waterfall and agile project management have dominated the project management landscape for the past 20 years or more. Each has its own strengths and weaknesses. Waterfall project management is the older of the two. It’s a style of project management where the software’s features are all planned up front. The project proceeds from step to step on a predictable timeline. First planning, then customer approval, then coding, then QA, then release. It’s a very good system for handling projects where you know all the requirements at the beginning of the project.
Agile project management is a bit different. Instead of planning out the entire project at the beginning, agile takes an iterative approach. Developers deliver small chunks of the software to customers as quickly as possible. Those same developers then use feedback from customers to improve and build the next chunk. This project management style works well when you don’t know every requirement of the project at the beginning. Agile provides benefits by providing software more quickly but struggles to provide predictable timelines for the project’s completion.
Advocates for each project management have been arguing for decades over which is the best. The truth is that they’re both right: the strengths and weaknesses of each mean that each style can be most effective for different projects.
What Are Some Projects Where Waterfall Is Better?
As we’ve noted, waterfall project management is always going to be a better fit for some projects. For instance: you wouldn’t want to design software for a satellite via agile’s iterative approach. You’d find that your bosses would quickly tire of writing checks to launch new satellites each time you fixed the failures of your previous system. While your team might not be launching satellites, it’s possible that you’re doing work which is similar. Waterfall teams thrive in situations where you know all the requirements of the software up front. It is also an effective approach when your customers aren’t willing to commit to a heavily-involved iterative cycle. Senior management in many companies prefer waterfall-style project management because it’s structured and predictable. It’s easy to understand when and how a project will move to the next phase. Managers like this, because it makes the project’s state easy to communicate.
Overall, the best argument for waterfall comes when shipping software is expensive and needs to be correct the first time. Like with our satellite example from before, there are many areas of software where you can’t afford to learn what does and doesn’t work with failing software. Beside spacecraft, there are a variety of other examples. Software that controls engine or braking function in a car would be a bad fit for agile, or software that controls heart monitors in a hospital. Any time you need your software to be right the first time, waterfall is a good fit for your team.
What About Hybrid Approaches?
One of the first rules of agile project management is that you should adapt the rules to fit your team. An agile team which dogmatically adheres to rules they’ve set missed the point of agile philosophies in the first place. This means that agile/waterfall hybrid approaches are achievable, and the right fit for many projects. A hybrid approach might take the structured up-front planning process from waterfall, and pair it with agile’s focus on delivering small parts of the software. An approach like this achieves some of the best parts of waterfall methodologies but delivers small parts of the software more quickly. This allows customers to use new features as soon as possible. Management appreciates the more structured style of developing software, and customers appreciate getting software more quickly. Many developers appreciate avoiding the high number of meetings that agile demands of their teams.
In my experience, this is how most software teams operate. They find some parts of the agile philosophy that work for them, and they combine them with a structured, waterfall-style approach. It might be that the team finds real value in short, focused sprints or doing regular retrospectives to identify areas where the team can improve. Whatever the reason, approaching your project management strategy by choosing tactics that suit your team is the best way to set yourself up for success.
How Can I Maximize My Waterfall Project?
If your team commits to building your projects through a waterfall approach, you’ll want to make sure that you maximize your likelihood of success. I’ve found there are a few habits you can adopt to ensure your project’s success. For starters, you should make sure that you have developer voices well-represented during your planning phases. Many teams will try to use technical managers to serve as technical voices during planning, but I’ve found that they’re sometimes insufficient. Developers have a more firm technical grasp of the limitations of your existing software, which means they’re helpful at guiding discussions about what is and isn’t possible with your team.
A second piece of advice is to adopt agile approaches when they fit. For instance, say that you have a desired feature, but nobody is sure whether or not it’ll work with your software. An agile team might take a few weeks to prototype an implementation in order to see if what they’re trying is possible. Even if you’re a waterfall organization, there’s no reason you can’t steal this idea!
There is a spectrum of project management recommendations that also apply no matter what type of project management philosophy you follow. You’ll never go wrong ensuring that lines of communication between stakeholders are effective. You should coach developers to raise emergent issues with the implementation as early as possible. Everyone involved should recognize that timelines for delivering software are subject to change, as writing software is a bit like trying to walk along the beach in California.
If you’re looking to take your waterfall skills to the next level and network with fellow professionals, you might also look into the 2019 Waterfall Conference. You’ll have the chance to hear from smart speakers and learn from leaders in the field.
Is There a Place for Waterfall in 2019?
I don’t think it’s a stretch to say that there’s a place for waterfall in 2019. The waterfall methodology is the best fit for a variety of different projects, including some where agile would be a complete non-starter. Approaching your projects with care and planning is a key skill for any project manager to possess, regardless of how your team chooses to deliver software. Managing projects using a waterfall philosophy ensures that you’ll spend time designing your software and that the version that goes to your customer is the best your company can deliver. Agile philosophy encourages teams to fail fast; waterfall suggests that teams should avoid failing at all. Whatever style of project management you use, Plutora can be a powerful tool to manage your projects.
Delivering high quality software is hard, but with attention to detail and hard work, it is possible, no matter the philosophy your team adheres to.