Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Is Kanban? From Toyota to Software, and Why It's More Than a Board
Kanban is not a board but a strategy that optimizes the flow of value by limiting WIP; the board only makes it visible. Using the Bookstore support team's board, we trace the path from Toyota's pull system to Anderson's work at Microsoft and Corbis, compare the Kanban Method with The Kanban Guide 2025.5, and introduce the Guide's three practices and four flow metrics.
The Definition of Workflow and Board Design: When Work Starts and When It Finishes
What turns a board into Kanban is the Definition of Workflow behind it: the work item definition, started/finished points, states, WIP control, explicit policies and an SLE. We build the Bookstore team's board from these six parts, separate queue and active states, show how tying Done to the production deploy instead of the merge changes cycle time, and cover common board design mistakes.
WIP Limits and Little's Law: Start Less, Finish More
With throughput fixed, raising WIP stretches cycle time by the same factor; Little's Law is the arithmetic behind it. In our C# simulation, raising WIP from 3 to 10 takes average cycle time from 2.4 to 7.9 days, and adding context switching cuts throughput too. We cover Little's Law's assumptions, why it is not a forecasting tool, how to set a first WIP limit and pitfalls like per-person limits.
Flow Metrics: WIP, Throughput, Work Item Age and Cycle Time
We compute the Kanban Guide's four mandatory metrics, WIP, Throughput, Work Item Age and Cycle Time, from six months of the Bookstore team's board data with a .NET 10 console app. We see why percentiles beat the average, how to read a cycle time scatterplot and an aging chart, why Work Item Age is the earliest warning, and how measuring from the Created date turns a p85 of 14 days into 79.
Service Level Expectation and Monte Carlo: Answering "When Will It Be Done?" with Probability
For a single item the answer is the SLE ("85% within 14 days"); for many items it is a Monte Carlo simulation that samples historical daily throughput. Running 10,000 times on Bookstore data, our C# code says 30 items finish by 25 November with 50% probability and by 6 December with 85%. We cover reading percentiles from the right end, explaining forecasts to stakeholders and when the forecast goes wrong.
Actively Managing Flow in Kanban: Blockers, Aging and Flow Reviews
Actively managing flow means reading the board right to left from the oldest item every day, escalating blocked work, limiting expedite and finding the bottleneck with data. We compute CFD band widths from Bookstore data in C#, see how Code Review became the bottleneck in July, how the Theory of Constraints steps solved it (p85 from 16 to 11 days), and why the next constraint is the deploy rhythm.
Scrumban and the Kanban Guide for Scrum Teams: Adding Flow to Scrum
Adding flow to Scrum doesn't require dropping the Sprint: the Kanban Guide for Scrum Teams adds a DoW, WIP limits and the four flow metrics to Sprint Planning, the Daily Scrum, Review and Retrospective without changing any part of the Scrum Guide. We cover Scrumban as Ladas described it, as a transition path, its loose use today, and choosing Scrum, Kanban or both for support, platform and product teams.