Ditching Scrum to become Agile is often empty-headed

I often read posts where the Agile Manifesto is misunderstood and used as an excuse to ditch Scrum. The well-intentioned advice is to stop using Scrum and wing it with the more powerful Agile Manifesto as your guide.

Agile isn’t an excuse for winging it — Photo by LA MM

Without exception, the reasoning in these articles goes as follows: Why follow the dogmatic process dictated by Scrum that doesn’t serve your specific needs? Why settle for Scrum, if you can tailor the way of working to your unique, special context by applying the principles of the Agile Manifesto? Why do Scrum if you can be Agile instead?

In short: Agile is awesome, and Scrum is just a watered-down version of Agile.

When you ask these questions, you are missing the point of both Scrum and Agile. Allow me to explain.

Scrum is a founding father of the Agile Manifesto

The Agile Manifesto is an attempt to capture the essence of different Agile frameworks like Scrum and XP. The Agile Manifesto is a derivative work that tries to distill the spirit of what these existing, different frameworks had in common. Without its Agile parents Scrum and XP, there would be no Agile Manifesto.

Using the Agile Manifesto to claim Scrum and XP aren’t Agile, it is like saying the paintings of Claude Monet aren’t Impressionist. The label Impressionism was invented after there were Impressionist paintings. Monet’s work Impression, soleil levant was criticized in a Parisian newspaper to be a sketch at best, and this ultimately led to the term Impressionism being coined.

You can’t use that same label to now claim that the Impressionist works of Monet do not belong to the Impressionist art movement. By that same token, you can’t use the Agile manifesto to claim Scrum isn’t Agile.

Agile isn’t an excuse for winging it — Claude Monet, *Impression, soleil levant* — Public Domain

The Agile Manifesto is outdated, while Scrum keeps evolving

The Agile Manifesto was written and unchanged since 2001. I’d argue software development has changed a lot, and especially the field of Product Management has matured significantly since then. The Agile Manifesto is a time capsule filled with the latest and greatest software development insights of that time. But time has not stood still since then.

Around 2001, there were still lots of companies struggling to deliver working software. If you have any doubts about this, think of Windows XP which was released in 2001. Try to remember how often your computer would crash, display an error or show a blue screen of death. Can you still remember the Windows XP error sound? Almost 20 years later, I can still instantly recall that sound, that’s how bad it was!

And then, compare this to the current version of Windows, where I can’t even remember the last time I encountered any showstopping problems. We’re now in an era where companies can provide working software just fine. There are many efficient Feature Factories out there. The main challenge is to deliver something that matters: software that delivers value to customers and the business.

Scrum has evolved since 2001, and the first Scrum Guide was written in 2010. To contrast the Agile Manifesto with Scrum: the Scrum Guide has been updated 5 times, and we are now in the sixth iteration. Here are some examples of changes:

Scrum has expanded its scope from building products to solving complex problems.
The release planning meeting has been removed.
Sprint Burndown and Release Burndown were mandatory artifacts but have since been removed.
Sprint Plan changed from a commitment to a forecast.
Scrum values have been added: Courage, Openness, Respect, Focus, Commitment.

There were many more changes, and Scrum is still evolving! There is a new, long-awaited version in the works. The Agile Manifesto, however, is stored in an icebox, with some principles standing the test of time, and others much less so.

Stop clinging to the Agile Manifesto like it is some form of absolute truth everyone should aspire to be like. It is almost 20 years old, unchanged, and Agile in practice has definitely evolved since then.

You can’t build great products using just Scrum

Scrum isn’t enough to build great products. Period. Scrum is purposefully incomplete and needs to be enriched with your own ideas, insights, and knowledge to deliver the most value in your specific context. This necessary enrichment by the people who perform the work is what makes Scrum ultimately Agile. It’s up to the people to figure out their real, preferred, and successful working process.

Scrum doesn’t tell you what to do, Scrum shows what is going on. Scrum provides few answers. It is like a spotlight that lights up the darkness to show what is going well and where there are bumps in the road. How you solve those problems is entirely up to you. Do you want to apply the Agile Manifesto to solve those issues? Go ahead!

This is why people who claim you should ditch Scrum and become Agile instead are missing the point. Scrum provides minimal scaffolding which you can use to build something on top. The scaffolding allows you to perform work, but all that hard work is still up to you.

When you ditch Scrum, all the problems you’ve had before will still be there. Except now, Scrum won’t be there to help show you what problems exist. If you were not able to solve these problems with Scrum, I can guarantee you won’t be able to fix them without Scrum. Scrum isn’t supposed to resolve the issues that really matter. That difficult job is left for you to figure out.

If you want to learn to ride a bike, better stop focusing on the training wheels

The biggest reason why people decide to ditch Scrum is because Scrum becomes a goal by itself. Scrum is never about doing Scrum, it’s about leveraging the transparency of Scrum to figure out how you can deliver more value.

When you want to learn how to ride a bike, people often attach training wheels on the side. If you always keep talking and focusing on those training wheels, you will never learn how to ride the bike. At some point, you need to focus on what you want to achieve: riding the bike. That means the focus should shift from the training wheels to riding the bike.

Willem-Jan Ageling wrote an excellent article on Scrum and Agile training wheels, which explores the comparison more in-depth. When you apply Scrum, you need to shed those training wheels as soon as possible.

Agile isn’t an excuse for winging it — Picture by Vladislav Vasnetsov

When you practice Scrum, the best judge of how you are doing is not to what degree you adhere to the Scrum Guide. The question you should be asking instead: are we delivering products of the highest possible value? What can we do to deliver more value to our customers and the business?

That’s the only thing that matters when you do Scrum. Is it producing the outcomes you want to achieve? If it doesn’t do that, who cares how well you are following the rules of Scrum. If it isn’t working and producing the results you want, it is more important to figure out what is missing than what rules you aren’t following.

Agile isn’t an excuse for winging it