I have seen a number of interesting confusions going on with these terms recently as far as agile and scrum go: people asking if something is “Agile” or “Scrum”. Job positions asking for “agile scrum masters”, which show that some people think you can do scrum without being agile. Then it occurred to me: how about explaining what’s the difference between Scrum and Agile.
So in this blog post I want to quickly cover the important differences as far as Scrum and Agile for you to never be confused again. I will address many questions I got from beginners in the community. If you are in a hurry, jump to the In a nutshell section.
Is there a difference between Scrum and Agile?
Yes, there is. Scrum is a framework. Agile is a mindset.
Scrum gives you a structure on how to execute your work. Agile gives you principles to guide your way of thinking.
Agile is bigger than Scrum.
You can choose to visualize it this way: Scrum is a small circle, inserted in a big circle: Agile.
And that is so because Scrum is ONE of many possible implementations of Agile.
What is Agile?
I realized that other than this quick introduction I never really dedicate a blog post to Agile itself. I guess it’s time to break it down better to you.
Agile started officially in 2001 when some folks doing software and software managed declared that they were “uncovering better ways” to develop software and codified their ideas into what is known today as the agile manifesto.
They declared that certain values should guide great software development and that you could live these values by enacting 12 principles. If you want more insights on each of the principles, as a 21-year-old celebration I am writing about each and you can start with the first one here:
Probably the most important agile value is:
Individuals and interactions over processes and tools.
Tools and techniques come in support of people doing their best work. People are not blindly subject to tools and techniques. It’s always cheaper in money and emotionally to change processes than people.
Agile as a mindset, as a way of thinking, is about products being developed by people and for people, in the face of constant and rapid change. While the pace of things seems fast today, it was just a hint and prediction back in the late 1990s. So, the agile manifesto was quite controversial, because most of the models for developing products, software included, were very stable, slow-paced, and full of approvals and gate-phases.
According to agile, it’s better to develop things in small steps and constantly ask for feedback instead of spending a lot of time thinking about all details, then spend a lot of time implementing all the details and then asking for feedback.
With agile you reduce risk, cost, and achieve better quality by doing things incrementally. You are also more future-proof because a requirement defined two years ago might have changed in the mind of the customers and even as far as laws and regulations go. We need to respond faster to change, and that’s where Agile shines.
But the most important thing I like to highlight with agile is that you must consider human aspects whenever you want to get a product done. Simplified processes, focus on human interaction, collaboration of ideas and elevating autonomy, mastery and purpose of the product developers. Agile recognizes that people cannot be managed in the same way as machines.
As you can see, in many ways agile offered a paradigm shift from a mechanistic approach to work and to employees and even customers. According to Taylorism , efficiency is what matters and dividing work in specific tasks designed by someone other then the workers. It made sense back then where workers’ education seldomly went beyond 3rd grade.
Things are much more different when you enter the realm of services and knowledge workers.
What is Scrum?
Scrum is just one of the many frameworks and methods that exist to implement agile.
As of today, though, according to the state of agile report, Scrum is one of the most utilized agile frameworks out there. That’s why it’s so known and sometimes confused even.
Scrum is known by the concepts of Sprints, or cycles in days or weeks during which work is done. Focused, uninterrupted work. A team accept changes in the beginning of a sprint, then get a focused approach on creating your product or your software. The team has autonomy to decide the best course of action. Then in the end of the sprint, the team come back to show what they’ve done.
Simply speaking, Scrum has 5 events, or meetings with specific quorum and intention. You have your Sprint planning, where you commit the upcoming Sprint Goal, the work to be delivered. You check-in every day with your team members in what is called the Daily Standup. And as the Sprint comes to an end, you show the work you produced to the outside world in the Sprint Review. It all ends with the Sprint Retrospective, when the team looks back and learns from how they’ve worked in the sprint.
Scrum itself is an event. A meta event, a container where all the other events happen.
Scrum has 3 accountabilities, kinda like roles or hats that you wear:
- Scrum Master, the one who looks at how effectively the team is working.
- Product owner, who maximizes the value of the work prioritized.
- And everybody else in the team, who are called developers: the ones making the product or developing software.
Why Agile frameworks and methods?
Because some people felt like giving instructions on how to implement agile.
Frameworks simplify the adoption of ideas, giving people more concrete approaches. Frameworks are tools, and as such, are not a bad thing.
One thing is to say “deliver frequently” and “at regular intervals inspect and continuously improve” in the manifesto. Another is to give instructions like in Scrum on how to implements those things in the concept of a Sprint and Sprint Retrospectives respectively.
It’s important to notice that in theory Scrum is older than Agile in paper. In the early 1990’s Jeff Sutherland co-created what was once to become what we know from Scrum.
It’s also from late 1990’s that XP (eXtreme Programming) was making its way into the world as well.
So why are these frameworks, especially Scrum, considered agile if they started before the agile manifesto?
- They are aligned in agile principles: collaboration, incremental deliver, value is measure by the client, progress is working product and not a bunch of ideas on paper.
- While the agile manifesto was codified later, in 2001, the feelings and ideas behind it were bubbling up ever since the PC and computing revolution in the mid 1980s.
- The folks involved with things like XP, Scrum and other techniques are signatories of the agile manifesto.
No framework is a silver bullet, though and it’s unfair to think otherwise. Different frameworks fit better different spaces and solve different problems.
It is also common and normal that teams and organizations adopting agile will outgrow these default frameworks in favor of developing their very own agile frameworks and approaches.
Agile in the 21st century
Today Agile is used in many other industries, such as marketing, product development, health care, just to name a few. It has evolved too. Things such as business agility, customer-centricity and adaptive organizations are important elements of 21st century Agile.
You can find agile approaches such as Modern Agile, where the focus is on generating faster, more valuable results you can also see things like Heart of Agile, where the focus is the human and learning.
You will notice all these and many other second wave agile approaches move away from “established” agile frameworks.
And that is because frameworks were invented with much more specific results in mind, which was intended and it’s fair.
As an example, even though Scrum has evolved and got simpler, Scrum was and still is a framework for developing complex products. Applying it in other contexts is possible, but it was never the intention of the framework, so success can be modest.
Agile and Scrum in a nutshell
Agile is bigger and freer than Scrum.
Agile is a mindset. Scrum is a framework to implement this mindset.
Let’s draw to understand in the simplest form. Draw a big circle and call it Agile. Draw a much smaller circle inside it and name it Scrum. That’s a way of visualizing how they are related to each other.
Agile is a mindset, and mindset is not a mysterious thing. A mindset is a way of thinking that considers human approaches for working, for servicing customers and for responding to change in products and organizational structures.
Agile considers values and principles such as motivation, collaboration, and technical excellence, and YOU CHOOSE how you want to implement those principles according to your current reality. That includes your business and market, your technical needs, and the culture of people in your teams and your organization.
Scrum is one of the many frameworks to implement agile product development. It also happens to be the most used one as of today, so I’d say it’s not a bad idea to understand how it works.
Interested in learning more about Agile?
You are in luck!
I’m hosting an online masterclass that I call Agile Accelerator. Because that’s what it is! It cuts through the fluff and helps you understand agile in a way that’s actionable and useful! Great for new learners in agile but also to reset your agile knowledge!!
You’ll also get an opportunity to ask me those burning questions that keep nagging you!
Register for free and meet me there!
Interested in learning more about Scrum?
If you are interested in learning more about Scrum, check out my e-book. Scrum is very simple, and you can learn how to use it in a day. If you never worked with agile before it most certainly introduces you to agility in a very practical way.
