The Difference Between Agile and Scrum
By: Florian Lefebvre
Tags: Scrum, Agile, Management, Product Management, Business

Photo by Ferenc Horvath on Unsplash

“Our company is Agile”. “We’re doing Scrum”. “We’re looking for an Agile Project Manager”. You can hear those more and more often. But what does it actually mean?

The rising popularity of Agile

A simple way to show the rising popularity of Agile is to look at google trends.

If we first look at the evolution of the word “Agile” this is what we get :

Google Trend graph for “Agile”

This isn’t at all impressive, but now if we look for “Agile framework”, we see a stronger rise of the interest over time :

Google Trend graph for “Agile framework”

Adding the word “framework” shows two things :

As we experienced in the software industry, people have been talking more and more about Agile

People are looking to get something they can apply (hence the word “framework”)

The rising popularity of Scrum

As for Scrum, we can find similar trend graphs for “Scrum” and “Scrum framework” :

Google Trend graph for “Scrum”

Google Trend graph for “Scrum framework”

But what IS Agile?

On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.

That is what you can read on the “History” page of The Agile Manifesto. Among those 17 people, you can find :

Kent Beck, who invented Extreme Programming,

Martin Fowler, a renowned software architect, who practically invented dependency injection,

Robert C. Martin, also a software architect famous for his SOLID Principles and “Clean Code” book,

Jeff Sutherland and Ken Schwaber, inventors of Scrum (more on this later !)

Those people met at a time where the software industry processes were slow, heavy and did not promote value or people. They wanted to do things differently, and they were already doing it (with Extreme Programming, Scrum, etc.).

Bob Martin, who invited them to meet, thought they could put all their experience to work. Together, they could find the core ideas behind actually developing better software.

Now, a word of caution, what they mean by “developing software” is the whole process. It’s not only about writing the code, it’s about producing a product with the goal to satisfy its end users. That matters a lot because it means that everyone in the company, not only the coders but everyone, must participate. Or at least be on the same page for this to work.

So they wrote The Agile Manifesto. And it’s simple. It’s about what they value :

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

They understand that software developing is made of many parts, and they don’t try to remove what they don’t like. Things like processes and tools or documentation have their use, but it should not be the focus of attention. Not as much as individuals and interactions, or simply a working software.

With those four values come twelve principles. Those principles are the embodiment of the four values. What strikes me the most, and why I love The Agile Manifesto, is how it puts human beings at the center of things, how it shows trust in people.

Now, the truth is it’s quite light, which was the idea. That is why you can find so many articles or books about what Agile is. And sometimes it can feel like those writers are talking about something completely different. That is the reason why I always point people back to the Agile Manifesto, to get back to the source, to what it actually meant at the beginning.

I encourage you to read the complete manifesto (reminder, it’s basically sixteen sentences, a pretty fast read). The simple but core knowledge and insight gained from it is really worth your time.

So, what is Scrum then?

As you must have noted, the inventors of Scrum were part of the writers of the Agile Manifesto, which is mainly the reason why they were invited.

Jeff Sutherland had been dealing with project management long before that, after being a fighter pilot in the Vietnam War and a Doctor of Mathematics.

In the 90’s he was involved in several projects and he started developing habits to improve the way things were going. Those habits piled up and were the birth of Scrum.

The name Scrum comes from a team that Jeff Sutherland coached. They had had issues synchronising correctly between team members. And he helped them come to the conclusion that they should have a daily meet where they would discuss important things, exchange information and have the opportunity to help out each other. He asked them how they wanted to call it. They decided that since they were going to be standing in a circle for a short time, and since they liked rugby — that played a part — they would call it Scrum.

In 2010, Jeff Sutherland and Ken Schwaber published the first version of the Scrum Guide. They updated it multiple time through the years. At the beginning of the guide you can read:

Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

It’s around seventeen pages long. A longer read than the Agile Manifesto, but if you want to use Scrum, or work in an environment where you’re supposed to “do Scrum”, then I recommend that you spend a little time reading it. Reading the document at the core of the framework you’re trying to use, has a way to put things into perspective.

But, what about those articles, books, people that don’t mention any of this?

I like to go back to the source, but the source is not always enough. Some things are hard to apply at work if you don’t have a more detailed guide. And the Agile Manifesto or Scrum Guide do not always give the level of detail you need.

It is a good thing that others show a more detailed approach, that they show you how you can profit from all this, step by step. But sometimes things don’t go as planned and companies end up slowly drifting away from what matters. That’s when you really need to go back to the core and ask the hard questions.

Please share with us if going back to the basics has helped you see things differently!