top of page
Writer's pictureBen Staples

The Difference Between Agile and Waterfall: Explaining to a Non Techie



Agile is the bees' knees. But some people don’t understand.


Why is it important to be able to explain the difference between waterfall and agile to people?


At any company, many of your co workers will be on non technical teams. Stakeholders, upper management, customer service. Critical parts of the operation like marketing, operations etc. have often not yet been onboarded to an agile way of working. But when the tech part of an organization is running agile, it is important to onboard your stakeholders so that the approach your team takes isn’t misunderstood, and team velocity isn’t slowed.


Often times when a company wants to start to use agile methodologies to deliver customer value, they will transform individual parts of the organization at a time instead of trying to transform the whole organization (this in itself is quite agile). Oftentimes, while tech may already be running agile, other parts of the organization are not; making the ability to convey the importance of agile even more important.


You could also be in an organization where there is a shift to tech from a traditional industry. Caterpillar (the construction machinery company) for example has been around forever but is really leaning in to applying internet technologies to their construction equipment. Especially with COVID, the shift to connectivity is being sped up in many traditional industries.




OR maybe you just want to be able to explain what you do to your parents, or relatives.


In general if you are working in tech, at some point you are going to have to explain the value of agile. If nothing else, this is driven by how long agile as a methodology has been around, versus the waterfall methodology. While agile has been around since 2000, Waterfall has been around since the 1970s! No wonder why it has been so prevalent, especially in more traditional industries.


We can compare these two ways of delivering a project with a popular agile analogy:


Let’s pretend that we are in New York city, and we need to get to Los Angeles. For the sake of this analogy, we are just starting with the clothes on our back and need to build or acquire our means of transportation.





The waterfall way of getting from New York to LA:


We are in New York and we have no money. We start talking to people, get a job and start making money. After a long, long time, we have enough funds to build a team of engineers, designers, etc. We sit down with our team and we think long and hard about the ideal way to get to LA. We do competitive analysis, focus groups about how people have experienced their prior travel across the US. We align that while traveling by air or train would be the fastest, in these crazy COVID times we want our own personal car.


Now that we've got the outline, we'll make a project plan. As a team, we talk about sourcing materials, what it should look like, what the seats should be made of, brake pad specifications, etc.


Unfortunately, we run out of money. Comfort is the top priority and our order for fine Italian leather seats ran us over budget so we need to stop production of the car, find a source of more money, and can’t make it to LA until we have the funds to continue production.


We pick up a second and third job, take out some loans, and resume development of our car.


The team meets with navigation experts to plan out the absolutely perfect trip, where to stop and stay over, where to fuel up and what type of fuel it should take.


We order the materials, wait for those to come in, and start constructing the car. Let’s say all of this takes a year (it would take a lot longer). After the year we go for a test drive and find that unfortunately the steering wheel has a defect and has to be sent back to engineering. Finally the engineers fix the problem, get the new steering wheel installed and we are on our way.


Overall we have a great drive. There were a few bumps in the road and detours needed because of construction that were not in our project plan, but we make it. So much time has passed, LA is a completely different place than what we first heard about when we started our project plan. Oh well.





WHAT A JOURNEY


Now lets see what an agile approach would look like for getting from New York to LA:


We’re in New York, we have no money, but we know we want to get to LA. So we start walking! We know the sun rises in the east and sets in the west, so let’s head west! Well we walk a bit and try to make money where we can and eventually we can afford a map. Now we really know where we’re headed and we start to plan out the next day's walk in advance.


Eventually we have enough money and we trade up for a skateboard. Now we are cruising! But we need to stick to back roads because of traffic. The pace is slow, but it is so much faster and more fun than walking. We keep planning out our route with our map and are starting to make more progress. Eventually we make enough money and we trade our skateboard and some funds for a bike!


Now we are moving! And we can take bigger roads than on the skateboard. We can also if we really want to go off-road if it's a more direct route!


In no time at all, we made it to LA! And WOW was it so much faster than the waterfall approach, it was so much cheaper we didn’t even need a car, just a general sense of what direction we need to go in. Eventually, if the distance had been long enough, we could have made the investment in a car, a plane, or another mode of transportation.


Who is the customer in our trip to LA analogy? It’s us! And value in this case is distance traveled on our way to LA. If we are traveling even an inch, that is more value than standing in place. The farther along we go in our journey, the better off we’ll be. Before we had a map, maybe we weren’t going in the exact right direction, but at least generally we were moving with moderate certainty.


There it is, a clear, easy, non technical way to understand the difference between agile and waterfall approaches to doing things. My hope is that you have the opportunity, if you need it, to sit down with a stakeholder questioning agile and walk them through an analogy like this one. If done right, it should be able to transform outsiders into insiders all aligned with the approach!


Just remember:

comparison of agile versus waterfall



About the author:

Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com


I do product management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want even more book recommendations?! Contact me!

105 views0 comments

Comentarios


bottom of page