What teams taught me by failing safely

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 safely

Agile as a learning system, not a delivery framework

Agile 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 framework

Scrum Masters and Cynefin – when the team needs stability first

This is the fourth and final post in a short series exploring the Scrum Master role through the four main Cynefin domains:

  • clear
  • complicated
  • complex
  • chaotic

The first post looked at the clear domain, where simple rules and repeatable practice can help.

The second post looked at the complicated domain, where teams need expertise, analysis and informed judgement.

The third post looked at the complex domain, where teams need feedback, experiments and learning.

This post looks at the chaotic domain.

What is the chaotic domain?

In the chaotic domain, the situation is unstable.

Cause and effect are unclear.

There may be pressure, urgency, confusion or even panic.

The team does not have enough stability to analyse the problem properly. It may not even be clear what the problem is yet.

Continue reading Scrum Masters and Cynefin – when the team needs stability first

Scrum Masters and Cynefin – where learning matters most

This is the third post in a short series exploring the Scrum Master role through the four main Cynefin domains:

  • clear
  • complicated
  • complex
  • chaotic

The first post looked at the clear domain, where simple rules and repeatable practice can help.

The second post looked at the complicated domain, where teams need expertise, analysis and informed judgement.

This post looks at the complex domain.

What is the complex domain?

In the complex domain, the relationship between cause and effect can only be understood afterwards.

The work is uncertain. The team cannot simply apply a checklist or ask an expert for the right answer. There may be no single right answer.

Instead, the team needs to learn through action.

Continue reading Scrum Masters and Cynefin – where learning matters most

Scrum Masters and Cynefin – when the team needs expertise

This is the second post in a short series exploring the Scrum Master role through the four main Cynefin domains:

  • clear
  • complicated
  • complex
  • chaotic.

The first post looked at the clear domain, where simple rules, checklists and repeatable practice can help.

This post looks at the complicated domain.

What is the complicated domain?

Hand-drawn Cynefin framework diagram showing four domains around a central area of confusion: complex, complicated, chaotic and clear, with each domain labelled with its constraint type, response pattern and practice type.
A line drawing of the four regions of the Cynefin framework: Clear, Complicated, Complex, and Chaotic, plus the central unknown area Confusion. (Source: Wikipedia)

In the complicated domain, the work is not obvious, but it is still knowable.

There may be more than one right answer. The team may need analysis, diagnosis or specialist input before deciding what to do.

This is the world of expertise.

Continue reading Scrum Masters and Cynefin – when the team needs expertise