Liquid Scrum


Des Volkes Scrum

Des Volkes Scrum

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.

People's Scrum

People’s Scrum

Liquid 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?

First: Deliver!

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.

Shared Responsibility

Shared Responsibility

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.

De-Scaling: Increase Trust, Invite People to Make Choices, Reduce Org Structure

De-Scaling: Increase Trust, Invite People to Make Choices, Reduce Org Structure

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!.


  1. Matthew Heusser
    August 23, 2014

    Hello Olaf – nice post. Very similar to some of the things I have been thinking about. I like it.

    One question though – why make the timebox always two weeks? Initial Scrum sprints were 90 days, IIRC because the problem they were solving was requirements churn/whiplash. Of course, if you tell the team they have 90 day timeboxes (instead of 180 or whatever the old school team was doing before) there won’t be much improvement there.

    So here’s an idea I got from Ron Jeffries that I’d like to write up at some point: Start with a one or two day timebox to /ship working software/. The team will fail. That’s okay. Try again. Fail. Try again. Fail.

    By the /second week/ they’ll figure out how to add a column to a report or something. this teaches how to slice stories, assess ‘size’/impact, how to scale the test process to the risk (instead of ‘full’ regress test) and how to deploy quickly. all of which are things teams need.

    Once they can actually get anything done, extend the timebox to two weeks. At that point, though, you might not need the 90 days – but I might use the 90 days for a release train for multiple teams.

    Just a couplea thoughts. Great post.

  2. Trust Artist Mystery, Magic, or Science? - Trust Artist
    August 31, 2014

    […] Being present with my clients makes the difference. It doesn’t matter at all if I use Scrum or Kanban, the difference between these methods is very small if it’s me using them. It’s me […]

  3. I Have Compassion For Managers - Adventures with Agile
    April 4, 2017

    […] spirited rather than literal translation, adding some of our own material to the book. I published one of those new essays a few years ago. There is one more essay I added, which is so dear to my heart that I translated […]


Leave a Reply