Is Scrum really a methodology?

I'm not sure where your definition of "methodology" came from, but it's not one that I'm familiar with. When I'm talking about software product development methodologies, there are two definitions that I'm familiar with:

• A Guide to the Project Management Body of Knowledge states that a methodology is "a system of practices, techniques, procedures, and rules used by those who work in a discipline".
• ISO/IEC 24744 states that a methodology is a "specification of the process to follow together with the work products to be used and generated, plus the consideration of the people and tools involved, during an information-based domain development effort".

If I had to guess, I'd probably say that the PMI folks would consider Scrum to be a methodology, since it does define some practices and rules to help manage product development in a complex space. The ISO 24744 people probably wouldn't consider Scrum a methodology since it's incomplete and doesn't provide enough details into the specific process steps, how tools play into it, and all of the necessary work products.

Then you also have terms like "method", "process", and "life cycle" thrown into the mix, which doesn't help.

Out of all of the words, "framework" makes the most sense to me to describe Scrum. Frameworks tend to be partially-complete structures that can be fleshed out and completed. In the software world, frameworks are also abstract and highly reusable in various contexts, with the details being used to specialize them for different contexts. All of this fits nicely with what Scrum is. It provides a few abstract roles, events and sequencing of events, and rules that different teams can plug different details into. There are many different ways to use Scrum and still "do Scrum" in accordance with the small number of rules.

I'm not sure where your definition of "methodology" came from, but it's not one that I'm familiar with. When I'm talking about software product development methodologies, there are two definitions that I'm familiar with:

Perhaps this is a big part of the problem. We seem to be a bit stuck in a hole that has been dug by waterfall software practitioners. The term is far older than software, and far broader than product delivery, and yet we seem only concerned with how it's been misused by waterfall software delivery methods of the last few decades. 



I agree that framework is a good word, but something can be both a framework and a methodology. 



So I guess the reason I'm asking the question is because we always seem to get defensive when we see the word methodology, but it feels to me like we're reacting to it's misuse, not the reality of the term. 





For full transparency, at this time yesterday I would have said the same as you. It was only because I found myself ready to type out a defensive critique of someone describing an 'agile methodology' that I decided to take the step back and look into it, and believe I may have been wrong all these years. 

When it comes to terms, I'd rather get people to stop using the life cycle related terms (SDLC, PDLC) to mean sequential, plan-driven approaches (or waterfall approaches).

I'm a bit less picky when it comes to "process", "methodology", "method", and "framework", but I do tend to use "framework" when something is incomplete and isn't prescriptive and words like "process" or "method" when there's a great deal of specificity - my implementation of Scrum is my process or method, which is likely to be different than your implementation of Scrum, but both are built on the same framework.

I will say that I do sometimes group Scrum in with "agile methodologies". My thinking there is that if you are using the Scrum framework as it was designed and intended, the end result should be a process or methodology that is consistent with the Manifesto for Agile Software Development. However, I do know that not everyone who claims to be using Scrum is using the framework as it was designed or intended, which leads to faux Agile or Dark Scrum or similar names for things that use Agile terms and concepts or appear to be Agile but are not.

@Michael wrote: So I guess the reason I'm asking the question is because we always seem to get defensive

Actually, I'd say people get downright nasty!

I had a very respected member of the Scrum community, someone I like and respect very much, tell me 'I would never get taken seriously' if I kept saying Scrum was a methodology.

Even on this forum, a few days ago, a respected member called me out publicly in what felt like an effort to shame me for referring to Scrum as a methodology. It is most unwelcoming, and might I even say, bullying.

Scrum is Not About Software

The problem with the ISO/IEC 24744 definition is that it is for software engineering. Scrum makes it clear in no uncertain terms that it is not just for the software domain. It is more general and is cross-domain. So a more general definition must be used.

Most people use the dictionary to define words. Agile practitioners value simplicity, as the Manifesto says "simplicity... is essential." So why must we make things so complicated with something so fundamental?

Here's the dictionary definition?

meth·od·ol·o·gy

1. a system of methods used in a particular area of study or activity.

To argue Scrum is not a methodology, you must argue that it provides no methods. No rational person could argue that.

Just look at the daily scrum. We state who can be there, we can state who can participate, we specify the strict conditions in which Scrum Masters or POs are allowed to speak, we describe the purpose of the Daily Scrum and we even time box it down to 15 short minutes.

Does that sound like some sort of a system?

Do there seem to be methods associated with it?

Any rational person would say yes. Everyone in the broader software development community says 'yes.' Only die-hard Scrum Practitioners would argue that it doesn't. All while bullying, belittling and publicly shaming others who don't agree with them.

Straw Man Arguments

When I see Scrum people argue it's not a methodology, it's always a straw-man argument where they create a ridiculous definition of 'methodology' and then argue against it. Gunther Verheyen's linguistic gymnastics to create a definition that bares no resemblance to how any regular person would define a methodology is one of my favorites:

‘Methodologies’ are typically composed of stringent and mandatory sequences of processes and procedures that implement predefined algorithms.

Yeah, that's not the definition of a methodology.

Compliance Testing

It seems to me like this is a big compliance test.

If you want to be accepted in the Scrum Community, you must unlearn the basic definitions of words. You must then accept new definitions that bare no resemblance to reality. And then you must shame others who do not comply with unlearning.

Compliance testing others is not a good way of creating partnerships and deepening friendships. It's quite the opposite.

Scrum Courage?

Honestly, I really fear even writing this.

I wonder if saying something as simple, honest and truthful as 'well, Scrum does meet the dictionary definition of methodology' will limit my ability to advance my career in the world of Scrum.

If I don't 'drink the Kool-Aid', will I get pushed out of the industry? I've already been told that nobody takes me seriously because of my unabashed use of the dictionary to define words. I've already been called out publicly.

But I've always believed in speaking truth to power. And courage is a Scrum value. The problem is, I use the dictionary definition of courage. Perhaps there's a different definition of courage that I should be using?

Honesty and Truthfulness

One of the other things that bugs me is that the push to redefine words and mark people who don't adopt your double-think as 'suppressive persons' just doesn't seem honest or truthful.

If we as practitioners can't be truthful and honest with ourselves about something as simple as the definition of the word 'methodology', then how can anyone trust us to guide a Scrum Team, coach others, be transparent?

If your first introduction to a team is to show them that you not only refuse to accept the universal definition of commonly used words, but that others must accept the redefining as well, what credibility do you have when it comes to commitment, courage, focus, openness and respect?

I believe in the Scrum Values. I don't think lying to ourselves about the definition of basic words, and forcing others to comply with the lie, is in line with them.

I think we can do better.

Thanks Darcy for a long and thoughtful reply. I definitely agree that there feels like a strange cargo cult element to the use of language, and I think it was the realization that I was contributing to it that spurred this post. 



I'm sure many of us are familiar of the story of the monkeys that were sprayed with water when they tried to climb the ladder to get the bananas? 



The social bullying you're talking about is something I definitely recognize, and I think perhaps we've all been conditioned to behave like those monkeys without every actually realizing it.

I intentionally did not use the word 'cult' in my reply. :)

Framework: First and Foremost

And I do believe Scrum is a framework, first and foremost. That's exactly what I teach.

But I also think you are correct when you say that 'framework' and 'methodology' are not mutually exclusive  terms. Things can be both.

Yes, I respect Scrum as a framework.

But at the same time, when writing, talking or speaking, you can't use the word 'framework' a hundred times over and over again. So you use synonyms to try and make your writing or speech sound better and more egalitarian.

But yes, even the occasional use of the term seems to raise the ire of the enthusiast community.

Value of a Framework

I also understand the reasons behind the impetus to frame Scrum as a framework.

I always frame Scrum as a 'framework' when introducing it to others. I don't disagree with that approach for one second.

We want to distinguish Scrum from Waterfall. We want to let people know that Scrum is flexible and adaptable, unlike traditional software development methodologies.

And we want people to know that Scrum is 'purposefully incomplete' as the Guide states, and that people must discover their own, low-level processes and methods, above and beyond what the Scrum Guide says.

Granularity of Methods

I think the argument often comes down to granularity.

Scrum is very high level. In the Scrum world, 'processes and methods' are thought of as being more granular and fine-grained.

And I think we want people to understand that. It's a distinction we want to make clear to people who are new to Scrum. And it is a very important distinction to make.

But at the same time, the word 'methodology' doesn't make any judgements with regards to granularity. So it is a restriction we as Scrum practitioners impose on the definition of the word 'methodology'.

But we as a community don't have the right to redefine commonly used words. It's an intellectually dishonest pursuit, especially if we are going to use this new, self-serving definition as a linguistic stick to beat others with.

I'm against beating others with sticks. I'd rather convince them with kindness.

I'm with you Michael, the term methodology is overloaded and has a lot of nasty baggage.

I used to coach on RUP back in the day.  They I learned agile.

To me RUP (and SAFe) both try to give you an answer to any problem you can have.  "We have the solution in this 5,000 page document".  You just have to toss out what you don't need but it's hard to toss out anything to come up with a reasonable approach in an organization, so people tend to keep a lot of stuff that isn't needed very often.  This is a tailor down approach.

The scrum guide is a tailor up approach.  "You can add what you need but this is the core that you can't throw away".  People tend to keep their approach lighter with tailor up.  

Notice I didn't say methodology or framework.  That's too loaded of statement.  I also want to say the SAFe isn't terrible, it just has a lot of stuff in it and can be used poorly without the right mindset (empiricism and self organization).  This isn't here to debate SAFe or RUP, just to use those as well known super sized collections of guidance.

Thanks Chuck, and I totally agree. I'm an SPC also (shock horror), and my opinion is SAFe is a bad framework but a great body of knowledge. 



I also think it's totally fair that anyone would describe it as a methodology. Like you say, the word has baggage, but getting mad at people for using the word seems like the wrong approach. I think it's more important to clarify that regardless of the word used, it's being treated as a tool to support empiricism, not an exact guidebook. 



Sometimes I think we practitioners turn people away with our purity testing around language. I caught myself doing it and realized that's not who I want to be. 

Here is my thought:

FRAMEWORK - gives you the What - You figure out the How.

we do not follow it to the letter, but we know what our goals are and we aim 

for it in the most efficient and effective way adhering to values and principle of Agile.

METHODOLOGY - gives you the How - the steps, Following it to the letter. Dot's the 'i', cross the 'T' - 

with the nuances of too much detailed work that are unnecessary.

Step 1, buy her flower, Step 2 dine in expensive restaurant, step 3 buy her diamonds - the objective

of how to say i love your wife.

Agile gave us what it wants. - Working Software over comprehensive documentation - it does not tell you to the letter What you need/ steps you need to the letter, nor How comprehensive is comprehensive, does it tell you should not exceed a thousand word?

It has it's upside and downside - there are people who love doing what they are told to do, every step of the way and there are people who'd like the empowerment. To exercise their innovative mind on how to do things. Think about what Knowledge worker attributes are in the organization.

Scrum guide says...Scrum is a lightweight framework that helps people, 

teams and organizations generate value through adaptive solutions for complex problems.

...and yes, people can begin to go through the semantics of methodology and framework and what differs :) 

Scrum is an empirical process that encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve. It is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Scrum emphasizes teamwork, accountability, and iterative progress toward a well-defined goal. It is widely used in agile software development and can be applied to all kinds of teamwork. The three pillars of Scrum are transparency, inspection, and adaptation. By following these principles, Scrum enables teams to structure and manage their work effectively.