When it comes to managing complex projects, many companies still employ a rigid, top-down process known as ‘waterfall’. In this post, we explore how to transition from waterfall to agile methods for better, faster, and often cheaper solutions.

The Problem With Waterfall Methods

Originally developed under the context of manufacturing, waterfall methods work in a series of dependent phases that start with gathering extensive requirements up front and executing a project based on those requirements. While a waterfall approach may work well for simple, straightforward projects, it doesn’t work well for complex projects, including digital projects, which typically contain a lot of unknowns.

Here are just a few reasons why waterfall methods can be problematic:

1. First, it’s impossible to predict every potential outcome with a rigid set of project requirements created up front.
2. Waterfall’s rigid framework doesn’t allow you to course correct based on learning that occurs throughout any project.
3. The Cone of Uncertainty can make it really difficult to accurately estimate and plan waterfall projects. This is also why RFPs can be so problematic.

A Better System for Executing Complex Projects

Complex projects are filled with uncertainty. When you’re building a new website or digital product, for example, you can make assumptions, but you don’t always know who your users are or which features they will find most appealing. This is fine—in fact it’s unavoidable—as long as you incorporate frequent testing into the process. This allows you to re-prioritize features based on test results.

With waterfall methods, testing isn’t typically built into every cycle of a project. This doesn’t leave much room for collaboration or incremental feedback. If changes are required late in a project, executing them can be both expensive and time consuming. Many a website project has gone over time and budget based on late stage misunderstandings about how features should work.

The whole system works better if the all parties can work together to test assumptions and validate (or refute) ideas. The process should work collaboratively rather than as a series of ‘grand reveals’ where some project stakeholders aren’t involved in decision making. The only caveat is that, to work in this way, all project stakeholders should feel comfortable with a bit of uncertainty.

Agile methods can help teams better manage complex projects by embracing uncertainty and incorporating continuous learning into the process. We’ve taken an agile approach to projects for many years now at Mightybytes.

What are Agile Methods?

In 2001, a group of software engineers recognized that the typical way software was built no longer worked. So they came together to write the Manifesto for Agile Software Development. Their idea was that software development should value collaboration and response to change over hard-set processes and contract negotiations. Companies that built single software products adopted this new way of thinking quickly, but many agencies working on client projects weren’t so quick to pick it up.

Agile methods break large, complex projects down into a series of manageable chunks, or “sprints” in agile parlance, that each focus on a core component of the larger project. Each sprint has clear functioning deliverables that can be tested against organizational goals and desired outcomes—with real end users whenever possible. Typical agile processes consist of:

• A sprint planning session where you divvy up tasks among the team, rate the difficulty of each task, then have the product owner (in our case the client) prioritize them
• Working in two-week sprints with demonstration/feedback at the end of each sprint
• Having a daily stand-up during each sprint where team members talk about tasks they’ve accomplished and potential blockers that could impede progress
• Testing is incorporated into every sprint, rather than saved for the end
• Using a system to track velocity during each sprint and across your larger project to better understand overall progress

While agile methods are commonly used in project management and software development, they can also be applied to organizational processes as well. For more information on how that plays out, check out our post Five Lessons Learned from Agile Processes or grab a copy of our friend Pamela Meyer’s great book The Agility Shift.

How to Manage a Transition from Waterfall to Agile

Agile methods are easier to grasp in the context of working on a single project. Navigating a successful waterfall to agile transition as an agency, however, is bit trickier. We’re constantly working on multiple projects at a time. Agile does work for teams with multiple projects, you just have to think of the whole operation as a single project: your business. We think of client work as sub-projects and balance them accordingly within context of our overall company capacity.

For starters, plan a sprint with clear, functioning deliverables, typically every two weeks, to determine velocity. To maximize time for everyone on your team, assign tasks and fill up everyone’s sprint, allowing for about 20% flex time to cover any inevitable unknowns that will arise during the sprint.

This helps you figure out who has bandwidth and who’s overloaded. It will also help you determine how much you think you can get done versus how much you can actually get done. Then you can start to make incremental changes to address that.

A tool like Harvest Forecast or one of the forecasting add-ons for Jira can help with this process. At the end of each sprint you should have a fully functioning deliverable to demo with your client. Use feedback from this demo session to help you prioritize items for the next sprint.

Here are a few things to try that can help get your team ready for a waterfall to agile transition:

1. Team capacity: Figure out what your total team capacity is. This is the total number of billable hours per week for your team. Remember to leave enough flexibility in the schedule for non-billable tasks, which always come up. For designers and developers in an agency setting, a 70-80% billable utilization rate is common.
2. Individual capacity: Plan each person’s workload individually rather than planning workloads by team. This will help you better accommodate always changing project requirements while also maintaining your team’s sanity. A core agile team of designer, developer, and product manager working equal time on a project may sound nice, but it’s not practical in reality if you have multiple projects going on at once.
3. Estimating: A key part of successful sprint planning is estimating task difficulty. Start first by using hours as your scale of difficulty (i.e. how many hours will something take), then move into rating difficulty on a scale of 1-10. Hardcore agile practitioners use a more complicated scoring process based on the Fibonacci scale. This will help build team consensus on how to execute each sprint’s required deliverables.
4. Sprint length: Sprints are typically two weeks long, but this may not work for your team’s capacity or the project they’re on. Consider adjusting sprint lengths as necessary until you find something that works for all project stakeholders.

Remember that transitioning from waterfall to agile is a lengthy process, but in the end it improves your relationships with project stakeholders, including clients, as the work becomes more collaborative. Agile also improves your ability to track company efficiency, and it’s great for morale because collaborative teams show their work and receive feedback at the end of every sprint.

Transitioning Clients to Agile Methods

Our clients tend to eventually love agile processes because they get to review deliverables and offer feedback at the end of every sprint. At first, however, managing a more collaborative process might be tricky. The time commitments required to execute successful agile projects can be initially daunting for some, especially if they’re used to waterfall practices, where deliverables are much fewer and further between without as many opportunities for input.

Here are some steps that can help you more easily transition clients from waterfall to agile:

• Discovery: Start with conducting a solid discovery process that incorporates agile methods. This will get them used to working collaboratively. 
• Check-Ins: Use ongoing communication to break down formalities and kickstart the collaborative process. Collaborative project management tools, regular calls, and holding sprint demos in person can help with this.
• Uncertainty: Help your clients understand the value of embracing uncertainty and continuous learning while also being clear with them about expectations around timing, budgets, etc. Features they think they want in the beginning might be re- or de-prioritized during ongoing user tests. And that’s okay.

At Mightybytes, we incorporate user research and testing as well as wireframing and prototyping into as many of our digital projects as possible. Coupled with iterative sprints, these agile-friendly techniques help us bring projects to life quickly while also ensuring higher chances for success. If you need help with the transition from waterfall to agile, please feel free to get in touch with us or check out or agile white paper below.

Note: This post has been updated from a previous version to more accurately reflect current approaches.