Sometimes I’m asked if there’s any way to apply agile approaches to waterfall work to get some of the benefit when a company isn’t interested in moving completely to agile. The answer is absolutely yes, you can apply these to your benefit. We’ll explore this over a few different articles, starting with this part one.
The single biggest thing you can do to improve your waterfall process is to implement a phased approach to your development.
Agile Principle: Working Software is the Primary Measure of Progress
An unfortunate risk of waterfall development is that it sometimes delivers “shelfware. Shelfware is extensive documentation and design of a system which is to be constructed, but never actually gets constructed. This is sort of the consolation prize of a cancelled project. Typically, this then gets forgotten about or just goes stale as business requirements, needs, context, and conditions change and evolve from when the original project was considered.
By focusing on working software, we can minimize the risk of a project which was supposed to create business value in the form of software, but instead provides nonfunctional, aging, increasingly stale binders of paper.
We attack the risk by implementing the software in phases. One of the effective strategies that a software project of any length (6+ months) can have is to determine domains of functionality and deliver end-to-end capability of incremental depth as the phases progress. Each phase delivers completed, fully functional, potentially shippable software. “Potentially shippable” means you could deploy it for use to the intended audience, but perhaps are only deploying to your pre-production or staging environment to prove that you could deploy it fully if you were asked to do so, while continuing to your next phase.
A Learning Example of Phased Implementation
Let’s look at a sample case of this thinking as a learning illustration. The scope of the project is that you are to construct a simple shopping website. It will display lists of products to customers, allow them to fill a shopping cart, perform checkout, including payment, and a successful completed checkout results in an order sent to the warehouse. Assume the product catalog is already provided to us, and the warehouse team picks up with the process from receiving the order.
For simplicity, we will assume you’re using a typical “4Ds” waterfall process of “Discover, Design, Deliver, Deploy”. We will apply the 4D process over 3 phases.
Here is a list of the functionality to be constructed in each phase. The construction plan follows below that.
Display product catalog, simple catalog search page, search results page, ability to select any one item for purchase, select quantity for that item, checkout only for that item, make payment using one type of credit card, provide order to warehouse for this one item with necessary customer information for fulfillment and shipping.
Add shopping cart functionality enabling selection of multiple items prior to checkout, add additional credit card types to checkout, enhance order to warehouse to handle all shopping cart items, add abilities to the search results page including sorting, filtering and pagination.
Add additional styling and graphics to all pages and add richer search features by product attribute and class.
Illustrative project plan using phases:
Remember that “deliver” is our inclusive term for all coding and QA activities. Code should be fit-for-use at the end of delivery and does not require further tweaking or changes.
Note that while I’m using months for simplicity and illustration, the point is to layer your activities over time. It is conceivable that a project like this might be relatively short if you’re building on a platform that does the heavy lifting. Your phases might be 5 to 7 weeks; whatever fits the right frame for your particular situation.
From a waterfall perspective, why do this? Why not keep a normal 4D pattern and do one long project with all of your discovery, design and delivery sequentially without overlap or loop-back?
You get these project benefits:
- Easier resource allocation
You aren’t gaining and releasing team members as frequently; your allocation will be more level and predictable.
- Team functions better together
Your team members are all present for most of the project. If your team has a question about the requirements during phase 2 delivery, the BAs are still there and haven’t gone to a different project. Information is fresh in their minds as discovery activity was recent. The same goes for the stakeholders with whom they’ve spoken.
- Reduce risk for project issues
You are reducing many types of risk by getting into end-to-end software development first. If there are undiscovered challenges with development, QA, or integration, you discover them early in the project and can adapt.
- Retain stakeholder attention and involvement
By delivering working software frequently, you keep stakeholder attention throughout the project vs. just at the beginning and end. This reduces the risk of requirement drift and requirement staleness.
- Easier change requests
Small request? Let’s see if we can fit it in right now. If not, we can put it in a future phase, which starts in a month or two.
- Deliver value faster
In the waterfall project example, you’d get all your value at the end, month nine. Here, you get it at months five, seven, and nine, incrementally..
- Reduce risk of failing to earn ROI
If you have to halt your project, you have at least some ROI and not just shelfware. Each completed phase represents a retired risk that the funding expended to that point will produce no value.
- Reduce risk from funding reduction
If your overall organization receives a request to cut 10% of the budget, your effort in particular has working software to show the value & progress of your project. You’re less likely to have a funding cut placed on you than the team that hasn’t produced any code yet.
You also get these valuable product benefits:
- Real attention given to real software
You can show working software to stakeholders inside and outside the company and get real feedback to real function. This is always better than just mock-ups.
- Adapt project to real world feedback
You can incorporate this feedback into the project quickly. You can consider modifying or dropping part or all of a feature that you have discovered to be lower in value in order to build on ones that you have found to be higher in value. This produces better project deliverables within the same project funding.
- Real deliverables make real conversations
If you don’t have room to accommodate the work within your current project funding, you have actual working software and actual feedback from customers about that software on which to make make your request for additional resources. This is a much better basis for additional funding compared to speculation and conjecture about feedback from software that you haven’t constructed yet.
For all these reasons – and more – I consider applying phasing to projects to be a clear best practice for any waterfall work effort.
About the Author
Ryland Leyton is a Senior Business Analyst with New Signature and is based in Atlanta, GA. Ryland loves getting to help clients solve business issues through creative & valuable use of technology solutions. Working in tech since 1998, he has moved through different roles starting with database & web development, and gradually moving through project management and into business analysis. He has a strong love of agile practices and works to help people benefit from agile wherever it makes sense to do so. Ryland is a frequent educator and speaker on BA, PM, and Agile topics. His books include “The Agile Business Analyst: Moving from Waterfall to Agile”, as well as being a Core Team Author of Version 2 of the IIBA BABOK Agile Extension. Ryland often gets involved in career & workplace conversations (as you’ll see on our blog ), and his recent 2019 book “It’s About Your Career: Skills for a lifetime of loving your work!” has become a conversation starter in professional groups.