Managers Can Make Or Break Your Scrum Teams - Their Influence Is Essential

Scrum anti-patterns and how management can help to remove them

A while ago, I wrote an article discussing the 10 most misunderstood or missed parts of the Scrum Guide. On the surface, you would think these have nothing to do with the manager of these teams. But I will show that this is untrue. The influence of management is enormous.

From my experience, they have the highest impact on the effectiveness of the Scrum Team. Despite the fact, that they aren’t part of the team. Does this sound far-fetched? Let’s go through them one by one!

Scrum doesn’t exist to deliver features

Scrum is not about delivering something new every Sprint. It is to ensure the team is maximising value through discovery. Many teams still use Scrum as a delivery framework. Almost always, this is because of the wrong incentives.

These wrong incentives mostly come from management. They expect teams to “deliver what they promised”. One way how this materialises is how the teams are measured. Here are two examples:

• Velocity (how much work can a team complete per Sprint) is considered to be a productivity metric. Ideally — according to these managers — velocity grows over time.
• Predictability (what part of what a team planned are they actually delivering) is another metric. Changes to the planning are considered to be a bad thing.

Other examples of unwanted management behaviour are:

• Expecting the team to do whatever they can to finish the backlog items.
• Only focusing their narrative on the planning, building and demoing of the features. Not on the feedback loop of actual value.

This is also related to the following misunderstandings I discussed last week:

• Scrum is not about chopping work up into smaller items
• Scrum events don’t serve to plan the output of the team
• The items on the Sprint Backlog aren’t the team’s commitment

How to help fix it

For starters, managers should not focus their narrative on output. They should emphasize the outcome instead. This means discussing with the team what they plan to achieve with their product and how they are processing towards this.

An example of the output is the number of safety measures in a car (seatbelts, airbags, cameras, brake assistants, etc). The outcome here could be reducing the number of casualties in traffic. In the end, it is not about the safety measures. What really matters, is reducing casualties, the outcome.

Having the narrative on outcome switches the focus to what is really important, especially in a complex environment. Because complexity brings with it that you don’t know what will happen. But you DO know what you wish to achieve. So it makes all the sense to talk about that instead.

The Scrum Values aren’t non-essential

Trust is a prerequisite for transparency. Transparency enables inspection and adaptation. The Scrum Values (courage, commitment, focus, openness, respect) help to establish this trust. But trust isn’t something a team can have in isolation.

Yes, the team can live the Scrum Values. But if the environment doesn’t support the team in this, they will not succeed with Scrum. Their stakeholders should uphold the Scrum Values too.

Managers often play a deciding role in the downfall of Scrum Values. When they don’t accept failure, they make it difficult to show courage or openness. When they request the team to switch priorities all the time, they impact focus. When they are unclear or contradictory in what they expect from the team, commitment takes a hit. When they don’t respect the team’s decisions, they can’t expect to get respect themselves.

How to help fix it

Managers should lead the way. They should live the Scrum Values too. When they show respect, are open and courageous, committed and focused, they show the team these values aren’t just lip service. And this helps to build trust.

As someone higher in ‘rank’, she or he has an undeniable position of power. Whether the manager wants it or not, it is essential to realize this. By showing example behaviour, the manager can help build an environment of trust.

A manager could play a role in assessing whether the Scrum Values are actually embraced. The Scrum Values can help detect undesired behaviour patterns.

A manager could also help to keep unwanted behaviour away from the team, expressing what is ok and what is not.

The Product Owner and Scrum Master don’t have a higher hierarchical position

The Scrum Team knows three accountabilities: Product Owner, Scrum Master, and Developer. They are hierarchically equal. Together, they decide what to do and how to do the work. On top of that, stakeholders have a role to play. They should provide their feedback and new insights. And they should collaborate on what to do next.

Not all Scrum Teams are in this position. They either have a Scrum Master bossing them around, a Product Owner pulling their strings or a manager telling them what to do. This behaviour will continue as long as the organisation allows it or even welcomes it.

How to help fix it

The manager can help avoid this situation or fix it by clearly communicating and showing example behaviour. By making clear that everyone in the team is equally important, with different accountabilities.

Typically this doesn’t happen with words alone. The actual behaviour of the manager is the most impactful. So, respecting the Developers’ decision on how much they can do during a Sprint and how they do it. Accepting that the Product Owner makes the decisions involving maximizing the value. Showing that the Scrum Master is a leader accountable for the effectiveness of the team.

Scrum Masters shouldn’t ignore the organization

Scrum Masters have to help the organization, its employees and stakeholders, to understand and enact Scrum and empiricism. Scrum Masters should also work on the implementation of Scrum in the organization.

Sadly, most Scrum Masters I have worked with weren’t expanding their activities beyond the team. Often, this is due to the lack of understanding of the accountability and support from the organization that this is part of the ‘job’. Or it is due to lack of time.

How to help fix it

Managers should help the Scrum Master to serve the organization. They can do this in several ways.

For starters, the managers can help to clarify the importance of the Scrum Master's accountability. They should show they take it seriously. As leadership accountability and not a side job. Not something you can do in your spare time as a developer.

Secondly, they can help the organization to understand the position of the Scrum Master as a coach, trainer and facilitator of change. They can help to empower the Scrum Master by setting the right conditions for them to do their work.

Product Goal and Sprint Goal aren’t optional

In a complex environment, teams should use the desired outcome as a source to create the product. As they don’t know what will happen, they can rely on long-term output-focused plans.

The longer-term outcome-oriented objective is the Product Goal. The short-term outcome-oriented objective is the Sprint Goal. Many teams don’t use the Product Goal and Sprint Goal, focusing solely on finishing the backlog items.

How to help fix it

The first thing that managers can do is to stop hammering on the output, as described earlier. But managers can be even more effective when they confirm the importance of goals. They could communicate the company vision and goals and help the team to align with these goals.

Practices like Objectives and Key Results (OKR) and Evidence-Based Management (EBM) are very helpful here. Managers can (help) implement and ensure effective use of these practices to strengthen the team in defining their goals.

The Definition of Done is halfheartedly implemented

The Definition of Done is extremely important in Scrum. It is a commitment to the quality of the Increment. It brings transparency. When an Increment is Done, everyone — the team and its stakeholders — knows what this means. This helps to have an effective Inspection of that Increment. Which is one of the key aspects of Scrum.

I know teams that tend to skip parts of the Definition of Done. Sometimes they are pressed by the organization to do this. Another anti-pattern is that the team defines a Definition of Done that is detached from the organization as a whole.

How to help fix it

Managers should help establish an environment of trust. Help stakeholders understand they should respect the team to plan, build and learn. This relates to living the Scrum Values.

They can also help to raise the understanding that Scrum is a discovery framework. Not a delivery framework. The team creates value through discovery. That it doesn’t make sense to skip parts of the Definition of Done to finish items in the Sprint. Because failing to achieve the Sprint Goal also is a way of learning.

The Definition of Done also is based upon organizational standards. Managers can help uncover the standards that are applicable to the product the team is accountable for.

Managers as leaders

In complex environments, many of the traditional management responsibilities are not effective—especially the responsibility to tell the team what to do, how, and by when. Teams are self-managing to create high-value products.

There’s plenty left for the managers. In fact, the manager will have additional responsibilities. They should communicate the company goals and help the team to align with these goals.

They need to embrace their role as a stakeholder of the team, providing feedback and new insights to help the team to determine what to do next.

They should lead the way in establishing trust and should help the Scrum Master to build an understanding of what it means to work with Scrum. They should also help create the right environment to allow the team to remove impediments themselves. Even if they have an impact on the organization.

The world of Scrum needs leaders who can grow beyond the traditional manager role. Leaders empower the team in their journey to discover the best way to create a valuable product. Managers should become leaders.