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

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

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

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

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

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

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


“When will it be done?”


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

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

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

Work Item Age.

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

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

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

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

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

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.

Lean canvas is a one-page business model template that helps entrepreneurs, intra-prenuers and startups begin decomposing their business model quickly and efficiently. It is a visual tool that forces you to think through the key elements of your business model, such as your target market, value proposition, and revenue model. It can fully replace a 30 page business plan in helping you answer the most important questions for your business model. The Lean canvas is part of Ash Maurya’s Continuous Innovation Framework which constitutes an essential building block to our method for starting and growing your business.

When a team or organisation have never come across Kanban for knowledge work, it is necessary to take a step back and explain the method and the benefits in simple words. This isn’t always easy!