What exactly is cycle time in Kanban — and why does it matter? In the context of knowledge work, cycle time measures how long a work item takes to travel from a starting point to a finishing point in your workflow. But there's more nuance than meets the eye: should you measure work days or elapsed time? How do you handle holidays, weekends, and that one teammate on vacation? And why does an item started and finished on the same day have a cycle time of one, not zero? This piece walks through the practical definition, explains why elapsed calendar time keeps standards from eroding, and shows how cycle time scatter plots can help you build a service level expectation — turning historical data into a practical tool for rightsizing future work.
How do we deliver value in Kanban and isn’t Kanban just about outputs?
Isn't Kanban just about outputs? Doesn't it miss a trick on value and organizational capability? This piece pushes back on both assumptions, using Scrum.org's Evidence Based Management framework — with its four key value areas of current value, unrealized value, time to market, and ability to innovate (or, more honestly, "inability to innovate") — as the lens. The argument: Kanban is a strategy for optimizing the flow of value, not just stuff out the door, and when used with discipline it improves all four areas. Along the way: why classes of service often make things worse (with a thought experiment about queues at the Ukrainian border), why intangible work earns its keep, why prioritizing already-started work is a classic trap, and why the dance of finishing, watching for aging, and avoiding starvation is the heart of doing Kanban well. Take the time it takes, so it takes less time.
Why adding Lean UX to Scrum with Kanban is integral to the future of agile?
Scrum with Kanban already gives teams a serious edge in delivering value on a steady cadence — but how do you know you're delivering the right things? That's where Lean UX comes in. With two-thirds of product features rarely or never used (according to the Standish Group's CHAOS report), the cost of building the wrong thing is staggering. This piece explores how layering Lean UX techniques onto Scrum with Kanban helps teams discover unmet customer needs, test risky assumptions, and avoid building products nobody wants. A walkthrough of the Lean UX canvas — from framing the business problem to identifying the assumption that could sink everything — shows how humility, experimentation, and data-informed decisions create both better products and more rewarding work.
How Kanban helps people solve complex problems
Kanban is a strategy for optimizing the flow of value — and that makes it especially well-suited to complex work, where uncertainty is the rule, not the exception. This piece walks through the Kanban practices through a complexity lens: defining and visualizing the workflow so signals (and signals of trouble) become visible, actively managing items so nothing ages or stagnates, and continuously improving the workflow to strike a better balance between effectiveness, efficiency, and predictability. There's always a bottleneck in complex work — if there weren't, capacity would be unlimited — and finding it isn't about blame. Plus a real example from a fast-moving consumer goods marketing team that solved a hidden bottleneck simply by adding a swimlane per dependency partner. A reminder that the board should serve the people doing the work first, with executives getting clarity as a bonus.
How can Scrum with Kanban help people solve complex problems?
Scrum already helps teams deal with complexity — so what does adding Kanban bring to the mix? This piece looks at how Scrum with Kanban tightens the empirical loop, sharpens focus, and helps teams navigate complexity more easily through one definition of workflow, four practices, and four measures. From visualizing aged work, blockers, and unacknowledged dependencies, to using throughput and Monte Carlo probabilistic forecasting in Sprint Planning and Sprint Review, to managing expectations early enough to course correct — this is about more than visual boards. It's about avoiding execution bias, dodging groupthink, and not falling into the "build it and they will come" trap. Because in complex environments, simply talking to the customer beats a fantasy of what we think they want. Plus a reminder that value today isn't just about customers and the organization — it's also about sustainability, risk reduction, and learning.
Tameflow, Scrum with Kanban, the Kanban Method, Kanban – the Flow Strategy, Kanplexity, Enterprise Flow, Flight Levels, Vanguard Method, and Paddy Irish Man walk into a bar. What follows is a satirical send-up of the flow methods landscape, where each approach orders a drink — and reveals its personality in the process. Tameflow obsesses over constraints. Scrum with Kanban won't compromise the goal. The Kanban Method declares itself the chosen one. Flight Levels wants air traffic control. Vanguard Method wants the backlogs gone. WIP Limits is the bar manager. And Paddy Irish Man just wants five Guinness before closing time. By the end of the night, fever charts are out, walls are being painted "Scrum," and Cynefin walks in to declare who's right — without explaining why. A loving roast of an industry that takes itself a little too seriously.
A Deeper Look - Client Reports Back on Progress After PSK Class
What does Professional Scrum with Kanban actually look like a year on? In this client report-back, "Lucy" — wearing developer, manager, and scrum master hats — walks through the wins, the struggles, and the eureka moments. Like the lightbulb moment when she realized a Kanban system could go upstream and downstream and capture the entire value chain. Like the five sprints it took to get rid of story points, and the six months it took for probabilistic forecasting language to land. Like adjusting WIP limits over a couple of sprints until the team hit equilibrium and stopped delivering everything on the last day. Plus the messy bits: a re-org that broke the Nexus, a Jira workflow that forced story points back in (so the team put five on every story), and the brutal trade-off of stepping back from coding to be a better manager. Honest, practical, and full of moments other practitioners will recognize.
A Client Reports Back on Progress One Year After a Professional Scrum with Kanban Workshop
It's easy to obsess over the Trustpilot review right after a workshop. Did I entertain? Did I perform? Were people satisfied? But the real question is whether the workshop made a difference to the work lives of attendees a year later. This piece is a candid client report-back, broken into the good (multi-team workflows, Monte Carlo probabilistic forecasting, more frequent delivery, higher customer satisfaction, and new team members picking up Scrum with Kanban from their colleagues without training), the bad (newer teams without colleagues to learn from dismissing Kanban as "overkill" and never looking at the cumulative flow diagram), and the ugly (no full-time Scrum Master worrying about flow, and an expedite lane that would make Daniel Vacanti weep). Plus a personal note from one team member on how it changed the trajectory of their career. A reminder that a little knowledge can be dangerous — but a lot of it can be transformational.
Introducing Kanban for Complexity™ (Kanplexity™)
Scrum operates in the complex problem domain, but what happens when teams genuinely can't deliver potentially releasable value in 30 days — or even 90? This piece introduces Kanplexity, a variant of Kanban designed for teams working deeply in the complex space, where unknowns outnumber knowns and team members' belief systems may sit closer to Kanban than Scrum. Built to complement what teams already do and support both the complicated and complex domains of the Cynefin sensemaking framework, Kanplexity uses rhythmic cycles instead of sprints, two roles (Teams and Servants), five events, and an emphasis on small self-managing cross-discipline teams learning from stakeholders in fast feedback loops. It supports discovery and delivery, attempts to avoid the Innovator's Dilemma through both disruptive and sustaining innovation, and offers tried-and-tested strategies for scaling beyond two teams. The price of entry: complexity sense-making, embracing uncertainty, optimizing WIP, explicit policies, and avoiding local optimization.