Blog

To maximize the amount of work done, maximize the amount of work not done. Huh? Think of it this way: you're in the plate-spinning business. Would you rather spin your optimal number of plates, or run ragged trying to stop them from hitting the floor? This piece is a quick, no-nonsense reminder that knowledge work is messy, entangled, and unforgiving of overload. Watch your work item age. Use the board itself as an aging chart. Swarm on the oldest and the blocked. Avoid fake items that pretend to deliver value. Push the finish line past delivery to value realization, so you don't end up running a feature factory. Start everything, and everything takes forever to finish. Focus, finish, and feed. Slack time is your friend.

Standard, fixed date, expedite, intangible — the four classes of service from the Kanban Method are familiar to most practitioners, but should you actually use them? This piece walks through what each class means (and what doesn't count as a "real" deadline — your grandmother's birthday doesn't), and makes the case that from a pure flow point of view, classes of service hurt more than they help by causing some items to age while others get fast-tracked. There's a better way to handle urgent requests: record a breach in your WIP limit instead of increasing it. Plus a humorous tip involving two sleeping bags for testing how urgent an "urgent" request really is, and a clever real-world example from a large bank where one leader paired classes of service with a four-day ceiling on work item age. The one class of service worth keeping? Intangible — especially when the culture is obsessed with utilization.

It is essentially re-wording an assumption or set of assumptions in a way that is put more like a question, or something that needs to be tested, eg. we believe this particular set of assumptions to be true, and we will know if we are right if X happens.

I think the key difference really would be: the leader leads the way in terms of direction and then creates the space where that might happen. A leader is understanding that it is not just about delivery, that two-thirds of things are rarely or never used and so maybe we should be trying to have a heat-seeking missile to find the value in the market and maybe use cheap experiments so we do not lose our short and massive bets.

Two-week sprints have quietly become the industry default, and a lot of teams never question it. But the length of your sprint shouldn't be driven by what's most popular — it should be driven by how long it actually takes your team to deliver a Done increment. Anything shorter invites shortcuts and technical debt; anything much longer points to a product backlog problem that a new sprint length won't solve.

Work item types are optional in Kanban — but used well, they can transform how teams read their boards and respond to aging work. This piece walks through a practical example: imagine a red item that's four days old on a board with an 85th percentile SLE of eight days or less. At first glance, it looks fine. But what if red items typically take three days or less? Suddenly, that card is in real trouble. By assigning a Service Level Expectation to each work item type — and showing it visibly on the board — you stop treating apples, oranges, and grapes as if they were all the same fruit. Plus a tip on showing both the 85th and 95th percentiles when there's a big gap between them, why bringing analytics to the board is half the battle, and how to use SLEs without bashing people over the head with metrics.

The Kanban Guide strips Kanban down to its minimal essentials and makes a lot of things optional — including the backlog itself. So where does a funnel fit in? This short piece explains how a funnel works as an optional container in your workflow: a kind of backlog for the backlog, useful when you're working with a roadmap or a now/next/later structure. It's a holding space for ideas that haven't been properly considered yet — submissions that may or may not earn a place in the backlog. Plus a quick reminder that, unlike Scrum, a Kanban backlog isn't necessarily ordered.

The definition of workflow is arguably the most important section in the Kanban Guide — and if you don't get it right, much of what follows simply doesn't work. So what should actually go into it? This piece walks through the essentials: defining the kinds of work items that flow through your system, identifying at least one "STARTED" and one "FINISHED" point, and applying the four key measures — work in progress, throughput, work item age, and cycle time — to each. It also covers the explicit policies that keep a Kanban system honest (replenishment, prioritization, pull, blocked items, exit criteria), the role of service level expectations and rightsizing, and why having more than one definition of workflow on a single board isn't just allowed — it's often exactly what your team needs.

Release planning is built on a promise most teams can't actually keep: that we know what we'll deliver and when. In reality, we're working with so much uncertainty that the most honest answer is "we don't know" — but stakeholders rarely accept that, so we need a better way to share a forecast without pretending it's a commitment. Monte Carlo probabilistic forecasting offers exactly that, provided you avoid burn-up charts, 50/50 dates, and the plumbing problems that quietly wreck your data.