standing behind a waterfall with arms raised
PHOTO: eflon

A conversation I recently had with my son who just completed his first year of college was a real eye opener. Beyond the typical late-teen topics, we spoke about how his first project in computer science class went. He told me how his team had to define the entire project they were building up-front, then they began to code, then test, fix and finally release. 

Having lived in the world of software development for the past 25 years, I couldn’t resist asking questions. So how did that work out for you? Did you have a lot of rework part way through as you learned and got feedback? Did you really think you knew everything there was to know at the start? And so on. 

I got the answers I expected. It was hard, Dad. When we started, we did as the professor suggested: We documented what we were going to build, then we built what we thought we were supposed to build, then we had to start a large part of it over and do it again and again.  

Although I hoped his professor was putting him and his classmates through a learning experience to help them understand the pitfalls of such a process, sadly that was not the case. This is how the professor expected them to work and how many organizations still work today. They think they can just define it all up-front and then deliver on those requirements — typical “waterfall” thinking.



Related Article: Agile, Kanban & Scrum, Oh My: Which Product Management Approach Is Right For You?

Traditional Waterfall Approaches 

Waterfall has been the dominant development practice for as long as we have been building things. It is a process where work is divided into large sequential steps. The process typically flows in one direction, which is forward, thus the term Waterfall. 

For example, in software development, the steps are often requirements analysis, design, implementation, testing, deployment, release and maintain. Many of these projects are spread over several months or years.

As you can imagine, by the time you get six months down the road, many things that could not have been anticipated have likely changed.

traditional waterfall approach

Agile Was Born, But Has it Grown Up?

In February 2001, 17 people got together to find a better approach, with a focus on delivering software-based products. They had already worked on some approaches and things had been evolving, but it was time to formalize their thoughts. The Agile Manifesto was signed during that retreat and it has been full steam ahead — although not as quickly as many would like. 

Despite the release of the Agile Manifesto and the ongoing work done of these 17 people and their teams, many organizations are still building software-based products using waterfall methods. Why is that?

In theory, waterfall is predictive. We know what we want to deliver, we put dates on when we expect to deliver and how much it will cost. But we can only predict so far out before teams drag on for years, working to deliver the wrong thing, missing deadlines and going well over budget. 

One highly reported on US Government project — The Internal Revenue Service (IRS) Customer Account Data Engine (CADE) project — was conceived in 2000 and finally pushed live (only in part) in 2006. Many reports, including this one, discuss what happened. The short of it is, they spent a significant amount of time defining the entire system and enterprise architecture before doing any work and then based the work on those designs. Of course, by the time the work began, the designs were out-of-date. And so the fun began.

Projects still go on this way too often: no real end in sight, executives coming and going, blame being placed everywhere, wasting money and time. It is time for definitive change.

Related Article: 4 Agile Principles for the Modern Marketer

Planning Too Far Out Will Leave You Behind

In today’s world of easy to access and procure technology resources, you must be fast to market, but also fast to change. This means building just enough to get started and go from there, getting feedback along the way on what you've delivered by the users of the product. Virtually everything containing software and technology is changing overnight, so you cannot plan too far out, or you will be left behind.

Start small, learn and grow as you build

One of the most popular (some would argue the most popular) ways to develop software-based products with agility is Scrum. Scrum, which was created in 1995 before the signing of the Agile Manifesto, is a process framework for resolving complex problems iteratively and incrementally to a create a high-value solution that elates customers.

scrum framework

Scrum is:

  • Empirical instead of predictive.
  • Iterative instead of sequential.
  • Concentrated on gathering continuous feedback instead of gathering in stages.
  • Value-focused instead of deadline-focused.
  • Self-organizing instead of control and command.

With Scrum, you work in Sprints of 30 days or less. At the end of the Sprint at least one increment (you can deliver more often) is production-ready. You now have the opportunity to reflect on what has been built with stakeholders (users, customers, leaders, etc.) and then plan for the next Sprint, evolving both the process and the plan to keep improving through continuous inspection and adaption. This helps the team avoid the pitfalls of long delays, unpredictable changes, new competitors and more that come with waterfall.

Related Article: How to Ensure Your Organization Can Win With Agile

Too Many Storms Have Come and Gone

When developing software-based products you no longer have the luxury of years to deliver something. The markets around us are changing, competitors are coming online and technology is evolving more quickly than ever. You need to deliver and learn quickly, without long gaps or delays. You must accept feedback and react to it, both in process and what is being delivered.  Without the ability for constant change and agility, customers will leave you behind.