There are some unspoken thoughts creeping into many delivery conversations lately.

If developers can generate code faster, test faster, produce documentation faster, then surely delivery becomes more predictable as a result?

And forecasting becomes … easier? Surely flow improves automatically?

If there is one habit that software organisations cling to longer than any other, it is starting work to feel in control. As if making the decision gives people some sort of satisfaction or power.

Roadmaps get refined, plans get approved, quarters get kicked off. Then work starts because it’s “time” and not because the system is ready.

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.

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.

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.

When I introduce myself as a kanban consultant I sometimes get a puzzled look back. So here are some thoughts on the subject.
Kanban coaching consultants (or just kanban consultant) play a vital role in helping organisations adopt and implement the Kanban Method effectively.

Calculating work item age is an essential part of running and optimising a workflow using Kanban practices. Contrary to popular belief you can benefit from Kanban measures and workflow optimisation regardless of what other processes you may have implemented (e.g. Scrum or DSDM or even a scaling framework). For the purpose of this article I would assume that you understand the ideas of Kanban for knowledge work and that you will know why tracking work item age is essential..