The Biggest Shift in My Thinking as a Scrum Master

One of the biggest shifts in my thinking as a Scrum Master and Agile Coach was realising that most teams are far more constrained by the systems around them than the processes they follow.

Early in my career, like many people in Agile environments, I focused heavily on ceremonies, boards, burn downs, story writing and frameworks. I believed that if we followed Agile processes well enough, better delivery outcomes would naturally follow.

Over time, I started noticing something uncomfortable.

Some teams were doing all the “right Agile things”:

• stand-ups

• retrospectives

• sprint planning

• backlog refinement

• burn down tracking

…but they still struggled to deliver software confidently, consistently or safely.

At the same time, I saw other teams improve significantly without dramatically changing their Agile process at all.

The difference was rarely process compliance.

The difference was usually learning.

The teams that improved the most became curious about how software delivery actually worked.

They wanted to understand:

• why deployments were painful

• why testing took so long

• why releases felt risky

• why large changes created instability

• why feedback cycles were slow

• why quality issues kept returning

As a result, conversations started shifting toward concepts like:

• CI/CD

• testing automation

• batch size

• DevOps

• architecture

• deployment confidence

• observability

• feedback loops

Not because everyone suddenly wanted to become an engineer, but because the team was beginning to better understand the system they were operating within.

This completely changed the way I thought about the role of a Scrum Master.

I stopped seeing the role primarily as someone responsible for enforcing Agile process.

Instead, I started seeing the role as helping teams improve their capability to deliver.

Ultimately, that is the role.

At some point, you need to stop thinking too hard about Scrum, SAFe or any other “Agile” framework and start thinking more deeply about how to help teams learn, improve and deliver confidently.

A big part of that shift came from working in government and large enterprise environments.

These organisations are often complex systems with:

• governance structures

• funding constraints

• risk management obligations

• legacy technology

• dependencies

• layers of approval

• competing incentives

A lot of these things move slowly.

Sometimes painfully slowly. Well, in my experience, a lot of the time...

And while it can be tempting to spend energy fighting every organisational constraint, I found this often left teams frustrated, cynical and dependent on external change before they felt they could improve anything themselves.

In the most effective teams I worked with, we took a different approach.

We focused on what was within our control.

We improved:

• collaboration

• quality practices

• automation

• technical understanding

• communication

• experimentation

• deployment confidence

• learning culture

Incrementally and consistently.

Over time, these improvements compounded.

Interestingly, this often positioned us to take advantage of organisational change when it eventually happened.

I’ve seen organisations slowly become more open to:

• faster deployments

• continuous delivery

• team autonomy

• modern engineering practices

But when those opportunities appeared, not every team was ready.

Some teams still relied heavily on manual testing, large release cycles and fragile deployment processes. Even if governance barriers disappeared overnight, they still wouldn’t have been able to safely deploy frequently.

Other teams were stuck trying to change things they had little influence over.

However, we were ready.

In many environments, meaningful improvement starts long before the organisation fully changes around you.

For me, this became one of the most important principles in delivery improvement:

Focus on what is within the team’s control.

Not because organisational systems do not matter.

They absolutely do.

But because sustainable improvement often begins by helping teams gradually increase their ability to learn, adapt and deliver with confidence regardless of the broader organisational complexity around them.

That shift fundamentally changed how I approach Agile coaching, delivery leadership and continuous improvement.