Scrum 101: Three Myths of Traditional Scrum

Hi, I’m Georges, Scrum Master Myth Buster.

As a resident Scrum Master at Kinney Group, I’m responsible for promoting and championing Agile & Scrum habits on our automation projects. I started off as a developer, which shaped a lot of my goals and expectations in Scrum today. I have a bias to producing work, lightweight management involvement, and simplifying everything that’s not technical. A Scrum Master’s role is to produce an environment that is encouraging for developers and for growing the Agile mindset. Throughout my journey of training, execution, and experimentation, I have seen common Scrum myths permeate through the software development and project management ecosystem. Follow along as I debunk three myths about traditional Scrum best practice, so hold on to your Jira tickets and let’s go through the big offenders!

Myth #1

Scrum makes my development teams more efficient.

One of the first books I read for training was “Scrum: The Art of Doing Twice the Work in Half the Time.”A great read for learning the Scrum trade, but with an untrained Scrum eye, some directors and management may take away the wrong impression of how their teams will operate under a new delivery framework.

Teams today are most likely doing a hybrid practice of Homebrew/Waterfall/Agile systems. A distinct change in your Agile practice may reinforce good habits that make your team faster, however, it’s important to remember that speed is not the goal of Scrum. The goal of Scrum is to make our teams more effective not efficient.

With a bias to client and user interactions, our engineers are executing on project goals while verifying their work repeatably. Many may argue that effectiveness leads to efficiency from a high level, and they would be right, but the message behind Scrum-based development should never promise the moon. Short-term stumbles and smaller gains will happen along the way and Scrum allows your team to break these bad habits along the way. Sometimes, a team needs to slow down before they can speed up, resulting in more effective work to reach a customer’s goal.

Myth #2

Scrum is a set of meetings and rules for my developers.

I love this myth. It’s at the same time entirely true and completely misleading. By reducing Scrum to its artifacts and ceremonies, we ignore the foundation that Scrum rests upon — the Agile Mindset. When you ignore the Agile Mindset, your Scrum practices will never reach their full potential. This may ultimately get in your way instead of fostering a better development environment.

Equally important, the Agile Mindset not only requires your developers’ participation, but it involves your entire delivery pipeline. Your company’s salespeople need to champion the need for Product Owner involvement. Your business analysts need to write Statements of Work that promote handshake agreements on changing priorities. Your project managers need to keep their development teams as stable as possible. Scrum is not a set of meetings and rules for your engineers to follow. It’s a shift in the entire delivery framework and requires everyone to pitch in.

Myth #3

Scrum is the evolution of Waterfall and supersedes it.

Scrum and Waterfall are two delivery frameworks eternally locked in a misguided war of buzzwords and superstition. The truth is, they both have value for different reasons. Scrum did not kill Waterfall. However, Scrum did create a system that is better suited for rapid development, experimentation, and unknowns. Waterfall still has place for fixed, ‘simple’ work requirements. By requirement and by design, these won’t deviate from the initial technical and feature scope. With complex, initial asks on a Waterfall project, it’s no wonder that Agile processes have taken over. However, it is important for developers and managers to treat the words, “We are doing Scrum” with respect and not as a not-so-clever way of saying, “We aren’t doing Waterfall.”

Myths = Busted

There is a common misunderstanding intertwined within these myths: Scrum is easy. The truth is that Scrum isn’t just a simple evolution of the classic plan to execution flow of Waterfall. Scrum requires all hands-on deck in an organization to support. It is not a band-aid, but a methodical shift in how a company operates. If executed and supported sufficiently, adopting a Scrum practice can result in the effective delivery of your product and, most importantly, happy clients.