Some people often wonder: are agile and scrum the same? There’s a lot of confusion out there. I saw a thread on Stack Overflow on this topic that was full of complete nonsense. So I thought I would clear things up. Short version: agile and Scrum are NOT the same. Now I’ll get into what each one is and why that is the case.
Agile is one of those things that is difficult to define, even though people know what it is. I think of it is a mindset, or a philosophy, or an approach to how we might think about things. But here is one of the most common misconceptions: Agile is not a methodology! So when you hear people talking about “Waterfall vs Agile Methodology”, there’s something going wrong.
Although to be honest, Waterfall isn’t a methodology either: it is also a mindset or approach. PRINCE2 for example is an example of a Waterfall methodology.
Is Scrum a methodology? We will get to that shortly.
The Agile Manifesto does not put forward a methodology of software development. There is nothing there about sprints, scrums, standups, backlogs, or anything like that. The only actual practice mentioned is retrospectives: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Apart from that, it is just values and principles, nothing else. And values and principles do not count as a methodology.
The Agile Manifesto talks about values, what things are emphasised, what things are promoted, what are the priorities. There is very little there about how things are to be done.
And that makes sense. Agile is about empowered self-organising teams that are respected and left to find the best ways to do the work. If the Agile Manifesto gave specific instructions on what methodologies everyone must follow, it wouldn’t be very agile, would it?
Scrum came about around the same time as the agile movement, in the 1990s. People were doing agile for years before the Snowbird meeting that produced the Agile Manifesto. Ken Schwaber and Jeff Sutherland based Scrum off some ideas they had, and got the name from an influential 1980 article called The New New Product Development Game.
Scrum got its name from the rugby formation, where a team of people with different strengths and skills work together as a unit to move a ball along the field.
In some ways Scrum is a methodology, in some ways it is not. Like many methodologies, it does prescribe some practices, rules and roles. It defines three roles (product owner, scrum master, developer), and what they are and are not allowed to do.
It defines three artefacts (Product Backlog, Sprint Backlog, Product Increment), and what they are for. It defines basic rules around how work is structured: a short iteration or “sprint”, starting with Sprint Planning and ending with a Sprint Review and Sprint Retrospective.
However, there is not much else in there. The Scrum Guide is longer and more detailed than the Agile Manifesto, but it is still short and light-weight. That is because Scrum is not so much a methodology as a framework. Scrum teams are meant to use empiricism to gradually build up and adapt processes and methodologies as they go, continually inspecting and adapting.
That means not just inspecting and adapting the product (via Sprint Reviews), but also inspecting and adapting the team itself and how people are working (via Sprint Retrospectives).
So the main difference between Agile and Scrum is simply one of type: agile is a set of values and principles, Scrum is a lighteight framework and methodology for building products. But are they closely related? Can you be agile without doing Scrum? And can you do Scrum and not be “agile”?
You can definitely follow the values and principles of agile and not do Scrum. Scrum is simply one way of doing agile software development. There are plenty of others: eXtreme Programming (XP), Crystal, DAD, XSCALE, plus various scaling and de-scaling frameworks such as SAFe, LeSS, Nexus, and Scrum at Scale.
Scrum is the most popular framework out there but it is certainly not the only one and does not have a monopoly. Many people believe Extreme Programming (XP) to be closer to the original ideas of the manifesto authors.
Sadly, you can also do Scrum and not be agile. Because Scrum is such a lightweight framework, it is missing many of the rigorous software development practices found in XP, such as refactoring, Test Driven Development, and Continuous Delivery. Scrum prioritises flexibility and adaptation, but often this means that teams end up with bloated products full of technical debt because they don’t have refactoring and automation testing practices.
Before all the Scrum purists jump up to protest, here is a quote from Jeff Sutherland himself, the co-creator of Scrum:
“Few implementations of Scrum achieve the hyper productive state for which Scrum was designed… Those that do all implement variations on XP”.
There you have it. For Scrum to really work, you need to be doing XP practices within the framework of Scrum, which many of the original agile believers have been saying all along.
Often this does not happen. Scrum is a simple system to implement, and many Scrum teams end up with half-baked zombie Scrum, no rigorous technical practices, no test automation, infrequent integration and releases. So you can definitely do Scrum and not be agile.
Some would say that these people aren’t really doing Scrum, and often that is the case, but often it isn’t. You can have a product backlog and do sprints and have a scrum master and all the rest and not be agile. I think a lot of people have worked in places that testify to that.
So agile and Scrum are not the same after all. They both come from similar places but are solving different things. Scrum is a specific system that grew out of the original values of agile, and has some good practices but is missing many practices that are really required to do agile properly.