Liberty vs Control — Why Scrum Teams And Managers Collide

And how to fix this anti-pattern

Scrum is intended to bring people together to create value. Instead, the introduction of Scrum often creates a wedge. Teams use Scrum as a shield to avoid responsibilities. Managers look for the wrong things to measure the performance of a team.

Many will recognize these behaviours. They are toxic to a Scrum environment. In this article, I will address the anti-patterns and discuss how to fix misconceptions. This will create a collaborative environment to maximize the creation of valuable products.

Scrum anti-pattern 1 — Scrum Teams dodge responsibility

Scrum Teams love Scrum because of the following:

“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.?They are also self-managing, meaning they internally decide who does what, when, and how.” —?Scrum Guide 2020

Many see it as liberation. Scrum removes the chains they felt in the way they were top-down managed before.

The following adds fuel to the fire:“In complex environments, what will happen is unknown.” —?Scrum Guide 2020

Too many Scrum Teams draw the following conclusions from these two statements of the Scrum Guide:

We determine what we do. And we determine how we do it. Management should not interfere. Also, we can’t look beyond a Sprint. So we don't have to plan beyond the Sprint. We don’t even have to commit to our work in a Sprint.

Often teams use the argument of complexity to say they can’t predict anything. They can’t?look further than two weeks?(or whatever the Sprint length is). They build an Increment and learn from that to understand what to do next.?They learn along the way.?Sprint after Sprint they only uncover what to do next at the next Sprint Planning.

This behaviour shows a misunderstanding of what Scrum is. Before I address it, I will first discuss management misconceptions.

Scrum anti-pattern 2— Managing the wrong things

Many managers struggle with Scrum. On the one hand, they are not part of the decision-making. This is with the Scrum Team. On the other hand, they are answerable for the effectiveness of their department. So they try to find ways to uncover how the team is doing. Their traditional thinking line is towards progress and output. They were used to plan work spanning a longer time to understand how teams did. During a project, they managed scope, time and budget.

With Scrum, these options appear to be gone. But the managers still want to cling to something. So they look for ways to measure?productivity:

• They measure velocity and growth of velocity over time.
• They measure predictability: did the team deliver the items as planned?
• They measure the number of items delivered.

They seek certainty in these numbers to justify the work the teams do. But measuring productivity and output is also a misunderstanding of Scrum.

The impact of mutual misunderstandings

When teams believe they are autonomous and not bound to commitments and managers believe they need to measure the teams’ productivity, they are on a collision course. Teams believe managers want to micromanage them. Managers believe teams want to dodge responsibilities. The thing is, they are both right. But they are also both wrong.

The Scrum Teams are right that they are self-managing. They determine what they do when they do it and also how they do it. They are also correct in stating Scrum works for complex environments and that “what will happen is unknown.”

But in Scrum, you wish to create value by achieving?goals.?Scrum Teams commit to reaching the Product Goal. They create Increments as a stepping stone toward the Product Goal. At the Sprint level, Scrum Teams commit to reaching the Sprint Goal.

Scrum’s way to resolve these issues

Product Goals and Sprint Goals are about the?outcome, about the creation of value.?Scrum Teams should be able to monitor their progress toward meeting these goals. This is a far cry from the misconception that Scrum Teams don’t look beyond a Sprint.

It’s here where the Scrum Team and the manager have a common interest.?When the Scrum Team informs the manager about the progress towards their Goals, this fits the needs of the manager.?As long as the manager understands that Scrum is about the outcome, not about output.

Managers don’t need to actively look for performance information anymore. They get everything they need from the self-managing Scrum Team.

Scrum Teams need to aim for transparency.?This means that the?progress towards the goals is kept up to date as much as possible.?The manager only has to look at the Product Backlog and Sprint Backlog and attend the Sprint Review to know how the team is doing.

Scrum is all about taking responsibilities

Scrum is not an excuse to escape responsibilities. It is an approach to delivering value in complex environments. It requires a commitment to reach your goals and transparency of the progress towards the goals.

Scrum Teams need to set a Product Goal. Then they need to determine how to measure progress towards the Product Goal. Whenever Scrum Teams create an Increment, they create an opportunity to inspect progress towards the goal. The most logical place for Scrum Teams to have this inspection moment is at the Sprint Review. Together with their stakeholders, they inspect the Increment and other factors that may impact the Product Goal. At the?Sprint Review, Scrum Teams also show their progress toward the Product Goal.?This is why it is vital to have good measurements in place.

At the end of the Sprint Review, the Scrum Team can reorder the Product Backlog with the new insights they gained.

You can compare it with how Google Maps works. Suppose you wish to travel from Paris to Nice in the summer and there’s heavy traffic. Your goal is to reach Nice.?Google Maps will outline a route to follow and a projected time of arrival. But it will constantly inspect if the route is still the fastest option. When there’s a better alternative, it will suggest you switch to that route and update the projected arrival time. The goal, of reaching Nice, is still the same. In the end, this is what matters.?It is not about sticking to the initial plan, ending in a traffic jam.

Closing thoughts

Scrum Teams and managers often make each other's life miserable.?In many cases, this is due to a misconception of Scrum.

Scrum is not about productivity. Scrum is not about output. Scrum is not an excuse to avoid thinking long-term. Scrum is a framework to create value in a complex environment. Scrum Teams do this by creating a goal and taking steps towards the goal, inspecting and adapting.

Commitment and transparency are used all over the place in the Scrum Guide. They aren’t hollow words. On the contrary, they highlight the importance of relentlessly working towards the goal.