Gather 'round the metaphorical campfire readers as I'm about to spin you a story that will sure make you tremble in fear (as you read from the all-too-bright light that shines from your phone while laying in bed).
Our tale begins with a man named Billy, who was the lead software manager of a local bank company. Billy was a particular individual who always needed to do everything in a specific order. As result, when he had a project he was leading, he would always follow a specific methodology to create software - the waterfall methodology! *cue eerie music*.
Now you may be asking...what is the waterfall methodology? Well, readers, if you don't know what it is, the best way to explain it is to think of a waterfall. A waterfall is a powerful stream of water that moves in only one direction. The water never goes back up, it only goes down.
In software development, the waterfall methodology is a model that follows a linear sequence of activities. Those activities or "phases" are dependent on each other and to complete a project through this methodology you must follow each phase in a corresponding order. Those phases, may be titled in various ways, but typically follow this order - requirements, design, coding, testing, deployment, and then maintenance.
Following the waterfall metaphor, a project using the waterfall methodology must follow that process. You complete all your requirements first, and once done, you don't go back. You keep moving forward.
Return to Billy - this year Billy was in charge of a huge project at his bank to create the function in their mobile app where a user can take a photo of a check and upload into their bank account. In this story, this feature didn't exist in other mobile apps and Billy and his team were on the cutting edge of innovation with this one. If they could get this feature out to their customers, they could crush their competition and take a leading edge in the banking industry!
Billy, however, is a creature of habit and was very clear with his team that they had to use the waterfall methodology. As result, they planned out a timeline of 6 months to complete all the activities in corresponding order. The team got to work quickly...
Five months pass....Billy's team is about to reveal the check upload functionality. Billy wakes up on a dreary morning and turns on his phone to read the news. He is surprised to find that his largest bank competitor has just released the same functionality! His heart sank as he realized that his company had fallen behind the curve, and no longer was leading in an innovative project. He knew that he and his team were now too late....
Did this story make you shiver? Well, corny-ness aside, the point is that the waterfall methodology, though was a prime model to use in the 90s for software development, just doesn't really cut it anymore in our progressive age of digital technology. In theory it makes sense that by planning everything out you know what you want to achieve in an initiative, but there are a lot of risks and challenges that come with developing and implementing that way, which essentially boils down to impacts to time and money.
There are instances where waterfall is an okay methodology to use, such as when your goals and your project timeline are very clear, and when all your constraints are understood before starting your project. However, if there's any unknown or potential course for change, then waterfall is unfortunately an inflexible model.
.
Here are some other examples where waterfall may also cause challenges for success:
- Billy's team forgetting a specific feature in their requirements phase (example - creating a limit of $5,000 to deposit per day), causing extra money and a delayed timeline to update
- The identified customers that would benefit from Billy's project identifying additional needs after deployment (example - wanting a 50/50 distribution of a deposited check into 2 bank accounts), causing the need for extra money and a delayed timeline to update
- Those same customers after deploying the software don't like the end product and/or don't need it anymore!
So you may be asking yourself, if not waterfall, then what? Well, since the 2000s the agile methodology has been on the rise of popularity and a lot of companies focus to using some aspects of agile. In the academic sense, agile is where you plan your project in small chunks or "sprints." During that sprint your team prioritizes what work is most important during that time (which is usually 2 to 4 weeks), and the end of each sprint your team then evaluates if your project plan needs to change. Agile becomes synonymous almost with the words quick and flexible, as your team has to be able to deliver value to their customers as fast as they can, but also change course if something doesn't work according to plan.
Other models in increasing popularity are DevOps and Scaled Agile Framework (SAFe). DevOps (Development + Operations) focuses on trying to shorten the system development life cycle through continuous delivery of software. SAFe is a set of workflow approaches to guide organizations in agile practices. Do you see the commonality though? They also focus on speed and flexibility, which are those core components of agile!
Agile though has its own challenges, especially if things are changing too much, such as customer expectations or other factors that causes a lot of rework. When that happens, its often best to take a pause and re-evaluate the goals of your project and what you're trying to bring to your end user; otherwise, you could just be burning money changing the same thing over and over again.
At the end of the day, there's really no black and white answer on how to develop your software. It really comes down to what you're trying to do, what you know and don't know about your project and its goals, and how your organization is set up. For example, if your organization has an overly structured decision making structure, following the agile methodology can be difficult in practice, just like if you have an objective with a lot of unknowns, you may struggle using the waterfall approach. Treat each initiative as its own and know that there are a lot of different ways to define, build, and deploy software.
References: