We have translated Tobias Mayer’s The People’s Scrum into German. Tobias asked us to create a spirited rather than literal translation, adding some of our own material to the book. We’re nearly done with the translation. There is one essay I added, which I’m so excited about that I translated it into English for you. It elaborates on ideas I’ve written down here.
I have changed the way I introduce Scrum to organisations quite substantially, inspired by my failures and by observation of how Kanban worked differently, in some places. This is how I do it now: entirely optional, no rules, pure invitation. Scrum based on trust. Scrum treating people as adults. Scrum as a way to descale your organisation by removing what you don’t need anymore, in very small steps.
This is a first of some more posts about the People’s Scrum book, German edition: Des Volkes Scrum.
Over and over we observe Scrum not reaping the expected benefits. Its adoption frequently gets stuck. Why is that? Mostly Scrum is being introduced in a revolutionary way: after brief preparation we assign the roles and run our first sprint by the book. In other words: we focus on getting everything right. Yet that’s not the point.
Surely Scrum only unleashes its full effect when employed “fully”. Does this need to be all at once? I choose a new car based on the sum of its features, yet I don’t feel obliged to use all extras on my first drive. On the first drive I focus on the essentials—and many of the essentials are hopefully known and familiar. If they weren’t, my ride would be highly dangerous. That’s what happens to most teams in their first sprint: they fail. Cunning coaches interpret that as an important learning experience. That doesn’t make it less demotivating.
The Kanban method changes the existing process with a more gentle approach. It’s first principle is “Start with what you do (k)now.” From this we may learn to introduce Scrum differently: Focus on what’s essential. Not the rules. The essence of Scrum is for me: deliver together and reflect together, in a regular cadence.
A few years ago the meme “Kanban is like water” has spread, putting the difference to Scrum in a nutshell. Kanban is flexible and adapts to the existing environment. Scrum is hard as ice and deforms environments it hits. How can we melt this ice? How do we do Liquid Scrum, Scrum like water?
Scrum adds one constraint to the system to better be able to see what matters: the two week cadence. (The Kanban method adds another kind of constraint: it limits work in progress. Different approach, similar intent.) All that matters in those two weeks is that we deliver.
At the end of the two weeks we look back and ask how we can do better within the next two weeks. As long as we can’t deliver every two weeks, all other interests are secondary. We uncover what keeps us from finishing and delivering our work in two weeks. To do this it helps to visualise the work and to coordinate daily with each other and current events.
Second: Focused Interests
As soon as we can deliver regularly, we want to take care of three interests: we want to deliver the right thing, we want to build it right and we want to continually improve. These interests are in conflict, which we can helpfully resolve only if we are able to deliver. Only then we can know if we’re doing the right thing—without delivery there’s no feedback; without feedback we can’t improve.
Scrum recommends to have “one voice” for two of these interests. The Product Owner speaks from the perspective of customer value: she wants to deliver the right thing. The Scrum Master speaks from the perspective of the people, the team, the “whole” and wants the whole to continually improve. Focusing the interest in one person is good, yet it doesn’t reduce our collective responsibility: we want to deliver the right thing, build it right and continually improve. As soon as one of those becomes somebody else’s problem, we rob Scrum of its soul.
Now the Scrum meetings make sense: Here we decide what to deliver next and how we want to build it. We check how far we’ve proceeded and update our plan. We focus our reflection on these capabilities and are able to pointedly improve. In the daily scrum we sharpen our awareness for the quality of our product, our path, and our team.
Only now it starts to be useful for us to fully employ Scrum. Scrum is an aspirational goal, not a toolbox we need to use according to someone’s instructions. If Scrum shall release us, we as human beings need to have the option to decide. Scrum is the more effective, the more we feel invited to make voluntary choices: for the whole and any of its parts.
Now our liquid scrum can enter the third stage: We adapt it. Scrum doesn’t contain anything needless. It’ll become less helpful if we omit something. Once we’ve made the experience what value a specific element of Scrum holds for us, and we replace it with something else that works better in our context, we want to do what fits our situation better.
The different elements of Scrum have different effects depending on the context we use them in. Therefore I suggest to completely employ Scrum bit by bit, before we then adapt it with focused experiments based on hypotheses formed from our own experience.
This way we can introduce Scrum in a philantropic and appreciative way, guided by the needs and wants of the people and the system. We avoid resistance by options to people instead of coercing them into something. We invite people to take the freedom to gain awareness, and the freedom to make choices.
That’s our idea of the People’s Scrum. One constraint… and a few sensible and established options. No coercion, no rules. Freedom to make choices. Liquid Scrum: like water!.