Failure is not usually something organisations want to talk about.
We prefer words like delivery, progress, efficiency and success. Those are good things. But in Agile work, some of the most important learning comes from small failures that happen early enough to do something about them.
The key is not to avoid failure completely.
The key is to make failure safe enough, small enough and visible enough that the team can learn from it.
Continue reading What teams taught me by failing safelyAgile is often described as a way to deliver work faster.
That is not wrong, but it is incomplete.
At its best, Agile is not simply a delivery framework. It is a learning system. It helps teams discover what is true, what is valuable, what is possible and what needs to change.
Continue reading Agile as a learning system, not a delivery frameworkScrum Masters are often expected to help.
They notice tension.
They see confusion.
They spot inefficient conversations.
They recognise patterns before the team does.
So the temptation is obvious: step in, explain, fix, smooth, coach or redirect.
Sometimes that is exactly what is needed.
But sometimes the most helpful thing a Scrum Master can do is pause.
Continue reading The Scrum Master’s hardest skill is knowing when not to actAt some point, every Scrum Master faces this tension.
Do you enforce the process?
Or do you support the team?
It is easy to drift into becoming the process police.
But that is not where real value lies.
Continue reading Scrum Master not process police – choosing the role that actually helps teamsAgile is meant to help people respond to reality.
But sometimes Agile itself becomes a way of avoiding reality.
When that happens, practices become rigid, language becomes moralistic, and teams are judged not by whether they are learning, but by whether they are following the ‘right’ process.
This is where Cynefin helps.
Cynefin reminds us that context matters. Not every problem is the same. Not every team needs the same response. And not every Agile practice fits every kind of work.
Dogmatic Agile usually sounds certain.
It says:
That kind of thinking can make people feel safe, because it offers clarity and control.
But it can also become blind.
When Agile turns into a rigid formula, it stops being adaptive.
Cynefin asks a more useful question: what kind of situation are we in?
That question changes everything.
In the clear domain, standard practices and repeatable steps may work well.
In the complicated domain, expert analysis and judgement matter.
In the complex domain, you cannot rely on fixed answers. You have to probe, learn and adapt.
In the chaotic domain, you act first to create enough stability to make sense of what is happening.
Cynefin does not reject method.
It rejects the idea that one method fits every situation.
Many teams struggle not because they lack frameworks, but because they are applying the wrong kind of thinking to the work in front of them.
For example:
These are not just mistakes in practice.
They are mistakes in sense-making.
Cynefin introduces humility into Agile.
It reminds us that:
That makes Agile less ideological and more useful.
Instead of asking, “Are we doing Agile properly?”, a better question is “Given the nature of this situation, what approach makes sense here?”
Cynefin does not weaken Agile.
It strengthens it by returning it to its purpose.
Agile was never meant to be a belief system.
It was meant to help people respond well to change, uncertainty and learning.
Used together, Agile and Cynefin can help teams become less dogmatic, more thoughtful and more responsive to reality.
That is often what real agility looks like.
