Scrum is not a methodology
Scrum has no exhaustive and formal prescriptions on how to design and plan the work, actions and behavior of all players involved in product development against time, let alone how such designs and plans would have to be documented, approved, stored, etc. Scrum has no rules for upfront predictions of document types and (intermediate) deliverables to be produced or the time at which they should be produced. Instead of installing and thriving on hand-overs, toll gates and control meetings like IT methodologies typically do, Scrum helps eliminating them as a major source of delays and waste.
‘Methodologies’ are typically composed of stringent and mandatory sequences of processes and procedures that implement predefined algorithms. As such, methodologies tend to rule out the creativity, autonomy and thinking of people with components like phases, tasks, must-do practices, techniques and tools. As long as the methodology is being followed everyone feels safe, because they are formally covered, even in the absence of working results or proven progress. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail. Complex problems, for which Scrum was designed, are more unpredictable than they are predictable. Today’s world has more complex challenges than simple cases.
Scrum is not a methodology. Scrum is even the opposite of such big collections of interwoven mandatory components and instructions. Scrum implements the scientific method of empiricism, the process of inspecting in order to adapt at regular intervals, not aspiring to try to predict what the adaptations will be. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and thriving on the self-organizing capabilities of people to deal with unpredictability and address complex challenges.
Is Scrum a process?
If Scrum is a process, it is certainly not a repeatable process. That might be a challenge to explain, because the term ‘process’ typically invokes a sense of algorithmically predictable steps, repeatable actions and enforceable top-down control; the sort of expectations that in our world are typical for a… methodology.
Scrum is not a commanding process. If referred to as a ‘process’, then Scrum is a servant process. What works best for all involved players, their working process, emerges from the use of Scrum. The players discover the work required to close the gap between an inspected intermediate result and an envisioned outcome. Scrum is a process that helps surface the real (daily) process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we call Scrum a… framework.
Scrum is a framework
Scrum describes the roles and rules upon given principles that help and facilitate people in a low-prescriptive way, that help people create a framework for regular inspections and adaptations. The Scrum Guide holds the definitive description of the base rules of the game. The prescriptions are minimal, but every single one of them addresses dysfunctions that were (and are) common in (software) product development.
Over the 2+ decades of Scrum, the rules of Scrum, as captured in the Scrum Guide, have gradually evolved, with small functional updates and releases. The prescriptions of Scrum, what needs to be in place to have the full benefits of Scrum, become more and more focused on emphasizing ‘what’ is expected in developing complex products over instructing ‘how’ to do it.
A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (a ‘how’ of managing progress). This obligation however has been replaced by the explicit expectation that progress on the mandatory Scrum artefacts, the Product Backlog and the Sprint Backlog, is visualized (the ‘what’). The form or format of the visualization is no longer prescribed, thereby turning burndown charts into a non-mandatory, but still good practice; a good way to play the game and suitable in many situations.
Yes, it’s Scrum if Product Backlog and Sprint Backlog exist and if a visualization of their progress is available, accessible and clear. This may be a burn-down chart with open effort. It may also be a burn-up chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.
The Scrum framework leaves options for different tactics to play the game, ways that can at any time be adopted to the context and circumstances. Scrum, as a framework, can wrap many practices. When applied well, the overall system will still be recognisably… Scrum.
The Scrum core values give direction to the actions, the behavior and the additions to the framework. Upon that core, in a ScrumAnd way of thinking many opportunities emerge. Have a look at some illustrations of ScrumAnd.
[…] Scrum is not a methodology, although we’ve all heard it referred to as such extra typically than the variety of killings in Game of Thrones. Scrum gained’t give a solution to each query, and it gained’t offer you the exact process for responding to each state of affairs you face. And most likely because of this incorrect interpretation, most scrum implementations are additionally incorrect: Teams don’t get worth. This ends in most likely essentially the most silly assertion about scrum: “Scrum doesn’t work.” […]
[…] Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings in Game of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.” […]
Due to abundance of training content available for Agile/Scrum, i am getting a bit confused with the wording used by various people on the net. Some claim Scrum is a framework and some claim Scrum is a methodology. So people using different terminologies to explain the Scrum can confuse beginners or new comers to Scrum. Thanks for clarifying that Scrum is a framework and not a methodology.
It’s just semantics. Scrum can be considered to be a framework or methodology in my experience, thankfully a thing of the past now I’m retired.
[…] Scrum is not a methodology, though we’ve all heard it generally known as such additional often than the number of killings in Sport of Thrones. Scrum acquired’t give an answer to every question, and it acquired’t provide the precise course of for responding to every state of affairs you face. And probably on account of this incorrect interpretation, most scrum implementations are moreover mistaken: Teams don’t get price. This results in probably most likely essentially the most foolish assertion about scrum: “Scrum doesn’t work.” […]
[…] https://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/ […]
[…] in its more general definition, is a simple framework to help us address complex challenges. Product development is the subset of complex problem […]
[…] Gunther Verheyen «Scrum: Framework, not methodology» https://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/ […]
[…] スクラムは、人々が複雑な課題を最大限に活用できるように支援するシンプルな フレームワークです。組織はスクラムの洗練されたシンプルさを再発見しています。未来？ […]
[…] “framework” with “methodology”: Gunther and […]
[…] purpose of the Scrum framework is to establish essential boundaries of such an environment of self-organization and intrinsic […]
[…] Scrum: Framework, not methodology […]
[…] is a simple framework to manage complex challenges. Software delivery is a complex challenge. Software delivery […]
[…] is a simple framework that supports people in making the most of complex challenges. Organizations are re-discovering the […]
[…] conceive an approach specific to their context upon the empirical foundation of Scrum. Scrum is a framework, not a traditional IT methodology. The Scrum Guide describes the framework, the minimal boundaries […]
This blog is the best description I read on Scrum. It describes best the intent of the framework.
Nevertheless I have question:
I embrace scrum for eliminating the heavy weight processes and little value, stepwise prescriptions one can find in many software development life cycle descriptions. But I “feel” the pure Scrum framework also eliminates some kind of valuable knowledege from our ancestors – just to reinvent some of them again and again.
a) Shouldn’t or couldn’t there be a concept of something like a pool of “potentially reusable knowledge” from which the Scrum team may choose – let’s say – “proper methods”?
b) To be concrete: I saw two Scrum projects in the recent past who run into big rework in their second release (Sprints) because the architecture they build on was not working. In hindsight one could argue release one just picked out the “easy stories” from the backlog and a little loner “classical” requirements analysis and architecure planning” could have avoided these large amount rework affords. Personally I think, you couldn’t avoid rework in generally, but what was the flaw with the taken approach. The management was definetely shortly before killing the whole program.
I googled a little on the topics “scrum and architecture” and “scalable scrum”. What one finds is something like “Sprint Zero” (seems some architectural groundwork is done here) or the “scaled agile framework” (www.scaledagileframework.com). Especially the later one defines among other thins a role “System and Solution Architect” which “Participate in planning, definition, and high-level design of the solution and …”.
But is this still Scrum, pure Scrum? Extending it with a special Sprint Zero, embedding it into something greater? But on the other side these guys seems to answer questions which Scrum alone does not answer and it seems that replacing traditional project and software development methods with Scrum leaves some risky gaps for greater projects and orginasations.
Oh god, my text is got longer and longer. Sorry. But what is your opinion on these issues?
Ben
Hi Ben
Glad you enjoy my blog.
Scrum has no concept of ‘Sprint 0’. In Scrum all work is organized in Sprints, and each Sprint delivers a potentially releasable Increment, a finished version of product. It is not unusual to perform architectural work or rework, where one or more Sprints deliver less functionality. It is an opportunity, to be able to do such a revision along the way. It is a learning from creating the product, which is the only validation of architectural choices anyhow.
No upfront work delivers the same learnings.
G.
“Scrum is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems.”
If that’s the case then why are sprints a mandatory part of Scrum, and according to the Scrum Guide should not be more than a month? It seems that Scrum is only applying empiricism insofar as it fits within Scrum. True empiricism would test whether Scrum itself works and if an incremental approach to developing software is appropriate.
I’m content to accept that Scrum meets a dictionary definition of a methodology as a way of doing things.
Hi Dene, at the heart of Scrum is the process of regular inspection and adaptation. The events of Scrum help people do this at a certain frequency. If you feel you need another frequency, or discover your own, do feel free to do so. Nothing should hold you back, probably certainly not the formal fact that it is not in line with the definition of Scrum.
[…] Мы продолжаем переводы статей по Agile- и Scrum-тематике, сегодня — статья Гюнтера Верхеена «Скрам – фреймворк, а не мет… […]
[…] article on why agile Scrum is a […]
[…] Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings inGame of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.” […]
[…] Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings in Game of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.” […]
[…] Scrum 如果你在不了解敏捷方法的前提下谈论”敏捷”方法，你或许会搞错并且被知道这些概念的人揭露出来，接下来我们讨论主题”Scrum和其他的敏捷方法”。 Scrum并不是一种方法论，虽然我们认为Scrum是一种方法论的次数可能比《权力的游戏》的被杀人数还多。Scrum不会回答每一个问题，它不会为你面对的各种情况提供清晰的结果。可能是由于这种不正确的解释，大多数Scrum实施也错了：团队没有从中获取到价值。这样的结果也对Scrum做了不客观的声明：”Scrum并不好用”。 […]
[…] Scrum is not a methodology , though we’ve all heard it called such more often than the number of killings in Game of Thrones . Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.” […]
[…] http://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/ […]
[…] Scrum emerged in the early ’90s from the work of Jeff Sutherland and Ken Schwaber. They formalised and turned their way of working into a cohesive set of rules and roles for complex product development, that was formally presented as “Scrum” to the public for the first time in 1995. As the co-creators of Scrum are signatories of the Manifesto for Agile Software Development, the Agile values and principles underpin the Scrum framework. […]
Nice read!
I am an old-school self-made programmer. Today at work, a colleague-programmer made a similar statement “about scrum not being a (software development) methodology”. Given my background as an amateur of philosophy, I was confused. I googled about it and landed on your excellent writing.
Now, I was pretty sure that what I knew about scrum – I know just a little, I admit – all fits in, what I understood is “methodology” (philosophical). So I re-read about “methodology” on http://en.wikipedia.org/wiki/Methodology. After, I still believe “scrum” DOES fit the philosophical term “methodology”. So, I am afraid that, at least in a philosophical context, I must disagree with you.
But OK, we are speaking about software development, not living in the ancient world of philosophy. So I took the time to read about methodology in that context as well : http://en.wikipedia.org/wiki/Software_development_methodology. Please do take a look at that article, under section “As an approach” … it says “… may also refer to an approach used to apply the software development methodology framework. Specific approaches include … 1990s … Scrum …” (!) Really. Would you reconsider? Or pick up the fight at Wikipedia?
Anyway, I loved your writing about the framework, and hope certainly to read more on your blog. Please excuse me, for being both an amateur in programming and an amateur in philosophy ;-)
Yet another positive: I will finally start reading one of the books that is on my list for years: “Discourse on the Method”, by Descartes. In fact, I will get in my car and listen to it: https://librivox.org/discourse-on-the-method-by-rene-descartes/ Now.
Cheers,
Rik
Hi Rik, thanks for the feedback. I have no plans to start fighting Wikipedia, and it doesn’t look like I have to, as you grasp my line of thinking (in why we prefer to call Scrum a ‘framework’). Enjoy your philosophical discoveries.
Gunther
One of the best works that I have read that explains the general view that people casually take by referring ‘Scrum method’ or ‘Scrum process’…
Thank you, Vishal. It is the essence of the beauty of Scrum: discovery, learning, improvement, people. Much more than seeing Scrum as a way to better ‘deliver’ IT projects.
I totally agree! Nice read! It always makes me shiver when people talk about the SCRUM Methodolgy. :-)
Nice one to read again, as it usually is :-) I’ll be sharing it
Koen, thank you for liking and sharing.