Don’t go chasing waterfalls.

Or, our experience moving away from a Waterfall process to an Iterative approach.

Waterfall To Iterative

“We should be building cakes in slices not in layers”. An analogy using cake to describe a web development process, you say? You’ve got my attention Mr. Geoff Wilson of 352 inc. He might have uttered some other items of importance after that, but I had already been transported back to my childhood home — the kitchen to be precise — with my mother icing her layered banana cake. Warm, just-out-of-oven, delicious layers of cake coated with chocolate icing.

Several times while writing this post, I came dangerously close to losing the thread completely and offering, instead, a banana cake roundup. As resplendent and thorough as a post like that might be, covering everything you’d want to know — including any possible purpose for nuts (the answer is none) — I feel like I should right this ship now before I get carried away.

Building a cake, or websites, in layers is what we’ve been doing with the Waterfall process for at least a decade. Building a cake, or websites, in slices however, is brand new for us. We had been toying with Agile — grabbing bits from here and there all in an effort to make the process a little faster and more predictable — but hadn’t yet worked in a purely iterative way. It wasn’t until hearing Geoff’s analogy that things started to really make sense to me.

Waterfall Set Up

In our typical Waterfall process (and using the ‘building a cake in layers’ analogy) we’d start off with a layer of strategy, do our work, create a deliverable, and then get sign off. Moving out of strategy, we’d get into a melange of prototyping and content creation. After that process had taken way longer than we’d initially thought, we’d get sign off and then start slathering on some visual design. You could do style tiles, move straight into comps, or a mix of both — whatever blows your hair back. Then, after a few rounds of revisions, finally nailing what the client meant when they said ‘slick’ or ‘corporate’ we’d be able to get (say it with me) sign off. Logically, after this, we’d move into development, then QA, and finally deployment. But, of course, not before receiving sign off.

If Waterfall works for you, great, you can stop reading and go outside. If it doesn’t, or you have a sneaking suspicion that there has to be an alternative that isn’t Agile (big A), you might get some benefit from our trial run with an Iterative approach.

Our Iterative Approach

We attempted to use an interpretation of an Iterative Approach with a new client, Scalar. New client, new approach — what could go wrong, right? I’m sure my team thought I was nuts, trying it out on a new client with a big project, but we had already tried a dry run on a much smaller project with much less risk. That particular project team, while not gushing, at least saw merit and potential. That was enough for me. Naturally, there was some resistance and apprehension, as there was a very real possibility that it could all fall apart like our experiment with designing in the browser did.

For us, an Iterative approach didn’t seem like a huge leap from what we already do — strategy, design, dev, QA — we’d just be doing it all in much, much shorter intervals and in smaller slices. Rinse and repeat until there aren’t any slices left to build. Everyone possessed the right skills to make a go of it, we just needed to leverage them on tighter timeframes. Designing in the browser, on the other hand, was a foreign method to everyone. Our designers didn’t have too much experience coding, which resulted in our devs teaching them things on the fly — like how to best develop the ideas that they’d normally just bang out in Photoshop (as we hadn’t moved on to Sketch yet). To say it was a failure is being kind. I only bring this up because it still stings three years on and provides a cautionary tale and backdrop for any future tweaks and changes to our process — “Remember when we did that? Yeah, that didn’t work out so well”.

With the team more or less on board, we decided to split the Scalar project into three phases: ‘Kick off’, ’Ground Work’, and ‘Sprints’. Kick off and Ground Work were sprints unto themselves but rather than sprinting to produce useable software or a website feature, we were working with the client through stakeholder interviews, kick-off workshops, audience insights, content audits, high-level content strategy, and IA. The goal was to identify what pages, features, and content would end up going into the actual sprints.

A point of internal discussion revealed that without an overarching visual design direction or style guide, the final design might be rife with inconsistency. We needed to establish some ground rules on what designers could and couldn’t do during a sprint. We also felt that our Content Strategy Documents, a deliverable that identifies hierarchy of content for each page and balances the business and user goals, would be an ideal candidate for the ground work phase too.

The remainder of the project timeline would consist of five sprints, each three weeks long. We’d be actively working through prototyping, content creation, design, development, and QA for a nine page bilingual site. At the end of each sprint, a few of those pages/modules would be 100% QA’d, ready-to-go, and complete. The client could theoretically go live with those slices if they wanted to. Not a great idea, but they had the option.

Challenges With Waterfall

Sure, Waterfall is certainly a tidy process on paper — it’s logical and makes perfect sense when you explain it. But, we’d always had challenges with it and never had a way around it because, well, it was just the way we’d always done things.

Now that we have some context for comparing the two methods, we’ve noticed that Waterfall has some glaring pitfalls that you don’t necessarily know how to deal with until you’re not doing Waterfall anymore.

Inflexibility

The process itself creates its own risks and complexities to manage. It takes too much effort to mitigate risk and puts a huge burden on project management. So many things hinge on what was discussed in previous stages, which might have been weeks or even months ago. Rather than having a team firing on all cylinders and being flexible when change happens — and we all know that it does — we were far less accommodating. It’s hard to be accommodating when strategy, for which every subsequent decision is based, had been given the ol’ client rubber stamp of approval some time ago. A Waterfall process gives power to the agency to say ‘but you signed off and now I have to bill you for this change’.

I’m not saying that you can’t or shouldn’t do that, but let’s be honest, we all hide a little behind ‘sign off’ — maybe hide is the wrong word. We take comfort in knowing that things are locked down and that there’s a mechanism in place that allows us to bill for work when changes are introduced post lock down. Even still, no one feels great about it. Clients are spending more than what they wanted and the goal posts just got changed up on us.

It’s a little too unrealistic and maybe even irresponsible to assume that a client won’t have changes to their competitive landscape, business, or marketing efforts during the course of an engagement so why not have a process that at least allows for change and makes you look like a true partner? We design for outcomes, goals, and intent all the time in the work we do yet we don’t design a process that takes the realities of working with clients into account.

Low Collaboration

We’ve always been a fan of client collaboration. We do our best work when the client team is right there with us. But the kind of collaboration that a Waterfall process offers is phased and isn’t sustained throughout the project. We felt that we couldn’t build up the kind of momentum where both teams were working as one.

Each layer of the cake saw high client participation at certain points and then a big drop-off. Some stages take longer than others and so the peaks of participation ultimately are farther apart. That isn’t to say that we didn’t communicate with the client because we did, but that communication was less about being in constant contact, asking for feedback on even the smallest detail, or showing them the latest iteration of a feature. It was more about checking in or providing a phase update. It wasn’t until their feedback was needed, close to the end of a stage, that saw the highest client involvement.

I think that’s a really big challenge with Waterfall because while it offers points of high client engagement it doesn’t provide for constant collaboration throughout each phase. An Iterative approach is all about frequent and sustained collaboration on all aspects of a page or feature to move a project smoothly through to completion, with everyone on board, all the time.

Decision Decay

There’s a line in Gladiator, one of my all-time-watch-it-anytime favourite movies, that seems applicable here: “What we do in life, echoes in eternity”. The decisions we make now, will affect us later on — never have truer words been spoken about Waterfall.

A typical Waterfall project timeline for a site is, say, 14–18 weeks. Your mileage may vary but that was typical for us. Strategy is set at week 4 and design complete at week 8–9 and then, 6 weeks after strategy and 10 weeks after the start of the project, development gets underway. The number of times that internal meetings have been derailed because no one can remember why certain decisions were made during the strategy phase or why X is a requirement, is unsettling. Yeah, we document decisions in various places — like Basecamp, Invision, Asana, Slack etc — but discussions and the resulting decisions that all took place weeks ago have a shelf life. Waterfall promotes decision decay because not everyone is completely engaged at all times over the entire course of a project.

Even though our design and dev teams are pretty tightly integrated, people get busy and have to spin off one project to help out on another or even just slightly shift their priorities. Those absences or shifts in focus, while not insurmountable, change the dynamic. It’s not hard for this to happen either. A dev doesn’t really begin the lion’s share of his or her work until, the design is signed off and complete. So what’s a dev to do for the 8–10 weeks that they are underutilized? The short answer is not that project.

Waterfall made it easy for all our teams (client team included) to disengage from a project when the work being done during a particular phase wasn’t completely in their bailiwick. You’ve probably seen this happen with your teams. A dev, waiting for the design phase to wrap up, declines meetings to work on something a little more pressing. Or, a designer, after development is underway, is occupied on other projects. Or most frustrating, but not at all surprising, when a client team is less engaged during a wireframe and prototyping phase yet still provides sign off, only to ramp up their engagement during visual design. It’s natural to get more excited about things taking shape in a real tangible way. Progress is good. But, now that they are highly engaged, things that we might have missed the mark on and might have been points for collaboration were glossed over and signed off on weeks ago.

I don’t believe this to be a project management thing — though I’m sure some of this can be mitigated by some seriously good PM. This is a fundamental process thing where our project discussions, the resulting decisions, and the action taken to execute were so far apart that the only predictable outcome was inefficiency. Project success is achievable when a team can shrink the periods between discussion and execution at every step.

Gratification & Trust

Going back to the cake analogy. The Waterfall process is like a 10-year-old me obediently letting the first couple of oven-fresh layers of cake cool– not wanting to be on the receiving end of my mothers disapproving stare. So, I’ll placate and let her do her work. Then, when there’s a few layers already done, I’ll sneak some cake and she’ll just have to deal with fixing it because she’s already so far into the process. I’ve got some cake, she’s got a mess to fix — It’s hard to fix a cake when there’s a fistful missing.

I’m not suggesting that clients behave with malice towards their partners just as I do not maliciously pick apart my mother’s hard work. I just want the cake faster, just as clients want their website faster. But pushing to get to the deliverable by breezing through important parts only to make changes later erodes trust. The agency is never certain if anything is locked down and can’t trust the client at their word — just as my mother can’t trust that I won’t steal the cake. If she’d just baked a slice instead of a full cake, we’d both be happy.

Challenges With The Iterative Approach

Wrong Assumptions & Inexperience

The challenges we faced with an Iterative approach were all based on having little experience with the method. So, just by sticking to it, we’ll probably overcome the challenges we faced on the next round.

The worst assumption that we made was that we could or should do all the things that we normally do in Waterfall, for Iterative. Because things happens so fast and you’ve got three weeks to get to completion, we lost a lot of time in the first two sprints doing our Content Strategy Docs (CSDs) and prototypes.

For CSDs, a quick conversation with the Scalar team could have resulted in a quicker ‘go’, ‘no-go’. Instead, we formalized the document and needed a meeting to go over it. We didn’t need to do that and it ate into time we could have been using to make strides forward.

We also assumed that sprints could overlap. We probably wouldn’t have scheduled a project in this fashion under normal circumstances but, since we had already communicated a deadline to the client before deciding on the Iterative approach, we had to find a way to make our sprints fit.

During the course of a sprint, we had three meetings or reviews pre-planned — a prototype review, a design review, and a final dev review. Because of the overlap (and poor planning), we’d fallen short of that final dev review and couldn’t overcome that misstep until we neared the end.

On paper though, it seemed like it would work — Dev would tidy up the loose ends as one sprint closed while at the same time, participate in strategy, sketch sessions, and work on the HTML prototype for the next sprint. That didn’t work out at all.

After the first couple of sprints, even though, amazingly, we were still hitting our deadlines, we had an internal chat about how the process was working. We tweaked and made some on-the-fly changes like switching to sketched prototypes and eliminating the formalized CSDs completely. Everyone appreciated the extra little bit of time to do it right rather than rushing.

Moving Forward

The result of making those changes was the elimination of virtually all decision decay. Everyone, including the client team, was working to complete a sprint together, buzzing about on Slack (including the client) or Asana, and getting what they need to finish the job. It felt like the last day of the project was less frenetic. It felt like what productivity should feel like, measured and goal oriented.

We had built up so much trust by keeping the client involved and collaborative, working through problems together and turning around solutions quickly. They were able to see that our expertise wasn’t in just making things look pretty at the deliverable stage, but rather we showed huge value by choosing to have quick meaningful discussions instead of lengthy, and sometimes inconvenient meetings to bat around potential solutions to problems.

When we were finally able to catch up and have a dev review of all completed pages, a little surprisingly, very few things actually needed to change — that was a win.

An Iterative approach created a lot of predictability and as a result, days were easier to plan. The whole process was mapped out before you so you knew what your work day consisted of. We never expected to realize that benefit. The whole team rarely needed a jump start to get going — client and internal teams alike — we all knew that the fate of the sprint was everyone’s responsibility and we all rallied.

Overall, it was a positive first step but there’s surely room for improvement. I’m happy to hear your feedback on your approach or, if you want to chat more about how we’re making out, send me a note @steeben.

Oh, and here’s my mom’s banana cake recipe in case you’re still thinking about cake:

Banana Chiffon Cake

5 eggs (room temperature)
2 tsp. baking powder
1/2 tsp. cream of tarter
1 tsp. baking soda
1 1/2 cups pastry flour (sifted)
1/2 cup vegetable oil
1 1/2 cups sugar
2 tbsp. orange juice
pinch of salt
1 cup mashed ripe bananas (3–5)

Separate eggs. Mix all ingredients except egg whites in one bowl. Fold in beaten, stiff egg whites. Pour in 2 layer cake pans (9” pans) and bake in 375 degree oven for 1 hour.

Place on racks until completely cool. Slice each layer cake in half. Fill 2 bottoms with wonderful chocolate icing and then proceed to cover the whole cake with more icing.