When Scrum Masters should deliberately let teams fail

In many organisations, mistakes are still regarded as something to be avoided wherever possible. At the same time, innovation, continuous improvement and sustainable learning processes often only emerge when teams try out new approaches, challenge assumptions and deliberately draw lessons from setbacks. Particularly in complex working environments, where uncertainty and change are part of everyday life, dealing with mistakes constructively thus becomes a key prerequisite for long-term effectiveness.

In the Scrum context, too, the question arises as to what role the Scrum Master plays in shaping a team culture that fosters learning. This is not merely a matter of accepting mistakes. Rather, it is about creating a framework in which experimentation is possible, risks are taken in a considered manner, and teams can systematically learn from their experiences. At the same time, boundaries must be taken into account, for example where safety, legal requirements, Sprint Goals or the interests of customers are concerned.

After all, continuous learning is one of the key success factors in an agile environment. Scrum is based on empiricism and thus on the assumption that not all answers are known from the outset. Instead, assumptions are tested, feedback is gathered and insights gained are used to gradually improve products and working practices. A conscious and responsible approach to mistakes and experiments therefore does not stand in the way of successful product development, but is an essential part of agile working.

Failure needs limits

One of the Scrum Master’s roles is to coach the entire team with regard to cross-functional skills. [1] At the same time, they are responsible for the effectiveness of the entire Scrum team. This also includes facilitating learning through failure, encouraging a constructive approach to mistakes, and creating space for calculated risks.

Of course, there are limits to this:

• Security risks: Experiments must not jeopardise people’s physical or psychological safety, nor IT or information security.
• Jeopardising the Sprint Goal: Experiments must not disproportionately jeopardise the achievement of the Sprint Goal and thereby diminish its significance. [2]
• Exposing individual team members: Mistakes must not lead to individual team members being publicly blamed or shamed.
• Breaches of legal or regulatory requirements: Laws, compliance requirements and internal guidelines must be adhered to at all times.
• Risk to customers, users or partners: Learning experiments must not have any negative impact on customers, end users or business partners.
• Breaches of data protection or data security: Data protection guidelines must be strictly adhered to, particularly when conducting experiments with real user data.

The trick lies in creating sufficient scope for learning and development without taking disproportionate risks. Scrum Masters should therefore continually weigh up the potential for learning against possible negative consequences. This is less about whether mistakes can be avoided, and more about the conditions under which they can make a positive contribution to the team’s further development.

A thoughtful approach to risk makes it possible to promote learning in a targeted way without losing sight of responsibility for people, objectives and outcomes. This is precisely where a principle comes into play that focuses on the conscious handling of experiments and failure: Fail Fast, Fail Forward.

Fail Fast, Fail Forward

“Fail Fast, Fail Forward” describes an approach in which ideas and hypotheses are tested at an early stage in small, controlled steps. [3] The aim is to obtain feedback quickly and to learn from it in a targeted manner. The focus is not on avoiding mistakes, but on consciously allowing experiments, the results of which are incorporated into the next iteration. Failure is not regarded as a setback, but as valuable information that helps to make better decisions and drive developments forward in a targeted manner.

This principle is becoming increasingly important, particularly in dynamic and digitally driven working environments. Through the use of artificial intelligence, automated workflows and AI agents, products, processes and operating conditions are changing at a rapid pace. As a result, decisions are less likely to remain valid in the long term and must be continuously reviewed and adapted. Rapid and structured experimentation becomes a crucial factor for success in this context: hypotheses are validated or discarded at an early stage, assumptions are scrutinised, and solutions are developed iteratively.

This is precisely why Scrum Masters should engage deeply with the ‘Fail Fast, Fail Forward’ principle. Their role is not merely to support the application of the Scrum framework. They also create an environment in which teams can experiment with confidence and courage. In doing so, they navigate the tension between fostering learning and taking responsibility for risks, quality and stakeholders. This principle helps them to actively shape this tension and support teams in turning uncertainty into structured learning, without taking uncontrolled risks.

What controlled failure looks like in practice

The key point in all these examples is that the Scrum Master does not allow teams to fail in a way that causes harm. Rather, they facilitate controlled and transparent failure within defined boundaries so that genuine learning can take place. Safety, quality and accountability are maintained at all times, whilst deliberately creating space for uncertainty. What matters is not the failure itself, but the targeted use of the results, regardless of whether they meet expectations or come as a surprise.

In a Scrum context, it is repeatedly evident in practice that learning occurs above all where teams are prepared to sacrifice short-term certainty in favour of new insights. This is precisely where tensions often arise, as organisations are naturally geared towards planning, predictability and reliable delivery.

A typical example is the deliberate decision not to safeguard the Sprint Goal to the maximum extent possible, but instead to test a new technical architecture during the ongoing sprint – for instance, when migrating a central module. In doing so, it is accepted that individual planned features may not be fully completed. The focus shifts from complete delivery to the question of whether the technical direction is viable and what insights can be gained from it for further development.

This tension is even more evident when new technologies are introduced. There is often a tendency to evaluate new tools or AI components initially in isolation and with as little risk as possible. Instead, a new AI component can be integrated directly into an existing ticketing system to test automatic categorisation under real-world conditions. Despite the model quality not yet being stable, a production-like deployment is deliberately chosen in order to gain reliable insights into benefits, limitations and integration effort.

When it comes to product assumptions, too, many teams tend to validate hypotheses as comprehensively as possible in advance. This often delays the acquisition of genuine insights. Another approach is to test an assumption such as ‘users will actively use feature X’ directly within the product environment, for example using a rapidly implemented prototype in the live system or a highly limited roll-out. Even low usage or clear rejection provides valuable information about actual needs and replaces speculative discussions with concrete data.

Another example is the targeted refactoring of legacy systems. A team might, for instance, overhaul a central backend module whilst the system is still in operation, even though it is known that this may lead, in the short term, to instability, increased errors or restrictions in the ordering process. Deliberately accepting these risks serves the aim of sustainably reducing technical debt and improving the system’s stability and maintainability in the long term.

Finally, this approach also applies to the further development of team processes. For instance, a new planning format may be introduced which deliberately avoids traditional effort estimates and instead works with hypotheses and rough ‘T-shirt sizing’. The first implementation may be less structured than established formats, require more coordination, or reveal uncertainties within the team. However, it is precisely these effects that provide important learning opportunities for iteratively improving the approach and adapting it more effectively to the team’s collaboration.

Failure can be part of the learning process

Continuous improvement and a constructive approach to dealing with mistakes go hand in hand in agile working. Learning rarely results from perfect planning. It arises when teams test their assumptions, seek feedback and adapt their next steps based on new insights.

This approach is crucial, particularly in complex environments where uncertainty is part of everyday life. Teams do not need to rule out every risk in advance. They can experiment in small, controlled steps, gain insights and iteratively improve their solutions. Accountability remains essential in this process. Quality, as well as the impact on customers, users and the organisation, must not be lost sight of.

This is precisely where the Scrum Master comes into play. Their role is not to shield teams from every mistake. Rather, they create a framework in which controlled failure is possible and genuine learning can emerge from it.

Perhaps this is precisely where the key distinction lies: allowing teams to fail deliberately does not mean leaving them to their own devices. It means trusting them to gain their own experience within clear boundaries and to learn from that experience.

Notes:

Would you like to discuss agile leadership and how teams take responsibility with Niklas Magerl? Then simply get in touch with him on LinkedIn.

[1] Tasks of the Scrum Master
[2] Benefits and formulation of sprint goals
[3] Which elements support ‘failing forward’?

Would you like to support Niklas Magerl or discuss failure as part of the learning process? Then share this post within your network.

Niklas Magerl has published more posts on the t2informatik Blog, including: