“That’s Impossible!”

Self-Limiting Beliefs in Scrum and how to deal with them as a Scrum Master

Christiaan Verwijs
The Liberators
Published in
5 min readMar 22, 2021

--

“It’s impossible for our team to be cross-functional” replied someone recently when Barry Overeem and I asked them why they were struggling to create a working Increment every Sprint. It’s just one variation of a common response we often get. Other examples are “We can’t just have one Sprint Goal per Sprint”, “It’s impossible for developers to visit the customer site”, “It’s impossible for us to deploy to production”, “Management will never allow us to self-select teams”.

We understand where this is coming from. When you start to work empirically — e.g. with Scrum — many things can seem impossible. Deliver a new and working version of the product every Sprint? Impossible! Give a Product Owner mandate over how to spend the product budget? Impossible! Have only one Product Owner for several Scrum Teams? Impossible!

But is it really impossible? It’s important to always remind ourselves that we’re talking about changing how people work together and how that work is organized. We’re not talking about putting a person on the moon tomorrow. Or resolving all conflicts overnight. We’re not talking about feats that are humanly impossible to perform. Instead, we’re talking about behavior, the norms that guide that behavior, and the decisions (implicit or explicit) that gave rise to both. And this perspective — that we’re dealing with accumulations of human-made decisions — changes everything. Because decisions are never immutable and set in stone. They are not laws of physics, even though they’re often treated as such in the workplace.

“This perspective — that we’re dealing with accumulations of human-made decisions — changes everything.”

Back to cross-functional teams

Take the example of not being able to create cross-functional teams. In this case, the Scrum Master believed that designers and developers could not be merged into one team because it violated the departmental structure of the organization. But what drove the decision to structure work this way? Who decided that it is still the best structure today? Who decided that the structure has to be followed at all costs and that no exceptions are allowed? Who decided that the work of designers and developers is so distinct that it can’t be combined?

Whenever you run into things that seem impossible, it’s good to remind yourself that there is someone or some group in the organization that made a decision that makes it seem impossible now. That doesn’t make it easy to change things all of a sudden, but it does put a human face on an otherwise abstract impossibility. More importantly, it makes it clear that we’re dealing with beliefs — not facts.

Self-Limiting Beliefs

Stating that something is impossible in how people do their work in teams or organizations is simply a belief. And a self-limiting one at that. The problem with these kinds of beliefs is that they effectively make you give up. And by expressing this belief to others, you’re also reinforcing it throughout the organization. The more people repeat that something seems impossible, the less likely it is that improvement is possible.

“Stating that something is impossible in how people do their work in teams or organizations is simply a belief. […] The problem with these kinds of beliefs is that they effectively make you give up.”

Another problem with self-limiting beliefs is that they are absolute. When you say that something is impossible, you also rule out the possibility of small, incremental improvements. It’s all-or-nothing. If it is really too hard to create completely cross-functional teams now, what is the first step you can take to make progress in that direction? Maybe you can get permission from management to do an experiment with one cross-functional team, and leave the other teams as they are? Maybe you can let designers and developers meet frequently during the Sprint to adjust their work? Maybe you can look into technologies and practices that make it easier for developers and designers to collaborate (like Bootstrap, Angular, or style guides)?

The Scrum Master as a Coach

For us, the identification of self-limiting beliefs is at the core of coaching. So when we say that the Scrum Master acts as a coach, we essentially mean that they help people identify self-limiting beliefs that exist in themselves, their team, or their organization and then to gently challenge those beliefs. One way for Scrum Masters to do is by asking open and inquiring questions:

  • What decisions were made by you, your team, or organization that make it seem that something is impossible now?
  • What would be necessary to adjust, revert, or update those decisions?
  • How can we create an urgency that change is needed?
  • Who needs to be involved?

For example, as a Scrum Master, you may have a Development Team that considers it to be impossible to work on only one or two items at a time. What decisions did they, and others, make that make it seem impossible? They may have decided that it is more efficient to work on multiple items at the same time instead of just a few. They may have decided to use a certain technology that makes it difficult to collaborate on a single item? By drawing the conversation away from what seems impossible, and to the decisions that make it seem that way, you essentially uncover areas for improvement and further exploration.

Once the decisions for making something seem impossible are better understood, Scrum Masters can move out of their coaching stance and create transparency around the consequences of those decisions. What happens because the Development Team decided to use a technology that makes it difficult to work on only a handful of items? If the decision was made outside the team, how can the Scrum Team create transparency around the impact of this decision on their work? Transparency is a great way to create urgency.

Finally, Scrum Masters can go and find the people that need to be involved to change, update, or reverse a decision. This is where an internal community of Scrum Masters is very helpful. The Liberating Structure Social Networking Webbing is also ideal for this (try our do-it-yourself workshop here). These people can then be brought together to reconsider the decision — in light of its impact — and to identify alternative decisions. Liberating Structures like 1–2–4-ALL, 25/10 Crowd Sourcing, and Troika Consulting are really helpful here. The Liberating Structure Myth Turning (in development) is ideally suited for challenging potential self-limiting beliefs.

The Art of the Possible

When it comes to changing how people work together, nothing is really impossible. Instead, there is a decision that someone made, somewhere, that makes it seem impossible. Fortunately, decisions are not immutable. Even when this can be very difficult or not worth the effort at this moment, they can be changed, appended, or even reverted. So rather than conceding that something is impossible, and essentially giving up, it’s more productive and motivating to focus on what is possible. This is why it is so helpful to believe in the Art of the Possible.

You can already support us with $1/month. Find out more on patreon.com/liberators

--

--

Christiaan Verwijs
The Liberators

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Developer, organizational psychologist, scientist, and Scrum Master.