Agile vs. Scrum: what’s the difference?

Agile and Scrum are so often mentioned together that many people don’t know there’s a difference.

But there’s a big difference — it’s like comparing apples to oranges. Or — more accurately — like comparing an overarching goal with the roadmap leading you there.

The 2 can work together in harmony, but they each have their own unique purpose.

This article will settle your Agile vs. Scrum confusion once and for all.

What is the difference between Scrum and Agile?

Agile is a philosophy, and Scrum is a way to put that philosophy into practice.

Project management experts refer to Agile as a project management methodology, and Scrum as a framework. The Scrum framework gives the Agile method form in the real world.

Say someone has a philosophy that all sentient life was sacred. Because of that, they don’t think it’s right to eat meat.

The belief in life being sacred is that person’s methodology, while being vegetarian is their framework.

Similarly, believing in a religious faith could be called a methodology. Going to a house of worship every week is a framework.

Scrum is one of several frameworks developed by project managers who believed strongly in Agile. Others include Kanban, XP, Lean software development, and Scaled Agile Framework (SAFe).

Why is this important to understand? Because in project management, your beliefs influence your actions.

Try monday dev

Agile vs. Waterfall

In the early days of software, a certain belief system ruled: a product should never be shipped until it’s absolutely internally perfect. This gave rise to a software development practice called the Waterfall methodology.

In Waterfall, a software project follows several distinct stages in order. First, researchers analyze the need for the product. Designers sketch ideas, developers create features, and QA engineers test for bugs. Nobody starts their job until the team before them finishes.

The whole thing can take 6 months or more, but at the end, the customer gets a complete, polished product.

At least, that’s the theory. In practice, by the time a Waterfall software project is finished, customer tastes are likely to have moved on.

That’s assuming you were building something they wanted to begin with.

The Waterfall model makes close communication with end-users difficult. Meeting their needs often turns out to be guesswork.

Traditional Waterfall approaches also rely heavily on documentation, which tended to slow everything down.

A group of these managers, dubbing themselves “organizational anarchists,” got together in 2001 for a now-legendary meeting at a ski lodge. This resulted in the “Agile Manifesto,” in which the anarchists documented the 4 values you’ll see in the next section.

The interesting thing about this meeting, though, is that almost everyone who attended already subscribed to a modern project management framework. Many believed in Scrum or Extreme Programming (XP).

You read that right: Scrum was invented before Agile project management. Long before, in fact. The concepts behind Scrum first appear in a paper published in 1985.

It’s a common misconception that the Agile Manifesto struck software development like a bolt from the blue. In reality, it was a consensus document, written by people who shared little in common but a few core values.

Once you know the history, you can understand the key distinction between Scrum and Agile.

The end goal of Scrum is to build processes. It’s a framework that a project manager can use to decide what needs to be done.

The end goal of Agile is to promote a set of values. You can easily have an Agile workplace that doesn’t subscribe to Scrum. You can even — at least hypothetically — have a Scrum team that isn’t Agile.

That’s why it’s often called Agile Scrum — to make it clear the team is embracing both Scrum and Agile together. It also explains why there’s not really such a thing as “Scrum methodology.”

So what are the key values of the Agile method? Let’s take a closer look.

Is Agile a methodology or a framework?

Agile is a methodology that was originally designed for managing software projects. It’s built around the fact that software can be delivered quickly, and iterated constantly. Gaps and errors are seen as opportunities for learning rather than abject failures.

That certainty lets a project manager build an Agile approach around 4 key values.

1. Individuals and interactions over processes and tools

Earlier project management methodologies stressed the importance of regular practices and consistent tools. Every team was required to use the same tools and processes, no matter who was on the team or what they were trying to do.

Agile methodology recognizes that every team and project is subtly different. While there’s value in consistency, there’s greater value in going to war with the army you have.

In the end, an Agile team is composed of people, and every process is only as good as the people running it.

Instead of finding a one-size-fits-all tool for every project team — which doesn’t exist — an Agile process constantly adapts to help team members reach their full potential.

The monday.com team task manager template, pictured above, shows how this can work in practice.

This accessible, customizable dashboard lets each Agile team member self-report on what they’re capable of getting done. You can add new columns as you like, making it the perfect platform for flexible, people-focused plans.

Try monday dev

2. Working software over comprehensive documentation

We mentioned above that traditional software development approaches demanded enormous amounts of documentation.

UX researchers documented customer requirements, engineers documented technical specifications, technical writers documented procedures for end-users, and QA testers documented bugs.

This was all a holdover from the days when most engineers focused on hardware.

In hardware, the cost of making a mistake is much greater. If something goes badly wrong, a microchip engineer might have to throw out weeks of work, while a software engineer can just revert back to the last stable release.

Agile still values documentation. In fact, none of the Agile values advocate getting rid of anything. They’re about changing your priorities.

By focusing on working code over documentation, you give your developers the freedom to get the job done.

The only thing an Agile developer needs to get started is software requirements specifications — everything else can happen after that.

3. Customer collaboration over contract negotiation

Under the old systems of software development, clients would meet with developers to negotiate the details of what the developers could deliver.

After that initial period, the customer would have very little input on the final product.

The relationship was often adversarial: clients got annoyed at the lack of transparency, while developers grew frustrated whenever the client made requests that internal processes couldn’t meet.

Because of the radio silence during design and production, Waterfall project management sometimes resulted in final products that the end-user flat out didn’t like.

The Agile manifesto promoted a seemingly simple concept: the best way to fulfill your stakeholders’ requirements is to talk to them.

Instead of working to the confining terms of a negotiated contract, Agile development becomes a conversation between clients and developers.

Agile software development emphasizes getting working software in front of your customers as soon as possible — what’s known as the minimum viable product (MVP). With an MVP, they can start giving you feedback immediately.

Gathering your feedback in one place — as with the monday.com feedback tracker template, pictured above — lets it guide your project team as they work. Your end-users become collaborators instead of adversaries.

Try monday dev

4. Responding to change over following a plan

This is perhaps the key value that makes Agile what it is. If this was the only one you’d heard of, you could still build a workplace that looked at least recognizably Agile.

The fourth value heralded the rise of a function known as change management. It’s illustrated by the monday.com template below.

The old attitude held that change was a liability. It cost money, and so was to be avoided no matter what. The best project was the one that changed the least between inception and conclusion.

The Agile mindset argues that change is inevitable. The market will change. The tools will change. Customers will change their minds.

Instead of avoiding change — which is impossible — an Agile project team builds systems to reduce the cost of change. If you anticipate change, it doesn’t need to cause expensive delays.

Is Scrum a methodology or a framework?

Scrum is a framework for applying Agile principles to a real-life project team — just like Kanban, Extreme Programming, and the Scaled Agile Framework (SAFe).

Let’s take a look at one more monday.com template.

This is our sprint planning template. It looks simple (that’s what we aim for), but it’s also a complete introduction to the basic concepts of Scrum.

We’ll refer back to it as we take you on a tour of the 6 Scrum principles.

1. Empirical process control

At the heart of Scrum is a focus on controlling processes through transparency, oversight, and evidence-based thinking. A Scrum process can be observed from all angles and changed with little cost.

Using a template like the one above makes your Scrum team processes easy for every stakeholder to observe and manage. Any changes can be quickly communicated to the whole Scrum team.

2. Self-organization

Trained workers are happiest and most productive when they’re allowed to manage their own work.

Scrum takes it for granted that the best person to prioritize a task is the person who’s actually doing it. The role of the project manager, or Scrum master, is to distribute tasks and remove obstacles blocking individual contributors.

With monday.com, every team member can update their own templates, giving you nearly real-time knowledge of how they’re managing their workflows.

3. Collaboration

Scrum project management is about the value that teams can create by working together. Storing information in a central dashboard makes collaboration that much easier by ensuring everybody is starting from the same page.

Try monday dev

4. Value-based priorities

Agile Scrum project management organizes unfinished tasks into a product backlog (for the entire project) and a sprint backlog (for the current sprint or iteration).

At the start of each iteration — which usually lasts around 2 weeks — team members claim the items from the sprint backlog, starting with the highest-priority tasks.

Software is key for managing this part. A project manager or a product owner could use monday.com to update the value of each backlog item in real time.

5. Timeboxing

It’s impossible to overrate the importance of timeboxing to the Scrum process. Timeboxing means that when you say something will take an hour, it takes an hour or less.

Not only does timeboxing improve efficiency, but it also makes it easier to treat time as an expendable resource — which it is. A daily scrum meeting is as much a resource expenditure as an employee salary or software subscription.

6. Continuous improvement

In sharp contrast to old-school 6-month development cycles, Scrum treats project management as a series of short “sprints”.

Each one is an opportunity to get feedback from customers and other stakeholders, making sure the product stays pointed toward a consensus goal.

Agile vs. Scrum: idea vs. execution

Once you understand the nature of Agile vs. Scrum, you’ll never be confused about the difference.

Scrum is a way to interpret Agile. Agile is the idea; Scrum is the execution.

We designed the monday dev to be the perfect Agile tool. Instead of trying to respond to an imagined set of needs, monday.com gives you the power to fulfill your own project management requirements.

Check out our monday dev today, and see what it can do for your project.