Have you ever been in a training session and found your mind wandering — or even drifting off to sleep? Most of us have. Our brains are wired to learn through doing, not through passive listening.

That’s why Scenario-Based Learning (SBL) is a game changer. It places learners into realistic situations where they must consider options, make decisions, and understand the consequences of those decisions. It transforms theory into lived experience.

Below is an example from one of the Agile Horizons courses.

SBL Example: Understanding Scrum Roles in Real Life

In the course, we first cover the Scrum roles:

• The Scrum Master coaches the team and the organisation, and removes impediments.

• The Product Owner manages the Product Backlog and works with stakeholders on prioritisation.

• The Developers own the Sprint Backlog and are responsible for quality.

This all sounds fine in theory — but what does it actually look like in real life?

This is where a scenario brings the learning to life.

The Scenario

• The team is mid-way through a Sprint.

• A stakeholder contacts a developer they know personally and asks for a “quick, urgent item” to be added this Sprint.

• They insist it’s only 2–3 hours of work.

This scenario works well because:

• It’s familiar to most Agile practitioners

• It contains a sense of tension and urgency

• There is no obvious right or wrong answer

• It encourages debate and critical thinking

Learner Options: What Should the Developer Do?

After discussion, learners typically identify three possible responses:

1. Say Yes

2. Say No

3. Say Maybe – and escalate the discussion

We then consider the consequences of each option.

Consequences

Saying Yes

• The item may not meet Definition of Ready

• It may not get done within the Sprint, risking metrics and commitments

• It sets a dangerous precedent where stakeholders feel they can bypass the process

• The team quietly absorbs the risk

Saying No

• Protects the Sprint, but may damage stakeholder relationships

• Can feel overly rigid or uncollaborative

• May not reflect the spirit of transparency and partnership in Agile

Saying Maybe

• Creates space for proper discussion

• Invites the right roles to be involved

• Balances stakeholder needs with team sustainability

• Is usually the option learners feel most comfortable with

Using the Scrum Roles to Resolve the Scenario

Because the scenario immediately follows learning about Scrum roles, learners now apply the theory to solve a real problem.

A collaboration board works well here — learners add digital sticky notes under columns for:

• Scrum Master

• Product Owner

• Developers

This quickly generates valuable discussion and shared understanding.

Through guided facilitation, learners typically arrive at something like:

Product Owner

• Works with the stakeholder to understand the true priority and urgency

• Clarifies whether this request outweighs other Sprint or Product Backlog items

Scrum Master

• Coaches the stakeholder on how Sprints work

• Explains the importance of Definition of Ready

• Protects the team from bypassing process through personal requests

Developers

• Assess whether the item is feasible

• Discuss implications for quality, workload, and the Sprint Goal

• Collaborate with the Product Owner on possible trade-offs

This approach transforms the learners from passive listeners into active problem-solvers. They are no longer memorising definitions — they are using them.

Benefits of Scenario-Based Learning

This scenario (and others like it) strengthens training by:

• Actively engaging learners in realistic decision-making

• Converting abstract concepts into practical, memorable skills

• Encouraging discussion and peer learning

• Building capabilities such as critical thinking, questioning, and hypothesis testing

• Helping learners see how Agile theory applies to their day-to-day work

Scenario-Based Learning doesn’t just teach Agile — it allows people to experience Agile

As Agile continues to mature, new practices naturally emerge. While this evolution is healthy, some practices take teams away from true Agility. These are often referred to as Agile anti-patterns—ways of working that appear Agile on the surface but undermine the core principles.

Here are five of the most common anti-patterns and how to resolve them.

1. Long-Term Planning

Scrum teams, when following the Scrum Guide, generally think one or two Sprints ahead. There is no requirement for long-term planning in Scrum. However, many organisations have commitments linked to quarterly or annual delivery timelines, and so naturally push teams toward longer-term planning.

A common example is PI Planning / Big Room Planning, where teams align around priorities and goals for the upcoming quarter. This can be useful if treated correctly.
The problem arises when managers treat these plans as fixed commitments, slipping back into command-and-control behaviours and holding teams rigidly accountable to dates.

The solution lies in the Agile Manifesto value:
“Responding to change over following a plan.”

And the related principle:
“Welcome changing requirements, even late in development.”

Long-term plans should remain forecasts, not commitments, and should evolve as priorities change.

2. Scrum Master as the Sole Facilitator

A common industry habit is to assume the Scrum Master must facilitate every Scrum event. While a Scrum Master can facilitate, the Scrum Guide simply says they ensure events are productive, positive, and kept within the timebox.
It does not say they must run them.

There are good reasons to share facilitation:

1. Team members develop confidence and facilitation skills, increasing overall maturity.

2. The Scrum Master avoids becoming a bottleneck.

3. Events don’t collapse when the Scrum Master is on leave.

Scrum Masters can strengthen their teams by coaching others to facilitate, rotating responsibilities, and building capability across the team.

3. Stakeholders Joining the Events

Stakeholders are strongly encouraged to attend the Sprint Review, but their presence in other Scrum events can be harmful.

I’ve seen Daily Scrums slowly turn into status meetings as stakeholders expect updates on every work item.
I’ve also seen Retrospectives shut down because the team no longer feels psychologically safe to speak openly.

Both the Scrum Master and Product Owner need to help stakeholders understand:

• The Sprint Review is their event.

• Other events are for the Scrum Team only.

• Transparency can be achieved by improving visibility of work and metrics, without disrupting Scrum events.

When stakeholders understand the purpose of each event, interactions become healthier and more productive.

4. Expanding the Definition of Ready and Definition of Done

The Definition of Ready (DoR) helps guide the team on what items are ready for a Sprint.
The Definition of Done (DoD) ensures completed work meets the standard required to be part of the increment.

The problem comes when these definitions start to include phrases like:

• “Solution Architect review”

• “Management sign-off”

• “Approval from XYZ committee”

At this point the team is drifting back to Waterfall, re-introducing phased gatekeeping before work can progress.

To stay Agile:

• Keep DoR and DoD lightweight.

• Avoid turning them into bureaucratic checkpoints.

• Uphold Agile values of collaboration, flexibility and flow.

5. When Tools Become King

Tools such as Jira or Trello support transparency and visibility, and are fully aligned with Agile principles.
The issue arises when teams focus more on tool hygiene than collaboration—Scrum Masters acting as “Agile Police”, obsessively cleaning data and enforcing rules that distract from delivering value.

This loses sight of the first value of the Agile Manifesto:
“Individuals and interactions over processes and tools.”

Tools should support teamwork, not replace it.

Conclusion

Agile will continue to evolve, and new practices will emerge. But to keep Agile truly Agile, teams must regularly look back to the foundations: the Agile Manifesto, its 12 Principles, and the guidance in the Scrum Guide.

By recognising and addressing anti-patterns early, teams can maintain focus on collaboration, flexibility, and delivering value.

Even experienced Agile Leaders can fall into subtle traps that quietly block their teams’ potential.
Here are five of the most common Agile Leadership mistakes — and what to do instead.

1️. Trying to Be the Knowledge Expert

Old-school management teaches that leaders must know everything — from technologies to business processes — and that authority comes from knowledge.

But in Agile, that mindset doesn’t work:

• It’s impossible to know everything.

• It stifles team motivation, creativity and mastery.

Instead of being the oracle of all things, ask your team for their input:
💬 “Sanjeev, could you explore a few branching options for this release?”
💬 “Adam, what would an Agile approach to this look like?”
💬 “Chew Min, what’s the best way to train users on the new features?”

You don’t need to know everything — use that to your advantage. Involve others, empower them, and build trust.

2️. Giving Teams Solutions Instead of Problems

It feels natural for managers to hand teams solutions. But Agile Leaders know that giving teams problems to solve is far more powerful.

Scenario:
Your team’s salon booking app has seen a dip in customer satisfaction.

Option 1 – Give a solution:

“I’ve reviewed the survey data and know exactly what we need to fix. Here’s the list of updates.”

Option 2 – Give a problem:

“I’ve grouped the feedback into five themes. Let’s go through them — I’d love your ideas on how to address each.”

With Option 2, the team feels engaged, motivated and valued. You’ll also benefit from the insights of those who know the product best — the people who built it.

3️. Starting with the What Instead of the Why

As Simon Sinek famously said, “Great leaders start with the Why.”

Many managers start with the What:

• “Here’s what we need to do.”

• “Here’s the roadmap.”

• “Here’s your action list.”

But great Agile Leaders begin with why — why this matters, why it benefits customers, why it excites the team.

When you lead with purpose, people follow with passion.

4️. Delegating the Removal of Blockers

Traditional managers often see fixing blockers as someone else’s job.

Agile Leaders take a different view — they embrace servant leadership, helping teams remove impediments so they can focus on value delivery.

Scenario:
Your testing environment keeps going down mid-sprint.

Option 1 – Delegate: Ask the environment team to keep uptime high.
Option 2 – Serve: Collaborate with them, explore root causes, brainstorm fixes, plan maintenance outside business hours, and establish a comms plan.

Servant leaders who get involved build trust and dramatically improve team productivity.

5️. Assessing Individuals Instead of Teams

If we paraphrase the first value of the Agile Manifesto, it’s this:

“Teamwork is more important than processes and tools.”

Yet some managers still assess individuals — measuring story points per developer or ranking Scrum Masters.

That approach kills collaboration. Instead, assess the team as a unit:

• How effectively are we working together?

• What can we do to support and improve the team?

Agile leadership is about nurturing teams, not judging individuals.

💡 Conclusion

As leaders move from traditional management to Agile Leadership, they can inspire, motivate, and unlock the best in their teams.

The ideas shared here — and many more — are brought to life in Agile Horizons’ Agile Leadership Workshop.
Visit the Courses page for more details.