Agile vs. Waterfall – A Practical Guide to Leveraging Both

In a previous post I talked about the good and bad of Agile and Waterfall. This triggered some insightful and unexpected offline conversations. From that, I wanted to share a more practical guide to how to manage an Agile environment while supporting more traditional Waterfall-style projects.

Sprint Setup

Throughout a sprint, Agile project cards will move through the columns as you would expect (To Do, In Progress, Code Review, Ready To Test, In Testing, Ready To Deploy, Deployed and Done). These type of project cards are almost always deployed as step in the sprint and the estimates include that. This workflow is fairly standard for Agile and most tools support this.
As well, for us there are now some research, UI and UX activities, captured as card work, for upcoming development that help to better define and ensure the small parts fit into the larger solution. This means that any sprint is a combination for development work AND more design type work for upcoming development.

Supporting Waterfall Project Works

While our Agile approach has grown from the bottom up, Waterfall projects move from the top down. You could argue, that these are just big Agile projects, and that is the point. More than anything, this approach was taken to get buy-in from the existing stakeholders to a new way of getting work done.

A standard Waterfall project is broken into milestones. A very high level plan is designed and a more detailed plan is created for phase 1. This is where the design everything Waterfall approach is abandoned.

Once phase 1 is broken into individual cards, they can be estimated and added into sprints – just like the Agile project cards. As phase 1 comes to end an, a deployment card that encapsulates all that work is created and put into the appropriate sprint. At that point, cards for phase 2 should have been prepared and the cycle continues.

Pulling It All Together

At the end of the day, we needed a consistent way for requests to be explained to the development team and this worked for us. It’s definitely not the only way and that is the point. You need to find the best method for the people, process and tools you have access to.