It is perhaps unsurprising when you consider the widespread adoption of the framework by development teams around the world that there seems to be almost as many variations of practices as there are teams working under the auspices of Scrum. Over the years since Scrum burst onto the development scene as a new way of organising to deliver complex work, a host of techniques, customs, and habits have found their way into how teams implement Scrum in the real world. Anyone who has worked with different teams in different organisations can tell you how these customs can vary and of the delight that can come with introducing to a team a practice that you saw work somewhere else.
However, amidst the myriad of associated practices something about Scrum has gotten lost. The core truths of Scrum, the underpinning theory that gives rise to core values that are to be exemplified by the team as they engage in the limited set of well-defined events that mark the cadence for delivering increments of value, don’t play as big a part in the day-to-day as the habits that have formed on top of the framework. It appears that a lot of teams have forgotten, or perhaps didn’t know in the first place, that Scrum is a defined framework and not a collection of habits that are supported by tools like Jira.
The Scrum Guide is the foundational document that outlines what exactly Scrum is, the values behind the framework, the people involved, and the events that need to take place in order for Scrum to be effective. Even as the primary source of definition for Scrum, the Guide is a lightweight document at only fourteen pages long, which is reflective of the philosophy that informs the approach; but the brevity of the document isn’t the only surprise.
The Guide is firm on what is and what isn’t Scrum, stating that the framework outlined in the guide is immutable and that any practice that does not completely implement everything described in the guide isn’t really Scrum at all. What’s interesting here is that a lot of the practices that you may see implemented as “Scrum” in the real world aren’t mentioned in the guide, though there is an acknowledgement of how these things come to be, facilitated by something of a loophole that allows for various techniques to extend Scrum without needing to be vetted or described anywhere in the core framework.
Where this takes a bit of a turn is when you look at how certain practices, for example having the Scrum Master or Product Owner never work on backlog items, contradict how the framework should operate as stipulated in the Guide, suggesting that teams that don’t ground their practices in the framework and refer back to the Guide to verify the techniques they are utilising may in fact be introducing problems rather than solving them.
The Scrum Guide is a surprising read and worth reviewing on a routine basis to help ensure that the practices being followed by a development team aren’t straying too far from the whole point of the framework: the central aim of generating value through adaptive solutions to complex problems.
Links
https://scrumguides.org/
https://en.wikipedia.org/wiki/Scrum_(software_development)
Martin Minnock 