Scrum is just one of the many flavors of Agile. And, like ice cream, there are more flavors than you might think; enough to give you brain freeze.
Given that there’s a whole guide written about Scrum, it’s a logical starting place for a definition:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
In Essential Scrum, Kenneth Rubin defines the Scrum framework as:
“A collection of values, principles, practices, and rules that form the foundation of Scrum-based development.”
Patty Corry once defined Scrum as an abstract class which I think is a perfect metaphor.
“Scrum is an abstract class, obliging teams to provide the implementation.”
For those who have never worked as a software developer, this analogy might not make much sense. It’s been many moons since I wrote code, so I don’t think it would be advantageous for me to try to explain his example. Instead, I’ll give an example that might be more familiar.
In today’s corporate culture, it’s common to communicate via PowerPoint. The higher the executive, the more likely a PowerPoint will be obligatory. To deal with this common need, many companies will develop a template enabling consistent branding and improving efficiency.
Hermione and I might use the same template to create a presentation, but our end product will be very different. Her presentation might be on the benefits of the Gantt chart, and mine might demonstrate how Kanban metrics can help teams identify impediments. Yet both decks have the same look and feel because we derived them from the same template.
Also, both Hermione and I can put presentations together more quickly. Leveraging a predefined slide format allows us to focus just on our unique content and saves us from having to design every slide from scratch.
Scrum is a lot like a PowerPoint template. It gives us three roles (Product Owner, Scrum Master, and Developers), five events (The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), and three artifacts (Product Backlog, Sprint Backlog, and Increment). Similar to how a template might give us three introduction, five informative, and three timeline slides. In Scrum, we fill the roles with people from our organization like we’d fill the informative slides with bullet points. We implement the five events and set the agenda of each like we might tweak milestones on our timeline slides. We determine how to manage the three artifacts in the same way we might ascertain the best way to tell our story with the slide formats available.
What we don’t expect from a PowerPoint template is for it to tell consumers how to develop their presentation. The template’s original creator has no way to anticipate every future user’s needs. The template provides only the building blocks, and it’s up to the creators to add relevant content.
Scrum gets a lot of criticism for causing this problem or not solving that problem. It’s easy to find lots of articles and opinions about how useless or harmful Scrum is. In most cases, it’s not Scrum itself that’s the problem; it’s that team’s specific implementation of Scrum.
The creators of Scrum never intended for it to be a one size fits all solution. It’s a framework that helps you get started, leveraging empiricism to customize the process to your unique needs.
Head First Agile defines agile as:
“Agile is a set of methods and methodologies that are optimized to help with specific problems that software teams run into, and kept simple so they’re relatively straightforward to implement.”
That is true, I suppose, but I feel like it covers up the inspiration of agile. Kenneth Rubin captures the essence of the origin in his definition of Scrum from Essential Scrum:
“An umbrella term used for a group of related approaches to software development based on iterative and incremental development. Scrum is an agile approach to development.”
In his mini-rant on the misuse of the term TDD, Ron Jeffries confirms both the original intent and his dislike for what it has become today:
“The term “Agile” was vague at the beginning, as an umbrella term covering many methods. It is now watered down to the point where to people who care, a project calling itself “Agile” is assumed to be messed up, and it usually is.”
If I were to taste test this smorgasbord of cheesecakes, I would be able to define for you the distinguishing elements. Personally, I’m a fan of the original graham cracker crust, and I’m not too fond of fruit smeared on my slice. If you sat me down in a room with sixteen other cheesecake connoisseurs, we might discuss what constitutes the quintessential cheesecake. Perhaps we’d even boil it down to four values and twelve principles.
Since consuming the quintessential cheesecake grants one the feeling of contentment, we might call our findings the “Contentful Manifesto.”
Perhaps this example is a bit weird, but it illustrates how the Agile Manifesto came to be.
Agile initially emerged as an extraction and simplification of the most effective techniques and concepts that software development teams used successfully back in 2001.
A group of like-minded folks got together at a ski resort to discuss some big ideas. Many of them were proponents of different approaches to software development. Even though they weren’t all following the same process, they all saw some success. After reflection, they could highlight the similarities between their approaches and summarize the key concepts into four values and twelve principles. These values and principles became known as the Agile Manifesto.
After that, commercialism got a hold of it, and it took on legs of its own. Some would argue it walked right off a cliff, but that’s a topic for a different blog post.
I’ve alluded to this above, but let’s state it outright. Scrum came first; Scrum existed before the Agile Manifesto (and thus before Agile).
In Mountain Goat Software’s Certified Scrum Master course, Mike Cohn mentions that his first experience with Scrum was around 1994 or 1995. This timing aligns with the 1995 publish date of Ken Schwaber’s SCRUM Development Process paper.
These facts indicate that Scrum’s popularization started nearly six years before the birth of the Agile Manifesto.
I’ve heard an agile trainer say Scrum is to agile what Samsung is to refrigerators. Samsung is a brand of refrigerator, and Scrum is a brand of Agile.
I prefer to describe it as a flavor. I think I probably have a food addiction.
A shared benefit of all agile methodologies is helping agile teams deal with complex projects.
As with anything else that has multiple flavors, there is always a favorite, and with agile, for better or worse, the clear winner is Scrum.
“There have been many surveys done over the years that have found that the most common approach to agile is Scrum.”
I believe that the popularity of Scrum as an agile framework has helped add to the confusion and leads to people commonly conflating the two terms as the same thing.
As all squares are rectangles, but not all rectangles are squares, all Scrum implementations are agile, but not all agile teams are running Scrum.
So, can your team be agile without Scrum? Yes, as mentioned previously, there are several flavors of Agile. You could practice a different Agile methodology. Or, you could follow the values and agile principles in the Agile Manifesto without following a named approach.
In fact, there are tons of flavors of agile, some of which I’d never even heard of. Australian Agile Coach Craig Smith developed a nifty little visual that includes forty agile methodologies, but I have no doubt more are cropping up.
A look at this page from the agile signatories will confirm that almost everyone came from a different approach or background. This diversity means that multiple points of view went into crafting the document, which is a good thing.
It’s incredible that seventeen people, who are proponents of different approaches, could get together and boil their thoughts down into four values and twelve principles. Maybe it’s just the way the world is now, but I’m not sure you could get seventeen people to agree on pizza toppings, much less something this thoughtful.
Like there are many different flavors of ice cream, so are there many different flavors of Agile. Scrum is just one example. Scrum is Agile, but not all Agile is Scrum, just like pistachio ice cream is ice cream, but not all ice cream is pistachio (thank goodness).