If you are not flexible, you are not doing Scrum

“The oak is the strongest tree in the forest, but the willow bends and adapts. When the fires and storms hit, it is the willow that survives.” — Kara Barbieri

The essence of Scrum is being agile: a small team that is highly flexible and adaptive.

In short: Scrum requires people to be flexible. Flexible in their interactions with others, to understand how to deliver the most value. Flexible in their processes to be able to improve them. Flexible in their plans, so you can follow a better plan as more information becomes available.

So my question to you: how flexible is your Scrum team? And if your team is not flexible, are you really doing Scrum?

Novice Scrum teams usually become less flexible

Most teams starting with Scrum actually become less flexible. New Scrum teams try to play it safe, when faced with so much change, uncertainty and risk. The Scrum team layers familiar and unnecessary rules on top to give themselves back the feeling of control.

The problem with playing it safe is that you risk not really changing. This is a problem, because Scrum is a framework that allows the real working process to emerge. You need to discover what works best and this requires taking risks.

“The greatest risk in life is to risk nothing. The person who risks nothing, has nothing and becomes nothing.” — Leo Buscaglia

To change you need to step out of your comfort zone. By staying near your comfort zone, you end up doing what you have been doing before with a slight twist.

This might sound very abstract, but allow me to give some concrete examples of teams that are playing it too safe and being inflexible.

How flexible is your team if they respond the following way in different situations:

Sprint Planning

• “We cannot add this issue to the Sprint as it does not meet our Definition of Ready.”
• “We can’t include this issue in the Sprint, because it does not have Story Points yet.”

Only prerequisite in Scrum is that a Product Backlog item is forecasted to be completable within a Sprint. Story Points are an optional and complementary practice.

Refinement

• “We cannot discuss this issue in refinement, because it needs to pass through pre-refinement first.
• “Acceptance criteria are missing from the User Story. Please add acceptance criteria so we can refine this issue in the next session.”

Pre-refinement is not a concept in Scrum, only refinement. The development team usually spends no more than 10% of their time on it. Acceptance criteria are optional, though Scrum guide states Product Backlog Items often include test descriptions that will prove it’s completeness when “Done”.

Working together with other teams

• “We can only help you if you discuss it with our Scrum Master first.”
• “We cannot add the issue to the Sprint, because we’ve already started our Sprint.”

Scrum Master does not need to act like a gatekeeper for the team. It’s fine for other teams to interact directly with each other. Issues may be added or removed from the Sprint, as long you don’t endanger the Sprint Goal.

So the main question that remains: why are teams responding like this instead of being more flexible?

Why are teams not flexible?

“If failure is not an option, then neither is success.” — Seth Godin

To become more flexible, the team needs to change their ways.

To change their ways, the team needs to take risks.

To take risks, the team needs to feel safe enough to be willing to take these risks.

The safety to be able to take risks is called psychological safety. Teams that experience psychological safety have team members that:

“Feel safe to take risks and be vulnerable in front of each other.”

Without psychological safety, there is no risk-taking. Without risk-taking, there is no real change. And without no real change, your Scrum team will never become flexible. The team will just try to find a way to fit what they were doing before in the Scrum framework.

Psychological safety was identified as the key ingredient of high-performing teams at Google in the Aristotle project. Psychological safety also forms the foundation for a model that describes the different stages of high-performing teams: ‘The Five Dysfunctions of a Team’ model by Patrick Lencioni. Psychological safety forms the foundation of the model.

It is important to mention, there is more to high-performing teams and taking risks than only psychological safety, but psychological safety forms the foundation of a high-performing team. If you don’t trust each other enough to rely on each other, then how can you become a high-performing team?

Being flexible requires psychological safety

Scrum requires Scrum teams to be flexible.

Without flexibility, you will not be able to discover how to deliver the most value. It will not be possible to figure out the best working process. It will also not be possible to figure out the best plan when new information arrives.

Most teams starting with Scrum actually become less flexible. Novice Scrum teams try to play it safe, when faced with so much change, uncertainty and risk. The Scrum team layers familiar and unnecessary rules on top to give themselves back the feeling of control.

The problem with playing it safe is that you risk not really changing. This is a problem, because Scrum is a process framework that allows the real working process to emerge. You need to discover what works best and this requires taking risks.

Psychological safety -> Taking risks -> Changing ways -> Flexibility

In order for Scrum teams to take risks they need to feel psychologically safe. This allows for taking risks that lead to real changes to the working process that allow for flexibility and responding to change.

In short: if your team is not flexible, it’s not doing Scrum!