Scrum, actually, has been around for a while. Scrum emerged in the early 1990’s through the work of Jeff Sutherland and Ken Schwaber. They packaged their practices into a cohesive set of rules and roles and named the entirety „Scrum“. The term, actually, was inherited from the ground-breaking 1986 paper The New New Product Development Game. The reference to the game of rugby reflects the importance of team engagement.
Scrum, actually, has had a stable core since its first public presentation in 1995. The essential definition of Scrum was codified in the Scrum Guide in 2010. This definite body of knowledge describes all parts of Scrum, and the rules that tie them together. Scrum is defined as intended and designed, i.e. a cohesive set of rules and roles implementing empiricism for complex product development. The rules and roles described in the Scrum Guide gain full clarity when read as an expression of the Agile values and principles.
Scrum, actually, is intentionally kept low prescriptive. Scrum sets the frame for people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, merely guides the work. Scrum’s basic rules are immutable. Flexibility comes from the zillion variations to apply the rules, selected and tuned to context and circumstances. Hacking the basic rules of the framework breaks the cohesion, and disregards one or more principles and foundations upon which Scrum is founded.
Hacked versions and implementations of Scrum are possible. Isolated use of Scrum’s terminology or practices is possible. They might work. They might be fun. They are not Scrum.
Scaled implementations of Scrum don’t change the fundamental rules and roles of Scrum, nor the underlying principles. They only require different tactics. Instances that change the core of Scrum are not Scrum.
Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty. Scrum can wrap many development and organizational practices, tools and techniques. Scrum creates the capability of continuous adaptation in a environment of constant change, regardless whether that change is caused by our own will or by external turbulence. Scrum turns complexity from a threat into an asset.
Scrum, actually, propels agility through releasable Increments of software. A releasable Increment is available by the end of a Sprint or sooner, not later. A Sprint takes no more than 30 days, and is often shorter. Frequently an updated, improved version of software can be made available to its users and consumers. Feedback from actual use can be gathered to drive changes, improvements, enhancements. Assumptions are turned into learnings, ultimately into a pivot if required.
