Would you rather be late — or wrong? A strategic case for Waterfall development

‘Waterfall’ methods of developing product get a bad rap — and for good reason. Building software is extremely expensive, and so building the wrong thing by not integrating user feedback, the major risk of waterfall methods, is something you should avoid like the plague.

Except that’s a lie.There are cases where being wrong is the better failure mode than being late. In these situations, being able to strategically deploy a waterfall method, with its upfront planning, can be really powerful.

Being wrong is the worst

Understanding whether a software project is “worth it” by doing a cost-benefit analysis is very difficult because of the unknown unknowns that cause time estimates, our best guess of the costs, to often be inaccurate. The bigger the problem, the more unknowns there are. Using agile methods to break the work down into tiny little chunks means you can estimate more accurately and iterate through the backlog until yay, you’re done! This reduces the risk that you’ll end up in a “not worth it” situation after a lot of sunk costs.

Throughout, product managers define the minimal valuable feature scope to deliver, so the product is built like an onion with layers and layers of values. The first layer is a very small valuable project. A tiny onion, but still an onion. Subsequent releases add further layers to the onion. At every point, you can test whether that layer is valuable to the user and iterate on what you’re doing.

With agile, you get to B2 — what the user really wants — through a winding path of iteration. You avoid shipping your (wrong) first guess, B1.

This iterative approach greatly reduces the risk that you’ll deliver the wrong thing to your users. Since building software is so expensive, being wrong about what to build is in most cases a huge business risk. It’s not a risk many companies can afford to take on the regular.

Using an agile approach and slowly iterating toward a valuable solution, incorporating user feedback and improving your work methods as you go, is often a slower approach than getting all the requirements nailed down and just bashing out the project. It’s a squiggly line.

With a waterfall method, you take faster straight line route. You end up at B1: what you think the user wants. PSA: This is often not what the user actually wants.

Because agile methods increase predictability and reduce the risk of building the wrong thing, they’re extremely powerful and a best practice for most real-world development scenarios. However, there is still a case for using waterfall methods: when you’d seriously rather be wrong than be late.

Except when it’s better to be wrong than late

At Buffer, we sometimes experience cases where being late is a business risk we just can’t take. The last time this happened, we needed to remove automated retweets from our product by 23 March, and we had just 2 weeks notice. If we were late, we’d risk six million users losing access to Twitter because we’d violate their new spam reduction policy. For many users, using Twitter more effectively is the entire point of using our product, so we could not afford to miss this deadline. Twitter was serious, and this news was very sudden.

In this case, the straight line route to B1, our best guess for how to remove automated retweets on time, was what we needed. Even a poor user experience delivered on time would be better than shipping a great experience on 24 March, and risk losing access to Twitter entirely. In this case, there wasn’t time for a squiggly line where we iterated and tested and demo’d and retro’d.

A final set of requirements, locked down, and then getting heads down delivering exactly that was what we needed. Being wrong we could fix later. Being late would be catastrophic. The only back-and-forth we kept was as we discovered technical blockers, trying to find the quickest way around. As much as possible, we did not want to squiggle!

I’m grateful that Kara McNair, the EM who lead this team, knew through more than a decade of experience that what we needed now was a straight line, “waterfall-ey” method from our problem to any viable solution — and how to make that happen in an agile oriented team. Any solution that got rid of the offending retweets by the 23rd was better than an ideal solution on the 24th.

The team delivered a solid release on time, and without compromising work hours. That was some great engineering management to see in action, and Kara having lead waterfall-style development teams in the past was key to our success that day. The upfront planning and early design changes saved the day here. If you don’t really know how to waterfall, start here!

When to play that waterfall card

Being late is usually not devastating, and it’s so, so expensive to be completely wrong. The risks with agile are lower, so it’s often the objectively better process. However, waterfall methods might be what your next project needs if the following are true:

1. The wrong solution on time is definitely and substantially better than an ideal solution just one day after the deadline. In our case, there was a limit to how wrong we could be. The problem statement was extremely clear and we knew our solution would roughly solve that problem — it just might not be ideal.
2. Your timeline is weeks, not months. The longer the timeline (i.e. the bigger the scope), the higher the risk of unknown unknowns ruining your upfront plans, and you could end up both late, and wrong.

Thanks Paul Richardson for the chats that sparked this post!