When Henry Ford implemented the first assembly line in 1913, he probably didn’t know that he was about to change the world. He immediately took the build times of an automobile from 12 hours all the way down to 2.5 hours.

The assembly line caught on and began to expand to other processes. We started seeing changes in the way things were being developed throughout the world, from clothing to food to kitchen appliances.

The assembly line even made an impact in software development. The start to finish process was so ingrained in our minds that when building software became a thing, it was natural to follow suit. And in 1970, we had the birth of waterfall development.

What Is Waterfall?

Waterfall is a software development strategy that does all the product design up front. Every field, every button, every navigation path, every event. The software design is compiled into a giant design document and sent to the customer. No stone left unturned.

The customer reviews the design with the expected behaviors and either sends it back for modifications or approves it. On approval, the design document is sent off to a development team to build. The development team builds the software exactly as it says in the design document. There are no checkpoints, just start and finish.

When the product is complete, the customer receives it for the first time. There is no opportunity to change behavior or labels. What they get it a polished, finished product.

A significant pitfall of waterfall development is customer need vs want. If the design document didn’t translate into the software the customer had in their mind, they won’t be happy with the finished product.

The customer doesn’t know what they want. What they do know is the problem they want solved.

The Waterfall House

Traditional waterfall will show the finished product to the customer. They don’t get to see it along the way, thus are unable to catch if anything doesn’t meet their expectations.

Imagine you are building a house. You sit with the contractor for days designing your perfect house. The blueprint looks AMAZING. You fork over some cash and the construction crews get working.

Photo by Daniel Barnes on Unsplash

But you aren’t allowed to visit the construction site. You are only allowed to come see the house once it is done. You don’t get the opportunity to come in and point out that the bathroom needs two sinks. Or that the back splash in the kitchen should be white subway tile.

You get to your house on closing day and it’s nothing like the design you had in your mind. You hate it. You could have remedied this if you had been allowed to come see it during the process. Now you either have to pay to do it again, or you have to deal with it.

This is how software is built in a waterfall model. Not quite the end user experience we expect nowadays.

How Do We Correct This?

Obviously you need to do some initial planning when building software. If you don’t, you’re going to have a hodgepodge of code that may or may not work. It definitely won’t be cohesive.

But how much planning is too much?

Honestly it’s not about the amount of up front planning you do. It’s more about how strict you are in staying with that initial design. It’s about how often you’re getting feedback from the client. It’s about how much of that feedback you’re taking to heart.

The counterpart of waterfall development is agile development. Agile takes shape in many different forms, but the core principles are the same:

Iterate, gather feedback, and adjust and redesign.

Most, if not all, software companies today say they are agile. And they are, to a degree. But time and time again, waterfall sneaks back into the mix. Development teams practice a technique that feels agile, but is still waterfall. To be agile, you need to do all three components: iterate, gather feedback, and adjust and redesign.

Photo by David Travis on Unsplash

So what are these development teams doing? They iterate and gather feedback, but when it comes time to adjust the design based on feedback, that’s where they diverge.

Companies have a budget they need to stick to. They need to get this project out the door by this date. Redesigning part of a project might extend that date another two months. It will get the customer the software they actually want, but later than the agreed upon time.

So they stay with the original design and keep going. They do another iteration and get feedback from the client that they mostly ignore due to restraints. This process repeats until the project is done and they have what they originally said they were going to build.

And the client isn’t happy. They’ve fallen victim to another waterfall process. Not because they want to, but because it was faster and allowed them to hit the budget.

Being truly agile isn’t easy. It takes significant adjustments both to development processes and to the way of thinking about development. In the end, it is worth it. You have software that is in use and appreciated, and the customer has an innovative product that solves their business problems.

Spotting Hidden Waterfall Development

Photo by João Silas on Unsplash

If you want to build software your clients love and appreciate, you need to be agile. You need to listen to their feedback and make appropriate changes. You need to give them an opportunity to design it with you. Don’t stand your ground because your idea is “better.”

Software that nobody uses has no value.

Keep an eye out for the following things when your team is developing a new project:

• All the planning and design is done up front and in high detail
• The team is unwilling to make changes based on feedback
• The finished product looks exactly like the initial plan

If you see one or more of these aspects in your development cycle, you might be secretly running a waterfall operation. And honestly it’s ok to do some waterfall. However, you will get the best results and the best software by staying agile and making adjustments to your plan as you go.

If you do some quick Googling, you will find a wealth of information on something called scrum-fall or water-scrum-fall. Scrum-fall is what we’ve been talking about. Many modern development teams practice it.

You do heavy planning up front and have the customer sign off. The development team starts building. This time, we show the customer the progress at regular intervals. They offer feedback which the team may or may not take back and adjust.

In the end the client has something that they are familiar with. It might still have some quirks and odd behaviors, but at least it’s not a surprise.

You might be doing some agile practices, but technically it is waterfall.

Making the Change

Remember when you were a kid and you had a loose tooth? You would wiggle and wiggle, but it wouldn’t come out?

Your dad would suggest tying one end of a string to the tooth and the other end to the door, then he’d shut the door. That was a horrifying thought.

But you’d keep wiggling, and still have not much progress. You’d eventually come around to the string/door idea. Your dad would tie the string to your tooth then tie the other end to the doorknob while you’re crying with nervous anticipation.

Photo by Annie Spratt on Unsplash

He’d throw the door shut and *POP* your tooth would come right out. Turns out it wasn’t that bad after all. It was your nervous fear that was driving the anxiety.

Same applies with moving to agile. It seems scary. It’s not something you’ve ever done before. What if it doesn’t work? What if I don’t get buy-off?

In the famous words of Nike and Shia LeBouf, “just do it!”

Come up with your initial design. Build it. Gather feedback. Adjust accordingly. Do it again, and again, and again. Build the best product you can.

It’s all about getting your software in use in production. Build what your customer wants, not what you want. Be flexible. Make a change.