Agile vs. Scrum. Scrum vs. agile. You hear them used almost interchangeably in the software industry. But are they really the same thing? If not, what characteristics set them apart?

In this article, I’ll answer that elusive question: what is the main difference between agile and Scrum?

First, let’s start by defining agile.

What is agile?

Merriam-Webster’s defines agile as:

  1. marked by ready ability to move with quick easy grace: an agile dancer
  2. having a quick resourceful and adaptable character: an agile mind

If you’re looking for a word to describe how you want your software development to be, that’s pretty powerful stuff. It’s easy to see why the founders of agile latched onto that word to represent their ideas.

In 2001, the Manifesto for Agile Software Development was published. It included their commitment to four key concepts:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These commitments were fleshed out into twelve principles to guide agile development. The whole point of agile was to be… well… agile. To get software products to market quickly, to be flexible to changing business conditions, and to prioritize what’s needed right now over long-term planning.

This kind of flexibility required agile to be lightweight – in stark contrast with the heavy overhead of the traditional waterfall approach. Agile doesn’t attempt to solve everything up front. In that respect, I like to describe agile as being “incomplete” by design. Instead, agile guides developers to identify what’s most important – and deliver it into the hands of the business as quickly as possible. And we’re not talking about buggy alphas and betas, either. Software developed using agile is fully tested each step of the way, so the product is always rock-solid.

Agile is all about focusing on results rather than checking boxes or project plans. Sure, you’ll create some checklists and plans like you would for almost any project, software or otherwise. But the difference is that with agile, your checklists are there to support speed and efficiency… not to kill them.

So how do we make this agile thing work?

As I mentioned previously, agile is really a set of ideals and principles aimed at guiding development teams to better software development techniques. But beyond that, agile is rather hazy. The manifesto never claimed to have all the answers. But what it did do very well was identify what was wrong under traditional development methods and offer a viewpoint that brought the software industry more in line with the needs of businesses.

Agile purposely didn’t dictate how to accomplish its guiding principles. It left that wide open for innovators to come up with their own solutions. So how do you put agile into practice?

For that, we need a framework.

In our case, that framework is Scrum.

Scrum: an agile framework

Some people call Scrum a type of agile. Others call it a subset. But Scrum isn’t really the same “type” of thing as agile at all.

The main difference between Scrum vs agile is this:

Agile is a philosophy.

Scrum is a tool to help developers put that philosophy into action. That tool is most often referred to as a framework.

Where agile avoids the day-to-day details of how to implement itself, Scrum aims to accomplish exactly that. Scrum gives development teams a set of processes, strategies, and daily routines to achieve agile development.

In fact, the whole notion of Scrum vs. agile is a misnomer. They don’t compete or clash at all. Quite the opposite – Scrum is built to complement and actualize the principles of agile.

To see how Scrum does this, please check out some of our posts such as Scrum Ceremonies: The Blueprint to a Highly Effective Sprint and Daily Scrum Practices to Rock Your Next Sprint.

So while the point of this post is to show how Scrum and agile are different, it’s important to note that in principle they are very much the same. It’s their purpose – how they’re meant to be used – that is different.

The purpose of agile is to establish software development principles from a philosophical standpoint. The purpose of Scrum is to implement that philosophy with a toolset of lightweight, flexible processes. Scrum vs. agile isn’t a competition at all – it’s a win-win.

Other agile frameworks of note

Scrum is not the only framework out there, either. Agile left the framework slot wide open for creativity and innovation. Some of the other frameworks of note are:


Kanban arose out of the Just-in-Time manufacturing processes of the auto industry and was first applied to software around 2005. The name means “visual signal” and it puts a high value on communicating through visible charts and workflows.

Extreme Programming (XP)

Extreme Programming relies on close customer involvement and rapid feedback loops to deliver production-ready software in short timeframes (similar to Scrum’s production sprints). It’s based on four values and twelve practices that align nicely with agile. You can view a process map of XP here.


Scrumban is, as you might guess, a merging of ideas from Scrum and Kanban. It adds some of Scrum’s daily structure but maintains Kanban’s focus on a visual Work in Progress Board. This makes it most suitable for projects such as maintenance, research and development, and post-production work.

Scrum: our agile framework of choice

At Ascendle, we’re big proponents of Scrum. And those who have worked with us know that Scrum’s results speak for themselves. For the rest of our readers, here are just a few of the reasons we choose Scrum as our framework of choice:

  • Scrum has the best balance of letting engineers make engineering decisions and business stakeholders make business decisions
  • Scrum empowers development teams with both responsibility and accountability
  • Scrum offers highly predictive and iterative techniques such as agile estimating and planning poker

Most importantly, we choose Scrum because in all our many years of experience we’ve found it to be the best framework for delivering commercial-grade software.

Now you can take advantage of that framework, too. For help setting up your own Scrum teams, or to boost your next development project with our expert Scrum teams, contact us at Ascendle today.

Share This Article