*Blog post originally posted on Scrum.Org
It’s interesting how we sometimes accept some rules without questioning them at all, and how some other times we try to bend them to suit our needs. While it is our choice to do so, we often know what the consequences of our choices are. It might not be that obvious with Scrum rules. In this article, I’ll talk about why that is and what are the actual consequences of not following the rules.
Every time I start working with a new organization as a coach or a new team as a Scrum Master, I hear all the same things.
From an organizational point of view, it usually is something along the lines of “we do agile in our own way because the pure way would not work in our situation”.
From the team point of view, I often hear something like “Scrum processes are too much overhead for us, we adapted them, so we don’t do retrospectives and we don’t have a dedicated Product Owner”.
All of these sounds a lot like Scrum-buts.
Obviously, what it means is that some rules in the Scrum framework were hard to follow, so they decided not to follow them. I would say it’s all fine, as long as there is a clear understanding of what it means. So let’s get on the same page about that.
The meaning of rules
I believe we learn the best from metaphors and examples, that’s why I’ll give you one.
Let’s imagine a hypothetical situation: you have a health concern, for example, chronic pain. You work with your doctor to figure out how to make things better and he comes up with a good action plan. He tells you that you need to follow a strict diet and do a certain set of exercises every morning and evening. If you do it, your pain will subside.
You go home and start following the plan. But after a couple of days, you start noticing some problems with this plan.
Firstly, you need to wake up 30 minutes earlier to do the exercises, and you’re not used to it. It’s pretty hard to keep the schedule.
Secondly, the diet is a bit too strict. After all, you had a cupcake every breakfast for years, you need your sugar!
So you start to make changes to the action plan (or rules, in other terms). You start skipping your morning exercises – you prefer to have the extra 30 minutes of sleep. Then you add foods into your diet that your doctor strictly told you to avoid.
After a month, you’re back to doing your usual routine and already forgot about the action plan altogether.
You see, the problem is that your chronic pain not only didn’t go away, but it also got worse. Because you were not following the rules prescribed by your doctor, you were not able to solve the problem you set out to solve. That is obvious.
Who to blame?
The question here is: who’s fault is it that your chronic pain persists?
We have three candidates: the doctor, the rules he prescribed or… you not following the rules.
And the winner is you.
It would be preposterous to assume that it’s the doctor’s fault since he did his best to prove you with a valid solution and relied on your honesty and dedication to implement it. The doctor would be to blame if you followed the action plan diligently and it would have worsened your chronic pain. But it wasn’t the case.
It would be silly to blame the rules themselves – they are just words written on paper. Rules themselves have no impact on the outcome, only what you yourself do with the rules.
That’s why the logical conclusion in this very realistic metaphor is that the persistence of the chronic pain is on you. You haven’t followed the rules with the needed diligence for long enough to see the outcome.
What about Scrum?
I know you’re asking yourself: “what does this whole story have to do with Scrum rules?”
Well, let’s look at the situation of implementing Scrum in your team and in your organization.
The problem that an organization employing Scrum is trying to solve is the complex environment they are in (or at least that SHOULD be the primary reason). An organization wants to become agile so that it can rapidly and deliberately respond to changing demand while controlling risk. It wants to satisfy customer needs and stay competitive in the marketplace.
That’s the chronic pain it tries to heal.
Scrum provides a certain set of rules that need to be followed in order to get this desired outcome.
So when we bend the rules, when we choose not to follow them, when we decide to adapt them to how we used to do things for years, who is there to blame?
The suspects are all the same: your Scrum Master or Agile Coach (the doctor), Scrum (the rules prescribed) or…?
In the example I gave you, it was obvious that the main problem was the patient not following the rules.
Somehow, when it comes to Scrum implementations, the blame often falls on Scrum itself (“the process is too rigid and it doesn’t work for us”) or on the Scrum Masters (“they make us follow rules we don’t like”).
The results
Scrum rules are no different from any other rules that are created to help you achieve the desired outcomes. In case of agile ways of working, the outcomes we expect might include higher customer satisfaction, motivated and engaged employees, lower business risks, frequent delivery, and more.
To get there, you have to follow the rules. If you change them, adapt or bend them, the primary consequence of it is that you will NOT get the outcome you were looking for. You will most likely get the opposite, actually.
It’s easy to stop exercising in the morning or start eating foods our doctor disapproved of. But the chronic pain might get worse.
The same goes for Scrum. It’s easy to stop doing Retrospectives, extend the Daily Scrum to include all managers, take away the decision power from the Product Owner, make your Scrum Masters do Delivery Manager jobs, and so on. But the organizational pains you had before might get worse.
Every single rule in Scrum was carefully designed for a reason.
Roles, events, artifacts, Definition of Done, Sprint Goals, monitoring progress, self-organization, cross-functionality and even terminology are paramount in getting you to the desired outcomes.
Adapting the rules the right way
Of course, one of the agile principles is continuous improvement, and Scrum is fully equipped to allow you to inspect and adapt in the future.
However, before you can really do effectively to achieve the same outcome, you need to do it the straightforward way FIRST. Meaning, follow the rules properly and diligently until it becomes natural and easy; until you get the outcomes you were looking for. At this point you will know why things are working a certain way, why rules are there in the first place – you’ve reached a higher level of agile maturity.
Now you can start adapting the rules to make them more flexible. Because if you adapt a rule at this point, you’d be able to see the consequence of it almost immediately. You will know if the adaptation is making things worse or better. And in the worst-case scenario, you can always go back to the previous rule before making a new adaptation.
The main point of this article was to show that when we make a decision to not follow certain rules, we need to understand the consequences of that decision. We also need to understand that the rules are not responsible for the outcome you’re seeking, it’s your diligence in following those rules.
As always, I would definitely start with understanding transparency and what is needed from you. Because if you choose to change the rules, you will need to be very transparent about it.
When you choose to bend the rules, remember to ask yourself what the consequences of that choice are.