Why take the leap from Waterfall to Scrum?

Most of my career, I’ve been a waterfall project manager. *Gasp* the horror, I know.  When I started working at Ample (a proponent of agile and Scrum), I discovered I had a lot to learn about these methodologies. 

Sure, I’d heard of these terms and even incorporated some of them in my work as an innovation strategist, but now that I was in the ✨tech world✨ — the very place where these principles originated — I realized I had to get on board, and fast. 

Now that I have gone through both Scrum master training and experienced the waterfall projects, what have I learned? Well, a lot, but mostly that agile and scrum are frameworks, not rule books, meaning everyone can benefit from incorporating them into their work culture (even in a waterfall-based environment!).

But before you can break the rules, you have to learn them. So what are the main differences between waterfall methodology and scrum methodology?

Waterfall Methodology

If you have experience in project-based work, you’ve likely seen a project timeline that looks like a waterfall — phase after phase listed out from the kick-off date to the due date. One phase ends and the next begins until the work is done. Then the team moves on to the next project. In this world there are a few key traits: 

Project Phases

Usually waterfall projects have set phases that include: requirements, design, development, testing, and deployment. 

This means that the project is seen as a whole: 

• The whole thing is designed. 
• Then the whole thing is built. 
• Then the whole thing is reviewed. 
• And then — you get the idea — the whole thing is deployed into the world. 
  

The whole thing moves through the process as a unit in its entirety. No part of the project moves into the next phase until all parts have completed the phase before. (If this sounds pretty inefficient to you, you might be on to something). 

Stakeholder involvement

In traditional waterfall projects, stakeholders are involved from the beginning when they share objectives, provide the list of must-haves, and gather any information needed to make the project happen. While they also might be involved in phase-by-phase reviews, they usually only come in at the end of phases for a final review before the project is released into the world. 

Sounds pretty typical, right? After all, isn’t that how things have been built for decades? Why fix it if it isn’t broken? 

Well, while I (maybe controversially) still think there are good uses of waterfall methodology, in general, it does usually mean longer timelines, less stakeholder involvement, and a tougher time adjusting if things change later on in the project. 

Scrum Methodology

To my surprise, Scrum is not a set of strict rules that dictate how work is managed.  Rather, it’s defined as “A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” 

What the heck does that mean? Here are my key takeaways:

The foundation of Scrum first emphasizes a set of values, before steps

Scrum has five core values: courage, focus, commitment, respect, and openness. These act as the foundation for any team that functions within the Scrum methodology. This also means the foundation isn’t based on external steps defining how work gets done, but on internal behaviors that the team (from leadership, down) must operate within. 

Empiricism is key

You cannot become a certified scrum master without hearing the words empiricism and empirical processes at least 10,000x within one week…or at least I’m pretty sure that was a requirement at my training. That’s because Scrum implements the three pillars of empirical process control, which are transparency, inspection, and adaptation. As a scrum master, you ensure the process is built on these principles for agility and team health. 

Scrum events make up the process 

After you understand that Scrum is built on a foundation of values with pillars of empiricism, then and only then do you learn the actual steps —  formally called Scrum events — of the Scrum process. 

These steps create an ongoing, iterative process to getting work done.

At this point you’re probably thinking, “Lady, you’re not even comparing apples to oranges here. More like apples to steaks.” 

And, while that might be  true, now that I’ve transitioned from waterfall to Scrum, I see now that in knowing them both I can compare the two more easily. Even though they differ in some major ways, I believe that even people operating in a waterfall world or a complex agency environment can benefit from Scrum, its value, and its processes. 

After some major growth as a company, this year at Ample we’ve really changed how we worked as a company and within our new teams, with the goal of more agility and better team health to go along with our high-quality output. 

This included learning more about Scrum processes while still living in the client-driven, rapid-paced technical space that requires a little waterfall experience and a lot of Scrum knowledge. 

What’s the takeaway here? 

I’d say that Scrum methodology can be used in any environment.

• The less that’s known, the more agile you need to be!
• Processes — regardless of methodology — should ensure quality work but also team health. Scrum is just as much about culture as it is about process.
• Radical transparency and communication are key contributors to Scrum and should be truly valued by every team.

Success isn’t just about getting to the finish line. It’s how you define the finish line and every step along the way. 

‍

Want to see how we use the Scrum methodology to bring your brand’s digital experiences to life? Check out our capabilities and contact us today!