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.

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.

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.

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.

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

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

Work Item Age.

And the reason is simple: Work Item Age tells you what is going wrong right now, not what went wrong last month. Fix your flow of work now and your delivery becomes more efficient, more effective and more predictable.


Most software delivery organisations are drowning in historical data and starving for present time insight. They measure averages, trends, and distributions, then act surprised when something that looked “fine” on a chart explodes into a late delivery, an escalation, or a missed commitment. Age is the metric that cuts through that nonsense.




What Work Item Age Actually Is (and Why People Get It Wrong)


Work Item Age is brutally simple:

How long has this item been in progress since it started?

• Not “how long does work usually take”.
• Not “how long did this take after it finished”.
• Not “how long has it existed in the backlog”.

It’s the elapsed time between start and now.

That’s it.


And yet, most teams either don’t track it at all or treat it as a curiosity instead of a management signal. Why? Because Age is uncomfortable. It exposes indecision, overload, dependency failures, and wishful thinking in a way that averages never do.

Cycle Time makes you feel informed.
Age makes you feel accountable.

The Fatal Blind Spot of Cycle Time

Cycle Time is a lagging indicator. You only know it once the work is done.

That makes it excellent for forecasting and improvement conversations, but useless for answering the most important delivery question:

“Is this item in trouble?”

Imagine a hospital that only reviewed patient outcomes after discharge. That’s how most organisations use Cycle Time. By the time you notice a problem, the damage is already done.

Work Item Age is the early warning system.

If something has been in progress for 18 days in a system where most work finishes in under 10, you don’t need a PhD in statistics to know you have a problem. You need to intervene.

Age is risk, not performance

One of the most common misconceptions amongst both managers and team members is treating Age as a productivity metric. It isn’t.

Age does not tell you whether someone is “working hard enough”.
Age tells you how much delivery risk you are accumulating.

Every extra day an item ages:
    •    Delays customer feedback
    •    Increases the chance requirements change
    •    Increases dependency risk
    •    Increases the probability of SLE breach

Long-running work isn’t heroic. It’s fragile.

If you care about predictability, Age should make you uneasy long before a deadline does.

Why WIP limits alone won’t save you
You’ll often hear: “We control WIP, so ageing isn’t a problem.”
That’s optimistic at best.

WIP limits restrict how many items you start. They say nothing about whether the items you’ve already started are actually moving. A system can be “within WIP” and still be rotting from the inside.

Age exposes when WIP control has become symbolic rather than functional.

If items are ageing:
    •    You’ve started work you weren’t ready to finish
    •    You’ve tolerated blockers too long
    •    You’ve allowed hidden queues to form
    •    Or the work is simply too big

Age doesn’t care which excuse you prefer. It just keeps counting.

Age is the (missing) link between flow metrics

One reason Work Item Age is so powerful is that it connects every other Kanban metric into something actionable.
    •    Cycle Time tells you what “normal” looks like
    •    SLEs tell you how much risk you’re willing to tolerate
    •    WIP tells you how much you’ve started
    •    Throughput tells you what finishes

But Age tells you which specific items are threatening all of the above.

Without Age, flow metrics stay abstract. With it, they become operational.

“But all work ages” (Yes, and that’s the point)

A common pushback is: “Everything has to age. Age alone doesn’t mean something is wrong.”

Correct. And irrelevant.

The question is not whether something is ageing, but whether it is ageing unnecessarily.

That distinction matters.

An item that is ageing because it is actively progressing through a well-understood workflow is fine. An item that is ageing because nobody quite knows what to do next is not. The metric doesn’t tell you the answer — it tells you where to look.

Age creates a forcing function for conversation.

How delivery leaders should actually use age

This is where most tooling and dashboards fall down. They show Age, but don’t integrate it into decision-making.

Here’s how Age should be used by delivery leads and managers:
    1.    Daily visibility
If you can’t see the age of in-progress items at a glance, you’re already too late.
    2.    Escalation by exception, not by deadline
Stop waiting for due dates. Escalate when Age crosses a meaningful threshold.
    3.    Trigger intervention, not blame
Pairing, swarming, de-scoping, dependency removal, or breaking the work down — not “working harder”.
    4.    Expose systemic issues
Patterns of ageing point to policy failures, not individual ones.

Age should make it obvious where leadership attention is needed, without leaders having to micromanage.

At this point I expect the question, “but our leaders don’t care about the cards on our board or how we deliver, how does age help us?” While there is more to unpack in this question, I’ll just focus on the age related part - Make age visible at the level they care. If you are delivering “New Payment System” but you’re only tracking and showing the work item age of the 20+ individual tasks then you’re missing a trick. Age needs to be visible at the level your boss cares!

The uncomfortable truth: age exposes bad decisions

Here’s why Age is so often ignored.

It shines a light on:
    •    Work started “just in case”
    •    Features prioritised without capacity
    •    Dependencies hand-waved away
    •    Oversized items pushed downstream
    •    Exceptions that quietly became the rule

Age doesn’t let these slide. It keeps counting while everyone else rationalises.

That’s why teams prefer historical metrics. They’re safer.

If you ignore age, you don’t really care about flow

This might sound harsh, but it’s accurate.

If your Kanban system:
    •    Tracks Cycle Time but not Age
    •    Celebrates throughput while items quietly rot
    •    Reviews charts but ignores ageing work

…then you’re not managing flow. You’re managing reports.

Kanban exists to optimise the delivery of customer value. Letting work age unnecessarily is the single biggest threat to that goal.

Everything else — WIP limits, boards, dashboards, forecasts — is in service of one thing:

Finish what you start, and don’t start what you can’t finish.

Work Item Age tells you whether you’re actually doing that.

In the next post, we’ll look at Service Level Expectations, and how Age turns an abstract forecast into a real-time risk signal instead of a broken promise.

Sure, you might get the impression that things are going okay. Tasks are moving. Your velocity in story points looks good 🙄. People are busy. Your board “looks fine.” (What is fine?!) And let’s not forget my “favourite” phrase - “At least everything is in progress, so that’s good!”

But that’s not good!!

Without proper flow metrics, what you have is guesswork dressed up as process. It might be good enough for the theatre your organisation plays but that’s all it is. Guesswork doesn’t scale, especially when you still have to give a good answer to the question “When will it be done?”.

This is where Kanban metrics step in. And you already knew that but it’s just that getting good answers is… well, difficult. I know.

Tracking with purpose

Let’s copy a famous phrase and start with why?. Why do we track:

•  Spot problems before they escalate
•  Have meaningful conversations with stakeholders
•  Forecast with confidence
• Create a shared understanding of how work flows and where it gets stuck

Remember, we measure to reduce uncertainty. (See Douglas Hubbard’s work).

When used well, kanban metrics help you lead proactively. Instead of answering, “We’ll try to get it done.” to an arbitrarily chosen deadline, you can say, “There’s an 85% chance we’ll finish it by next Friday.” That’s reducing uncertainty the other one is giving (probably false) hope.

What Are These Metrics, Exactly?

Thanks to the hard work of many clever folks, we’ve now got access to some seriously useful flow-based insights. Here are ten key ones every delivery lead should know:
    1.    Work Item Age Tracking: See how long each item has been in progress.
    2.    Service Level Expectation (SLE) Visualisation: Show when something is “at risk” of taking too long.
    3.    Pull-Based WIP Control: Prevent overloading teams.
    4.    Flow Metrics Dashboard: At-a-glance view of cycle time, WIP, throughput, and aging.
    5.    Custom Workflow Definitions: Reflect your team’s actual process (not just “To Do / Doing / Done”).
    6.    Blocked Item Visualisation: Highlight what’s stuck, not just what’s in progress.
    7.    Forecasting with Historical Data: Use past cycle times to predict future outcomes (Monte Carlo style).
    8.    Ageing Risk Highlights: Call out items at risk of becoming “silent blockers.”
    9.    Work Item Breakdown Support: Make big things small before they derail timelines.
    10.    Pull Signals: Let the system tell you when to start new work (instead of a backlog sprint panic).

Each of these tools offers a view of your system, and collectively, they give you a full picture of how value is flowing (or not flowing) through your team.


Why This Matters (Especially in Real Life)

You’ve probably been in at least one of these situations:

• A card’s been “in progress” for 3 weeks, and no one can quite explain why, there’s just one thing after the other and it never ends. It’s one of those things, Sigh..
• You’re asked when a feature will be ready, and your only honest answer is, “It depends.” or worse you make your engineers have a guess.
• Half the team is busy, while the other half is waiting on blocked work and picking up even more work while waiting. It makes sense, right! Sigh…
• A stakeholder drops a last-minute request, and you have no data to show how that impacts your flow. So you stop other work and jump on it instead.

Kanban metrics help you respond with evidence, not just instinct. Instinct is great but instinct + data is better.

In the olden days I used to spend hours typing in numbers from the physical board and then piecing together timelines in spreadsheets. Now, I just pull up the flow metrics dashboard and the story tells itself.

Metrics are signals and prompts for conversations

When implemented well, Kanban metrics aren’t just about the numbers. They’re signals that should prompt a conversation:
    •    “Why is this item still in progress after 12 days?”
    •    “Should we pause new work until this ageing card gets resolved?”
    •    “If we keep this pace, we’ll miss our SLE, do we need to shift priorities?”

Mature teams will understand it and will value it. Others really need to grow up because these signals are essential for improving the flow of work. It’s about building awareness, creating alignment, and protecting focus.

In-Person or Remote? It Doesn’t Matter

Whether you’re running hybrid teams, fully remote squads, have AI workers or everyone’s huddled around a whiteboard in the same room , flow metrics still matter and still work. You just need to surface them regularly:
    •    Pin metrics to team dashboards
    •    Make them part of daily standups
    •    Use them in retros to highlight systemic issues
    •    Share forecasting visuals in stakeholder updates

They make the invisible visible.

What you’ll gain by using these metrics

• Leading indicators    
• Fewer surprises
• Faster feedback loops
• Better prioritisation decisions
• Improved team autonomy
• More realistic stakeholder expectations

In short: your job gets easier, your team’s work gets smoother, and your delivery becomes more predictable. Tell me your don’t want that?

TL;DR

If you want to stop firefighting, start leading with data. Kanban metrics don’t take over the process, they reveal where the process needs support.

And once you see the patterns? You won’t want to go back.

Ready for the deep dives? I’ll now work through ten short, practical posts, one for each Kanban metric. Each will include:
    •    Why it matters
    •    How to implement it (in-person & remote)
    •    A quick example from delivery life

Stay tuned > next up: ​Work Item Age - The Only Metric That Tells You the Truth 

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

Once you’ve understood the problem you may suggest that the delivery teams in such organisations could have been better aligned to value chains which would enable them to deliver each increment independently, and you might be correct. For one reason or another the structure of teams wasn’t going to change in any of these organisations. I will not go into the details of why in this article so you will have to trust me that there were sufficiently good reasons for that.


Consider the following 1000 words in the shape of a diagram and I will explain the boxes and the interactions below.

Explanation of terms

In this diagram we use several terms that may need a little bit of explanation so I’ll start with that.

• Long Lived Teams (LLTs)  - refers to software delivery teams that look after a number of services or products and have a relatively stable structure. For example consider a team looking after the Authentication services at a large organisation. This may include services like login, multi-factor authentication, single sign-on, etc. Suppose we have staffed this team with six software developers, two quality assurance engineers, one business analyst (BA), one product owner (PO) and one delivery lead (DL). When we say that it is a Long Lived Team we mean that the same people(or roles) will remain on this team for a relatively long period of time. We also expect that an LLT is a modern day team, responsible for development, deployment and live support of their products or services (aka You-Build-It-You-Run It [YBIYRI] team)

 

• Short Lived Teams (SLTs - great acronym, I know ;) ) - Short lived teams are created for the purpose of delivering a specific feature that requires changes in multiple services (or products) and will ideally include representatives from each team that owns the affected services. An SLT will also have a BA, a PO and an Architect. These three roles will have different level of involvement depending on the size and complexity of every feature. An SLT is expected to disband once the feature is fully delivered in production. Sometimes people will participate in multiple SLTs. This is at their own discretion, provided that they feel they can handle the cognitive load. It’s worth noting that in this environment Software Architects take an advisory and supporting role and aim to help teams overcome hurdles in the organisation (be it technical or political) or provide advice when asked to do so.
  

• A note on the so-called tiger teams - You may find many similarities between SLTs and tiger teams however I believe there is one major difference at least based on my experience. The way I've seen tiger teams utilised is more like an exception - a team created to solve a complicated problem over a short period of time. Tiger teams are not common in the organisations I've seen them used. SLTs are part of the usual way of working in our approach. 

 

• Feature refers to a piece of functionality that delivers value to our customers. Therefore an increment that implements a change that makes no difference to our customers is not considered a feature. Features can be very visible (e.g. involving User Interface changes) or less visible (e.g. involving performance or stability changes). Example of an increment that makes no difference to customers would be implementing the back-end part of a form filling service. Our preference would be to implement the entire feature, end to end (E2E) so that it provides value to our customers when complete. Sometimes features can be delivered by a single LLT and other times they would require the involvement of multiple LLTs. We found the latter to be the case over 80% of the time.

Running LLTs


This model doesn’t tell you how to run your Long Lived Teams except for the expectation that they will be You-Build-It-You-Run-It type of teams. The fact that all five of our teams in our original implementation used a “Kanban for software” type of process might have helped our approach but we have no reason to believe that other methods would be unsuitable. The only real requirement for your process is to be able to accommodate the running of multiple SLTs alongside your LLT and to be able to make visible progress towards delivery of features. As such a process that forces you to plan a period of time in detail for say two-four weeks might not be very suitable.


Running SLTs


This is where most of the specifics of this model are concentrated. Creating more teams and asking your engineers to be part of more teams can risk upsetting some people. But in this model, being part of one or more SLTs is nothing too onerous. In fact, this is probably what your engineers already do but are probably much more frustrated due to the lack of structure and the disconnected nature of how work gets done between dependent teams. Think of the SLTs as one way to eliminate the dependencies. Here is how it works

1. SLTs add only two separate ceremonies for the lifetime of each feature.
2. The first one is the feature kick off. It could be led by the Product Owner or the Business analyst. Depending on the size of the feature it could even be a very short informal conversation.
3. The other one is demonstrating the completed feature. Often we’ve seen teams do quick informal demonstrations of individual pieces of the feature and a little longer one, when the entire piece is complete. This may not require any more people than just the e2e QA and the BA and PO.
4. SLT team members have a common way of communicating. Usually that’s just a slack channel bearing the name of the feature. These channels are public and anyone interested can join (although they rarely do). 90% or more of the SLT communication happens via this slack channel although ad-hoc sessions or cross team pairing is often observed.
5. There are no SLT stand ups. Instead the LLT stand-ups are open and anyone can join if they wished to learn more about something.
6. SLTs might do cross team pairing or ad-hoc sessions if something needs clarification but none of these are mandatory

What does this mean for…
The DL
Delivery leads primarily look after their LLT the way they usually do. Their responsibility related to SLTs are mainly about

1. Ensure kick off happens
2. Monitor the age of tickets in the feature and have relevant conversations if a ticket approaches the service level expectation
3. Track progress and report to grown-ups
4. Help out with any release activities necessary (e.g. training, adoption, etc)
5. Announce release and praise people

We have seen DLs successfully look after 3-4 SLTs in addition to their usual LLT.


The BA

Business analysts focus on features and work across delivery teams. Far too often we have seen BAs assigned to teams and having to figure out how to split user stories to fit in with the split of teams. We found it much more logical to have our BAs focus on the entire feature and work across teams. In doing so they often have to collaborate closely with the engineers (or technical leads if you have them) to ensure that the user stories they write are the right shape and will work for the teams both long and short lived.
We found that this concept doesn’t work well for every single BA we’ve come across however it worked for most and they found it very satisfying that they can see a feature delivered end to end.


The QA


The role of the quality assurance engineers is mostly the same as on any other modern Agile software delivery team. The only difference is perhaps the ask to have one of the QA engineers take end to end responsibility for every feature. We didn’t think this would cause any problems because our QAs were already self-organising to do the end to end testing. Making it more formal actually helped ensure the workload is shared appropriately. The  E2E QA co-ordinates QA activities, may lead on demonstrating the E2E feature and looks after the feature until it is working correctly in production.


The PO


Like the BA, the Product Owner looks after a whole feature (or a few features). If you find that you don’t really need both a PO and a BA you can probably run this model with just one of these roles. In big and complicated organisations we found that both roles add value. Our BAs were focused more on the teams and actual implementation and our POs were external facing and did the job of explaining what we’re building to the rest of the organisation and making sure we build the right thing.


The engineer


This model probably causes the least change for the engineers day to day. In our experience, our engineers saw the SLTs as a positive change that brought some structure to otherwise complex environment, enabling them to communicate easily, rely on a lightweight and clear process and resolve any cross-team issues quickly and efficiently. If you have technical leads they will need to work closely with all BAs that look after features related to their teams’ services. If you don’t have technical leads then engineers will have to share that responsibility so they can advise the BAs about feature implementation.


The architect


Architects, as alluded to previously, have an advisory role and an enabler role in this model. We have seen them involved in some, more complicated features but mostly not get involved unless asked to in the majority of features. Architects may be part of kick-offs and seek for ways to help the delivery. They may also get involved in conversations with other parts of the organisation or external vendors.
​

Example weekly schedule and sessions explanation


To make this a little easier to imagine I will share a sample weekly schedule and some of the sessions that might be happening. This schedule and the sessions are clearly context dependent and you may have different sessions that work in your environment. However it should give you an example of what might be needed to make this model work.

As already mentioned the LLTs can run their own process and we won’t try to detail what that might be here. We just added a line for LLT daily stand-ups which we found to be useful when they are open to all other teams should others want to listen to the conversation of a specific team.


Feature life-cycle sessions


Every SLT is formed because of a feature and the feature begins life in the product world and usually comes from a roadmap or a backlog. Product owners and Business analysts will have confirmed with relevant stakeholders what the business and user needs are before bringing the feature to the delivery teams. They would then often have an initial session with relevant tech leads or engineers if the feature is more complicated to make sure that there is an approach to implementation that works for all existing services and LLTs. This session may not happen if the feature is already well understood. Equally, further architectural sessions may be necessary when the feature implementation is very complicated.


Every feature will start its implementation journey with a feature kick off session which will usually involve the lead BA and/or PO, the relevant engineers from every team that has involvement in the delivery of the feature, one or more QA engineers and an architect if needed. In this session the BA will ensure all necessary user stories (or work items if you like) are created and stored in the same list which the SLT members can then refer to when they need to pick up more work.


When the feature is complete and ready to demo, the e2e QA will organise a feature demo with any BAs, POs and other interested parties involved. If the demo is successful the feature will typically be deployed to production ideally via the existing deployment pipelines as part of the continuous deployment process. This doesn't mean that early feedback is not sought during the development of the feature. Quite the opposite, typically every work item that is completed is demoed to the BA unless deemed unnecessary (e.g. for changes that don't impact the user experience). 


Sometimes as a result of the demos, more work or changes are identified, in which case new user stories (or work items) will be added to the list and the SLT will continue work until it completes the new work items. In some cases the e2e QA may organise a demo earlier intentionally to get initial feedback or in expectation that there will be changes necessary.
​

The features progress review


This is a weekly session that involves all Delivery leads, all Product owners, all Business analysts, all Architects as well as any senior stake holders and people involved in feature adoption (e.g. training, change management, etc).
We would suggest that this session moves quickly through features making sure actions are being actioned and does not take more then 30 minutes.

In this session, we would walk through all features that are in progress, typically in a priority order or starting from the features that have been recently completed, then those closest to completion and so on. We would then provide a brief update for how the feature is going and highlight any delays or blockers. Further action may need to be taken when there are blockers. The facilitator will prompt action owners for updates on their actions, will take notes and record as part of the feature update and will make sure new actions have owners. Towards the end of the session we will have a look at upcoming features and may then use this information to plan for feature kick-offs.
​

How about User research and UI design?

After some initial struggles we found that integrating these roles in the model can work well with some flexibility on how and when activities are done. Depending on your available people, when we refer to UX we may include the following roles: user researchers, UI designers, content designers. Some things to bear in mind

• When a feature involves UI changes or affects customer experience then we would involve the UX people as early as possible.
• A feature implementation may start using an initial and un-tested UI design and may then take into account feedback from user testing later on to implement further changes.
• UX professionals will work closely with POs and BAs early in the feature lifecycle and will be involved in feature kick-offs and feature demos
• Feedback from UX professionals will be implemented as early as possible but sometimes in a further iteration of the feature at the discretion of the PO
• Collaboration with UI designers will be frequent during feature development and often requires them to be part of the SLT.

​Final words


If you made it to here then well done! I know I probably wouldn’t have read as much. I need your help. Do you think this would work in your organisation? If no then why not? If you are experiencing dependency problems and insufficient cross team collaboration then how do you handle it? Is there anything in this article that doesn’t make sense? I’d love to hear from you.

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

However, as Agile coaching gained prominence, particularly in large organizations, its reputation began to suffer. This decline in credibility is linked to a range of factors, including the commercialisation of Agile coaching, the imposition of rigid frameworks like SAFe (Scaled Agile Framework), and a shift away from the core principles that initially made Agile effective.


How Agile Coaching emerged

Agile coaching evolved as organisations transitioned to Agile practices such as Scrum, Kanban, and Extreme Programming. The role of an Agile coach was initially envisioned as a supportive one, focused on helping teams and individuals adopt Agile values and practices. Drawing from roots in coaching and mentoring, Agile coaches were expected to guide teams through self-organisation, problem-solving, and continuous improvement.

Early Agile coaches typically had a strong foundation in both technical expertise and leadership. They worked closely with teams to foster a culture of collaboration, helping organisations embrace Agile principles and adapt them to their specific needs. The intention was genuine: to ensure teams could work more effectively, deliver high-quality products, and respond to change.

At its core, Agile coaching was aligned with principles of coaching and mentoring. It emphasised listening, guiding, and encouraging teams to develop their own solutions. It wasn’t about imposing rigid processes but about helping teams grow in their Agile maturity, becoming self-sufficient in delivering value.

The Shift: Commercialisation and Large-Scale Frameworks

However, as Agile methodologies grew in popularity, especially in larger organisations, Agile coaching became increasingly commercialised. Certification programs multiplied, often focusing more on ticking boxes than truly embodying Agile principles. Many Agile coaches became certified after a short course and a few exams, often lacking the deep experience required to truly mentor teams through complex organisational challenges.

Simultaneously, large-scale Agile frameworks such as SAFe (Scaled Agile Framework) began to dominate the corporate landscape. While frameworks like SAFe were designed to help organisations adopt Agile practices at scale, they often introduced a level of bureaucracy that directly contradicted the flexibility and autonomy that Agile was meant to provide.

In particular, SAFe has been criticised for turning Agile into a top-down, process-heavy system. Rather than empowering teams, SAFe often imposes a rigid structure, including hierarchical roles and predefined workflows, which can stifle creativity and autonomy. The introduction of layers of management and predefined sprints can make Agile feel more like the traditional waterfall approach it sought to replace, leading to disillusionment among teams and a growing perception that Agile—and by extension, Agile coaching—had lost its way.

The Erosion of Agile’s Core Values

One of the fundamental reasons Agile coaching has developed a bad reputation in recent years is the perceived shift away from Agile’s core values. Instead of focusing on customer collaboration, responding to change, and empowering teams, Agile has sometimes become a buzzword used to justify implementing complex frameworks like SAFe, which can feel prescriptive and inflexible.

This has led to situations where Agile coaches, instead of guiding teams in self-organisation, have become enforcers of frameworks. In such environments, Agile coaching is seen as a means of ensuring compliance with a predefined set of rules, rather than encouraging teams to evolve their practices based on what works best for them. When coaching becomes less about guiding teams and more about enforcing processes, it undermines the original purpose of the role.

Furthermore, Agile coaches often face pressure from executives who expect immediate, quantifiable results from Agile transformations. This focus on quick wins can lead to superficial implementations, where teams go through the motions of Agile without fully adopting its mindset. As a result, the true value of Agile coaching—developing teams, fostering continuous improvement, and enabling long-term success—gets lost.


The Future of Agile Coaching

Despite its current challenges, Agile coaching is still valuable when practiced with integrity. The best Agile coaches focus on fostering collaboration, helping teams navigate complex problems, and supporting the long-term growth of organisations. However, for Agile coaching to regain its credibility, it must distance itself from the commercialisation of certifications and large-scale frameworks that dilute Agile’s core values.


Agile coaches need to return to the fundamentals of coaching: listening, guiding, and empowering teams to take ownership of their processes. Organisations, in turn, must resist the temptation to implement Agile at scale using cookie-cutter approaches like SAFe without considering whether those frameworks align with their specific needs.

In conclusion, I'd say that Agile coaching has developed a bad reputation because of its association with rigid frameworks, the commercialisation of certifications, and a drift away from Agile’s original principles. However, when practiced with care and attention to its roots, Agile coaching can still be an incredibly powerful tool for fostering effective, adaptable teams and organisations.

Luckily the person questioning was happy to debate the question and to give me a chance to explain. To aid my explanation I produced the following diagram. I’ve come across this example in more than one book and I’ve found it useful in explaining the concept in the past.

Consider a scenario where someone (not me!) is consistently late for work in the morning and they are trying to improve their morning routine so that they can leave their house on time and be able to start their car drive to work before 8:30am.  Let’s say they explore the activities that need to happen between waking up and reaching their car. I offer two options in the diagram. The first one is similar to having a simple workflow of [To Do] -> [In Progress] -> [Done]. That is - there is a clear policy of when you move from step 1 to step 2 (alarm goes off) and there is a clear policy of when you move from step 2 to the final step 3 (I am in my car). Suppose you want to improve this process after being consistently late for the last 2 weeks. How would you go about it?
​

I know what I would do (eg break down into activities) and so I have also presented a possible morning routine with all the steps involved that one might need to get ready. Now I have multiple milestones, I can monitor how my “getting ready” is progressing and I can adapt accordingly to make sure I catch up on my schedule if I am behind. A simple example in case I am already running late by step 4 could be that instead of making an omelette for breakfast I might use some boiled eggs from the day before or I could make cereal and this will save me some time and I can be back on track. Without this level of detail it becomes impossible to make adjustments that can get you back on track and it’s difficult to analyse which steps might regularly cause you the delay.
​

It should be fairly easy to apply the same principles to other flows of work.The reasons for more visibility of the work flow and transition policies are the same as in this simple example. The benefits of applying these principles can be huge depending on your specific circumstances. It is therefor rather surprising that many teams and delivery programmes choose to ignore this level of detail.

Are you interested in how this principle can help your own workflow? Get in touch for a obligation chat.

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

To put things in a bit more context, my Kanban knowledge comes from the wisdom of Dan Vacanti and Prateek Singh, which is captured very well in various articles and mini books available at prokanban.org. I recently attended a Portfolio Kanban course with Dan and Prateek, which was very useful both in reminding me of things I learned in the past and adding some very useful tips and practices for portfolio work management.
Here, I am focusing on two practices that help with managing the aging of portfolio work items and specifically how to address these in Jira. Even if you use a different tool, these practices apply in a very similar way (that is, if you care about the things Kanban tells us to care about).

If you have read books or articles by Dan or Prateek, you would have gathered that one of the most important things you can do to improve the efficiency, effectiveness, and predictability of your delivery is managing the work item age. No surprise then that my first Jira plug-in was Work Item Essentials, which allows you to properly calculate and visualize work item age!

Now, when we look at the problem in the context of portfolio work management, there’s another element that comes into play. Of course, setting the start date and calculating age are still very important for your portfolio items (e.g., Epics in Jira), and I strongly advise you to still set this up. I have a handy article here that shows you how to do it, or you can use my free Work Item Essentials Jira app to save you some time.

In terms of portfolio items (for example, epics) that incorporate work items within them—e.g., stories—there is another signal that can be useful: the number of work items sitting underneath an epic. As with all signals in Kanban, monitoring the number of cards that are part of an epic is just another reason to have a conversation about the size of the epic, the options to make it smaller, and how the team would like to proceed depending on their understanding of the right size.
​
Enough with the chatter though, let’s go straight into setting up this automation.

Here’s an image that I hope is worth the 1000 words as advertised :-).

You need to be a team admin to create automations in Jira. Once you have access, you want to set up an automation that triggers on Issue Update (and also Issue Created, but the example here is with Update). Another prerequisite is to have a numerical field that you can update. If you don’t have one, you can add a new field assuming you have admin access. It would be useful to confirm if the field you choose can be displayed on your Jira boards because that’s what makes it really useful.

The first step after that is to verify that this issue isn’t an epic because we only want to update epics when issues get added or removed from an epic. Once we’ve confirmed that, we need to have a Branch Rule, which we define for parent, and then we have to do a Lookup Issues. Don’t ask me why, but that’s how this works (it took me a long time to figure it out, and I only did because of the support link in resources!). At this step, you are required to enter {{issue.key}}.

Note that the first time I did this Parent = {{issue.key}} worked just fine, but when I tried on a different Jira instance/version I had to use "Parent Link"= {{issue.key}} instead because it didn't work with Parent. 

When we do the lookup issues, we have to specify which field to edit and finally give it a value. The key value to remember is {{lookupissues.size|0}}. The |0 just says that if the value doesn’t exist, Jira will set this field to 0, which made sense in my case.
​
If you have done everything right, you can enable your new rule and test it by updating a story that sits under an epic and then checking the relevant field of the epic. If it updates correctly, you should be able to display it on your Jira board like this:

I’ve had to anonymise the text on the screen, but the main point is that I have two values displayed for every epic. The top one is the one we just did in this article—the number of cards that sit under the epic—and the second one is the work item age for the epic, which you can set either using my free Jira plugin or, if you can’t install plugins, just follow the steps in this article to create another automation.
Good luck, and let me know if you have any questions :)

Resources

1. https://community.atlassian.com/t5/Jira-questions/Smart-Value-to-display-the-sum-of-child-issues-linked-to-an-epic/qaq-p/2311631
2. prokanban.org

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

As a Kanban consultant I help teams and organisations to:

• Understand the Kanban Method and its principles
• Design and implement Kanban systems that meet their specific needs
• Improve their flow and throughput
• Reduce waste and improve quality
• Increase predictability and transparency
• Build a culture of continuous improvement

When we talk about the Kanban method, we need to clarify some points for there are many definitions out there and not all of them are in agreement with me.
The Kanban Method is a strategy for managing and improving the flow of work. It’s a workfolow management method that helps teams deliver work quickly and efficiently. It is based on the principles of visualisation, limiting work in progress (WIP), focusing on flow, and continuous improvement.

Visualisation
​
The first thing we want to do is to visualise the workflow by using a Kanban board. It is very important to define the when work goes in progress and when it gets to Done. It is also important to know the policies of when work items change statuses. The Kanban board should identify the different stages of work, and where each item of work is currently located. This helps teams to see the flow of work, track the age of work items, identify bottlenecks, and make changes  to the flow in order to improve it.

Limiting WIP

Kanban teams sometimes decide to limit the amount of work in progress (WIP). This can be done at each stage of the workflow or for all WIP stages. Limiting WIP can help ensure that teams are not overloaded and that work is flowing smoothly through the system.

Focusing on flow

In a kanban team, we need to establish a culture of focusing on improving the flow of work through the system. This means identifying and removing bottlenecks, monitoring work item age and focusing on aging items, and ensuring that teams are able to pull work into the system as they have capacity.


Continuous improvement

It is important for a Kanban team to establish a continuous innovation way of working and to continuously look for ways to improve their workflow. The team will use short feedback loops to identify areas for improvement and then implement changes to test and validate their hypotheses.

You may have heard about the four Kanban principles before. I am also aware that there are other similar lists but since I think they are still valid I thought I’d include them here.

1. Start with what you do now. Don't try to change everything at once. Start by visualising your current workflow and identifying areas for improvement.
2. Agree to pursue incremental, evolutionary change. Kanban is about continuous improvement, not big, revolutionary changes. Make small changes that can be easily implemented and measured.
3. Respect the current process, roles, responsibilities, titles. Don't disrupt the team's current way of working. Instead, work with the team to identify ways to improve the existing process.
4. Encourage acts of leadership at all levels in your organisation. Everyone on the team has the opportunity to lead and contribute to improvement efforts.

Why would you want to implement Kanban - Benefits of the Kanban Method
The Kanban Method offers a number of benefits, subject to a good implementation:

• Improved flow and throughput 
• Reduced waste and improved quality
• Increased predictability and transparency
• Built-in continuous improvement

Tips for implementing the Kanban Method

There are a number of guides on the internet about how to implement Kanban. If there is one that I can endorse that would be the ProKanban and Daniel Vacant one. Below is a shortlist of what you might want to do:

1. Visualise your workflow. Use a Kanban board to visualise your current workflow
2. Define when work starts and when it ends. Define policies for work items changing statuses.
3. Calculate and monitor work item age
4. Calculate and monitor cycle time (e.g. on a scatter plot) 
5. Review your charts and identify areas for improvement.
6. If appropriate Limit WIP. Set a limit on the amount of work that can be in progress at each stage of the workflow or for all WIP statuses
7. Focus on flow. Always aim to remove bottlenecks ASAP And make changes to improve the flow of work through the system.
8. Implement feedback loops. Collect feedback from stakeholders and use it to identify areas for improvement.
9. Continuously improve. Make small changes to the system and measure their impact.​

Being a Kanban coaching consultant is a challenging but rewarding career. You have the opportunity to work with a variety of teams and organisations, helping them to achieve their goals and become more agile and efficient.

Book a call with me to discuss your Kanban coaching needs.

This is the second part of my posts on filling in the Lean canvas. If you’ve come across this article first, you should take a look at part 1 to begin with. Lean Canvas is a one-page business model template that helps startups decompose their business model quickly. It is part of Ash Maurya’s Continuous Innovation Framework and while on the surface it looks simple, filling it in can be tricky and can lead you in the wrong direction.

These posts aim to help you in that respect.

Remember that one of the goals of filling in a lean canvas is to identify your riskiest assumptions and be able to validate if they are correct or if you need to change course.


Contents

1. Unique value proposition
2. High level concept
3. Solution
4. Next steps

Unique value proposition

As declared by Ash himself, your unique value proposition (UVP). is one of the canvas's most important boxes and the hardest to get right. It is very important for this section to focus on the number one problem you are solving. The UVP is your chance to capture your customer’s attention and your best chance is by addressing their biggest problem. 
Here’s a crash course on how to craft a good UVP - it must answer “what?”, “who?” and “why?”. There is a lot of advice you can read about UVP but what worked for me was an example, so here’s one:
Product: LeaveWizard

Headline: Automate leave and absence management to free up time and eliminate friction

Sub-headline: LeaveWizard replaces slow and out-dated leave planners with an automated and powerful system that helps you be more productive.

High level concept
The other part of this box is the high concept pitch. I’ve come across a lot of people struggling with this one. And that’s understandable. After all not everyone is building an obviously genius idea. Unless you’re opening a restaurant, there’s a good chance that most people will struggle to understand what If you’re proposing. 
If you struggle to come up with something concise and representative for your idea, my suggestion is to leave it for later. However, not too late. Being able to explain your idea to your customers is very important. Sometimes, even good explanations are not sufficient for your customers to see why they should consider using your product. So there is some skill required to make sure people “get it”.
Here are some examples that I made up and you might find helpful:

• Truck-star - Uber for trucks
• Boot-starter - KickStarter for Bootstrappers
• Edu-tube - YouTube for education

Solution
We often refer to our idea and our solution as one and the same thing. I’ve seen countless of founders who are so focused on building their solution that they ignore all warning signs and only realise they’ve built the wrong thing when it’s too late.
Your solution is important, which is why it has a box on the canvas but you also need to be prepared to change it depending on what your customers tell you. Your solution is also rarely the riskiest part of your model and identifying our riskiest assumptions is our main goal with the canvas. Sometimes people who have noticed a problem, don’t even have a solution and so this box could remain empty for a while if you’re exploring several options.
Very often, people like investors or advisors seem to not care about your solution. This is because they recognise that the solution is a small part of the business model. They are more likely to have questions about customer engagement and market size or opportunity. 
And last but not least, your customers also don’t care too much about your solution. They will be mainly concerned with solving their problems.
That does not mean your solution isn’t important, only that it’s probably not the riskiest part of your plan. In almost all cases your customers will be using an alternative solution to solve their problem. And when your new solution is replacing the alternative, your product will need to offer 3x to 10x improvement over the current alternative in order to cause a switch. And achieving this level of improvement isn’t always easy.
However at the initial stages it’s best to only loosely define your solution until you’re certain you understand the problem and that your customers recognise it and would pay for a solution.
Here’s an example for your Solution box:
Idea/Problem: People who use multiple calendars find it difficult to know when they are really available and if they commit to a specific time slot
Solution: Create some sort of calendar events aggregator that is able to consume events from multiple sources and determine when I would be available.
Next Steps
To keep each piece short I will end the second part here and continue with Channels in the next article in these series on Lean Canvas. 

If you liked this article please share it with your friends. Feel free to book a chat with me if you'd like some advice on your idea.

In the meantime, here are some additional resources about lean canvas:

• The Lean Startup
• Lean Canvas
• Another Guide to Lean Canvas

Contents

1. About Lean Canvas
2. Customer segments
3. Problem
4. Next steps

​About Lean Canvas

resource - lean stack website

The Lean canvas can be really simple and really useful, however depending on how you fill it in, it can also be misleading and it can send you in different directions causing a waste of time or even missing out on great opportunities. There is a huge value in the sections and questions on the canvas, the brevity of it and the simple layout help keep it short but the real value is in the information that you provide and as such, it is possible that things go wrong. Why is that?

The innovator’s bias is hard at work within all of us. Our ability to rationalise our reasons is very powerful and in the case of Lean Canvas, both the innovator’s bias and our rational skills work against us. I learned this the hard way but you don’t have to. Read on to find more.

In the text below I will outline the main steps and my high level advice about filling in each box. There is however much more to know about the meaning of the questions and how to understand and process your answers. If in doubt I would recommend finding an experienced Lean Stack coach to help you do it right. 

There is a historical confusion around the order of the questions. This is due to the first two sections having changed order once or twice as Ash was developing the tool. My advice here is that if you have a problem in mind, you can start with the problem box and
then move to the customer box. They are inherently connected though and you can’t go wrong if you start with the Customer box instead. The underlying thought has to be that the problem, as you see it, may not be the problem that your customers see. But also that your understanding about your customers can also evolve over time so that box can change too. 
If you want a definite answer I would say it is more important to identify the customer segments that you will need to talk to in order to validate your problem or discover a related problem that’s worth solving.
If you are part of a team, try not filling in the canvas as a group to avoid groupthink. Fill in your canvases individually and then bring them together into one. This technique is known as diverge/converge and can be very useful in many other cases when working as a team. This will result in more ideas and potentially more canvas variants of your business model. The canvas variants can be as a result of slightly different problems or different customer segments. Avoid using one canvas if you have identified very different customer segments. While you should aim to build your product for one segment first, in the early days you won’t necessarily know which segments will be best, so keep developing separate canvases for your different customer segments. 
When you complete your canvas for the first time it is far from being done. You will need to come back to it, refine your answers and adjust them based on your learnings. This may feel like a chore so I recommend establishing an accountability partner or attending a start-up boot camp like the one Ash Maurya runs or my 90 days start-up school.
Customer segments
Think about who are the people who experience the problem you are aiming to solve. But also think about who is going to pay for your solution. For instance, we started developing LeaveWizard with the employees and line managers in mind because we have witnessed the pain they feel when dealing with leave management. However, we soon discovered that they are not the people who pay for our solution. Those people were HR or Office admins and often Directors in the business and they had slightly different requirements. Avoid making the segments very wide. Often people think “anyone can use our product” but while that might be true, it is not very useful for your rollout strategy. You need to focus on smaller segments which get really narrow when you identify your early adopters. Your early adopters will need to be those who feel the problem the most and are ready to pay and perhaps wait for a few months for a solution. If possible you can identify and list your early adopters- e.g. by name.


Problem
The most important thing to remember here is that this is your current understanding of the problem. It is not uncommon to start with one understanding and end up building a solution to a very different problem. It is good to start with your understanding but be certain that it will change. It is very rare for someone to guess the problem right without talking to customers hence the low success rate of startups. There’s an endless list of examples of successful businesses that have started with one problem and ended up somewhere else - Groupon, Flickr and Instagram to mention a few.
The section of the canvas I find most intriguing is what comes next - Alternative solutions. This is so easy to get wrong but is crucially important for setting you on the right path. There are two main reasons for getting this wrong. Say you’re building an expense automation tool. It is easy to assume that your main competitors are other expense automation tools. And this is OK but what might be more useful is to look at the problem your tool is solving and then expand by figuring out what other solutions are doing the same job - e.g. spreadsheets. You are likely to find that most people solve their problem by using spreadsheets. It is not perfect but it’s free. And here comes the second trap. While it is useful to understand that your biggest competitor are spreadsheets, it is almost useless to try and say that in public because spreadsheets are free or almost free. This means you will be asking people to replace a free solution with a paid one and we all know that the hardest price change is from $0 to $1. 

Next Steps
To keep each piece short I will end this first part here and continue with Unique value proposition in the next article in these series on Lean Canvas. In the meantime, if you’d like a chat or need help understanding some of these concepts, please get in touch.