Kanban · Methodologies & SDLC Deep Dive

Anatomy

The Six Practices

Visualize the workflow — columns for each state (To Do, In Progress, Review, Done).
Limit WIP — a hard cap per column; if it's full, finish work before pulling new.
Manage flow — measure lead time and cycle time; smooth out where things stall.
Make policies explicit — what does "done" mean for each column? Who pulls?
Implement feedback loops — replenishment meetings, service-delivery reviews.
Improve collaboratively — evolve the system experimentally.

Why WIP Limits

Less context-switching — humans aren't good at parallel work.
Faster feedback — items finish sooner, reach users sooner.
Bottlenecks become visible — when "Review" is full and stays full, you see the problem.
Encourages swarming — when WIP is capped, the next free dev helps unblock, doesn't start something new.

Metrics That Matter

Metric	What it tells you
Lead time	From request to delivery — what users actually feel.
Cycle time	From "started work" to "done" — team capacity signal.
Throughput	Items completed per week — capacity over time.
Cumulative Flow Diagram	Stacked area chart that exposes growing queues.
Aging WIP	How long has each in-progress item been sitting?

Scrum vs Kanban

Predictable product features with stable team and roadmap → Scrum's rhythm helps.
Mixed work, interrupts, support tickets, ops/SRE, design — Kanban beats Scrum.
Variable item sizes — Kanban tolerates them; Scrum forces them into sprints awkwardly.
Hybrid ("Scrumban") is common — Scrum cadence, Kanban WIP limits.

Tradeoffs

"Just a Trello board" ≠ Kanban. Without WIP limits and explicit policies, it's just visualization.
No built-in cadence — teams need to add review/retro rituals or improvement stalls.
Hard to forecast for stakeholders used to "what will be done by Q3?"; use Monte Carlo on cycle-time distribution.
WIP-limit fights — managers push to start more; the team has to defend the cap.

Continue