As humans we often fail to be rational but excel at “rationalising". Our brains prioritise metabolic efficiency and social survival over objective truth. To conserve energy, the brain uses confirmation bias to filter new data through existing neural frameworks rather than performing the more "expensive" work of updating these neural pathways.

Most delivery issues seem obvious in hindsight.

After the fact, it is easy to point at the moment when things went wrong, whether it was a late dependency, a missed review, or a piece of work that was “almost done”.

The action taken or not taken at the time is always easy to justify - business pressure, higher priority elsewhere or someone accepting the risk, etc.

The uncomfortable part is that in almost every case, the warning signs were visible long before the risk became an issue.

Most delivery teams are stuck in a horrible reality of being pushed to provide estimates which are then turned into commitments. The estimates are an expression of confidence at best.

Dates are chosen because they feel reasonable, or because someone senior is comfortable with them, or because a plan demands certainty. The organisation then rallies around that date, progress is reported optimistically, and reality is politely ignored until the moment it can no longer be hidden.

Many delivery teams focus on what's in progress and what’s left to do.
Very few actively manage what's blocked. In fact, I’ve known a fair few over the years who actively skipped over the blocked items.
That's not just a minor oversight, it's one of the most expensive blind spots in modern delivery systems.

It bothers me. A lot. I used to go on LinkedIn to learn something. Now all I learn is that more and more of the content is AI generated. For instance, I’ve never known humans use this symbol “—“ so much. Have 90% of the people suddenly started doing that or are all these posts I am seeing generated by the same bot?

If your board says To Do / Doing / Done, your metrics are already compromised.
They are not just slightly off, and "good enough for now” is not good enough at all. Your metrics are actively misleading you.
And before you blame your tools, this isn't a tooling problem, it's a thinking problem.

Most delivery organisations don’t lack data. In fact they swim in data.

What they lack is understanding what to do with the data. To quote Douglas Hubbard "we should care about a measurement because it informs key decisions”​

But it is rare to come across an organisation that understands well why they measure in the first place.

If there is one Kanban idea that organisations love to talk about and hate to actually practice, it’s this one.

Pull-based WIP control. Everyone you meet who knows Kanban is also an expert in WIP.

The most common question delivery teams are typically asked is also the most damaging one:


“When will it be done?”


Not because the question is unreasonable, customers are absolutely entitled to ask, but because most organisations answer it in a way that guarantees disappointment. Dates get guessed, confidence gets projected, risks get accepted and uncertainty gets quietly ignored until it turns into high profile failure. Yes, an estimate is better than no estimate but estimates turn into commitments and that only leads to problems.

If you only tracked one metric for your flow of work, this would be it.

Not cycle time.
Not throughput.
Not a beautifully colour-coded cumulative flow diagram.

Work Item Age.

After coming across the same situation a few times, I decided it’s time to write about an approach to software delivery team structure that we have used with great success at a major government organisation around 2018-2021. Since then I have worked with three other organisations that seem to suffer from the very same problem - they find it difficult or slow to execute delivery of features or product increments where there are multiple teams involved in the end to end implementation.

Agile coaching emerged as a key role during the rise of Agile methodologies in the early 2000s. Initially, Agile was intended to transform the way software development was managed, focusing on flexibility, team collaboration, and customer-centric approaches. 

I recently had a conversation with a team I was helping with their workflow. Upon explaining the need to define policies for when work begins and ends, and policies for when it transitions between different stages I was asked why they would ever need more stages than simply [To Do] -> [In Progress] -> [Done]

(Updated 2026) If you know something about Kanban and perhaps a little bit about Portfolio Kanban, you may be aware of the need to know and display two signals for your epics that will help you manage your flow of work better.