The SDLC & Methodologies

Kanban & Lean Thinking

18 min Lesson 6 of 10

Kanban & Lean Thinking

When a development team adopts Scrum, they gain sprints, ceremonies, and velocity charts. But some work does not fit into two-week boxes — a support queue, a continuous deployment pipeline, or an ongoing regulatory review. For those contexts, Kanban offers a different answer: visualize every piece of work, limit how much you can hold at once, and watch bottlenecks expose themselves naturally. This lesson explains Kanban, the Lean philosophy it draws from, and why every systems analyst should understand both.

The Origins: Lean Thinking from the Toyota Factory Floor

Kanban was born not in a software company but in a Toyota car plant in the 1950s. Toyota engineers observed that overproduction — making parts faster than the next station could consume them — created mountains of costly inventory. Their solution was the kanban card (Japanese for "signal card"): a physical card attached to a bin of parts. When a bin was emptied, the card traveled back upstream as a signal to produce exactly one more bin. Production was pulled by actual demand rather than pushed by a forecast.

The broader set of ideas around this practice became known as Lean Thinking, and it rests on two pillars:

Maximize value — focus every activity on what the customer actually needs.
Eliminate waste — remove anything that consumes time or money without adding value. Toyota named seven classic wastes: overproduction, waiting, unnecessary transport, over-processing, excess inventory, unnecessary motion, and defects. In software, these translate to unfinished features, handoff queues, redundant meetings, gold-plating, large backlogs, task-switching, and bugs shipped to production.

In 2007 David Anderson applied these ideas to software teams, publishing what became the Kanban Method for knowledge work.

The Kanban Board: Your Flow Visualizer

The central artifact is the Kanban board — a grid of columns representing the stages a work item passes through from request to delivery. Consider an online store building a customer self-service returns portal. Their board might look like this:

A Kanban board for the returns portal team. Development is at its WIP limit of 3 — no new card may enter until one exits to Review.

Each card (sometimes called a work item or ticket) represents a feature, a user story, or a bug. Cards move left to right as work progresses. The columns in the example above are: Backlog → Analysis → Development → Review → Test → Done. Your team might use different column names, but the principle is the same: make the invisible visible.

WIP Limits: The Engine of Flow

The most counter-intuitive and most powerful practice in Kanban is the Work In Progress (WIP) limit — a maximum number of cards allowed in a column at any moment. In the board above, Development has a limit of 3. When all three slots are filled, no new card may enter Development until one moves to Review. Developers who finish a task cannot grab the next backlog item; instead they swarm on existing items to unblock the bottleneck.

Why does this help? Because multitasking is waste. Context-switching costs an analyst or developer 15–30 minutes of ramp-up time per switch. A team working on 10 items simultaneously delivers all 10 slowly and unpredictably. The same team capped at 3 active items finishes items faster, finds defects sooner (the code is fresh in memory), and makes the pipeline's true constraint obvious.

Identifying bottlenecks: When a column is persistently full and the column to its left keeps accumulating cards waiting to enter, you have found your bottleneck. Kanban does not hide this — it forces the conversation. The systems analyst's job is to diagnose why the bottleneck exists: understaffing, unclear requirements, missing tooling, or a slow approval gate.

Core Kanban Metrics

Two metrics give a Kanban team its feedback loop:

Lead Time — the elapsed time from when a card enters the board (customer request) to when it exits Done. This is what the customer experiences. A logistics firm tracking a new shipment-exception workflow cares deeply about lead time: how many days from "we identified this gap" to "the fix is live"?
Cycle Time — the elapsed time from when a team member actively starts work on a card to when it is done. This is what the team controls. Shortening cycle time by removing internal blockers directly shortens lead time.

A Cumulative Flow Diagram (CFD) plots the count of cards in each column over time. Parallel bands that stay roughly equal in width indicate a healthy, stable flow. A band that balloons signals accumulation — a bottleneck in that stage. Analysts use CFDs in retrospectives to provide evidence for process improvements rather than arguing from anecdote.

Lean Waste in Knowledge Work

Kanban's Lean lineage means the team regularly asks: "Is this step adding value or is it waste?" Common wastes a systems analyst might surface during a board review at a clinic building an online booking system:

Waiting — a requirements card sits in Analysis for three days waiting for a stakeholder to confirm the appointment-cancellation policy. Root cause: decision-maker not included early enough.
Over-processing — every wireframe must pass through two rounds of management sign-off even for trivial UI changes. Root cause: outdated approval process copied from a paper-forms era.
Defects — five cards per sprint return from Test to Development because the acceptance criteria were ambiguous. Root cause: the analyst's Definition of Ready is too weak.
Inventory (large batches) — thirty requirements written up-front before development sees them. When priorities shift, most are thrown away. Root cause: big-design-up-front habit.

The analyst's role in a Lean team is to keep the Definition of Ready sharp. A card should not enter Analysis unless the business question is understood; it should not enter Development unless acceptance criteria are clear and testable. Tightening this gate eliminates the most expensive waste: rework.

Kanban vs Scrum: Choosing the Right Tool

Kanban and Scrum are both Agile approaches but serve different contexts. Scrum works best when work can be planned in batches and the team needs rhythm: sprint reviews, sprint goals, and velocity tracking. Kanban works best when work arrives unpredictably, priorities shift daily, or the team runs an operational service alongside project work. Many mature teams run Scrumban — they keep Scrum's retrospectives and reviews but replace fixed sprints with Kanban's continuous flow and WIP limits.

Kanban is not "no planning". Teams without WIP limits and without regular retrospectives are not doing Kanban — they are doing unmanaged chaos with sticky notes. The discipline is in setting limits, measuring flow, and acting on the metrics. Without these three things the board is just decoration.

Kanban for the Systems Analyst

Even if your team uses Scrum or a waterfall phase gate, Kanban thinking sharpens your analysis practice. Use it to map the current state of a business process: draw every hand-off, every wait, every approval. Then identify which steps add value and which are waste. This "value stream map" is one of the most powerful tools in the systems analyst's kit — and it is pure Lean thinking applied to process redesign rather than software delivery.

In the next lesson we examine the analyst's specific role inside Agile teams — how to write user stories, manage the backlog, and collaborate effectively with developers who are moving fast.