Scrum Is Not a Methodology
Methodologies in the world of IT and software product delivery are detailed, stringent, and mandatory sequences of processes and procedures, implementing predefined algorithms. All the steps to be followed in, and answers to, every possible situation are carefully documented. For problem x, see p. n of the handbook. Methodologies replace creativity, autonomy, and thinking 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. Methodologies depend on high degrees of predictability for the preset algorithms to apply. Traditional methodologies are founded on the belief that product development is a simple activity that can be planned and executed with a high degree of predictability. This belief is invalidated in practice, again and again.
Scrum is based on the fact that product development is complex, highly unpredictable, and covered in many uncertainties. Although Scrum represents a methodical approach, i.e. a disciplined application of empirical process control, Scrum has no exhaustive and formal prescriptions on how to design and plan the behavior of all product delivery actors against time, let alone how these designs and plans must be documented, signed, handed over, or stored. Scrum has no rules for upfront predictions of document types and deliverables to be produced or the time of their production. Instead of installing and thriving on hand-overs, toll gates, and control meetings like IT methodologies typically do, Scrum removes them as a major source of delays and waste.
Scrum is the opposite of a big collection of interwoven mandatory cookbook instructions. 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.
Is Scrum a Process?
If Scrum is a process, it is certainly not a repeatable process (of predictable or repeatable steps). That might represent a cognitive challenge because the term 'process' typically invokes algorithmic predictable steps, repeatable actions, and enforceable top-down control; the sort of expectations for a... methodology.
Scrum is not such a commanding process. If referred to as a 'process,' then Scrum is a servant process. What works best for all involved players and their working process, emerges from the use of Scrum and the boundaries set by 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 process, structures, and ways of working that are continuously adapted to the actual context and current circumstances. Therefore we prefer to call Scrum a framework.
Scrum Is a Framework
Scrum as a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way. The Scrum Guide holds the definitive description of the rules of the game. The prescriptions are minimal, but every single one of them addresses a common product delivery challenge.
The Scrum framework leaves different options and tactics to play the game, ways that are able to be adapted, at any time, to the context and circumstances in which the team finds itself. The Scrum core values give direction to the actions and the behavior of the Scrum team, and the additions they make to the framework.
Over the nearly 20 years 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, becomes more and more focused on emphasizing 'what' is expected in developing complex products over instructing 'how' to do it. Check out the overview of revisions.