<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

Agile vs. Scrum: What's the Difference?

Scrum. Agile. If you’ve worked in or near software development in the last 20 years, you’ve heard these two terms tossed around a lot. And, because they’re often used together, people sometimes think they’re the same thing. 

Here’s the thing, though: while Scrum and Agile are related, they’re not the same, and it’s important for people at companies interested in using either or both to know what they are, so that everyone is speaking the same language. 

So maybe that’s you; maybe you’re confused about Agile and Scrum. Or maybe you think you might know what they mean, but aren’t sure. Maybe you have no idea what either means, and at this point you’re too embarrassed to ask. 

No worries — you’re in good company. Plenty of people are confused about Agile and Scrum. Read on for a better understanding of both. 

The short answer 

Agile methodology is a fundamental philosophy about software development. Scrum is a one of the processes that uses the Agile approach. 

Let’s break that down a little bit. 

What is Agile? 

Agile software development is an approach to software development that values adaptive planning, iteration, continuous improvement, and collaboration between developers, clients and sometimes, the end user of a project. 

Rather than sticking to a plan for the plan’s sake, Agile encourage a quick and adaptable approach to changes or problems. 

Agile methodology was first laid out in a 68-word manifesto in 2001, by a group of 17 developers who called themselves the Agile Alliance. You can read it, and the 12 underlying principles here, but because it is so short, here is the manifesto in its entirety: 

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. 

That focus on responding to change, as well as collaboration, interaction and continuous improvement, have become the hallmarks of Agile. 

There are several methodologies that fall under the Agile umbrella. Scrum is one of those. 

A Brief History — and Explanation — of Scrum 

Scrum, a methodology named for “scrummage,” a rugby term, actually predates agile by a few years. Scrum was created in the 1990s by developer Jeff Sutherland (one of the members of the Agile Alliance) as an alternative to Waterfall, the time-consuming development process that was prevalent at the time. 

At its core, Scrum is a business methodology that organizes workers into small, self-governing teams that work on set tasks during short periods of times called sprints. 

Teamwork is a very important part of Scrum. Teams are made up of between three and nine people whose members complete large projects by taking on one task at a time, and completing those tasks in short, intense sprints. 

Each scrum team has just three roles: a Project Owner, who comes up with the list of tasks the team must complete and is the voice of the customer during each sprint, a Scrum Master a coach who makes sure no obstacles get in the way of the work the team is doing, and the team members who complete the actual work.   

The team has quick daily meetings (called stand-ups because the meetings are sometimes done standing up, so they don’t take long) in which yesterday’s work and today’s tasks are discussed, as are any obstacles that have popped up. At the end of a sprint, the team reflects on what went right and wrong during the sprint so they can do better during the next one. 

There are some key benefits to scrum. Huge tasks are partitioned into manageable tasks, for one thing, and the short, hardcore sprints force teams to focus on those tasks and accomplish them by a set deadline. The fact that everyone’s work is visible to everyone else means the team can respond to changes quickly and efficiently. 

In other words, it’s an agile way to work.   

There’s more than one way to be Agile 

Scrum isn’t the only Agile methodology out there. There are several. Kanban is one. Lean is another. DevOps is yet another. Some of these methodologies and frameworks are used in combination with one another, some are used exclusively. It depends on an organization’s needs. 

If your company is considering using any of these frameworks or methodologies — even if you yourself don’t work in software development — take a moment to investigate and try to understand the terminology. 

That way, everyone is speaking the same language, and things can get done quickly and efficiently. That, in itself, is Agile.  

Thinking of implementing Agile? Contact us. We will help you implement (and understand) Agile, Scrum or any other Agile methodology that works for you.

Paul Rasmussen

About Author Paul Rasmussen

Paul wants to live in a world where he can golf every day of the year, he has an unlimited number of “Do Overs," and he hits every goal he sets for himself. As a project manager, one of Paul’s strengths lies in managing multi-faceted Agile projects. After tackling some tough ones, he’s learned a lot about which management styles do and don’t work in a given situation, when and how to ask the hard questions, and how to identify who can be counted on at critical junctures. Throughout the project cycle, he strives to give team members and clients more than what they expect. “When I can do that, it’s amazing to see the lasting business and personal relationships that are made.” Outside of work, you are likely to find Paul at the golf course, brewing up his own specialty beer, or whipping up something new and crazy for Saturday breakfast. The past few years he has spent an inordinate amount of time assembling toys for his kids. Paul grew up in Sparta, near LaCrosse WI. He graduated with a degree in Management Information Services from UW - Oshkosh. He and his wife Jody have two daughters (Maddison & Skylar) and a son (Dyllan).


Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.