Compasses, Trees, and Pains

I have heard, read, and had nightmares starring the same old question time and again: “Am I doing Scrum or not?” Generally speaking, coaches, trainers and old-timers have a very blunt and clear answer for that: “If you are following all of the framework rules you are. If not, you are not.” Easy and blunt, to say the least. The rationale behind this idea makes a lot of sense: Scrum is a very tiny yet powerful machine that will not achieve its goal if you customize it.

Given this very simple definition, a highly mnemonic word was coined by Eric Gunnerson some years ago in order to describe flawed Scrum implementations: ScrumBut:

    •    “Yeah, we’re doing Scrum, but we have three product owners”
    •    “Of course we are practicing Scrum! But well, sprints vary from a week to three months, depending on the needs of the product owner”
    •    “Doing Scrum is great! But it’s a real shame daily meetings are taking more than an hour.”
    •    You name it…

From this perspective, there’s a crystal clear way of beginning your journey with Scrum: follow all rules since day one, without questioning them. The machine will do its work, lighting the path that lies ahead. No machine, no lights.

The leaking rainbow

Scrum is a great way of dealing with a dysfunctional organization, but there's no such thing as a non-functioning organization. When starting a Scrum implementation, companies have a certain way of working that delivers. If not, the company would have ceased to exist long ago. So how could we use Scrum without jeopardizing a business that, like it or not, somehow works? Radical changes seldom last: take a look at diets. From fat to thin to fat in, say, weeks. Maybe the ScrumBut approach is not the best one in the long run...

Instead of considering that the landscape is absolutely dark and gloomy, let's depart from a different picture: the status quo is not clear skies and mushy grass, but there's light. Think of a cloudy, rough, treeless, mountainous scenery. Depressing, yet walkable. What is Scrum then in this apparently hopeless topography? Imagine a rainbow. A beautiful, gleaming rainbow. At the end of that rainbow there's the renowned cauldron, full of gold. Nobody has ever reached the cauldron, but this is a very special rainbow. Gold coins fell while the rainbow was created. Therefore the pathway is full of coins. Gold, gold, gold. Yet the road is neither marked nor easy to walk: there are slopes to climb, narrow ridges to walk and precipices to jump over. Scrum is merely your compass. The end of the rainbow is that way. You won't ever reach the cauldron, but you know the journey is worth it because there are coins to gather on your way. Yet, it will be an arduous walk. Impediments. Lots and lots of them.

Be proud of your Scrum sprout 

Your Scrum adoption is a unique journey. If seen from a project perspective, it is undoubtedly an incredibly complex one. Therefore the approach we'll follow will mimic that of nature: organic growth. We'll basically nurture a tree. The ScrumMaster (let's just call it a Scrum coach at this stage) is the seed and retrospectives are the watering and sun. The terrain in which this Scrum tree will grow is distinct, unrepeatable. But is merely having a Scrum coach and retrospectives every one or two weeks Scrum? I'd say it is. To me, Scrum is not the same as the Scrum framework. Scrum is the tree, and there's a tree as soon as a sprout has showed up.

What will the embryonic roots, branches, leaves and trunk look like? Let's go back to the way a retrospective is ran: the ScrumMaster, acting as the facilitator of the meeting, helps the team acknowledge their most acute pains. Pain that team members have experienced for such long a time that they have now forgotten how much it hurts. Inertia is like anesthesia: the mind simply negates the discomfort.

Now the team has accepted it has problems. Moreover, they know they are in deep trouble. The symptoms have emerged. Now it's time to get to the root cause; to the actual disease. Just as medical doctor would do, the Scrum Coach will help the team, mostly by asking questions that guide an exploratory dialog, get to the actual cause behind the pain. After some rigorous root cause analysis, team members have found themselves the cause behind their suffering. Moreover, they have spoken it out, and that has changed their attitude towards the problem forever. This is the moment to change process: the team has thirst for a cure. They are ready to try out whatever the doctor suggests, especially if the proposed solution sounds like a sensible low-risk one.

Say a team has been working for months on a project. Or on six at the same time. Maybe they come from a consultancy firm. Maybe they have to work with developers from the client. Maybe the project is internal to a company. Maybe it's not. Whatever the scenario, there's pain out there. Let's say the most acute pain right now is ambiguity and contradictions in requirements. The cause seems to be that the team is acting in response to the loudest shout directed at them, whether it is from the marketing VP or from the help desk team leader. The problem is on the table and the Scrum coach proposes a slight change in the process: one of the team members will try and act from now on as the only entry point for requirements.

Let's try this out for two weeks. If it doesn't work, we can discard it. The new strategy is clear and has been embraced by everyone inside the team: If, say, the enterprise architect asks a team member to code a new interface, the guy-who-now-is-the-entry-point will politely ask the architect to briefly discuss with him the reasons behind this directive. They will try it for a week, and it will most probably work. The sprout of their Scrum team now has a tiny part of a role of the Scrum framework called Product Owner.

After two weeks the team gets together with the Scrum Coach. It worked. Things are a little bit better than before. It was not easy: stakeholders became angry sometimes at receiving a question instead of a "yes." But it worked. And now is time to reflect, to explore, to diagnose. Again. The biggest pain is now that some tasks don't get done because everybody thinks someone else has done it. Just like a volleyball team that stands to a still when the ball is shot at the very center of their side. There's a communication problem at the root.

The Scrum coach puts an idea on the table: how about getting together for 10 minutes twice a week, so that we learn what the others are doing. Sounds reasonable. And they try it. And it works. And the tree has just grown a little bit. Now a tiny branch has sprung up from the sprout: their Scrum tree now has also a meeting that resembles a little bit something called Daily Meeting in the Scrum Framework. And the tree will grow, as long as the Scrum coach waters the plant.

The tree grows as a result of the coach's facilitating a decision: what to change now, and why. The answer is simple: the pain that hurts the most. That we will call Pain-driven facilitation. Needless to say, pain is not inflicted, but rather made visible. And that is what Scrum is all about after all.

The replanting challenge

So what's with the idea of "use the whole framework or else be fated to process doomsday" that lies behind the ScrumBut accusing finger? If we step back to considering every Scrum implementation a very complex project in itself, utilizing the whole framework from day one would be like transplanting a tallish tree from the Scrum greenhouse into your very own actualities. Replanting sometimes works…and many times it just doesn't. And when it doesn't, the young tree appears to grow for sometime, but in reality it is drying up in the inside.

It is dying, slowly. And when a tree dies, only bark remains. Bark in this case is the mechanics of the framework: empty roles, boring meetings, nonsense artifacts. Until one day a strong wind blows and the tree simply falls down. The wind can be anything: from going to production now to mere death by hour-long daily meetings, Scrum is just abandoned. It didn't live up to its expectations. And for a good reason! Maybe they could have taken a more organic approach to implementing the framework…