Scrum is not an agile methodology

People have lost sight of the fact that Scrum is not a methodology. I see comments such as “Scrum is killing agile” and it drives home, with emphasis, that there’s a huge disconnect between understanding what an agile methodology is and what Scrum is (and I know I’m beating a dead horse, but it’s important — because Scrum is not a methodology!).

Let’s start at the beginning and reiterate this original statement from Schwaber and Beedle, the creators of Scrum:

Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies, or standards.

Scrum is a process. One process, that must be taken and combined with other practices, methodologies and standards. A process does not, in and of itself, create a methodology and for this reason I say that “Scrum is not an agile methodology.” I might even go so far as to say “Scrum is not Agile,” but that’s misleading — because as a process, Scrum is compatible with and enhances agility, either taken as an “Agile methodology” or a general practice of being agile.

As Scrum has become more of a buzzword it runs into this dichotomy more often. I experience this frequently with my clients, where the dialogue goes something this this:

Me: “So, what methodologies do you follow?”

Client: “We use Scrum.”

At this point, I feel as if, say, I’d asked for a bowl of fruit and being given a bit of jam.

Me: “Yes, but that doesn’t answer my question since Scrum is a management process, not a methodology — do you use any development methodologies?”

This last is often poorly received. It’s at this point that I typically remind my client the reason I’m here is because they’re having trouble, and the reason is likely because of poor internal processes.

Methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. In the context of software and systems engineering, it specifically addresses how we manage the conceptualization, specification and delivery of the software. Scrum does not cover any of this. Scrum is just a management process that can be applied to pretty much any business situation.

A good methodology is going to provide a framework in which requirements capture and management is specified. Project parameters and management criteria, such as reporting structure, authority and responsibility, status management and progress management will be specified. Program assessment goals and objectives will be specified. Assessing organizational capability and planning growth or acquisition may be needed. How requirements are stated, what depth they must go to and what standards must be met, and how to manage change in requirements will be specified. Likewise, quality assurance processes will be set forth (for example, audits and controls will be put in place to ensure requirements meet agreed upon standards). Testing of the product will be standardized as well: What techniques will be used, what are the goals of the test program, and what will the output of the test program be? User acceptance standards should be specified and usability testing programs implemented. Transitional phase operations, often overlooked until “after we’re done,” need to be planned and prepared for — and then executed. Scheduling, resource planning and budget management are of course a key component of any well-run program. And through it all, meaningful measurement criteria must be established and communicated to stakeholders.

Scrum touches only the tip of the iceberg in regard to much of this. This is intentional: Since it’s designed to work compatibly with just about any methodology, Scrum explicitly avoids putting too many constraints in place. More than anything it’s intended to refine an existing methodology and process, improving its productivity through streamlining.

Of course, sometimes Scrum is all you need. A sufficiently senior team, comfortable with the problem domain, combined with a project of reasonable size and a business that’s willing to launch without a clear end-point can work. But more often than not, one of these four essential elements is missing. Perhaps the business isn’t comfortable with an undefined, vague end-point (they may want to know what the budget is, or have a hard launch date). Perhaps the team is new, hence the necessity for more structure and measurement. It’s a rare situation that we can dive into a project with no methodology, only the Scrum process, and come out the other side in a favorable position. Sometimes it will work, but it’s a gamble — and often a gamble that the business isn’t willing to bet on.

I’d like to stop hearing “we use Scrum” in response to the question “what’s your methodology?” It’s great to say, “Rational Unified Process with Scrum to streamline it” or perhaps “XP with a Scrum wrapper so we have better visibility,” but please don’t try to deliver software with “just Scrum.”

15 thoughts on “Scrum is not an agile methodology

  1. Couple of questions come to mind after reading your post:

    1. What methodologies would you recommend for teams considering using Scrum as a management process? I know there won’t be a single answer, a few candidates would be okay.
    2. Do you feel this misunderstanding of Scrum as ‘methodology’ is the reason Scrum is taking so much heat?

    The challenges I find with Scrum are because the cross-functional team of specializing generalists is incongruent with most traditional organizational structures. I think there is also a lot of role confusion when it comes to the PO and the SM. These roles are new and don’t map one to one with existing roles. Also, there is not enough guidance within Scrum to help people scale to multiple teams. The basic 3 role, 3 artifact, 3 ceremony framework breaks down past more than just a few teams.

    So, while I don’t disagree with your point, I am not inclined to think that Scrum being misunderstood as a methodology is really the nut of the problem.

    Thanks for the post.


    1. Mike,

      1. What methodologies would you recommend for teams considering using Scrum as a management process? I know there won’t be a single answer, a few candidates would be okay.

      That is more or less the root of the problem. Without knowing the parameters of your particular situation, it’s impossible to recommend a methodology that makes sense. For instance, if I were to suggest Rational Unified Process, I might be pushing you toward something that has far too much process and rigor for what’s needed in your environment. Likewise, to suggest Extreme Programming could do you a disservice unless your team was senior enough, and the project simple enough, to fit the methodology.

      2. Do you feel this misunderstanding of Scrum as ‘methodology’ is the reason Scrum is taking so much heat?

      Yes, at least to a degree. Many of my clients have been expecting Scrum to be ‘the solution,’ without gaining a proper understanding that it can’t solve all their problems. The expectation is: Send a few people to get Scrum certified, and we’ll be all set with a comprehensive methodology we can apply throughout the company. Unfortunately, the team members that go to training rarely come back saying “wait a minute, Scrum is great, but it’s not going to get the whole job done here!”

      Personally, I think Scrum is fantastic — but, it doesn’t address the methodology end of the problem. For that you need an awareness that your team/organization needs Scrum as well as something else. This is one reason Rational Scrum was born, because it provides a “single solution” to the problem by delivering both management process (Scrum) and a development methodology. But, it’s only one solution and it fits somewhere in-between the XP-methodology and RUP-methodology, so to speak. Depending on the amount of rigor you need, you have to choose the right methodology. Spacecraft tend to need Waterfall, while social networking sites work great with Agile methodology.


  2. A very good point; I think most people ‘forget’ or weren’t aware in the first place because they add in a bunch of technical practices alongside Scrum. Using Scrum as the core process and then adding in other Agile technical practices (e.g. TDD), one can get a customn Agile process that works quite well. Essentially the Scrum process + additional practices become a ‘methodology’, which is not really pure Scrum any longer per se. nothing wrong with it and it can work really well, but you’re right to remind us that Scrum isn’t really a development methodology.



  3. “Methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry”

    so, scrum _is_ a methodology. got it.

    seriously – if scrum is not a body of practices, procedures and rules, then nothing is. i’m not sure where you’re getting your scrum information from, but you’ll never see anything like this in the original scrum books and articles.

    scrum is a _project management_ methodology. it has nothing to do with engineering practices, testing practices, or organizational practices.


  4. I agree that the answer “we use Scrum” doesn’t properly answer the question “what’s your methodology” — how would you change they way you ask the question to better solicit the answer you were aiming for? If you know they’re using Scrum as their process, better to ask them how they are using Scrum to implement Agile Development methodologies.
    You get a simple answer to what sounds like a simple question, however what you’re asking for is much more detailed (as you explain). It’s a conversation starter rather than small talk, ya know?


    1. Matt,

      Very true. The most important bit is to get the conversation started. Inevitably, it rolls around to why Scrum is “failing” (in the customer’s eyes, at least) — next comes the education phase in which Scrum is properly positioned. Somewhere along the line, the lightbulb comes on as the customer realizes that Scrum is a great tool, but not the right tool for every problem. That leads to selecting the right tool (proper development methodology) and implementing a solution.

      Good point — thanks for making it!


  5. I’ve never understood all these discussion. I mean I don’t care if call Scrum a methodology, a framework or whatever. I understand what Scrum is, and what people can call with the name, and I don’t need additional label.

    Actually if you wanted to have all these labels most of the time you’d hear “we don’t use anything specific” answer since many companies just use some of best practices along with common sense as their software development methodology.

    If you asked me what do we use I’d answer it is Kanban supported with a set of best engineering practices and a lot of common sense. As far as I know we don’t follow anything specific. Does it mean we don’t have methodology? Come on, what a question.

    And after all, who cares?


    1. Pawel,

      Hearing a client tell me “we use Kanban with a set of best engineering practices” (or even “we don’t use anything specific”) would be great. It would mean the client really does understand the engineering process — and while they may be looking for ways to improve it, at least they know what they’re doing.

      The reason I care about this kind of thing is simple: More often than not, it’s my job to “fix” (or “de-risk” or “improve the process”) situations that are out of control. Often a great deal of the problem stems from a few root causes, one of which can be a complete misunderstanding of what Scrum is. By fixing the vernacular and finding a way to express how complex software and hardware engineering really is, it becomes clear how a more formal method may help solve a problem. It also helps dispel the belief that sending a few people to Scrum training is going to deliver a complete engineering process and solution to a customer’s needs. (These are worst-case situations but they do show up!)

      Thanks for the comment! Hope to see you back again.


  6. good point here. it’s also where this caution is to come from: Please don’t believe that just because some consultant says he uses scrum that his ideas and suggestions are “Scrum” based. They may specifically be that consultant’s personal software methodology. It’s important to know which part is scrum and which part is methodology.


  7. I keep quoting Ken Schwaber: “There are many reasons why your enterprise can’t deploy products and systems as rapidly, inexpensively and with the quality that you would like…Scrum won’t solve them. Scrum is simply a tool that will relentlessly expose them.”

    It’s tempting to call Scrum a meta-methodology. I’m not sure that’s entirely accurate, but it’s at least a pointer in the right direction. It’s hard to wrap your mind around though. I think Scrum is misunderstood because this idea is so radical and counterintuitive.


  8. “Okay, so we’ve decided to use Scrum. So that’s most of the thinking taken care of. Now, there’s just one more teeny-tiny question: how will we create working code?” Yep, welcome to the world of Software Development as Afterthought


  9. Zacharias,

    OK, it is one thing to believe something called Scrum (or agile, kanban, lean, you name it) will easily fix you broken process and it is another to take Scrum in general the orthodox way. With the former I’m with you. You can send a few people to Scrum training but most of the time it won’t fix broken process unless most of the people are committed to improve. And then it can be any consistent method which would do the job.

    On the other hand: is Scrum a methodology? Yes. No. Maybe. Depends how you use it. Depends what you understand as Scrum. Depends on modifications you’ve applied. Depends on hell lot of things. You want it or not Scrum became a buzzword which can mean Scrum by the book implementation or well-thought, Scrum-based custom approach or old crappy process with addition of daily stand-ups.

    You can be perfectly right with your skepticism when people tell you Scrum is their methodology but the other team can be totally puzzled with your questions. Depends on situation. Depends on context.

    When I hear some company is agile or works with Scrum I’m naturally skeptical since these terms are so often abused these days. But I’m equally skeptical when I meet people who put too much weight into labels. After all these aren’t labels which write the code.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s