From flow point of view, one of the worst statements you can make is “at least everything is being progressed”, yet I’ve heard that so many times from both inexperienced delivery leads and product people alike.

In my previous article, I explored feature ageing and discussed why it can be a useful signal for product managers. When you observe the ageing of features over time, you may notice a strange phenomenon with some late deliveries.

What I mean is that sometimes features that seem well understood and simple enough, and nobody expects them to become problematic, end up taking longer and becoming a risk.


Work on the feature continues but it just isn’t getting finished. Why?
Sometimes the answer is complexity that we could’t foresee before. Or a dependency appears that nobody could reasonably have predicted.

But occasionally, or perhaps most commonly, it is neither. Having watched delivery teams for a long time, I believe the most common reason is that there is simply too much going on at once.


The seduction of seeing things move

Moving work is not the same as completing work. If you are reading this post, you probably don’t need convincing about this statement.


But in organisations we often see that teams and often their bosses want to demonstrate that things are happening and they insist to start work on a feature so they can declare it as a win in their weekly reports.


People are also remarkably keen on starting new work. I get it, our brains like novelty, new ideas are exciting and new initiatives create momentum.

Anyone who’s spent a few years at big organisations will tell you that they change directions, sometimes too often, and what seemed important yesterday is no longer the top priority today. The decision to start on a new initiative usually feels reasonable. The issue only becomes visible when you step back and look at the whole picture.


From flow perspective starting without finishing is just about the worst thing you can do. Every feature that enters delivery joins a queue for attention. It competes for the same conversations, the same decisions, the same specialists, and the same organisational energy as everything else already in progress.

If we were on the manufacturing floor the queues might be too obvious to ignore. But in knowledge work, this accumulation is often invisible. It is the responsibility of the delivery leader and the product manager to make the queues visible.



The product manager’s view

In a typical organisation most people try to make things look good. It is somehow assumed that working on 4 initiatives instead of 3 is better. You are showing that you are working harder and it seems that you are getting more done. Your stakeholders look happy.
And as you follow this logic and new, urgent changes arrive, you soon end up working on 7 initiatives while your team’s only able to comfortably handle 3. You are getting so much more done.


But now things seem to be different. Attention of your key people is more fragmented and they “drop the ball” occasionally. Everything slows down because there are competing priorities, impediments take longer to resolve, people start to look and act overworked.

And soon enough some initiatives are beginning to look like they will be late. Your options are limited. Either make people work longer hours or drop something. Neither option seems attractive.

That’s the product manager’s dilemma.

How did we end up here? We wanted to show more progress. But work in progress is very different from work completed.


Why product commitments become fragile

Our senior leaders often demand commitments. And it makes sense, they invest in our teams and they want to see returns.


I think that when they first come across commitments most product managers are not ready for it. But the job demands it and so they often begin with a set of reasonable assumptions.

e.g. If Feature A takes approximately eight weeks, and Feature B takes approximately eight weeks, then we can make sensible plans when both will be done.

Of course these assumptions don’t survive first contact with reality. They breaks down when several features are competing for the same capacity at the same time or when an unforeseen work becomes urgent.
There are so many ways in which work streams can affect each other. In most cases work streams are not completely isolated. And so a delayed decision on one initiative can consumes attention that was needed elsewhere. Or a dependency on one feature creates waiting time for another. Or a critical specialist gets pulled between multiple work streams due to changing priorities.

The result is that the overall system becomes less stable and so delivery becomes less predictable.

Depending on what you report on, it can look as though the team has become slower while in reality, the system has just become busier.


What feature ageing is really telling you

In my previous article on feature aging I concluded that a simple signal can tell you what to pay attention to.

And I stand by that, it is a useful signal and it can help you uncover and resolve blockers, technical challenges, and delivery concerns earlier.

But while that’s a useful action to take right now, you should also be aware that feature aging could be hinting at longer term issues with your broader system.

It could be highlighting the cumulative effect of having too many things in progress at once. And this isn’t a straight forward signal because knowing what is a good work in progress limit isn’t possible without observing your flow of work for a while. And things get more complicated when the organisational structure changes often.

Being able to optimise your work in progress can have profound effects on your productivity but unfortunately it isn’t something you are likely to get right by using your gut feel. In fact in most cases the right number turns out to be a complete surprise to those inside the system.


The roadmap tension

There is a big problem with the traditional roadmap and I’ve seen organisations ignore it time and time again. Features are visualised on a timeline typically because that view makes sense to the senior leaders. Then the “rough dates’ Product managers use to create the picture quickly become expected dates.


Explaining why fixed dates are a problem is a whole different matter. if you need convincing go and check my Kanban series.

In short, if you use fixed dates, often these dates will slip and you will be asked to explain why.

It seems like Product managers are rewarded for identifying opportunities and then punished for not being able to predict the future in a world that works in probabilities, not in fixed dates.


As a side note, some organisations adopt a Now/Next/Later approach. This often seems different on the surface before you discover that they silently assign timeframes -e.g. Now is this month, Next is within 3 months, etc. Visualising your features on a Now/Next/Later board has its benefits but it doesn’t do much to introduce realistic forecasting so you can communicate only what you know with reasonably certainty.


A simple experiment

If you are not sold on this idea perhaps you can test it with data. You would not need sophisticated tooling, just a simple spreadsheet.

Keep track of the features you have in progress - e.g. every week write down how many features are in progress.

Then look at how many features start and how many features complete per given period e.g. monthly or weekly. It would be useful to have data over several months.

At this point you may be surprised by what you find. When you get updates from your teams it probably feels good to see things progressing. But from this higher level you may discover that the more activity you have (more features in progress) the fewer features get completed.



What Product Managers Need

This series is meant for Product managers so let’s focus back on them.

I believe Product managers need help to be able to recognise patterns that influence delivery outcomes when it is not too late.

We looked at feature aging first and now work in progress. Too much work in progress is one of those patterns.

As many very useful things, tracking work in progress does not require advanced analytics to notice it, just a way of seeing the relationship between active work and completed work.

Once that relationship becomes visible, many delivery problems start making more sense. And more importantly you have a chance to intervene.


What Comes Next

There is one further pattern that’s worth exploring in more detail.

You must have seen this. Some features seem to spend far longer in progress than others, regardless of how much work is happening around them.

When you investigate you may find out that the reason is simple. The feature itself was larger than anyone realised.

And that is where we’ll go with the next post.

In many of these conversations we explored transparency but not even a single product manager thought that is the case. Quite the opposite, most have as much visibility and access to the delivery team as one can wish for. So this is not about delivery teams hiding information.

And neither is because status reporting is deliberately misleading.

However we found out that there is a gap between seeing activity and understanding risk. And this gap leads to a rather interesting question.

If product managers are responsible for outcomes, how can they spot delivery risk earlier?

The answer, I think, starts with a simple signal we’ve called Feature ageing.


The difference between knowing and being told

Most product managers I’ve worked with are very helpful people. They will go way beyond the call of duty to remove blockers, facilitate conversations, fill in endless forms, you name it. But they can’t do any of that unless they are told by their teams - “Here is a problem we’d like help with”.

In short they don’t discover delivery risks when the risks appears but only when someone tells them. And most have accepted that there is no better way but nonetheless this creates a somewhat uncomfortable feeling.

Here is a common scenario. A new feature enters delivery. The initial updates sound positive and stay positive for some time. Then a dependency appears, “We’ll shout if we need help” the engineers say.
Then an urgent requirement appears, it can’t wait, and so you agree to park the work. Eventually the team is back on the new feature.  Then somebody mentions that things are taking a little longer than expected. Not too long later, the updates change.

“We’ve uncovered some additional complexity.” or “We’re still working through a few issues.” or perhaps “It’s mostly done.”

And somehow now everyone agrees the feature is at risk. But the interesting question is whether the risk appeared at this point or whether we only noticed it now.

In many cases, the warning signs were there much earlier but we just didn’t have a simple and clear way of seeing them.


What Is Feature Ageing?

Ageing of work is a simple concept that has existed for many years in various fields. It is simply the amount of time a feature has been actively in progress. That’s all.

To make use of feature aging you don’t need to track how much effort has been spent or how many story points remain (eye-roll) or how confident people feel about delivery.

Just how long the feature has been moving through the system. Most product managers already know roughly when a feature started. And they surely know when it eventually finishes.

The information already exists, you just need to collect it and use it to produce a signal that is otherwise hidden in plain sight.

A word of warning. The important part isn’t the Age and this is where people sometimes misunderstand the idea. A feature does not become risky because it is old however it becomes interesting when it is getting older than similar features normally are.


Imagine one feature has been in progress for thirty days.
Is that good? Is it bad? Impossible to say with just that bit of information.


However if you know that most of your features of similar complexity take sixty days, then thirty days is around 50% which is perhaps too early to start worrying about it.


But if most of your features of similar complexity take forty days, then you’ve gone past the 75% mark and I’d suggest this is something that deserves your attention.


So in short, the age itself is not the signal but the deviation from what’s normal is.


Why Status Reporting Struggles

Status reporting tends to answer one question very well “What are people doing?”. Yes, in theory it should also highlight any risks but I think, since our default position is to be optimistic, that it mostly fails at that task.


Product managers, being responsible for delivery of outcomes are usually more interested in
“Should I be concerned?” or “What can I help with?”.


Perhaps calling something a risk is putting people off? Perhaps we need a different question.


While a feature can have plenty of activity around it , it may still be taking longer than it should. There is no direct correlation to how hard people work or how busy they seem. In fact, some of the riskiest work often looks surprisingly busy.


And for that reason we need a signal that abstracts away from the busyness and the subjectivity of raising a risk. One such signal is feature ageing.


Aging of work doesn’t care how busy people are, it simply highlights when something is taking longer than expected.


Just how much data do you need?

Wouldn’t it be nice if you could just manage your features in your preferred way in a tool that also automatically can give you aging signals?


Well, yes, it would. But while such a tool doesn’t really exist yet, at least not out of the box, there is some minimal data collection that can help you identify aging signals fast.


I’d imagine you already have a simple list (spreadsheet?) with your features. For simplicity let’s assume that all you features are very similar in size (in reality they aren’t but that’s a more complicated case we can discuss later). All you need to record  in addition is when does a feature start and when does it finish.

Some features consistently finish fast and others take longer and over time, you will develop a rough sense of what normal looks like in your environment.


You can even capture feature dates historically if you have the data. This will provide you with a more realistic “normal” faster.

When you know what normal looks like, unusual things become easy to spot. Yes, being able to back this up with a proper calculation would be very useful but you could get value out of this data collection even without it.


Do product managers really need delivery metrics?

This is a bit like asking, do you really need a drill to hang a picture on the wall. There are of course more than one ways of achieving your goal. If you really want to see delivery metrics and you are comfortable with that then you probably should.


But I don’t think product managers need delivery metrics to get good delivery signals like when a feature needs more attention.


Metrics are useful and any signal should be able to demonstrate why it is signalling. But even if some product managers choose to look at the calculations as they gain more confidence in the signals they may skip the details.


What I am trying to say is that those product managers who are not comfortable with Kanban metrics, forecasts and formulas won’t need to worry about them if a good feature planning tool with built in signals existed.


Let’s assume for a minute that such a tool does exist. It only needs to answer a simple question:


“Does this feature deserve my attention?”


If you use feature ageing with appropriate signals you can answer this question easily.


The next step is up to you. You need to find out how to help. Because it is almost impossible for a tool to uncover exactly why something is taking longer or to identify the root cause or to prescribe an appropriate solution.


Would you like a free spreadsheet?

The obvious problem of all this is that (I assume) nobody wants to maintain yet another spreadsheet.


I think that most product managers already have more systems than they need. So wouldn’t it be nice if good product tools should have the capability to surface these signals automatically?


Of course ideally, you’d want one system perfectly connected and traceable from idea to production. I don’t want to go into the details (yet!) of why that isn’t happening. It’s not for the lack of attempts but at present no system seems capable to make it work for everyone.


Failing to have it all connected, you could use the simple logic this article describers. It is not particularly complicated and it doesn’t require product managers to necessarily know or care about probabilistic forecasting.


But it could provide that simple signal “This feature deserves attention.”


On the limitation of feature ageing​

Feature ageing is a simple and useful concept but it is not a silver bullet. It tells you which of your work items or features deserve investigation but it does not tell you why.

And I don’t believe it should because the answer is usually complicated and nuanced. A feature may be blocked but uncovering what’s blocking it can be very convoluted. There might be dependencies but the intricacies of how it should work cannot be known without extensive investigation.

So is there anything more we can do about it?
I think so, and I will cover that in the next article.

It is very common for the person who stands in front of the board of directors, or in front of the senior leaders in the organisation to demonstrate progress made by their product teams, to often be delivering a message that has been given to them by someone else. And this person would often feel accountable for progress and at the same time a little uncomfortable because they can’t see that progress clearly.


In some cases, at the start, there is an implied trust between the product leader and those giving them progress updates. Sometimes the trust comes later. But in either case the trust is often fragile, breaks at the first miscommunication and can lead to an ineffective long term relationship. That is if the relationship wasn’t bad to begin with. It can be very frustrating for both sides, as if they speak different languages.


From a delivery team point of view it is often difficult to see the significance of the commitments that product managers make. Or the need for setting expectations. Product managers find themselves explaining progress to stakeholders, leadership, and sometimes the board. And in many cases they don’t have sufficient confidence in the updates they provide. But in their desire to be more certain they may ask their delivery teams for details that seem irrelevant or petty. Yes, it is very frustrating for both sides.


Things typically get worse, when delivery goes off track. It is not uncommon for the product managers to be among the last to realise. But that’s usually not on purpose.


In truth people are almost never hiding things. Engineering teams are often optimistic but that’s almost never deliberate. So what is actually going on?


It is easy to point out mistakes in hindsight. It is harder to design a system that makes it easy to see what’s really happening.


The gap between responsibility and visibility

If you speak to product managers, many will tell you they have “visibility”. Dig a little deeper however and you’ll find out, what they mean is that they attend stand-ups, they join reviews, and receive updates, and can open Jira and see what’s in progress.

On the surface, everything is there. But the level of detail is often not right for the product manager. So they still rely on interpretation or a team meeting to write the weekly report.

A feature is “progressing well”.
Another is “a bit more complex than expected”.
Something else is “nearly there”.


All of which might be true but it doesn’t answer a more important question:

Is anything starting to go wrong? Should I be worried?


Why this is harder than it sounds

The natural response is to ask for more (see this article too) In this case more or better reporting.

It’s amazing how similar this can be in many and very different organisations.
“Get me more detailed updates!”
“Use clearer status categories!”
“Let’s have more frequent check-ins!”.

But these suggestions produce more information, waste time and have no effect on clarity.
And one of the reasons usually is because the reaction is a little late. By the time something is clearly off track, the conversation has already shifted into firefighting.

We talk a lot about visibility in our industry. The problem is that what’s typically made visible is  what’s easy to make visible, while the significant signal is buried in the detail.

When delivery teams are looking at tasks, stories, technical steps and logs, product managers are thinking in terms of features, outcomes, timelines. Sadly even when there is a system that’s supposed to tie it all together, product managers end up using something else, like a spreadsheet.

It is not just about transparency

It’s tempting to frame this as a transparency issue and sure enough sometimes it is, but also often it isn’t.

Most teams I’ve encountered are reasonably open about what they’re doing. However, being open about activity is not the same as exposing risk. Especially when it is not one of the very obvious risks.

It is possible to be very informed about work in progress but to never realise that something might be taking longer than usual or is quietly waiting on something else or just beginning to drift away from what’s typical.

That kind of signal is harder to spot, especially if you’re not looking for it directly.

There are, of course, well-established ways of understanding delivery risk. Current best practice would suggest looking at cycle time distributions, system stability and probabilistic forecasting.

The are all useful and personally I am a big fan. However, having spoken to many product managers over the last few months I now understand these tools are not always accessible.

For a product manager, trying to make sense of Monte Carlo simulations or percentile-based forecasts can feel like stepping into someone else’s domain. “And what even is system stability?” one product manager asked me.

Having good data to be able to produce forecasts or look at system stability is one thing and being able to translate it into a simple question like “Should I be concerned about this?” turns out to be very different.


How to think about it as a Product Manager

We spoke to many product managers who had varying degree of appetite to look at delivery forecasts. In all cases though they wanted it linked back to the entities they work with - features, outcomes, initiatives.

So perhaps we shouldn’t be trying to give product managers more data but rather figure out how do we give them clearer signals that sit at the level they actually work at.

For example we could highlight:

•     A feature that has been in progress longer than most others
•     A growing number of features all “in progress” at the same time
•     A team whose delivery pattern has become less consistent over recent work

They would be signals or prompts for a conversation. They would not require deep statistical understanding, but will point to something worth looking into.

If such signals are useful to Product Managers, the interesting part is that they don’t require a completely new method or even a new system.

Most Product managers we’ve spoken to already keep track of things like “when a feature starts”and “when it is delivered” and “how work is grouped at a feature or initiative level”.

If you have tracked these, then over time, that creates a useful history which would be enough to answer questions like:

•     what does “normal” look like for us?
•     when is something taking longer than usual?
•     are we starting too many things at once?

And once you have a sense of what is normal, you can start to notice what isn’t.

Knowing before you’re told

Is it realistic to know before others tell you? I think it is.
And there’s a sort of shift that happens when these signals are available.

Instead of waiting for an update (usually late) that something has slipped, you begin to see it forming and can do something about it before it’s too late.

The signals are not meant to replace conversation with your delivery teams. They give you another reason to talk and the starting point is now much earlier.

e.g. instead of asking “is everything on track?” you can now ask “this looks a bit unusual, what’s going on here?”

Implementing this in practice may not be as simple as talking about it. As is the case with many useful methods that I’ve learned, they often happen to be also difficult to use… And so adoption may not follow swiftly… unless we figure out how to make it very easy. This topic requires more research and more work.

I don’t have a good answer yet, but it’s something I’m exploring in terms of how I think about delivery and product, and in the tools I’m using.


What’s next?

In the next few posts, I’ll try to make this more concrete.

Starting with one of the simplest and most useful signals a product manager can have:

how long a feature has been in progress, and when we should start to raise questions.

And yet somehow, the thing you are actually trying to deliver never quite moves as smoothly as you wanted it to. Progress feels sporadic and slower than expected, but harder than it has to be.
Most people respond by looking for more effort, more process, or better coordination.

Growing up in Bulgaria, there was a story we learned early that explained the problem far more clearly than many modern frameworks ever have.

It’s called “Orel, Rak i Shtuka” which translates to “The Eagle, the Crab and the Pike”.
It is a rather simple fable which seems to describe organisational life remarkably well.


The Story


Three animals decide to work together. They have a cart to move, and they agree to pull it as one.
They lean in. They apply effort. They pull with intent.
But each pulls in a different direction.
The eagle pulls upwards, trying to lift the cart into the sky.
The crab moves backwards, because that is simply how crabs move.
And the pike drags towards the water, the place that makes sense to it.
None of them are lazy. None of them are refusing to help.
Each is acting according to its own nature.
And so the cart stays exactly where it is.


I only learned much later that the story itself isn’t originally Bulgarian. But that’s where I first heard it, and like most people who grow up with it, I’ve never quite forgotten it.


From Story to Organisation


The mapping is almost too obvious.

The cart is the work. The thing you are trying to deliver. The value you are trying to create.
The animals are the teams, functions, departments, and leadership groups surrounding it.
And the problem is not effort but direction and alignment.


Work only moves properly when forces align. When they don’t, effort starts cancelling itself out.

Yet most organisations respond to slow progress in a very similar way - by adding more.


More meetings.
More reporting.
More process.
More control
More escalations.
More pressure.
…


Very few stop to check whether everyone is actually pulling in the same direction. In fact some deliberately “do their own thing” as instructed by their leaders.


The Forces Inside Most Organisations

In most organisations, you can already see versions of the eagle, the crab, and the pike.
There is always a force pulling upwards, towards transformation, ambition, strategic change, growth.

Without that force, organisations stagnate.

But strategy has a tendency to drift away from operational reality. Initiatives become abstract. Ambition grows faster than the system’s ability to absorb it.

The eagle keeps pulling higher, while the rest of the organisation struggles to follow.

At the same time, there is usually another force pulling cautiously backwards.

Governance. Operational stability. Risk management. Legacy systems. Existing commitments.

This force matters too. Without it, organisations become unstable and fragile.


But its natural instinct is protection. It slows movement down. It adds checks, gates, and caution. Sometimes for good reasons. Sometimes simply because the existing system has learned to defend itself.

And then there are the delivery teams themselves, your engineers. and product teams, and maybe even operations. These are the people trying to move work through the system in the most practical way possible.

Often, here too, there is a tendency to optimise locally. Especially when leadership is fragmented, teams may focus on their own objectives, their own deadlines, and their own metrics of success.

And despite that work moves, it does not always move in a direction that helps move the cart overall.

It’s a situation in which nobody is doing anything particularly wrong individually or for specifically bad reasons. It’s just that they are not always aligned.


Why Work Stops Flowing


When you start seeing organisations through the whole system lens, many familiar problems begin to make more sense.

What makes priorities shift constantly? Why work starts but rarely finishes? Why do we have so many dependencies that slow everything down? Why are teams blaming one another? or looking to avoid being blamed?

Every team reports progress and they are always doing “a lot of good work” yet there is not much overall progress.

And because everyone goes out of their way to demonstrated that they are genuinely busy, the next assumption is that the problem must be either effort, capability, or execution discipline.
Of course there usually isn’t a measurement to support this statement.

And more often than not it’s not a fair statement to make. If someone was looking at the whole system and measuring flow that may well conclude that it’s a system design problem.

There are some simple things that are needed to help with flow.

A shared direction is rather obvious, but it is amazing how people can rationalise that into several very different directions based on leadership’s personal interpretation or other influences to priority. Establishing and maintaining shared direction is one of the crucial jobs of the top leaders in organisations and it requires dedicated continuous effort to communicate and align. Some may even say it is a full time job.


Being clear about constraints. We often forget our learning journey and assume everyone understands terms, rules and constraints the same way we do. Organisational constraints need to be clear and visible, communicated often and explained in accessible language.


Short feedback cycles is arguably the most difficult to implement of the three but it is crucial and there are many examples and frameworks to help you shorten your feedback cycles. Enabling feedback that arrives quickly enough for people to adjust before effort is wasted can be the difference maker on your improvement journey.


When an organisation struggles with these three, don’t be surprised if even highly capable teams spend enormous energy pulling against one another without realising it.


What some people often miss and what to do about it


Not us of course. This is about other people who miss things.

Perhaps you’ve witnessed this? Just like in the old fable everyone behaves rationally. Like every animal, every team is doing what makes sense from where they stand.
In a very generalised way: the leadership team pushes for innovation and change while the governance teams try to reduce risk and the delivery teams focus on optimising for execution.

On their own, all of these behaviours are sensible but altogether, they can work against one another. And adding more pressure to a system that can’t handle it, will never solve the problem.
Instead, it often makes it worse.

More pressure will not make the system adapt, it causes each part of the system to pull harder in its own direction.

And yet there are organisations that move well and they tend to have a few things in common - clear direction, visible constraints and faster feedback.

When you people understand, and ideally can see, how their work contributes to movement of the whole system, and not just their own part, they correct course and adjust to move together.

I know it sounds obvious when written down but sadly, it is surprisingly rare.


The Eagle, the Crab and the Pike


We grew up with this story as children in Bulgaria and it’s made to sounds simple so that kids understand it. At times I think it’s too simple.

But as I grow older and experience different work environments, I often find myself thinking about it when I evaluate organisations.

I rarely come across people who are unhelpful, or teams that are irrational, or effort that is fake.
And yet, the cart will not move. And the leaders will not learn.
Presumably because they already know best.

I suppose Adam Grant is right "We listen to views that make us feel good, instead of ideas that make us think hard.” (see "Think again", 2021)

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?

It’s an appealing idea but it’s also wrong.
Let me explain.

AI is speeding up the wrong (or random) part of the system

Most AI adoption today is happening at the team level. There is a reason for that. AI is technology driven and it is best understood by engineers.

Developers are using tools like Copilot or Claude to produce decent code faster, or generate tests and maybe explore different solutions.

This is very real progress and it certainly matters. But it only affects one part of the system- active work.


And active work is rarely where delivery systems spend most of their time. In fact it hasn’t been the bottleneck in the last 10-15 teams I’ve worked with.

This isn’t just my perception. It’s something DORA research has been pointing to for some time already.


Any improvements in local efficiency like faster coding, better tooling, higher individual productivity, don’t automatically translate into better system outcomes. In fact, they can make things worse if the surrounding system isn’t able to absorb the increased throughput.


The way most organisations use AI nowadays is amplifying exactly that effect. It increases the rate at which work enters the system, but it does not improve how that work flows through it.


Let’s talk about the part AI doesn’t fix

If you look at a typical Software Kanban system, you will find that most elapsed time is not spent doing coding/engineering work.


Instead we have a ton of data showing that it is spent:

•     waiting for reviews
•     waiting for decisions
•     waiting on dependencies
•     waiting for other teams
•     waiting for priorities to become clear

Or in other words, it’s spent in queues.

At present, AI can make the doing faster but it does nothing about the waiting. Some will say: it can speed up reviews? it can speed up decisions? etc. but in truth all these don’t really need AI to happen faster and use of AI does not guarantee flow will be improved.


Waiting is something we solve by measuring and optimising flow. Any new technology is exciting but here’s the uncomfortable consequence of the current most common use of AI: The faster execution becomes, the more visible and more painful the waiting becomes.


Why flow gets worse before it gets better

Imagine we have two teams that become faster thanks to AI, but there is also a third team involved in completing the work that doesn’t get faster. What happens then?


Work piles up at the slowest point. So queues grow and work ages and forecasts degrade.


From the outside, it looks like things should be improving. After all, productivity is up.

But from a flow perspective, the system has become more unbalanced and forecasts more unstable.


AI has optimised the activities that were already fast but did nothing for the bottlenecks.


Why Kanban metrics become essential


One of the things I spend a lot of time explaining is that Kanban metrics were never about measuring effort. They are about understanding flow.

And flow is exactly what AI does not manage for you.
In fact, as systems become faster and more complex, you need better signals, not fewer.


You need to know:
    •    where work is ageing
    •    where queues are forming
    •    where WIP is exceeding capacity
    •    where blockers are accumulating
    •    how throughput is changing


Without that, AI simply helps you go faster… in the wrong direction.


A practical way to see the issue


Recently, I was delighted to discover a simple exercise proposed by Prateek Singh which illustrates the point.

Take your Kanban board as it is and look at the exit criteria for each column. These are the rules that define when work can move forward.


Note: if you don’t have exit criteria go and check my Kanban metrics series now!


Looking at your exit criteria ask:

“Can AI assist with this?”


You’ll likely find that a large proportion of those criteria can be supported by existing tools or practices like code reviews, tests, static analysis, documentation, etc.


Then have a look at what remains and you will likely find things such as approvals, prioritisation decisions, dependency coordination, readiness for release or alignment across teams.


These are not technical problems but system problems. It is unlikely that you would want to use AI to solve them. But they are usually where flow slows down.


What about forecasting in the new age?


Most organisations that share their AI adoption strategies seem to be approaching it at the bottom via providing tooling for individual contributors and at the top with their enterprise AI strategy.

They rarely talk about solving specific problems via initiatives, meeting user needs via new features or making changes to enable cross-team flow.


Yes, you guessed it - this is where delivery delays actually live.

A quick reminder of what typically causes delivery problems - a certain team is overloaded or another team has different priorities or dependencies weren’t visible early enough or decisions took too long, etc.


AI does not automatically resolve these issues.

When execution gets faster, variability increases. This happens automatically because work enters the system faster which leads to queues forming quickly and bottlenecks shifting fast.


As a result traditional, estimate-based forecasting becomes even less reliable while Kanban forecasting becomes more valuable because it still reflects what is actually happening, not what was planned or estimated.


The local optimisation risk


One of the biggest dangers of AI adoption is local optimisation.
When you focus on improving developer productivity and team throughput but you don’t manage the system as a whole this results in longer queues, more ageing or blocked work and less predictable outcomes.


The DORA reports have consistently demonstrated that high-performing organisations optimise for stability and flow, i.e. reducing batch size, limiting work in progress, and improving system-level feedback loops.


AI tools, on their own, push in the opposite direction. They increase output at the edges of the system. Without flow control, that output accumulates as inventory, delay, and coordination overhead.
Feels like we’re back where we started all those years ago (sigh).


A different way to think about AI and Kanban


Instead of asking: “How can AI replace parts of our process?”

Try asking: “Where can AI support flow, and where do we still need human judgement?”


Some parts of the system will become faster, more automated and perhaps consistent while other parts will remain organisational, contextual or dependent on judgement.


Kanban signals help you distinguish between the two types.

If you’re leading delivery in an AI-enabled environment, the challenge is not adopting tools but maintaining system awareness.


When the system evolves faster than before, clear signals, are essential to keep it stable.


What about AI readiness?


A lot of current thinking about AI adoption focuses on tooling. Making sure teams have access to coding assistants, AI for testing, documentation, or analysis. Are they adopting the latest models?


From a system perspective, the introduction of AI is less about how fast work can be produced, and more about whether the system can absorb and flow that work effectively.


The DORA research consistently shows that performance is not defined by how quickly changes are made, but by how reliably they move through the system and reach users.


In that sense, AI doesn’t reduce the need for flow management because the cost of getting flow wrong increases as speed increases.


A system that cannot manage WIP, ageing, and dependencies will struggle more in an AI-enabled world.


The rest is silence


It is clear by now that AI will change how work gets done but it will not change the fundamental dynamics of how work flows through a system.


If you think that queues or dependencies will cease to exist or that you’ll never wait on decisions again it might be time to pause and reflect.


I think that these factors will matter more as execution speeds increase.
Kanban metrics are not a legacy practice that AI will replace. They are not competing with AI. They give you the signals that can help you make AI usable at the system level.

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.

Just… because we have it on the list. Tell me your organisation is not at least a little bit like this?
Pull signals are the antidote to that habit. And they are very uncomfortable for most organisations that have become used to equating motion with progress.

Why most organisations still push (even if they say they don’t)

Many teams claim to be running a “pull-based” system, but if you examine what they actually do, you discover a different story.

What you very often see is that work starts when one of these is true:

• a sprint begins
• a planning meeting ends
• a roadmap says so
• a senior person asks
• a deadline looms

None of these are pull signals. Work is pushed into the system based on time, authority, or anxiety.

And often you find that WIP limits do exist on their board, but they are routinely overridden “just this once”. And then, over time, the system stops signalling anything meaningful, and WIP limits become decorative.
Here’s a simple way to tell: If starting work does not require an explicit signal from the system, you do not have pull.



What represents a Pull signal

Just to make it clear. When a person decides or tells the team to start something, this isn’t a pull signal. A pull signal can only come from the system itself.

It is a system condition that the team has agreed to implement and when that condition flags up, it says:
“We now have capacity to finish something new.”

Most teams implement a very simple pull signal - when WIP drops below its limit.

But this isn’t the only pull signal you can implement. There are variety of signals that more mature systems might choose to implement. These include:

• WIP availability
• absence of blocked ageing work
• stable throughput
• acceptable risk levels
• manageable forecast impact

A pull signal is not about being given permission, or a direction from above or the start of an iteration. It’s mostly about the readiness of the system.


Why starting work is the most dangerous decision you make


From the perspective of flow finishing work reduces risk and starting work increases it.
This may sound simplistic but consider what are the consequences every time you start something new

1. A new work item almost certainly will lead to increase of the average age across the system
2. You add more delay to feedback on existing work and impact cognitive load
3. New work increases the risk of variability and therefore forecast reliability
4. New work can create new dependencies
5. And last but not least it dilutes focus

And yet, starting work is often treated as a win - at least we’ve started it!

Well implemented pull signals force organisations to consider the true cost of starting. It’s just a matter of paying attention to the signals.


Visible pull signals make trade-offs explicit


Which is probably the main reason they are being avoided. Push systems are attractive because they avoid hard choices.

When everything is “important”, it’s easy to accept that everything starts. The trade-offs are deferred to later, when urgency and politics take over. It’s a vicious cycle that many organisations never find a way out of.


When you use a real pull system then this logic is completely inverted.

When the system tells you there is “no capacity” then leaders are forced to answer important questions “Which work finishes first?” “Which work waits?”, “What gets dropped?”, etc.


Of course, these are uncomfortable conversations so it’s easier if we avoid them.


Using pull signals properly ensures we can’t do the avoiding part.



Teams can’t enforce pull on their own


It’s all good to talk about implementing a pull system from the bottom up, but without leaders’ support it won’t be an effective pull system.

Expecting teams to “just pull better” is not a realistic strategy because teams rarely control things like demand, priority changes, expedited work, cross team dependencies or organisation urgency.


When your leadership continues to introduce new work or expedite items regardless of system state, then your pull system collapses.
In order to have an effective pull system leadership must respect the pull signals.


This brings us to a very important point. One that brings together all previous posts in this series.


And that is because pull signals depend on all of the below:

• WIP is real and is respected
• Work item age is visible
• Blocked work is being tackled with priority
• Forecasts are trusted
• Breakdown of work is encouraged and supported

Without these, pull signals are either ignored or overridden.


With them, the system starts to regulate itself.



A proper Pull system requires patience

When organisations transitioning from push to actual pull they often experience an uncomfortable initial phase. Suddenly managers see fewer things get started and queues become visible. Then delays that were always there become more obvious and overall progress seems slower.


It’s easy to see how leadership may see this as things getting worse. But this is not a failure.

It is the mostly the same system but now it has gained the ability to tell you how overloaded it already is.


A Push system hides these signals by spreading risk and delays thinly across many items. Pull concentrates attention where it matters and thus changes where leadership needs to focus.


In a traditional push organisations it is common for leaders to spends their time chasing status, expediting work, resolving dependencies or conflicts and explaining missed commitments.


While in pull systems, their attention shifts to removing blockers, managing WIP, improving flow and making earlier trade-offs.

This leads to less drama and more focus on flow.


The problem with Expedites


You may think that expedited items are proper pull because the organisation needs them.
That’s not true for all the reasons explained earlier. Expedited items are exceptions.

They can happen since every organisation sometimes has expedited work.
But you need to treat such work as rare and an exception. Make sure the impact to other work and the cost are obvious.


If you treat expedited work as normal very soon everything becomes expedited, but in reality nothing really is.

Pull systems can tolerate exceptions but you can’t hide the impact.


Acting on system signals is a leadership responsibility


We have reached the hardest part of pull-based systems. If system signals are ignored outside of the remit of the team the pull system will not function.


Leaders must be willing to act or wait when system says so.

This will absolutely feel like loss of control which is what makes it really hard.
But when done right, it changes control from instinct to evidence.

Pull signals don’t remove the need for leadership judgement. They inform it with data.


Pull signals the end of these series and the beginning of real flow


The pull signals element of the Kanban system are at the end of this series to underpin their importance.

There cannot be faked or bolted on. They can’t be enforced with process alone.


Pull signals require all of the below:

• work item ageing is calculated and visible
• risk is discussed early
• WIP is respected
• forecasts are trusted
• leaders are willing to choose finishing over starting

When all of this is true Kanban metrics become very powerful. They are no longer reports but signals the organisation actually listens to.


Reach that point and flow is not just an aspiration but a property of the system.

And that’s when delivery leadership finally becomes calm, boring, and effective.
Sounds good, doesn’t it?

​Links to all articles in the series here

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.

When we encounter contradicting facts, that triggers cognitive dissonance, literally activating the brain’s pain centres and so prompting us to instinctively twist logic to relieve the discomfort. And because our beliefs are often tied to our identity and our "tribe" the amygdala treats a challenge to our worldview as a physical threat, casting our intellect in the role of a guard tasked with protecting our ego rather than a scientist seeking facts.

With this in mind it’s easy to see why adopting new practices is hard.
Consider a typical reaction when a feature delivery goes wrong:

“It turned out to be bigger than we thought.”

Then rationalising takes over “it was just too complicated”, “we couldn’t have possibly known beforehand”, “some work is just emergent” etc.

If you’ve followed these blog series from the start, you may sense where this is going.

Oversized work is rarely a failure of team practice. It is almost always a system and leadership failure that shows up late, expensively, and repeatedly.


Big work is the number one enemy of flow


From the perspective of flow efficiency, having large work items is the worst thing.

Here are some of the reasons. Large items:

•     age for a long time before delivering value
•     hide multiple risks inside a single commitment
•     delay customer feedback
•     impact cycle time distributions
•     make forecasting less reliable
•     amplify the impact of blockers

The importance of this is usually lost in most organisations. Rationalisation kicks in “We just have to do it!”, “We are running out of time in the market!”, etc. So organisations keep pushing big chunks of work into delivery systems and then fire people for not working hard enough.

Batch size is one of the most powerful levers in flow management. Small batches lead to better predictability, large batches… you get it.


How does it always end up with blaming the team?

Modern teams are used to conducting retrospectives and lessons learned sessions. Conscious engineers will always look for ways to improve. This leads to teams accepting that they can do better. But it doesn’t mean the problem or the blame always sits with the team.

This is convenient and often exploited by other parties. In many organisations, the ways of working and the culture have shaped people’s behaviour so that they avoid being blamed at any cost and so people will do a lot to avoid being in the mix of who’s to blame.


There is a better question to ask:

Who decided this was acceptable to start as a single item in the first place?

But this is often an inconvenient question. Teams don’t usually choose to work on oversized items. Those come from roadmaps, or because of specific funding or from dependent initiatives or from commitments made before delivery was consulted.

Blaming teams for size after the fact is easy but preventing oversized work requires earlier leadership decisions. That’s hard and rarely seen.


Work item size is truly measured by age and not estimation


One of the most useful things about Work Item Age is that it exposes oversized work in real time.


If an item is ageing well beyond the bulk of your historical cycle time, one of two things is true:
    1.    The system is blocked, or
    2.    The item is too big
Or often both.

When a large piece of work starts to drag, the most common reaction you’d come across is:

“We’ve made so much progress, we might as well finish it.”

Somewhat counter intuitively, this is sunk cost thinking, and it’s very expensive.

Large items are often not one thing. They are multiple valuable pieces bundled together.
If we treating them as one we will see

•     longer delays before any value is realised
•     higher risk of total failure
•     fewer opportunities to learn and adjust

Often people oppose breaking up work after it has started. From flow perspective this is not a problem and not a failure. In fact, it is often the most responsible thing you can do.

Looking to protect flow? Try work item breakdown


The sentiment you typically get in organisations is that breakdown of work is not worth the effort. However this is a reframing that is well worth going for.

Some people seem to see the breaking down of work items as just a planning or refinement hygiene exercise. But what it actually does is much more important and that makes it a flow protection mechanism.

Breaking work down is very useful because it simultaneously reduces work item aging and the risk associated with work. It helps reduce forecast variance therefore making your forecasts more stable and it has a significant impact on dependency reduction which is often the main reason for delays.

And one more thing that is often overlooked. Breaking down work creates smaller work items, and that in turn creates more frequent opportunities to stop doing the wrong thing.

Why work breakdown must be enabled (even if it seems trivial at first)


It is not uncommon for teams to be aware that work is too big. And to clarify, this usually is not a team level work item that is too big. That can be an issue for flow too , but the problem is typically one level above at the feature/portfolio stage.

Teams often lack is permission to split at that level. (And they need to have it)

Why? Because breaking work down at that level requires one or more of:

• renegotiating scope with stakeholders
• changing commitments already communicated
• challenging pretty roadmap
• delivering partial value instead of “the full thing”

Breaking down work at this level requires leadership to make that option available.

If leaders punish scope change but demand predictability, teams have no other option but to keep pushing the big item forward and hope.

But you do know that hope is not a strategy, right?

If you are bought into the benefits of work breakdown then consider acting before work starts.

This is where pull-based systems and breakdown support intersect.

Some questions you can ask to help you break down at the feature level before works starts

• “What is the smallest valuable thing we could deliver?”
• “What happens if we delay the rest?”
• “Which part carries the most risk?”
• “What would give us feedback sooner?”

To ask this questions, teams need to be able to challenge roadmaps, amend commitments and re-negotiate. These are not technical questions and they can only happen with leadership support.



Why is work often too big?


You can do you own root cause analysis and sure your context can be somewhat different. But there are some common themes like

1. funding models reward big batches
2. governance structures prefer projects over outcomes
3. planning cycles that seek long term commitment
4. fear of incremental delivery
5. lack of trust in teams and customers

Breaking work down exposes these tensions. That’s why it’s resisted.

But avoiding the tension doesn’t remove the cost, it just delays it and often multiplies it.

If your team thinks that everything Is “Too Big to Split”, then perhaps your thinking is too narrow.

Have you heard of “This can’t be broken down.”? While this is common, it’s rarely true.


You can dig deeper and uncover the actual reason, e.g.
“We’ve defined value too narrowly”
or “We’re optimising for internal milestones”
or “We’re afraid to release partial outcomes”
or “We don’t want to renegotiate expectations”


From a flow perspective, value can often be delivered in thinner slices than organisations are comfortable admitting.
Work item breakdown is about learning faster
The real pay off of breaking work down is the good old fast feedback loop.

When your work item are smaller then you validate assumptions sooner and reduce the cost of being wrong. Also risks become obvious earlier and you have time to change course.

In uncertain environments, learning speed matters more than delivery speed. Do you think your environment is certain? Perhaps think again!

A simple rule you can apply: If an item is ageing past where most work finishes, ask:


“What would it look like to split this right now?”

If you never ask, big work items will keep sabotaging your system.


One final thought

Some work really needs to be large. That’s fine.
But it should be rare and explicit and acknowledged as risky

If you always have big work items, you are not managing flow, you are just gambling with it.


In the final post of the series, we’ll look at Pull Signals, and how letting the system tell you when to start work is the final step in moving from activity management to true flow-based leadership.

​Links to all articles in the series here

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.

But for one reason or another, they were missed.

Ageing risk highlights exist to close that gap between what you could have known and when you chose to act.

Why delivery issues feel unexpected

Organisations often describe missed delivery as unexpected. How many times have we heard “It came out of nowhere” or “Everything seemed fine until last week” or “It was only a low risk”

But such claims are unhelpful and the issues are rarely unexpected.

What actually happened is that the important signals were ignored, the work was ageing quietly, and there was no meaningful response. Because nothing was technically “late” yet, nobody felt they should take action.

Ageing risk is how issues announce themselves early.


Work Item Age on its own is insufficient

If you’ve read this entire series (or meaningful Kanban literature) you would know that by now we’ve established that Work Item Age is the most important real-time flow metric. But Age on its own only tells you how long something has been in progress.


It doesn’t contain information about what’s normal, or how much risk it carries or what the impact would be. To make such judgement we need more context.

And this is where ageing risk highlights come in.


Risk is always relative

If a work item has been in progress for 12 days, this might be perfectly healthy in one system and very alarming in another.

The age of work becomes meaningful only when compared to historical cycle time, relevant percentile thresholds and your Service Level Expectation (SLE).

So risk is only relevant in your current context e.g. “relative to what normally happens here”.

Ageing risk highlights make that comparison explicit.


How to turn work item age into a signal

Historical cycle time distributions give us a powerful way to interpret work item age.

Here’s how to read it. When an item reaches:

•     the 50th percentile, it is already older than half of your completed work
•     the 70th percentile, it is older than most work you’ve ever delivered
•     the 85th percentile, it is approaching your SLE boundary

Each of these thresholds represents a change in risk, an important signal.

Ageing risk highlights use these thresholds as intervention triggers, not judgement points.


Why waiting until work hits the SLE is too late


Many teams only pay attention to a work item once it breaches its SLE.

That’s like only reacting when the smoke alarm goes off.

By the time an item crosses the SLE threshold one or more of these becomes true

•     you have limited options available
•     there is a lot of attention so urgency has increased
•     the attention makes decisions emotional
•     anything you consider has political impact

The goal of ageing risk highlights is to create conversations at the right time, when options are available and calm action is possible.


What are silent blockers


The problem with blockers is that often, most of the wasted time is because we didn’t know they are blockers. Let’s call them silent blockers.

They are silent blockers when

•     work appears active but isn’t progressing
•     items that get a bit of attention occasionally makes them appear “in flight”
•     tasks that nobody wants to admit are stuck

Making a decision if something is a blocker isn’t always easy. However the impact of delay adds up and eventually creates an issue.

When visualised and used properly, age is often the only thing that could expose these items.

If Age is increasing and nothing else is changing, it’s time to pause and investigate.


Teams rarely escalate ageing work


Teams usually know when something is getting risky. They just don’t shout about it.

There could be many reasons. Here are a few I can think of:

•     Because nothing is really “late”
•     Because escalation is seen as failure in their organisation
•     Because there is a conflict of priorities that nobody talks about
•     Because they think they don’t have the authority to change the situation

This is where ageing risk highlights can be helpful. This simple chart shifts escalation from personal judgement to system signal

The conversation changes and the concerns above are less valid. It’s no longer

“We think there is a problem”, it becomes “Our data says this item is now high risk”

This may be subtle but is very powerful.


How to use Ageing Risk Highlights


Ageing risk highlights are there to visualise a signal. This signal should trigger a discussion of options.

Here are some examples of what these options might be:

•     swarming or pairing to solve a problem or remove a bottleneck
•     removing or renegotiating scope
•     escalating a blocking dependency
•     deprioritising other work to free capacity
•     breaking the item into smaller deliverables

When you don’t visualise the signal, the perception might be that your team doesn’t work hard enough.


Your leaders must learn to pay attention earlier


When you manage work on a Gantt chart, it’s difficult to see when something has doubled its risk. And so you spot the problems when it’s too late - e.g. a date was missed, someone complained or another team escalated a dependency.

Ageing risk highlights brings a timely signal to leadership’s attention.
The time of your reaction has a direct influence on the cost of delay.


How about if the signal is too frequent?


This would point to a system problem. Some things to check: too much WIP? large work items? dependencies discovered too late? unclear decision policies? too many approval steps?

Ageing risk highlights expose such patterns quickly so make sure you don’t ignore the signal.



When Kanban stops being just about the team


It’s tempting to think of Kanban metrics as team level tools and many teams do just that.

But when you use ageing risk highlights well you begin to realise that you are breaking the team boundary.

When responding to ageing risk you often need to reprioritise, or change scope, or cross team collaboration or senior leadership decisions. All of these have scope to go beyond one team.

This highlights the important role of leadership and the value they need to add in order to help the system function well.


The consequences of not acting on the aging risks
When ageing risk is NOT visible
work ages quietly, forecasts become unstable, urgency arrives suddenly, blame replaces learning

When ageing risk is visible
conversations happen earlier, options remain open longer, trust improves, delivery becomes calmer and more predictable


The difference between the first and second is attention, not effort.


Ageing Risk Highlights turn metrics into management


Still not convinced? Have you ever tried it?


Ageing risk highlights transform your flow data into a management system.


They create a signal for you to follow, before your delivery starts flagging red.

If you have a Kanban system that tracks work item age but but then you don’t do anything with it then you are collecting evidence and choosing not to act on it.
​

In the next post, we’ll look at Work Item Breakdown Support, and why oversized work is not a team skill issue, but a leadership responsibility disguised as planning.

​​Links to all articles in the series here

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.

​When the estimates inevitably turn out to be wrong, we treat that as a failure of execution rather than what it is: a failure of thinking.

Kanban acknowledges the probabilistic nature of our work and takes a fundamentally different approach to forecasting. It does not try to pretend we can have complete certainty. It accepts uncertainty and then manages it explicitly.

Why deterministic deadlines keep letting you down

Traditional delivery forecasting assumes that if you plan hard enough, break work down far enough, and monitor closely enough, outcomes will become predictable.

That assumption simply does not hold in knowledge work.

Software, product development, change initiatives, and most modern delivery contexts are full of:

•     hidden complexity
•     unknown dependencies
•     learning that cannot happen up front
•     interruptions that cannot be scheduled
•     variability in work size that never fully disappears

Estimates attempt to compress all of that into a single number. Forecasts built on estimates inherit all of that optimism and then amplify it into pure fantasy.

This is why organisations end up with detailed plans that are consistently wrong in exactly the same direction.

The main kanban insight about forecasting

Kanban starts from a much less flattering but far more useful premise:

Nothing is as predictable as you want it to be.

Instead of asking “How long will this take?”, in Kanban, we ask:

“How long has similar work actually taken in the past?”

This is not about mistrusting teams. It is about trusting actual data over intention.

Historical delivery data already contains:

•     the real world impact of dependencies
•     the cost of waiting
•     the effect of interruptions
•     the consequences of starting too much work
•     the variability you keep pretending isn’t there

Ignoring that data in favour of fresh guesses is simply wasteful.

Cycle time is the raw material of forecasting

All Kanban forecasting relies on historical cycle time data.

Cycle time measures how long work took from start to finish, as defined by your workflow. Very import to note that, we capture elapsed time, not effort.

Elapsed time then includes:

•     waiting
•     reviews
•     queues
•     rework
•     handoffs
•     external delays

In other words, it reflects the entire system, not just the team.

If your cycle time data is clean and your workflow definition is honest and transparent, you already have everything you need to forecast. No estimation workshops required.

Why Monte Carlo forecasting is a big deal (even if you never say the name)

Monte Carlo forecasting often sounds intimidating, but the underlying idea is actually quite simple.

Instead of producing a single answer (e.g. a date), it produces a range of possible outcomes based on real historical behaviour.

It asks questions like:

•     “If we complete work at roughly the same rate as before, what might happen?”
•     “What’s the likelihood of finishing by a given date?”
•     “How much risk increases if we start more work?”

The output is not a deadline, a commitment or a promise. It is a probability distribution.

This is a major shift for most leaders, because it reframes delivery conversations away from certainty and towards risk.

Why leaders struggle with probabilistic forecasts

Many managers or delivery leaders are uncomfortable with probabilistic forecasts because they don’t provide a single answer.

That discomfort tells a story.

What people often want is not accuracy but reassurance. As such a date feels reassuring, even when it’s wrong while a probability feels vague, even when it’s honest.

But delivery leadership is not about reassurance. It’s about making informed trade-offs under uncertainty to navigate towards the goal.

Probabilistic forecasts make those trade-offs transparent. And that’s often uncomfortable.

Forecasting as a decision support tool

One of the most damaging and irrational habits organisations have is treating forecasts as commitments that must be met at any cost.

Once a date is spoken out loud:

•     scope gets bent to protect it
•     risk gets hidden
•     teams get pressured
•     reality gets negotiated

Kanban forecasting is designed to do the exact opposite.

Forecasts exist to inform decisions such as:

•     Should we start this now or wait?
•     What happens if we delay something else?
•     How much certainty do we need before starting?
•     What risk are we knowingly accepting?

If a forecast cannot change a decision, then it’s purely academic.

Why forecasting without WIP control is meaningless

Here’s the part many organisations miss.

Forecasting assumes some level of system stability. If you continuously change priorities, inject new work, and overload the system, then the work variability rate goes through the roof and your historical data quickly becomes irrelevant.

This is why Kanban insists on WIP control.

Without WIP control:

•     throughput fluctuates wildly
•     cycle time distributions degrade
•     forecasts become meaningless
•     risk compounds invisibly

Forecasting requires discipline and that’s a common failure for many teams.

If leaders want better forecasts, they must first stop starting more work than the system can handle.

What good forecasts reveal (that gantt charts hide)

Used properly, historical forecasting reveals things that planning meetings never do:

•     how sensitive delivery is to extra WIP
•     how quickly risk escalates when work ages
•     how much variability really exists
•     how fragile “stretch goals” actually are

These insights are often uncomfortable. They challenge assumptions about capacity, productivity, and urgency.

That discomfort is a feature, not a flaw.

Confidence is cheap, evidence is rare

Many organisations confuse confidence with competence.

Confident forecasts feel decisive. Evidence-based forecasts feel tentative. But only one of them improves predictability over time.

Kanban does not promise certainty. It offers something far more useful: situational awareness.

It allows leaders to say:

•     “Here’s what the data suggests”
•     “Here’s the risk we’re taking”
•     “Here are the options available to us”

That is what responsible delivery leadership looks like, even if it feels tentative.

If your forecast never changes, it was never useful

Here is a simple test for your forecast.

A good forecast should evolve as:

•     WIP changes
•     throughput changes
•     work ages
•     conditions shift

If your forecast is fixed, unchallenged, and rarely revisited, then it’s unlikely to be helping with decisions. Perhaps it’s defending your initial estimate?

Kanban forecasting replaces any deterministic narrative with evidence.

In the next post, we’ll look at Ageing Risk Highlights, and how combining age, percentiles, and SLEs helps you spot “silent blockers” before they turn into visible failures.

​​Links to all articles in the series here

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.

Blocked work is flow’s worst enemy. It needs focused effort, but instead it is usually being ignored.


Blocked work is still WIP

This often confuses people, including initially myself. But, work typically becomes blocked after a work item is picked up to progress. Rarely we know about the block before we make a start. And if the work has started then it is consuming capacity whether anyone is touching it or not.
Yes, it would be easy to shift it aside and make space for another WIP slot, but that would remove the urgency to resolve it and blocked items will keep on aging.
Therefore blocked work occupies a WIP slot and with that affects, mental bandwidth, dependency attention, and forecasting confidence.
Treating blocked items as "paused" rather than actively harmful is how organisations end up with boards full of ageing work and no clear sense of why nothing finishes.
Blocked work doesn't stop costing you just because no one is coding. It might be counter-intuitive but unblocking work is your best shot at improving flow.


The problem with under-visualising blockers

Blocked items are often marked with a tiny icon, a comment field, a linked blocking work item, or a vague note like “waiting". Worse, often, they are sent to separate status column which makes them easy to ignore.
Sadly this defeats the purpose of visualisation and instead is more akin to concealment.
If someone can glance at your board and they are not able to immediately see how many items are blocked, where they are blocked, and how long they've been blocked, then blockers are not really being managed. It’s more like they are being tolerated.


Blockers as signals, not problems

There is a rather damaging delivery myth doing the rounds - that blockers are team-level issues.
It is not useful to see them as a team level issue.
Blocked work usually points to one or more of dependency mismanagement, unclear decision authority, missing policies, overloaded reviewers, external team bottlenecks, or priority conflicts created at a level above the team.
Teams can report blockers. But in reality, they cannot resolve most of them without leadership action.
When blocked items age that’s rarely an indication that the team isn't trying hard enough. It's usually because the system isn't designed to unblock itself.


Aging blocked work leads to compounding risk

Blocked items are a problem on their own but when left to age, things get much worse. Stay with me, I am not being over-dramatic.
When work is blocked, its age continues to increase which increases the risk to SLE, followed by reduced forecast reliability, and an impact to downstream work queues.
And when blocked work sits untouched and people forget that it exists until it becomes urgent, you end up with escalations, more pressure to deliver and that in turn increases variation and leads to unstable forecasts.
This is how "surprises" happen. The signal was there all along, but nobody was paying attention.


"Waiting" is not neutral

Many delivery workflows include a column that might be called "Waiting" or "On Hold”. I’ve witnessed work items sit in such columns for months, no real focus on unblocking them.
These on-hold work items are not harmless.
Waiting work delays customer feedback, inflates cycle time, increases coordination cost, and distorts throughput data.
If waiting items were harmless, flow wouldn't matter.
The longer something waits, the harder it is to restart quickly. Flow is affected because context evaporates and assumptions age, people move on to new work. Waiting is far from neutral, it is dangerous.


How to visualise blocked work effectively

Blocked work should be “in your face” and impossible to ignore.
There are three elements to doing this effectively

• Visually distinct from normal WIP so it is immediately obvious
• Clearly specified reason for the block
• Displaying elapsed blocked time

A good blocked signal should prompt the question "why is this still blocked?" — not "oh yeah, we know why that one’s waiting."
If a blocked item doesn't generate discomfort then the signal is too weak.


The case of too many blockers

When a system experiences frequent blockers it’s likely because it is too fragile.
Blockers indicate one or more of

• work is being started before prerequisites are met
• dependencies are discovered too late
• policies are implicit rather than explicit
• WIP limits are being bypassed in spirit.

These are difficult to fix that with better execution. But they can be fixed by changing when work is allowed to start and who is accountable for removing obstacles.
Blocked work is a signal. Starting work too early is usually the problem.


Leaders must act faster than teams can

Blocked items expose one of the most important asymmetries in delivery systems: teams feel the pain immediately, leaders often feel it only when something explodes.
By the time escalation reaches management, the work is usually already old, risky, and politically charged.
Visualising blocked work early allows leadership to intervene before urgency replaces reason. That is not micromanagement. It is system stewardship.


If blocked items don't trigger action, you may want to stop and reflect

You can do a simple test.
When an item becomes blocked take note:

• Does something change?
• Does someone intervene?
• Does priority shift?
• Does capacity get reallocated?

If the answer to these questions is "no", then blocked item visualisation is not doing its job.
Perhaps it’s time to stop and reflect.


Managing blocked work is where improvement starts

In the spirit of some of the lessons from the book “A beautiful constraint” (by Adam Morgan and Mark Barden) , blocked items can be turned into an advantage.  They could become a great source of improvement data you already have.
Blocked items history can tell you where policies are missing, where decisions have been slow, where coordination fails, and where WIP limits are not adding value.
All you need to do is to learn from that data and avoid repeating the same mistakes.


​A Blocked item should say "Act Now", and not "check back later"

Kanban is explicit about actively managing work in progress. Blocked work is the most significant indication that active management is required.
If blocked items are ageing and nothing is happening, then I am afraid you are not managing flow, you are just watching it slow down.
​
In the next post, we'll move into Forecasting with Historical Data, and why replacing confident guesses with probabilistic forecasts is one of the most powerful, even if uncomfortable, shifts delivery leaders can make.

​​Links to all articles in the series here

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?

In the software and management consulting world, the primary product is advice. But nowadays, that advice is being increasingly packaged by LLMs. While AI is an incredible accelerator, the "pure" AI output often lacks the grit, the nuance, and the specific horror experience that a human consultant brings to a project.

If you’re reviewing a proposal, a technical audit, or a strategy piece, this post might be helpful.
I’ve worked with three different AIs to create the 10 tips below. Using them in combination may help you understand if the content you are reading is generated by an AI and perhaps not reviewed by a human.

1. The "Tapestry & Delve” language
Although this will likely change over time, it seems like the AI models currently have "favourite" words that they use with statistical frequency.

• How to tell: Watch for words like tapestry, delve, orchestrate, seamless, robust, and transformative.
• The reality: Real consultants use simpler, more functional language e.g. they don't "delve into the tapestry of digital transformation"; they "review the legacy API documentation."

2. The "Rule of Three" structure
AI is trained on "balanced" writing. It loves to group benefits or features into sets of three.

• How to tell: "Our approach ensures scalability, security, and efficiency."
• The Signal: If nearly every bulleted list or concluding sentence has exactly three rhythmic parts, it’s probably a machine seeking symmetry.

3. The "Moralising" conclusion
AI models are programmed to be helpful and optimistic. They almost always end an article or a post by zooming out to a "grand vision" of the future.

• How to tell: Phrases like, "Ultimately, by embracing [X], organisations can not only survive but thrive in the ever-evolving digital landscape"
• The human approach: A real consultant’s conclusion is usually a call to action or a warning about a specific risk, not a generic conclusion about the "digital era"

4. Absence of failure or stories
AI can explain how a system works, but it struggles to describe how it fails in the real world.

• How to tell: The writing is "clean." It lacks mentions of specific, messy human experiences, like for example that one time RabbitMQ wouldn’t start because someone rotated a certificate without telling anyone else.
• The test: If the article contains no "uncomfortably specific" examples, it’s likely synthetic.

5. The "It’s Not Just X, It’s Y" Pivot
This is a specific rhetorical phrase that I find the easiest to spot right now. I am told AI models use it to sound profound.

• How to tell: "It’s not just about writing code; it’s about crafting solutions."
• The signal: This pseudo-sophistication is a classic AI shortcut for creating a transition without having to provide a real, data-backed insight.

6. Perfect Paragraph Symmetry
Look at the article from a distance. Do all the paragraphs look to be about the same length?

• How to tell: AI generates "blocks" of text that are visually consistent (usually 5 or 6 lines).
• The human approach: Human writing is not as consistent. We write a long, complicated explanation which may then be followed by a short, punchy sentence. Like this.

7. Over-reliance on "Moreover" and "Furthermore"
While these are used in a grammatically correct way, statistically they are used a lot more by the machine than by a typical human.

• How to tell: A high frequency of formal transitions (Moreover, Consequently, Additionally, In addition).
• How humans write today: In 2026, professional B2B writing has moved toward a more direct, "TL;DR" style. Heavy use of academic transitions is a sign of an LLM trying to "glue" ideas together.

8. The "Voice of God" perspective
AI bots speak from a position of total certainty and universal truth. That is unless you point out a mistake and then they are forced to issue an apology.

• How to tell: A lack of "I," "We," or "In my experience."
• The signal: If the article states, for example, that "AI-first workflows are the only path to ROI" as a definitive fact rather than a debated strategy, it’s a model hallucinating consensus.

9. Predictable Analogies
AI offers analogies that are either too basic or too obvious. I guess on the flip side they are safe metaphors.

• How to tell: Watch out for obvious analogies e.g. comparing management to a "chess match," a "symphony," or a "journey."
• What a human might do: A human consultant might compare a messy legacy migration to "trying to change the tires on a car while it’s doing 70mph on the M1." In contrast it’s specific, localised, and non-standard.

10. The "Non-Existent" reference
In professional services, and perhaps in any respected field, we cite reports (Gartner, McKinsey, etc) or reputable publications. But the AI bot doesn’t seem to need to do that.

• How to tell: The AI might cite a "2025 study on software agility" that sounds plausible but doesn't actually exist, or it might attribute a real quote to the wrong person.
• What to do: Always check the specific "Year/Report" name. If it’s slightly off (e.g., "Google's Global Innovation Pulse"), then it’s probably just a synthetic hallucination.

Why it matters
In a world where anyone can generate a 2,000+ word article in 10 seconds, the value of originality has never been higher. If your content looks like it meets some of the criteria in the list above, then your clients will subconsciously (or perhaps even consciously) know it, and assume you are taking shortcuts with your other work too.
​
What should you do instead? Sure, use AI to draft, but then "break" the machine's patterns. Read, change the language so you can be proud of it, then read again. Add your own 3 AM stories, use a real world metaphor, and please, please, delete the word "tapestry."

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 organisations claim to be "data-driven" while collecting flow metrics from a workflow that bears only a passing resemblance to how work actually gets done. Then they act surprised when the numbers don't line up with reality.
When Kanban metrics fail, they don’t fail because the maths is hard but because the workflow is wrong.


Workflow definition comes before metrics

Kanban starts with a deceptively simple question: when does work start, and when is it finished?
If you can't answer that clearly, everything downstream becomes ambiguous.
Cycle time? From when, exactly? Age? Based on which state, what start date? WIP? Counting what, and where? Throughput? Finished by whose definition?
When teams argue endlessly about metrics, it's almost always because they skipped this step or started with something they thought is “good enough”.


Generic workflows hide everything inconvenient
To Do / Doing / Done is easy and it sure has its use but probably not in your complex context.
When the work requires a team or a few to be fully complete, it collapses waiting, rework, dependency delays, handoffs, review queues, and approval lag into a single comforting blur called "Doing".
From a flow perspective, that's catastrophic. You can't manage what you can't see, and you can't see anything meaningful when half of your process is hidden behind a single column.
I hear some say “but it’s miles better than what we had before” - sure, get some credit for the improvement but don’t stop there!


Your metrics are only as honest as your workflow

If your workflow definition is wrong, your metrics will faithfully report the wrong thing.
Cycle time might look fine because review delays aren't counted. Age might appear low because "started" is defined conveniently late. WIP might look controlled because queues don’t show on your board.
It’s easy to blame it on the organisational constraints, ancient processes and slow change. But when you design the workflow and if you hid waiting, dependencies, handoffs, etc then it’s doing exactly what you told it to do.


"Our process is too complex to visualise"

Ever heard this one? (also did you mean complicated?)
And no, it is not.
What you mean is: visualising it would be politically inconvenient, would expose uncomfortable truths, or would challenge existing accountability structures.
Most processes are not simple. Kanban doesn't require simplicity, it requires honesty.
A workflow definition isn't a documentation exercise. It's a declaration of how value actually flows, and it requires complete visibility of everything.


Start and finish are policy decisions

One of the most common workflow mistakes is treating "start" and "finish" as obvious.
But they often aren’t.
Does work start when it's requested? Or when someone picks it up? Or when analysis starts? Or when it's "ready for development"?
And then when is it finished? Code complete? Deployed? In production? Used by a customer? Paid for?
These are not semantic debates. They are policy choices that directly affect predictability and risk. If leadership hasn't explicitly agreed on these, metrics become political weapons instead of decision aids.


Most elapsed time is spent waiting

Another misleading signals some workflows tell is pretending work is always being worked on. That happens when your Doing state incorporates multiple activities and the handoffs between them.
The reality is that most time is spent waiting. Waiting for reviews, for decisions, for other teams, for clarification, for environments, for approvals, etc.
If your workflow doesn't make waiting visible, work item age will rise and no one will know why. What’s worse, people will blame it on execution instead of workflow design.


Custom doesn't mean complicated

A custom workflow doesn’t mean an inconveniently large number of steps.
The goal is not to model every micro-step, but to make flow-relevant delays explicit so that it reveals queues, highlights handoffs, exposes policy boundaries, and makes blocked states unambiguous.
Here is a simple test: if adding a column wouldn't change any conversation, you probably don't need it however if not having a column hides a recurring issue, then you definitely do.


Why leaders should care

The work teams produce lives inside workflows. Leaders can help design or influence the conditions around the workflow.
If the workflow hides decision delays, obscures dependency risk, or masks approval bottlenecks, that means leadership will repeatedly get the signals too late and may interfere in the wrong place or in the wrong way.
Better workflows shift conversations from "why is the work late?" to "why is work waiting here too often?”. The early signal makes all the difference. And that’s the difference between managing people and managing systems.


More metrics won't fix a bad workflow

This is what many organisations don’t get.
They try to compensate for poor workflow definition with more metrics, more charts, more dashboards, more reporting. All that does is waste effort and perhaps worse, increase confidence in bad data.
If your workflow doesn't reflect reality, improving metrics sophistication just helps you delay important decisions until it’s too late.


If your workflow hasn't changed, neither has your thinking

There is a signal sign worth mentioning.
If you struggle with delays, missed forecasts, escalated risks and your teams are frustrated then have a look at your workflow. Has it changed to try and improve the struggles?.
Kanban workflows are not meant to be static. They must evolve as understanding improves. If they don't, it usually means people stopped asking the difficult questions.
Don’t get me wrong, I know many organisations that avoid asking difficult questions and have been running like that for years. But is that what you signed up for? Is that the best you want to achieve?


Treat your workflow as a hypothesis

A workflow definition is not something you get perfect at the first guess. It's a hypothesis about how value flows.
Metrics exist to test that hypothesis. If the data doesn't match reality, don't argue with the data. Fix the workflow.

In the next post, we'll look at Blocked Item Visualisation and why treating blocked work as a footnote instead of a signal for action is one of the fastest ways to destroy flow without noticing.

​​Links to all articles in the series here

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.

In recent years it has become easy to create dashboards. They are everywhere, beautiful colours, impressive charts, etc. And yet, despite all this “visibility”, the same problems keep repeating: work gets stuck, forecasts fail, and escalations become the norm.

That’s because most dashboards are not built to support action. They are built to make someone look good.


Dashboards don’t improve flow


They can be pretty and easy to put together.

But a dashboard will not improve delivery on its own.

Instead, what improves delivery is:
    •    noticing issues early,
    •    agreeing it matters,
    •    and doing something different as a result.

If your dashboard doesn’t change behaviour, then it is decorative.

Worse, it can create the illusion of control while actively preventing intervention. People assume that because something is “being tracked”, it is also being managed. But often, it isn’t.


The most common dashboard failure mode


Most status dashboards answer the wrong question.

They answer: “How are we doing?”

What delivery leaders actually need answered is:

“Where should I be paying attention right now?”

That difference makes all the difference.

A dashboard that summarises last month’s averages is useful for looking back. It is nearly useless for managing work in progress.


Why organisations love charts that don’t hurt


There’s a reason dashboards gravitate toward:
    •    average cycle time
    •    throughput trends
    •    cumulative flow diagrams
    •    historical distributions

These charts are safe because

• They don’t point at specific items.
• They don’t force uncomfortable conversations.
• They don’t require immediate decisions.

And also, they don’t stop things going wrong.


What a flow dashboard is actually for


A proper flow metrics dashboard exists to support “right action, right time”, not reporting.

That means it must:
    •    surface current risk
    •    make delays obvious
    •    highlight where flow is breaking down
    •    invite action rather than explanation

This is why we (kanban practitioners) insists on a small, specific set of flow metrics. Not because they’re academically pure, but because they’re operationally useful.


The four metrics that matter (and why)


A flow dashboard should be anchored around four measures:
    •    Work Item Age – What is at risk now
    •    Cycle Time – What “normal” looks like
    •    WIP – How much has been started
    •    Throughput – How much actually finishes

Everything else is secondary.

These four metrics exist because together they allow you to reason about flow in real time.
Not when it’s already too late.


Why CFDs are so often misused
​

Cumulative Flow Diagrams deserve a special mention, because they are widely misunderstood.

CFDs are excellent for:
    •    spotting long-term stability issues
    •    identifying structural bottlenecks
    •    analysing systemic change over time

They are not so excellent for:
    •    managing individual items
    •    spotting immediate delivery risk
    •    deciding what to do today


And yet, many teams stare at CFDs during daily discussions, hoping insight will magically emerge.

Actually that’s a little unfair. There are other teams that don’t even stare at CFDs or anything else remotely useful.

However CFDs explain why things happened. They don’t tell you what to fix right now.


Dashboards should point


A good flow dashboard should feel slightly uncomfortable.

It should make it obvious that:
    •    certain items are ageing too long
    •    WIP is crowding a part of the workflow
    •    forecasts are becoming less reliable
    •    blocked work is being tolerated

If someone can look at your dashboard and say “interesting” without feeling any urgency, then your dashboard is not doing a good job.


When Everything Is Green, that means your thresholds are wrong

Another common anti-pattern: dashboards that never show problems. When I say dashboard I also include manually created reports. I’ve worked with many managers who always make the reports look nice and not showing any issues.
If nothing ever looks risky, then one of three things is true:
    1.    You are genuinely perfect (unlikely)
    2.    Your thresholds are meaningless
    3.    You’ve designed the dashboard to avoid discomfort
Flow metrics only work when they create tension between what is happening and what you want to happen.

When there is no tension, there is no improvement.


Dashboards are for leaders


Teams should use flow metrics to manage work.
Leaders should use flow metrics to manage decisions.

A delivery leader should be able to look at a dashboard and immediately see:
    •    where intervention is needed
    •    which risks require escalation
    •    what trade-offs are becoming unavoidable

If your dashboard does not make these signals obvious then it must be improved before it can be useful..


The real test of a flow dashboard

Here’s the simplest test you can try.


After your next dashboard review, ask the following question

“What decision did we make today, that were different because of what our dashboard is showing?”

If the answer is “none”, then your dashboard needs improvement. It might be well-intentioned, beautifully presented, etc. but it may not be as useful as it can be.


Visibility is only valuable when it enables action


Kanban is not about transparency for transparency’s own sake. It’s about enabling better decisions earlier, with fewer surprises and time and space to correct flow.

Flow dashboards exist to reduce the time between signal and response.

In the next post, I’ll look at Custom Workflow Definitions, and why inaccurate workflows quietly invalidate every metric you collect, regardless of how good your dashboard looks.

​​Links to all articles in the series here

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.

On paper, everyone agrees with it. In reality, most delivery systems are still push systems with a thin Kanban layer. Work gets started because it’s “important”, because someone senior asked, because a plan said so, or because the backlog looked scary. The fact that the system is already overloaded is treated as an inconvenience rather than a constraint.

And then we wonder why nothing finishes.

The core misunderstanding about WIP

Most teams think WIP limits exist to improve productivity.

False.

WIP limits exist to control risk.

Every item you start is a commitment to:
    •    Delay feedback on everything else
    •    Increase average cycle time
    •    Increase ageing across the system
    •    Reduce predictability
Starting work is not neutral. It has a cost. A very real one. Sadly, most people don’t get this.

Pull-based WIP control is simply the discipline of acknowledging the cost before you pay it.

Push systems feel fast

Push systems optimise for the illusion of progress:

• •     More things “in flight”
  •     More people “busy”
  •     More starts per week
  •     More status updates
  • Thinking we started it (therefore it should finish)

Push systems look healthy right up until they aren’t.
What actually happens is predictable:

•     Items wait in hidden queues
•     Dependencies multiply
•     Context switching explodes
•     Work ages silently
•     Delivery dates slip all at once

If you read this and get it, join the club - let’s be frustrated together!
This is not bad execution. It’s basic flow physics.

Pull is a decision rule, not a board feature
A system is not pull-based because it has WIP limits written on a board.

It is pull-based only if this rule is actually followed:

New work starts only when there is capacity to finish it.

That means:

•     Not when someone asks
•     Not when a sprint ends
•     Not when a plan says so
•     Not because “we’ll figure it out later”
•     Not because an engineer thinks he can do one more task while waiting for the build

If starting work does not require an explicit signal from the system, you don’t have pull, you have hope.


Why “Just This Once” destroys flow

Almost every team has exceptions:

•     “This one is urgent”
•     “This one is small”
•     “This one won’t really count”
•     “We’ll make it up later”

Individually, each exception feels reasonable. Collectively, they are catastrophic.

Exceptions accumulate silently as additional WIP. Age increases. Cycle time stretches. Forecasts degrade. And because nothing broke immediately, the system keeps lying to you.

Pull systems only work when exceptions are rare, explicit, and painful.

If breaking WIP limits is easy, your limits are decorative.



WIP control is about when you say no

This is where delivery leadership gets uncomfortable.

Pull-based WIP control forces you to answer questions you’ve been deferring:

•     What actually matters most?
•     What can wait?
•     What are we willing to delay?
•     What trade-offs are we prepared to make?

Push systems avoid these questions by starting everything and hoping reality sorts it out later.

Reality always does. It just charges interest.


Why is this happening

When WIP control fails, it’s rarely because teams don’t understand it.

It fails because:

•     Priorities change without removing existing work
•     Managers inject new work without removing old commitments
•     Capacity is assumed rather than measured
•     Expedites bypass the system entirely

From the team’s perspective, pull is impossible if leadership keeps pushing.

You cannot ask teams to manage flow while constantly overriding the mechanism that enables it.


Pull, age, and the real reason WIP matters

Here’s the connection most organisations miss:

The real reason to limit WIP is to prevent unnecessary ageing.

Every extra item you start:
    •    Increases the average age of everything else
    •    Reduces the chance of meeting SLEs
    •    Delays learning whether you built the right thing


WIP limits are not a productivity tool. They are an ageing control mechanism.
If you are tracking Work Item Age and still starting new work while old items stagnate, you are actively choosing delay.


What pull-based control looks like in practice


In a functioning pull system:

•     WIP limits are visible and respected
•     Starting work requires justification, not finishing it
•     Blocked work triggers focus, not avoidance
•     Leaders remove work to make space, not add pressure
•     Age is discussed before dates are missed

This is quieter than push. Less dramatic. Far more effective.

The hard truth: pull feels slower until it works

Pull systems often feel slower at first because they expose how overloaded you already are.

That discomfort is the signal you’ve been missing.

If adopting pull suddenly makes your delivery system look worse, that doesn’t mean Kanban failed. It means the system was already failing — you just finally stopped hiding it.


Starting Work Is a Leadership Decision

Finishing work is a team activity.
Starting work is a management choice.
If your organisation starts more than it can finish, no amount of team-level optimisation will save you. Pull-based WIP control is where leadership stops managing utilisation and starts managing flow.

In the next post, we’ll look at Flow Metrics Dashboards and why visibility without decision-making is just another form of theatre.

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.

A better answer requires a change of perspective. It requires recognition that a software delivery organisation operates in a complex (that is un-ordered) environment which means we cannot use deterministic language. We need to switch to a probabilistic approach.

Kanban’s answer to this problem is just that, to use forecasts instead. Unfortunately forecasts are something that management has trouble accepting and often completely misunderstands.

But don’t worry

• it can be explained
• it can be understood
• it has been done
• there’s detail how to do it further below in this article
• and there’s a lot of further reading if you need it.

Kanban’s answer is the Service Level Expectation (SLE).

What an SLE Is (and What It Very Much Is Not)

Let’s get the misconceptions out of the way first.

An SLE is not:
    •    A deadline
    •    A target
    •    A commitment
    •    A service-level agreement
    •    A promise that work will always finish “on time”

An SLE is a forecast.

Specifically, it is a probabilistic statement of how long a single work item is likely to take once started, based on historical data.


For example:


“85% of work items finish in 12 days or less.”

That’s it. No unrealistic promises. Just our best guess, based on data.

If that sounds less comforting than a date, good. Comfort is usually the enemy of predictability.

Why Deterministic Dates Keep Failing

Most software delivery environments still operate as if the future is predictable with enough planning. Your comprehensive 400 lines spreadsheet or detailed Gantt chart will not fix the future. It just isn’t predictable.

Knowledge work is full of:
    •    Unseen complexity
    •    Dependencies you don’t control
    •    Interruptions you didn’t plan
    •    Learning you couldn’t have done earlier

Pretending otherwise doesn’t make delivery more reliable, it just delays the moment you find out you were wrong. And yet , you can still come across many project and programme managers who try to do just that… Anything to avoid having a honest conversation with their stakeholders I guess?!

An SLE acknowledges uncertainty instead of hiding it. It tells the true story.

The Real Purpose of an SLE

The biggest mistake teams make is treating SLEs as a target to “hit”.

The primary purpose of an SLE is not compliance, it is early warning.

An SLE answers two critical questions:
    1.    How long should this reasonably take?
    2.    When should we start worrying?

Without that second question, predictability is impossible.

SLEs Only Matter When Combined with Age

On their own, SLEs are static. They only become useful when paired with Work Item Age.

Here’s the key shift:
    •    Cycle Time tells you what happened
    •    SLE tells you what usually happens
    •    Age tells you what is happening right now

When an item’s age approaches the upper percentiles of your historical data, the probability of missing the SLE increases fast.

That makes SLEs risk alerts, not performance bars.

Percentiles: Where the Signal Actually Is

Let’s say your SLE is set at the 85th percentile.

That means:
    •    When work starts, there’s a 15% chance it will exceed the SLE
    •    That risk is usually acceptable

But as the item ages:
    •    At the 50th percentile, the chance of breach roughly doubles
    •    At the 70th percentile, it approaches 50%
    •    Near the SLE, you’re running out of options

Each percentile crossed is an opportunity to intervene earlier rather than explain later.

If nothing changes as the item ages, you are ignoring the early signals.

Why Leaders Should Care (Even If Teams Don’t)

Here’s an uncomfortable truth: teams often can’t act on SLE risk without leadership support.

Why?
    •    Dependencies sit outside the team
    •    Priority conflicts are managerial decisions
    •    Scope reduction needs authority
    •    Swarming has opportunity cost

SLEs make this visible.
When an item is at risk, the question isn’t “why hasn’t the team finished yet?”
It’s “what decision are we delaying that would reduce this risk?”

That’s a leadership problem, not a delivery one.

Visualising SLE Risk (Not Just the Number)
Many teams actually calculate an SLE, then they write it on the board, but then ignore it.
That’s borderline worse than not having one.

An effective SLE must be:
    •    Visible where work is visible (yes Atlassian, on the board!!)
    •    Interpreted through age
    •    Used as a trigger for conversation

If an item breaches its SLE and nobody noticed until it was finished, the entire effort to calculate it and show it was wasted.
​
Visualise at the right level

There is something else. As  mentioned above, teams often can’t act on SLE risk. This is often because the breach of the SLE is at their level. All other teams look fine so it looks like “your team problem”. But it often is one of the other teams that will make your team breach you SLE. Because there is a dependency. That dependency isn’t visible immediately if you only show SLEs at team levels. So the answer is to visualise SLEs at the level your leadership cares about. This is often a level above the team board - e.g. programme or portfolio level. (More on that later).

Why SLE Breaches Are Not Failures
Another reason SLEs get abused is fear.

Teams worry that breaching an SLE means they’ve “failed”. That fear drives all sorts of counterproductive behaviour:
    •    Padding forecasts
    •    Gaming start dates
    •    Avoiding difficult work
    •    Redefining “done”
This is backwards.

SLE breaches are expected. That’s what probabilistic forecasts mean. Going over the SLE is not a failure, however failing to learn from the experience is.

The problem is having no idea an item was drifting until it was already late.

SLEs Replace False Confidence with Informed Risk

Delivery leaders can’t have certainty. So they need options.

SLEs, combined with age, give you:
    •    Earlier conversations
    •    Fewer surprises
    •    More credible commitments
    •    Better trade-off decisions

And perhaps most importantly, they allow you to say this with honesty:
“Based on what we know, this is how likely it is, and here’s what we can do about it.”
That’s acknowledging uncertainty instead of ignoring it.

If your SLE isn’t making you uncomfortable, it’s probably not very useful

A good SLE will:
    •    Force conversations you’d rather avoid
    •    Expose risk earlier than feels convenient
    •    Challenge optimistic narratives
    •    Reduce the need for escalation later

If your SLE never gets discussed, never gets breached, and never changes behaviour, it’s pointless.

In the next post, we’ll look at Pull-Based WIP Control and why starting work early is one of the most expensive habits delivery organisations refuse to break.