A deeper understanding on the…
Definition of Scrum
Road to PSM III — Episode 1
[revised for 2020 Scrum Guide update]
This road will be a bit tedious to some and is thus directed at those of you who take Scrum seriously and are willing to follow Alice and me down the rabbit hole into Scrum.org’s PSM wonderland.
Understanding Scrum means mastering the basics. Before we can even begin to develop a deeper understanding, we must revisit the basics.
PSM III doesn’t imply you have reached Ri level. Ironically, when I reached PSM III I began to understand how I wasn’t mastering Scrum at all. You simply begin to know there is a lot you still don’t know. Follow me?
But if you want to pass you must be able to answer questions that challenge your understanding of Scrum in practical context. Alistair Cockburn, in his talk on the Heart of Agile, revisited the Core of Scrum.
The Core of Scrum
Alistair describes the core of Scrum in only five sentences, starting with three pillars:
- Demo or deliver every Sprint
- The team decides (The team self-organizes; management butts out)
- Inspect and adapt every day
and two good ideas that enable the team to improve its focus:
- Chief Impediment Remover: Scrum Master
- Value Maximiser (we do what now?!): Product Owner
In essence, what Scrum truly made popular was Incremental Development.
“Anything else…”, Alistair continues, “is an add-on!” …An attempt to make Scrum understandable for Shu level people.
The Scrum Guide is very precise in its wording, but not really great at explaining why the guide says what it says. It is somewhat mystifying, and only by exercising it, does one begin to grasp what the Scrum Guide is trying to convey.
A Framework!
“Various processes, techniques and methods can be employed within the framework.” — SG
At first, I didn’t really put a meaning to the term framework; I found the term to be abstract. Framework, Methodology, Process…so what?!
Yet to truly grasp the essence of Scrum, you must be able to understand why this wording was selected for its single-sentence definition:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” — Scrum Guide
The best way I managed to explain it to myself is that a framework holds a canvas.
This canvas allows your team to create a world of their own.
The canvas leaves room to creatively and productively determine how and what you’d create. The framework is also considered lightweight. This implies that as much has been left out as possible, whilst retaining a lean but steady structure. Removing anything else will destabilize the whole. The canvas (not the framework) provides room for creativity.
So go ahead and find better ways of working by applying the framework.
It’s your wonderland! make it wonderful!
Hence the Guide states that everything that is part of the framework serves a specific purpose and is essential to Scrum’s success and usage. Although this may sound dogmatic, it is the framework in its entirety that enables freedom on the canvas!
Without a framework, the team's organization will be erratic and unstable, noticeable by constant conflict and unexpected disruptive events. Do you recognize this? perhaps it’s time to apply the framework professionally.
The guide is there to help organizations establish the framework so teams won’t get lost.
Not a process?
Scrum is founded on empirical process control theory. Scrum prescribes iterative development through Sprints and a cadence of events, which can be considered the Scrum process. This routine enables interactions between individuals so that they can self-manage their processes and tools. Consistency reduces complexity. So, in a way Scrum establishes an empirical process.
Scrum is a process framework. A process is a systemized way to take steps towards a particular end. In Scrum, the team is free to determine how it will create and apply this system. Kanban is often applied by teams to visualize and manage its process in the Sprint Backlog. Kanban is also not a process, but a strategy for optimizing the flow of value through a process. How teams design their flow that processes value and the rules they establish for that flow, can be considered a self-managed process in Scrum.
Not a methodology?
Many will argue that Scrum or Kanban could also be considered methodologies. They are not definitive methodologies, but a meta-methodology if you will. Many patterns can be applied within Scrum.
In complex environments there are no best patterns, only emerging patterns. The complex domain represents the “unknown unknowns”. Cause and effect can only be deduced in retrospect. That is why empiricism is at the core of Scrum and Agile. That is why the first five words of the Agile Manifesto the most important, yet often overlooked.
“We are uncovering better ways”- the Agile Manifesto.
How about a Game?
If anything other than a framework scrum is a game; or at least is says so on the cover of the Scrum Guide.
The Scrum Guide also reads its rules are meant to guide interactions between individuals, not enforce them.
Scrum does not enforce Scrum!
“Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” — The Scrum Guide
Scrum is a game that is practiced in many different ways. But a game has rules and requires a shared understanding of them; otherwise, there will be conflict.
You play the game for what it amounts to. As in sports, you can distinguish amateurs from professionals. That is why Scrum.org clearly distinguishes professional Scrum from mechanical Scrum.
In “mechanical” Scrum, we find teams following the procedural rules of Scrum, such as its cadence of events, its timeboxes, and its use of the artifacts, without having a shared understanding of its purpose. In mechanical Scrum, there is a lack of awareness, understanding, and commitment to empiricism, self-management, and the Scrum Values, which we do observe in “professional” Scrum. Mechanical Scrum Teams are output driven. They deliver but don’t really learn from its delivery. Whereas professional Scrum Teams are centered around quality and the pillars of transparency, inspection, and adaptation, achieving valuable outcomes and happiness.
Rather than stressing and enforcing the mechanics of Scrum, focus on the professional spirit of the game.
“Stop worrying about polishing it up so it is perfect, because it never will be. Anyway, there are far too many complex, chaotic situations in our world that you are skilled to help others address. We do not need to waste our time staring at our belly-buttons.” — Ken Schwaber
The less you argue the rules, the more you can focus on playing the game, which is to create value.
The Mirror
“Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.”
Scrum is not a framework that needs enhancing. Scrum is Scrum, not what your organization wants to make of it. Sadly, too many organizations change Scrum yet still maintain the facade that they are practicing Scrum, because there is value in saying you Scrum, even when you don’t.
“All this stuff about empiricism, self-management, and cross-functionality is just not realistic. This is not what we have in mind with Scrum.” A director told me in one of my first jobs as a Scrum Master.
Those who say that change is not necessary, or that it is too hard, are invested in things staying the same.
It’s not Scrum that needs to change, but the organization. Changing Scrum covers up problems and obscures the need for change. If problems are made visible through Scrum’s mirror, companies will prefer to remove, break or change the mirror rather than put in the work to change itself.
For example (and boy, do I have many to pick from), teams will try to explain that a Sprint can’t yet start, or isn’t ready yet, so instead, they meddle with the Sprint cadence. Teams will break time boxes because they simply haven’t yet figured out how to spend their time effectively. They’ll break items up into waterfall steps and spread them out across Sprints. They will switcharoo roles, or simply skip an event when something “urgent” comes up. They won’t have goals, because their work is too “diffused”. They’ll treat forecasts and estimates as deadlines. They won’t let teams self-manage because “they are too immature”… someone, please stop me.
It is our job as Scrum Masters to create that mirror and to prevent your colleagues from breaking/obscuring it. Obscurity is the nemesis of Transparency.
Scrum explains that it should be clear what the impact is on the delivered increments and what value is lost while the violation persists. Explain how these are impeding the team from solving complex problems. This is deficit. This must hurt. If this doesn’t hurt, it won’t be treated. So say no to patches, hack-fixes, and temporary painkillers.
For example, a team that chooses to abandon a Sprint Review or Retrospective will lose a VITAL opportunity to inspect and adapt. The event is considered to be in the way, rather than a means to find a better way. The organization thus demonstrates it is okay to meddle with the framework, and thus creates a pretext for others to do likewise.
Accept a companies obscurity and you’ll end up settling inside their magical wonderland, pretending all the crazy stuff is normal.
Ethics
Ethics are moral principles guiding the rules of conduct. Scrum Team members must have the courage to do the right thing and hold each other accountable as professionals.
There are ways team members and stakeholders can act unethically in context of Scrum. One of those things is intentionally doing Scrum wrong, or changing its definitions to mean something else to cover up problems.
There are other examples such as deliberately withholding information from the rest of the team. For example, if a developer intentionally withholds knowledge (such as defects) about the product being developed. Developers can deliberately obscure work, to give a false illusion of progress or productivity. It is also unethical to provide false data obscuring the actual value and quality of the product during a Sprint Review. They can also be false about one’s capabilities to cover up a lack of proficiency.
Unethical behavior can cause harm, for example, by deliberately releasing potentially harmful or substandard quality to deliver faster. Stakejholder can also push developers into unethical behavior, such as encouraging them to build software that collects private info from users without their consent or other courses of action that breach law and regulations.
I’ve used this introduction to lay the groundwork for what I will cover in the next episodes: Empiricism. In essence, Scrum is about uncovering the painful truths. So ask yourself: What are you and your team avoiding?
