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.

The second practice in the Kanban Guide is actively managing items in your workflow — and it's all about striking a balance. Finish work. Watch for aging. Don't let the system starve. Sounds simple, but most teams default to one extreme or another. This piece walks through what active management actually looks like in practice: treating blocked items like a fire in the building, looking at relative item age (an item in column one that's the same age as one in column two is actually older), avoiding the temptation to start something new instead of unblocking what's stuck, and being brave enough to cancel work that's quietly on hold. Plus a tip on banana skins as a low-tech aging signal, why classes of service get sidestepped in the Kanban Guide, and why moving work backwards is almost never the answer. Take items as quickly as possible to "finished" — even if "finished" means cancelled.

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.

Cycle time tells you how long a work item takes from start to finish — but cycle time percentiles are where things get interesting. Plot your cycle times on a scatter plot, lift a ruler up the page, and you can see where 50%, 70%, 85%, or 95% of your work items land. That's the foundation of a service level expectation (SLE): a probability-based forecast like "85% of items get done in 12 days or less." But which percentile should you actually use? This piece explains why the 50th is no better than a coin flip, why you should be cautious with the 90th and 95th, and why showing two SLEs on your board can keep you from misleading stakeholders. It also covers when it makes sense to have multiple SLEs for different work item types — a habit that's especially useful outside software.

Kanban is a powerful strategy for optimizing the flow of value through a visual pull-based system — but it's missing one important thing: a compass. This piece explores what Kanplexity adds to the picture, starting with the Cynefin sensemaking framework as a way to navigate complexity. When do you let the experts crack on? When do you run experiments? When does someone need to step in as a dictator in negative chaos? Cynefin helps answer those questions, but only if someone on the team can actually read the compass. That's where the Kanplexity guide comes in — defining the role of a guide, giving clear guidance for leaders cultivating environments where agility can grow, and showing how multiple teams (and even project managers) fit into the picture. Here's how Kanplexity creates clear water between itself and standalone Kanban.

Throughput sounds simple — the number of items delivered to the finish point of your workflow in a given time period — but there's more nuance to it than meets the eye. This piece breaks down what throughput actually measures, why it's tied to valuable work items (not sub-tasks or noise), and how to avoid the apples-and-oranges trap that pollutes so many teams' numbers. It also covers how to handle multiple finish points, why work item types matter more in non-software contexts, and the bigger question lurking behind every throughput conversation: are you delivering real value, or just turning Kanban into another velocity game? Because the goal isn't just shipping more outputs — it's delivering fewer outputs that produce more outcomes.