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.