1/ Scrum is not an acronym
The term ‘Scrum’ was first used by Hirotaka Takeuchi and Ikujiro Nonaka, 2 acknowledged management thinkers, in their ground-breaking 1986 paper “The New New Product Development Game“. They borrowed the name from the game of rugby to stress the importance of teams in complex product development. Their research showed that outstanding performance is achieved when teams are small and self-organizing units of people that are fed with objectives, not with tasks. Great teams require room to devise their own tactics to best head towards shared objectives. The well-known agile development method inherited its name ‘Scrum’ from this paper as it implements the same principles for developing and sustaining complex software products.
The Japanese authors of the paper also consider Scrum as the necessary core of any system that pretends to be Lean. But they never use the term ‘Lean’ because it has become synonymous to the Western interpretation and copy of the management practices of the Toyota Production System. And there can’t be Lean if the heart of it, ‘Scrum’ according to the authors, is overlooked. But in general this is the case, so the authors prefer to stress the need for the heart and soul of the system and take away the sole focus on the surrounding management practices. They therefore never talk of Lean, but always speak about Scrum.
As Scrum is no acronym, there is no reason to write “SCRUM”.
2/ Scrum is not a methodology
Scrum has no exhaustive and formal prescriptions on how to design and plan the behavior of all software development actors against time, let alone how these designs and plans must be documented and 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 software development methodologies typically do, Scrum removes them as a major source of delays and waste.
Methodologies are composed of stringent and mandatory sequences of processes and procedures, implementing predefined algorithms. As such, methodologies tend to replace 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. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail.
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.
3/ Is Scrum a process?
If Scrum is a process, it is certainly not a repeatable process. That’s often a challenge to explain, 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 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 process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we prefer to call Scrum 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 these base rules of the game. The prescriptions are minimal, but every single one of them addresses a common dysfunction of software development.
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.
A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (the ‘how’). 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 suitable in many situations.
Yes, it’s Scrum if the Backlogs exist and a visualization of their progress is available, accessible and clear. This may be a burndown chart with open effort. It may also be a burnup chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.
The Scrum framework leaves different options and tactics to play the game, ways that are at any time adopted to the context and circumstances. The Scrum core values give direction to the actions, the behavior and the additions to the framework.
