One project, several Cynefin domains

A project plan can make very different kinds of work look alike. Research the options. Make a decision. Test an idea. Implement the solution.

Each becomes another line on the list.

But those lines may require different approaches. One project can contain routine work, questions that need expert analysis and uncertainty that only practical experiments can help us explore.

Look within the project

Imagine redesigning a website:

  • Publishing approved content may sit in the clear domain, where a reliable procedure already exists.
  • Investigating a performance problem may be complicated, requiring specialist knowledge and analysis.
  • Discovering what helps visitors find the right service may be complex, requiring small, safe-to-fail experiments and observation.

These activities can happen alongside one another. The project does not need to belong to a single domain.

Nor does each activity have a permanent home. Implementation can reveal unexpected behaviour. Research can uncover a question that more analysis cannot resolve.

Match the approach to the situation

Cynefin helps us consider how to respond:

  • Clear: recognise the situation and follow an established practice.
  • Complicated: draw on expertise to analyse the options.
  • Complex: try bounded experiments, observe what happens and adapt.

The activity’s name does not determine its domain. ‘Research’ might mean looking up a documented answer or exploring something nobody yet understands.

Ask what makes the next step uncertain. Can an answer be found through expertise, or do you need to act and learn from the response?

Review the next few actions

Choose one active project and examine its next few actions:

  • Where would a checklist help?
  • Where do you need expert advice?
  • Where could a small experiment help you learn?
  • What evidence would prompt you to change your approach?

A useful project plan can hold several ways of working together.

Before asking how quickly an action can be completed, ask: what kind of situation are we dealing with here?

Agile handoffs: why are we explaining the work again?

The ticket moves to another column. Someone else picks it up. Then comes a familiar question, “What are we actually trying to achieve here?”

The work has moved, but has the understanding moved with it?

Every handoff creates a translation problem

Think about work passing from a stakeholder to a developer, from development to testing or from a delivery team to support.

Each person approaches it with different questions:

  • What problem does this solve?
  • What should we build?
  • How will we know it works?
  • What will someone need to maintain it?

These perspectives matter. The translation problem is making sure the purpose survives as the questions change.

A ticket might describe the requested change without explaining why it matters. A conversation might resolve an ambiguity without anyone recording the decision. The next person then has to reconstruct the context.

Continue reading Agile handoffs: why are we explaining the work again?

Ageing work: what your oldest unfinished item is telling you

Before your next conversation about velocity, try a different question: why is our oldest piece of work still unfinished?

Look at work the team has already started. Somewhere on the board, there may be an item that has survived several planning meetings, changed hands or quietly become part of the scenery.

Its continued presence deserves attention.

Continue reading Ageing work: what your oldest unfinished item is telling you

The hidden life of agile work: follow one item through its waiting

Earlier this week, we looked at the gaps between active steps: the time when an item is ‘in progress’ but nobody is working on it.

To make those gaps visible, follow one item through its journey.

Start small.

Choose a recently completed piece of work and reconstruct what happened from the moment it started to the moment it finished.

Continue reading The hidden life of agile work: follow one item through its waiting

Not everything on your to-do list is a task

Look at your to-do list. Does every entry describe something you can actually do?

‘Email the proposal’ is a task. But ‘New website’, ‘Resolve the staffing issue’ and ‘Improve team morale’ need more thought.

Some entries are

  • decisions
  • questions
  • experiments
  • situations that are still developing

Treating them all as tasks can leave you trying to complete something you have not yet understood.

Continue reading Not everything on your to-do list is a task