Compasses, Trees, and Pains

6 July 2011

Alan Cyment

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…

Article Rating

Current rating: 5 (1 ratings)


Cristian Aranda, CSM, 7/7/2011 2:20:10 PM
Hi Alan, very good metaphor.
The implementing Scrum is like any new implementation. Need a sure guide (compass). It has a growth process (tree) and if not properly monitored and controlled in time tends to diverge and emerging problems (pain).
Hola Alan, muy buena la metáfora.
El implementar Scrum, es como toda nueva implementación. Necesita de un guía convencido (brújula). Tiene un proceso de crecimiento (árbol) y si no se hace el seguimiento y control debido, en el tiempo tiende a desviarse y surgen los inconvenientes (dolores).
Guilherme Lopes, CSM, 7/9/2011 10:21:38 AM
Excelente post Alan. This kind of problems may (shall) happen on every methodology adoption, whether it is Scrum or not.

We can go beyond saying there is no such thing like "ScrumBut", there is "My Company Scrum". I think there's three main rules you have to follow to adopt Scrum: Deliver products increments in cycles, have o cohesive team and some kind of continuous improvement proccess.

To the hell if I'm not doing "15 min daily meetings", I know this is a tool that solves comunication problems on most companies, but at "My Company Scrum" we found a way that better fits our team and still solves our communication problems.

What do you think, which are the main cultural changes needed to start adopting Scrum?

Bet regards,
Guilherme Lopes
Alan Cyment, CST,CSP,CSM,CSPO, 7/11/2011 9:52:46 AM
Hi Guilherme!
I agree with you, but watch out for "AcmeScrums"! Whenever I hear a phrase like "Scrum is just a bunch of tools, I will use A, B & J because that's what we need at Acme" I smell fear of challenging the status quo. There's a world of difference between empirically building a Scrum implementation and an a priori, intelectual, conservative, fear-driven customization of the framework.
Regarding culture, to begin with I don't think every organization can adopt Scrum effectively. I truly like W.Schneider's ideas on culture (oldie article - worth reading: Scrum is counter-intuitive and many times negatively disruptive in competitive, cover-your-ass, highly oppressive (oppression = monologue where there should be dialogue) cultures. But, if terrain looks fertile, I think that the main cultural change there need be is the acknowledgement that we're doing the best we can, but not the best we could. This should lead to deciding that at least someone must stop worrying about product and start taking a look at things from the process perspective, yet with a humble, questions before statements approach.
mmmm....I'll try and "bulletize" it:
- We can always do better
- We need help
- Let's not ask the "helper" for answers but rather for questions

Maybe a precondition to all this is to become intellectually humble...
What do others thinks?

Agustín Polito, CSM, 8/2/2011 3:14:39 PM
Hi Alan ! Great article. I think that Scrum it's a very recent/new methodology and this it's the main reason of why corporations use Pseudo-Scrum or ScrumBut (accidentaly). Also, Scrum propose very big changes in the behaviour of human beings at work. I mean, when you say "cover-your-ass", clearly, this is a "normal" behaviour. So, i think that when you want to apply Scrum, first you should ask yourself "I want to change my mind?"

Keep writing !

Agustin Polito
Paula Martini, CSM,CSPO, 8/13/2011 3:57:32 PM
Oi, Alan! Seu texto é maravilhoso! A perspectiva humana da gestão da equipe do projeto é fundamental. E especialmente apropriada no scrum, guiado por 2 valores: o scrum master é facilitador e a equipe é autogerenciada.
David Burland, CSM, 9/8/2011 8:57:06 PM
Hello Alan. Great article. Thanks!! I particularly like your discussion about pain-driven facilitation and the idea that pain is not inflicted but rather made visible. This is helpful for discovering and working on communication issue within any company.
Anantha Narayanan, CSP,CSPO, 9/14/2011 1:24:44 AM
Hi Alan,
Like the way you put the tree metaphor for Scrum Development. But I still feel ScrumBut is a valid term and needs to be taken cognizant of if you need a truly agile environment.
One observation, sometimes the post looked like selling a Scrum as a distant dream.
Gabriel Fabian Ledesma Montaldo, CSP,CSM,CSPO, 9/20/2011 6:28:07 AM
Querido Alan! Muy buen artículo, es una lástima que la Scrum Alliance me haya contestado que no publica artículos en Español. Aunque yo tengo conocimientos de inglés, me parece que solamente publicar artículos en inglés coarta la capacidad de expansión de este método. Yo lo estoy intentando utilizar con equipos de trabajo que NO son de tecnología, son sociologos, agrónomos, etc. No leen ni hablan inglés.
Alan Cyment, CST,CSP,CSM,CSPO, 9/28/2011 1:04:38 PM
Hola Gabriel! Sí, completamente de acuerdo con que cercena mucho la difusión de Scrum que la Scrum Alliance esté tan centrada en el inglés. En cuanto a este artículo, los amigos de Comunidad Agil lo han publicado en español:

Un gran abrazo
Alan Cyment, CST,CSP,CSM,CSPO, 9/28/2011 2:25:03 PM
Hi Anantha,

Regarding your observation, I agree with you: to me Scrum is a very useful utopia. The kaizen motto of "perfection exists, I will never reach it and yet I will try to get nearer to perfection every day" is to me the engine that makes Scrum tick.
Aniruddha Ray, CSM, 10/2/2011 1:48:46 AM
There are clearly 2 views of Scrum implementation among experts. the puritan view that strongly urges implementors NOT to modify Scrum (unless you know why and how this can impact the complete methodology). I believe Ken Schwaber strongly endorses this view and I understand his POV. Scrum as a framwork is a very simple and loosely coupled set of rules but these have strong underpinnin gs based on behavioral sciences, management principles and human psychology. Often the change-agents make changes too superficially without appreciating that a change in one principle can have a whiplash effect on other (seemingly independant) principles and that's when Scrum fails like a pack of cards without we knowing why.

The other view off course if that Intelligent, Coherent changes can and might be done based on "real" needs. I have seen this happen and my view always (as an agile professional) has been to play the role of the inquisitor, challenging the teams to explain the premise/rationale and delve deep to explain the potential long term and critical impacts on other principles that can emerge as a result of the changes. IF the teams have really thought through the change and it's linkages and have readied themselves for these risks, the changes can be meangingful and efficient.
In my experience, most changes done in Scrum can be avoided with some team dynamics and working from first principles. However saying that is simple....doing that (always) may be impossible!!

You must Login or Signup to comment.