Why is it so difficult to run Scrum successfully?

Scrum has been out in the wild for many years. Its popularity seems to be ever on the rise; The list of companies using Scrum or some flavor of it is longer than ever. Yet another thing that is ever on the rise is the ranks of people who report having bad or even catastrophic experiences working with Scrum. What should we make of the discrepancy between this popularity and infamy?

One possible explanation is that Scrum is indeed just a bad framework with good public relations that developers don’t choose but get forced to use. I imagine that this may reflect the experience of some of you. It isn’t my goal to directly refute this view but I do hope that my tackling of the topic will create a new context for your past experience.

It was never a secret that Scrum isn’t easy

Right at the top of the Scrum Guide it reads:

Scrum is:

Lightweight

Simple to understand

Difficult to master

- The Scrum Guide™ 2017

In this article I want to show why “difficult to master” is baked into the framework and no matter how many years of Scrum in the wild we have the difficulties are here to stay. With understanding of the difficulties we will see why some teams performing the rituals of Scrum see generous rains of productivity as a reward yet others see nothing but drought. With this increased understanding I hope you too will be on your way to blessing rains.

It’s the pillars, stupid!

The difficult part about Scrum isn’t running the ceremonies, understanding the roles or converting backlog items to product increments. These belong to the “simple to understand” part; join a Scrum team for a few sprints and you’ll get it. Even outside the context of Scrum you’ve probably practiced sprints, dailies and retros. Chances are you already know most of what there is to know to make the right sounds and movements to do the Scrum rain dance. Whether it will rain or not is a matter that relies on aspects we will see shortly.

The Scrum guide, right before diving into defining the “meat” of the framework, contains a seemingly dry and technical paragraph. At first glance it seems as interesting and relevant as the error specifications chart of your TV manual, but it’s actually at the core of what instills power into Scrum, yet is also what makes it a difficult to master framework:

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

- The Scrum Guide™ 2017

To understand what these pillars mean let’s use a driving analogy. When you’re driving you constantly take in information (inspect) and make choices according to it, such as adjusting speed, changing lanes, shifting gears (adapt). The transparency part is how much of the relevant information is accessible to you. If your rear-view mirror is busted you’ve got a transparency issue. Transparency isn’t limited to information within the confines of the team/organization; you’ve got a plethora of external factors that affect your product as well. To use the driving analogy, an intersection that blocks the view of oncoming cars is a transparency issue as well.

These pillars are at the heart of Scrum. Every Scrum event and artifact is intended as an opportunity to exercise this cycle of inspecting and adapting. It is setting these pillars up and maintaining them in good order that is THE monumental challenge of implementing Scrum in an organization, and that’s a challenge you must continuously face.

Le’ts examine the pillars to see where the challenges lie and what can be done to overcome them.

Mastering Transparency

It’s not by chance that transparency is the first pillar: If transparency is broken there will be no hope for empiricism of any kind. How can you inspect anything if the information you have is wrong or partial to begin with? What will you adapt to if you were unable to inspect? If you were driving in a car with blacked out windows, how would you know where you should be heading?

So how do we achieve transparency? You could appeal to everybody’s sense of altruism in the team and explain the importance of transparency. That’s actually not a bad start and well worth doing. But if only matters were so simple. If the only thing you rely on is people’s good will you will discover that once their self interest conflicts with transparency, transparency will lose more often than not. Therefore let’s explore some organizational level techniques that can help make transparency an inherent part of the office culture.

#1 - Align the interests of the product with the interests of the people working on the product

It is a time-honored tradition for companies to measure performance on an individual level and dish out sticks and carrots accordingly. On the surface it makes sense; John’s performance is better than David’s. Shouldn’t John be rewarded and David reprimanded? Maybe we can replace David with another John. The problem with this approach is that you are creating a competitive dynamic between David and John, where they are incentivized to take actions that improve their perceived position in the race, rather than actions that improves the product.

Whatever metric you use to measure people’s performance will cause them to adjust their behavior to optimize their standing. If these metrics don’t align with the product’s best interest you will see behavioral adjustments that conflicts with the best interest of the product. Instead of supporting each other and having each other’s back, you’ll see people hiding failures, vying over credit and knowledge hoarding to position themselves as indispensable silos. Just a sample of the nontransparent behaviors that occur due to incentives that aren’t aligned with that of the product.

In order to combat this you need to strengthen the sense of “we all win or lose together” and work on removing as many impediments to this as you can.

Let’s try to define this idea in similar way to how the Agile Manifesto is worded:

Performance of the product over performance of individuals or teams

- Roy Klein, 2020

That is, while there is value on the item on the right, we value the item on the left more.

Measuring team output in terms of velocity, story points or bug counts can also lead to optimization behaviors that will harm transparency and cooperation. Wherever the best strategy for success in the environment is to optimize a metric, the information flow will warp around the metric.

#2 —Ask stupid questions

People may be willing to be transparent and may have important information that they can share but they simply don’t speak up. Why does this happen?

To understand how this works try to think to the last time you heard a fire alarm go off. In my office when the fire alarm goes off (fortunately so far it has only been for drilling purposes) the first thing people do is look at each other as if asking “is it ok for me to act on this?”. It is only when someone stands up and obviously starts towards the nearest fire exist that people are roused to action.

People are drawn to conformity by their nature. We want to behave as closely to those around us because standing out too much can have dire consequences (being an outcast meant almost certain death throughout most of human history). This trend towards conformity can easily create a culture of silence where issues are being suppressed and nobody dares to be the harbinger of bad news.

In such an environment someone needs to break the ice and be nonconformist. Someone needs to speak up, state the good things and the bad, and most importantly, ask “stupid questions”. You know those instances when something seems unclear only to you, as everyone else just nods in agreement? Most of the time it is only in the service of conformity that people appear to not ask the obvious. If you want them to open up you need to take the risk, blaze the trail and ask the stupid question. Create a new conformity where speaking up is the norm rather than the exception.

Mastering Inspection and Adaptation

If inspection is checking the speedometer and comparing it to the speed limit, adaptation is choosing which (if any) pedal to press — gas or brake, to maintain optimal speed. Sounds simple enough. Well, that depends. Have you ever had the experience of driving on a certain road for a while, only one day to discover that the speed limit was surprisingly reduced? It’s quite hard to stick to 90 Km/h when you’re used to 120 Km/h on the same stretch.

Change is uncomfortable. It’s uncomfortable when you’re used to specific ways of doing things and it’s uncomfortable when you had a plan in your head of doing something and turns out that you need to do something different. Again, this is a very human experience. We are coded to want to remain in our comfort zone. We are built to continuously plan ahead and we find it difficult to adapt to sudden unexpected demands.

But that is exactly Scrum asks us to do.

Here’s a story exemplifying how the comfort zone makes it difficult to adapt:

David the front-end developer was looking forward to the work day. He knew that in the to-do column waits a task of one of his favorite kinds: Visual changes. David is very visual and he’ll take CSS over JS any day. And today is such a day; he picks up the task and starts working merrily.

In the Daily (aka stand-up), another developer who’s working on a sprint goal related task complained that she is having difficulties with implementing tests and she might not finish the task on time.

David’s task isn’t sprint goal related but he hates writing tests. He is already in the zone hacking at the CSS and he figures that he’s no good at tests anyway and that it’s better if someone else helps out.

David remains silent and gets back to his task when the Daily is over. Nobody offers to help with the tests.

This is an example of the uphill struggle we all face when an opportunity to adapt presents itself but we find that we’d much rather maintain course. The mind is very quick to come up with reasons for why we should stick with what we know and want. When people don’t find the inner resources to upset the balance every once in a while adaptation tends to be insignificant and insufficient.

#3 —Accept only concrete changes

The Retrospective is perceived by most as THE Scrum event that enables inspection and adaptation. As we will later see it is far from being the only opportunity to inspect and adapt but it can be the easiest starting place to affect change if inspection and adaptation are absent in your organization.

First of all, and this should go without saying, hold a retrospective every sprint, at regular intervals. There is absolutely no excuse for skipping this crucial event. Second, make sure that each retrospective is concluded with at least one concrete change to the process, communication, tools or way of working. Concrete change means a change that is defined in such a way that it is trivial to inspect it for its impact. “Write more tests” is a fuzzy definition that’s difficult to inspect, as writing one more test meets the criteria, and writing a more million tests meets it as well. Maybe one extra test did not solve the original problem we had, and a million tests solved it, but created a different problem. So what was the impact of “write more tests”? Did it solve our problem or did it not? Since this is not a concrete change it is impossible to inspect.

Here’s a concrete alternative: “Builds fail if test coverage drops below 60 percent” . There is a clear criterion that can be implemented and inspected for its impact. That this is a concrete change doesn’t necessarily make it a positive change, but it is inspectable and once we try it out we can tell whether it was positive or not.

Any change that emerges from the retrospective needs to be clearly defined so you can inspect to see if it brought the intended benefit and adapt it in case it can be improved or if it didn’t achieve its purpose. You’ll never find out if “write more tests” needs to be adapted because you could always say “the problem wasn’t solved because we still didn’t write enough tests”.

#4 — Use the dailies for adaptation

The retrospective is definitely not the only opportunity to adapt. Get your team used to making changes, even small ones, on a regular basis during the dailies. If your dailies start and end with the 3 questions (“what did I do, what am I doing ,what am I going to do”) you may be performing inspection but you’re missing out on adaptation. I like to ask my team after we go over the current plan, “are we doing the best we can today to achieve the sprint goal?”. You might also push them a bit further with something like “What could we change about our daily plan to make our day more effective?”. The daily should end with everyone feeling that we are indeed doing the best we can today to achieve the sprint goal and tackle the Sprint backlog, according to our knowledge.

Final words

Scrum without the pillars is a neutered beast that adds little beyond overhead to the development process. Most of us at some phase of our career experience Scrum where we go through the motions and rituals and know that it’s pretty much a waste of time. This happens when transparency, inspection and adaptation are absent. Unfortunately performing the rituals is not sufficient to ensure that transparency, inspection and adaptation emerge.

If your organization suffers from the “Scrum by name only” syndrome where Scrum is nothing but overhead, the fix is not to replace Scrum. No matter what framework or way of working you choose you will get stuck in the same rut. The solution is to understand the behaviors, dynamics and structures in place that operate against transparency, inspection and adaptation and start creating an office culture that supports them rather than suppresses them. I covered a few simple yet powerful techniques to get you started but the most important thing you can do, whether you’re a Product Owner, Scrum Master or development team member is to lead by example in your own organization.

Once you understand how every Scrum event and artifact is there to serve as an opportunity of inspection and adaptation, and you understand how to bring about conditions that cultivate transparency, you’ll be well on your way to unlock the incredible potential of Scrum.

Do you want to write for Serious Scrum or seriously discuss Scrum?