#CS#Methodology#Agile#Kanban#Workflow
Kanban: Just Move the Post-it
Visualizing work flow. Why limiting WIP (Work In Progress) makes you faster.
June 4, 2025
Codemapo
Visualizing work flow. Why limiting WIP (Work In Progress) makes you faster.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.
Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?
Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?
Establishing TCP connection is expensive. Reuse it for multiple requests.
I was drowning in chaos. Running my first startup, I had a tiny team, a massive backlog, and zero clarity on what anyone was actually doing. I thought multitasking was a superpower—juggling five tasks at once made me feel productive. But every evening, I looked at the to-do list and realized nothing was actually done. We started ten things, finished none.
One morning, a developer I was collaborating with taped a whiteboard to the wall and drew three columns with a marker. "To Do", "Doing", "Done". She handed me a stack of Post-its and said, "Write down what you're working on. One card per task." Then she added the golden rule: "Max two cards in Doing. Per person."
I stared at the board. Two cards? But I have twenty urgent tasks! She smiled. "Then pick the two most important ones. Finish them. Then move to the next two."
It felt restricting. But we tried it. Within a week, something magical happened. Tasks started flowing. Done pile grew. Bottlenecks became visible. When cards piled up in "Review", we knew the reviewer was swamped and reallocated resources. When Doing stayed empty, we knew we were blocked upstream.
That whiteboard saved the product launch. The project shipped on time because we could see where work was stuck and fix it in real-time. That was my first encounter with Kanban—a system born in Toyota factories, now running software teams worldwide.
Kanban is Japanese for "signboard". It was invented in the 1940s at Toyota's manufacturing plants as part of their Just-In-Time (JIT) production system. The idea was simple: don't stockpile inventory. Produce only what's needed, when it's needed.
Here's how it worked. When a factory worker ran out of parts, they sent a kanban card to the supplier requesting more. The supplier produced just enough to refill the bin. No excess inventory sitting in warehouses. No waste. Just flow.
This is called a Pull System, as opposed to a Push System. Push is like a chef cooking fifty burgers before customers arrive, hoping they'll sell. Pull is like a chef cooking burgers only when customers order. Push creates waste. Pull creates flow.
Software development used to be Push. "We'll build these twenty features this quarter!" But what if customers don't need them? What if priorities change mid-quarter? Kanban brought Pull thinking to software. Start work only when there's capacity. Finish work before starting new work. This was revolutionary.
David J. Anderson adapted Kanban for software teams in the early 2000s. He realized that software work, like factory work, has a flow. Visualize the flow, limit work-in-progress, and you speed up delivery. Simple. Powerful.
A Kanban board is stupidly simple. You divide a wall (or a digital tool) into columns representing stages of work. The most basic version looks like this:
┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│ Backlog │ To Do │ In Progress │ Review │ Done │
│ │ │ │ │ │
│ [Task A] │ [Task B] │ [Task C] │ [Task D] │ [Task E] │
│ [Task F] │ [Task G] │ [Task H] │ │ [Task I] │
│ [Task J] │ │ (WIP: 2/3) │ │ [Task K] │
│ ... │ │ │ │ │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘
You write each task on a card (physical Post-it or digital card) and move it from left to right as it progresses. The board makes invisible work visible. Before Kanban, I had no idea how many things my team was juggling. After Kanban, I could see at a glance who was working on what, and where bottlenecks were forming.
When we launched our startup's first product, we had thirty tasks on the board. Fifteen of them sat in "In Progress" for days. That's when we realized the problem: we were starting too many things and finishing nothing. The board forced us to confront the truth.
The most important rule in Kanban is Work In Progress (WIP) Limits. You cap the number of cards allowed in each column. For example, "In Progress: Max 3 cards". When three cards are in progress, no one can start a fourth task until one of the three is finished.
# Example: Kanban Column Config
columns:
- name: "To Do"
wip_limit: null
- name: "In Progress"
wip_limit: 3 # Max 3 tasks at once
- name: "Review"
wip_limit: 2
- name: "Done"
wip_limit: null
Why does this matter? Because multitasking is a lie. Every time you switch tasks, your brain pays a "context-switching cost". You lose 10-20 minutes refamiliarizing yourself with the previous task. If you juggle five tasks, you spend more time switching than working.
WIP limits force you to finish what you start. They also force hard conversations about priorities. When a manager says, "Can you also work on this urgent task?", the team can point at the WIP limit and say, "Sure. Which of these three tasks should I stop working on?"
When WIP limits are introduced, the pattern shifts from starting ten things and finishing zero to finishing one before starting the next. Flow replaces chaos, and teams report significant improvements in completion speed.
Kanban measures two critical time metrics:
Think of a restaurant. Lead time is the time from when a customer orders food to when it arrives at the table. Cycle time is the time the chef spends actually cooking.
[Task Requested] ────────────────────> [Completed]
↑ ↑
Lead Time (7 days)
[Work Started] ───────> [Completed]
↑ ↑
Cycle Time (2 days)
If lead time is much longer than cycle time, it means tasks are sitting idle in the backlog or To Do column. If cycle time is long, it means the actual work is taking too long.
When lead time is long (say, 14 days), customers wait a week before work even starts. After implementing WIP limits and removing bottlenecks, lead time can drop significantly — teams have reported cutting it in half or more. Customers notice. Feedback comes faster. Product improves faster.
As you use Kanban over time, you can plot a Cumulative Flow Diagram (CFD). It's a stacked area chart showing how many cards are in each column over time.
Card Count
▲
│ ┌─────────── Done
│ ┌───┘
│ ┌───┘ ┌─────── Review
│ ┌─┘ ┌─────┘
│┌────────┘ In Progress
│└──────────────────────
└──────────────────────────────> Time
The thickness of each band shows how many cards are in that stage. If the "Review" band keeps growing, that's a bottleneck. If "Done" barely grows, delivery is slow.
Reviewing the CFD weekly reveals patterns quickly. If the "In Progress" band swells, it usually means someone is swamped or a bottleneck has formed. Redistributing work or adding reviewers gets flow moving again.
People confuse Kanban and Scrum. Both are Agile frameworks, but they work differently.
| Kanban | Scrum |
|---|---|
| Continuous flow | Time-boxed sprints (2 weeks) |
| WIP limits | Sprint capacity limits |
| No fixed roles | Product Owner, Scrum Master, Dev Team |
| Flexible meetings | Fixed ceremonies (standup, planning, retro) |
| Change anytime | Hard to change mid-sprint |
| Great for continuous delivery | Great for predictable releases |
Kanban flows like water. It's great for maintenance, bug fixes, and continuous delivery. You can change priorities instantly.
Scrum has a rhythm. It's great for projects with clear goals and deadlines. Every two weeks, you plan, execute, review, and improve.
Scrum works well during early product development. Two-week sprints are great for building features. But after launch, teams often switch to Kanban. Bugs don't wait for sprints. When a critical issue appears, you need to fix it immediately. Kanban allows that flexibility.
As your board grows, you can add swimlanes—horizontal rows dividing work by type.
┌─────────────┬─────────────┬─────────────┬─────────────┐
│ To Do │ In Progress │ Review │ Done │
├─────────────┼─────────────┼─────────────┼─────────────┤ Feature
│ [Feature1] │ [Feature2] │ │ [Feature3] │
├─────────────┼─────────────┼─────────────┼─────────────┤ Bug
│ [Bug1] │ │ [Bug2] │ [Bug3] │
├─────────────┼─────────────┼─────────────┼─────────────┤ Urgent
│ │ [Urgent1] │ │ │
└─────────────┴─────────────┴─────────────┴─────────────┘
Now you can see how much time you spend on features vs bugs vs urgent requests. Splitting the board into "Features", "Bugs", and "Chores" is a common pattern. When "Chores" keep piling up, that's a signal that technical debt is accumulating.
Kanban isn't just for teams. I use Personal Kanban for my own work. I keep a Notion board with three columns:
To Do:
- Write blog post
- File taxes
Doing (Limit: 2):
- Writing Kanban article
- Preparing client meeting
Done:
- Workout
- Groceries
Limiting myself to two tasks in "Doing" cured my multitasking habit. I finish one thing before starting the next. The Done column fills up, giving me a sense of progress. To-do lists feel infinite. Kanban boards feel achievable.
Physical whiteboards are great, but remote work demands digital tools.
Simplest. Boards, lists, cards. Great for small teams and personal use. No built-in WIP limits, but you can add them with plugins.
Enterprise-grade. Powerful workflow customization. But complex. Setup takes days. Best for large organizations with complex processes.
Developer-friendly. Keyboard shortcuts, fast UI, clean design. Strong GitHub integration. Popular with startups.
Built into GitHub. Issues and PRs become cards. Integrates seamlessly with development workflow.
# Example: GitHub Actions Automation
name: Move to In Progress
on:
issues:
types: [assigned]
jobs:
move-card:
runs-on: ubuntu-latest
steps:
- name: Move to In Progress
uses: alex-page/github-project-automation-plus@v0.8.1
with:
project: My Kanban Board
column: In Progress
Linear is a popular choice. Issues move across the board automatically as their status changes. Slack notifications keep everyone in sync. "John moved 'Login bug' to In Progress." Full transparency.
Before moving a card to "Done", you need a clear Definition of Done (DoD). Is code enough? Or does it need tests? Code review? Deployment?
Example DoD:
### Definition of Done
- [ ] Code written
- [ ] Unit tests written and passing
- [ ] Code review approved
- [ ] QA tested and passed
- [ ] Deployed to production
- [ ] Documentation updated (if needed)
Without a DoD, "done" becomes subjective. Developers think code completion is done. QA thinks testing is required. With a DoD, everyone shares the same standard.
Kanban's superpower is identifying bottlenecks. Like water flowing through pipes, work flows through columns. When a pipe narrows, flow slows.
How to find bottlenecks:
Code review is a common bottleneck. One reviewer. When they are busy, cards sit in Review for a week. Solution? Add more reviewers. Flow resumes.
Another bottleneck was perfectionism. One developer kept polishing code instead of shipping. We agreed on "80% done is good enough to ship." Deploy, get feedback, iterate. Speed increased.
Kanban pairs beautifully with Continuous Delivery. Instead of releasing every two weeks (like Scrum), you deploy as soon as a card hits Done.
Pairing Kanban with a CI/CD pipeline can shorten the release cycle from two weeks to daily deployments.
# Example: Deploy on Done
name: Deploy on Done
on:
project_card:
types: [moved]
jobs:
deploy:
if: github.event.project_card.column_name == 'Done'
runs-on: ubuntu-latest
steps:
- name: Run tests
run: npm test
- name: Deploy
run: ./deploy.sh
When a card moved to Done, tests ran automatically, and code deployed. Customers got features faster. We got feedback faster. Fast feedback loops accelerated improvement.
Kanban isn't a complex methodology. It's just making work visible and unblocking flow. You can start with Post-its and a whiteboard. Just enforce WIP limits, and speed increases.
During our product launch, Kanban saved us. We put a board on the wall. Every morning, we stood in front of it for five minutes. Each person said what they did yesterday, what they'd do today, and if anything was blocking them. Simple. But that simplicity created transparency and speed.
I still use Kanban for personal projects. A Notion board with "To Do", "Doing", "Done". Limit of two in Doing. Finish one, move it to Done. That moment of satisfaction when a card reaches Done—it keeps me moving forward.
Kanban isn't magic. It's just a mirror showing where work flows and where it's stuck. But once you see the blockage, you can clear it. That's the power of Kanban.