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.
Scrum has its roots in the world of software development. In that world, ‘methodologies’ are by design composed of stringent and mandatory sequences of steps, processes and procedures, implementing predefined algorithms and executors for each step, process or procedure. 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.
