The Agile Waterfall
Jon Arnold, a strategic consultant at Centresource Interactive Agency, explains how to blend the Agile approach and the waterfall method
Recently our team has been experimenting with a hybrid approach between Agile software development and the waterfall model. Many project management nerds are referring to this as “WetAgile”, an appropriate but kind of gross-sounding term. Before I explain further, a little background information:
We call our standard waterfall the 4D Approach: Define, Design, Develop, and Deploy. It’s pretty standard in the world of web and interactive, with each phase having a solid finish line before the next phase begins. It’s great for setting milestones with a client and managing expectations, but can often make for some difficult scheduling and internal struggles.
That’s the biggest drawback to a waterfall process: you’re never truly done with each phase. Despite the best laid plans, reality always sets in: a design decision needs to be amended to fit within a development environment; a forgotten interior page element suddenly becomes a necessity; or a developer needs a consult with a designer to work out an animation or visual transition.
With Agile development, we typically have a small, dedicated team working closely together inside a larger agency. There’s heavy communication and collaboration, and the client is often included in the discussion. Many Agile projects revolve around sprints, a one or two-week cycle of heavy development work that results in a new iteration or feature set on a live web product.
Agile Waterfall
If you think of waterfall projects as a staircase, Agile can be visualized as a series of concentric circles, building upon one another. We love this model for our Ruby projects and other dev-intensive, short timeline endeavors. That said, Agile makes some clients nervous. The short timelines and constant iterations can feel hyperactive and stressful to some clients, who would ultimately prefer a more traditional collaboration with our team.
So now, mixing the chocolate and the peanut butter … here’s what the Agile Waterfall generally looks like:
- A designer creates a homepage concept, which undergoes an internal review meeting with the developer and strategist.
- Reviews are made with that team and shared with the client, who also provides feedback.
- Final revisions are completed and the designer moves on to interior page concepts.
Meanwhile, a two developer team has begun initial development (typically one developer leads on actual dev, the other on theming). They have their marching orders from the first internal review meeting and so have an understanding of what needs to occur. Here’s their general flow:
- The lead dev sets up the CMS, the staging environment, and starts kicking tires on the main functional elements (through the models and controllers, typically).
- Prototyping of these elements occurs and are reviewed in a planning meeting with the designer and strategist to make sure everyone’s on the same page.
- Once the designer finishes step three above, the lead theming dev begins breaking down the homepage and integrates the existing dev work.
… and the whole thing keeps rolling on from there. During this process the strategist keeps the client in the loop and occasionally, shares the staging server credentials so the client has a backstage pass. The strategist also uses client feedback to help mold the visual and technical output from the production team.
There’s a lot of Agile purists out there who are probably bleeding from the eyes as they read this. To be clear, I’m specifically talking about projects that were brought on board our agency as a standard waterfall. These are typically smaller budget web applications or large marketing site projects, which generally work well inside a waterfall. This is also a good approach for a client who’s unsure or confused by the Agile process. Often Agile has an unlimited budget and timeline allocation associated with it, which can terrify the cost-conscious marketing manager who hired us.
So far, the results have been great. We’ve been able to surpass deadlines, save budget, and keep clients happy – the three key fenceposts for success in any interactive agency. In the great black box of interactive agencies (where money goes in, websites come out), this model allows us to be reflexive and client-focused while sticking to a tight budget or timeline.




6 comments
Comment: 1
Then once design is signed off, the front end team can pick up the design and the tech work and combine the two. There will always be some overlap and some tech that needs finalising, but you're ahead without wasting any time/budget.
I've adopted this exact process and with collaboration from all the teams, it's a good way of getting ahead.
Comment: 2
There has been a massive shift in the last year of design agencies to adopt "Agile" and blaming anyone pointing out that they're using the word wrong as "purists". You can have certain mix of both Agile and Waterfall, but whats described here simply isn't it.
"Often Agile has an unlimited budget and timeline allocation associated with it" is 100% completely and utterly false. It shows a complete lack of understanding of what an Agile methodology is.
Comment: 3
Comment: 4
http://en.wikipedia.org/wiki/Spiral_model
Comment: 5
@kevinjohngallagher I agree, it's all about the buzzwords. But each phase, or D, in the project uses it's own method for development. Most of the project I'm involved with use the Agile/Scrum for the third phase only. Because that's where (software) development is done.
This hybrid method is the best!
Comment: 6