Debunking the ‘Scrum isn’t Agile’ misconception
The Agile manifesto is baked into Scrum
In a previous article, I argued the following:
Using the Agile Manifesto to claim Scrum isn’t Agile, it is like saying the paintings of Claude Monet aren’t Impressionist. - Agile isn't an excuse for winging it
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 the same token, you can’t use the Agile manifesto to claim Scrum isn’t Agile. The thinking behind Scrum, XP, and other frameworks shaped the Agile manifesto, as they were trying to describe what they had in common and called this Agile afterward.
The ‘Scrum is one of the parents of Agile’-argument may not be convincing enough for you that Scrum is Agile. I’ve decided to make the case even stronger for all the skeptics out there by looking at how Scrum embeds the soul of the Agile manifesto in its framework.
Let’s hold a mirror in front of Scrum and evaluate how it tackles the different facets of the Agile manifesto.
1. Individuals and interactions over processes and tools
I want to stress, the ‘over’ part in the Agile manifesto doesn’t mean that what’s on the right isn’t important. Here’s how it is actually phrased in the Agile manifesto:
"That is, while there is value in the items on
the right, we value the items on the left more. - Agile Manifesto"
When there is a trade-off to make between the two items, the item on the left is more important. But it isn’t always a trade-off decision. Sometimes both can go hand in hand.
Now let’s circle back to ‘Individual and interactions over processes and tools’. The importance of people, phrased as individuals and interactions in the manifesto, was expressed as follows in an older version of the Scrum Guide:
“The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive.” — Scrum Guide 2017
Scrum is about small teams of people who have autonomy and ownership in figuring out how to best do the work. The sentence I quoted was removed in a later version of the Scrum Guide, but Scrum still at its core is about the team. The Scrum Team is clearly described as ‘self-managing’ in the latest version. This means they together have full authority to decide the why, what, and how of the work.
Scrum is minimalistic by design, or as phrased in the guide, purposefully incomplete:
“The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions — Scrum Guide 2020”
In short: it’s up to the people to decide what kind of process they want to work with and what’s good enough for them. Individuals and their interactions are at the core of Scrum.
Scrum doesn’t consider processes unimportant, but processes should be designed by the collective intelligence of the people who actually do the work. The goal of a process framework is to help you discover your own better way of working. Scrum helps by showing you what’s going on but doesn’t tell you what to do. Individuals and interactions are at the core of whatever tools and processes are decided to adopt.
If you want to learn more about the guiding philosophy behind a process framework, I can recommend you to read ‘Scrum is about inventing your own rules’.
2. Working software over comprehensive documentation
The main purpose of the Sprint is to deliver a piece of working software that Scrum calls the Product Increment. There’s even more to it than this, the Product Increment should meet the Sprint Goal and the Definition-of-Done. Dizzy yet? Okay, let’s unpack this dense sentence:
- A Product Increment is a working piece of software that contains all newly built features plus those that were already released in the past. If you add a brick, all bricks that were already there shouldn’t collapse.
- The Definition-of-Done is a quality checklist that ensures what is delivered meets specific quality standards. Not meeting the DoD means it isn’t done.
- The Sprint Goal is a valuable, overarching objective (why + outcome) of the Sprint. This ensures that meeting the objective is more important than following the plan.
The aim of the Sprint is to deliver a working piece of software that meets specific quality standards and achieves a clear and valuable goal. It isn’t only writing documentation, doing design work, or coming up with a fancy technical architecture. All those different aspects need to come together somewhere during the Sprint and result in a piece of software that can be used by your customer and delivers a valuable outcome for them.
That being said, documentation is still important. It is often part of the Definition of Done. Many teams interpret this statement from the Agile manifesto to mean we shouldn’t write any documentation.
How you should read this is that if writing documentation is at odds with producing working software, then producing working software is more important. Documentation is part of the work, but it shouldn’t be a goal to pursue on its own in isolation.
In short: the main purpose of the Sprint is to deliver working and valuable software. All events and artifacts only serve to support the Scrum Team in achieving this during the Sprint.
3. Customer collaboration over contract negotiation
It’s more important to do what’s best for the customer than to do what was initially agreed upon. Following the requirements and specifications, if going against them is more valuable for the customer, then we should do always do what’s most valuable.
Acting based on the latest and best information to do what’s best is more important than doing what we initially agreed upon.
Customer collaboration means emergence. You discover what best to do as you perform work. Your Sprint plan, acceptance criteria, and Product Backlog are never final. All of them should reflect your latest and best understanding of what will deliver the most value to the customer. Changes are welcome and encouraged. It means we’re increasing our understanding and acting based on the best information we have.
Scrum achieves this in the following ways:
- Product Backlog is an ordered list of what will deliver value that is frequently updated. It is never final or finished.
- The Sprint Plan emerges during the Sprint as the work is performed. The team never commits to a specific plan or scope, only to a Sprint Goal. This keeps the plan and scope flexible as we discover more how to best solve the customer problem we’re trying to tackle.
- At the Sprint Review, there is a collaboration with the most important stakeholders to decide what to do next based on the current understanding. We take one step at a time and decide our next step based on how the previous one went.
4. Responding to change over following a plan
The only thing that matters when doing a Sprint is building a valuable Product Increment that meets the Sprint Goal. The Sprint Goal prevents following the plan to become more important than meeting the objective. By working with Sprint Goals teamwork, flexibility, emergence, and adaptability are encouraged.
I’ve compared Scrum to Jazz before. Scrum works best when you improvise and act at the moment:
“You will never get your plans or estimates right, so don’t waste your energy on the illusion that you can. Instead, try to cultivate in your team the ability to respond to changes and making the best decisions on the fly.” Scrum is like Jazz — it works best when you play and improvise
Scrum is about acting and seizing the moment. Not staring blindly at the sheet music and doing everything you planned to do from the start.
Mirror, mirror on the wall, who’s the most Agile of them all?
If you hold a mirror in front of Scrum let there be no mistake: you can clearly see the striking resemblance between parent, Scrum, and child, the Agile Manifesto.
If how you do Scrum conflicts with the Agile manifesto, you’re probably doing something wrong. Scrum isn’t prescriptive, so people and interactions can govern whatever processes and tools you do decide to use.
That being said, the Agile manifesto is easily misunderstood. To add to the confusion, many people preach about Agile to further their own interests, by trying to claim Scrum isn’t Agile, but whatever approach they came up with is. That’s because Agile is hot, and everybody wants to have a piece of the action.
Scrum has Agile baked in. That doesn’t mean you can’t implement Scrum in a non-Agile way. The Agile manifesto can serve as a checklist of how Agile your Scrum implementation is, but let there be no shadow of a doubt that Scrum is Agile by design. The Agile spirit is baked into the core of Scrum, by attempting to give as much ownership over the process as possible to the people at the coalface doing the work.
In the end, it doesn’t matter if what we’re doing is Agile or not. Is it working? An Agile way of working is ideally suited for solving complex problems, but is that the domain you’re operating in? How nice it sounds, in theory, doesn’t matter, but does it produce the results we are expecting? Because in the end, that’s the only thing that matters.