Kanban 


Background

Perhaps you covered Taiichi Ohno’s Kanban system in undergrad business school. Back in the 1940’s at Toyota, he created a planning system that was genius in its simplicity and focus on a lean value chain—from production to customer. Crucially, overstocking and waste left on the factory floor is minimized. More recently back in 2004, David J. Anderson applied this principle to software development (Sidenote: His 2010 book KANBAN: Successful Evolutionary Change for Your Technology Business is on my to-read list).

According to Kanban Guides (2022), Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization.

Kanban Method in Software Development

Today, my team uses Kanban. We have a Kanban board to visualize the workflow, to manage the Work in Progress (WiP) and ensure we continually optimize the flow of work items (also known as stories) to optimally, deliver incremental value—pulling from right to left.

That’s a key part.

When a developer completes a work item, they then pick up the next item priority-queued for development. 

So in Kanban, the work is pulled through the board, rather than pushed.


Example Kanban boards

A typical Kanban board is made up of multiple lanes reflect each phase of a story. Each lane has a story cap as to not overload the flow and throughput. It’s about continual flow.

Here’s an example of Kanban boards lanes:


Call outs:
  • Research & Discovery doesn’t always exist. 
  • I’ve seen Design called Being Designed, to be more active. I quite like that. 
  • I’ve seen Design & PO Review split into Design Review and PO Review. 

It’s down to what works for the respective team. Each team sets their lanes from inside to out, agreeing them in the Definition of Workflow.  The lanes and ways of work ing can and should change based on retrospective learnings. So the Kanban model is continually refining itself based around value delivery and the team norms. 

 

Retrospectives

Each sprint, you’ll have a retrospective to continually improve the process. Briefly, it’s what worked, what didn’t work, what are opportunities to improve.

Pros ✅

I’m a big advocate of incremental growth, value and improvement. Small changes do make big differences. And each incremental of value is broken down so that no waste if ever left on the floor, if an MVP remains and MVP or even if a project is cancelled.

So ideologically, I love Kanban.

I also think the long-term throughput and team health/happiness is better than Scrum, for example, and reduces burnout.


Cons ❌

As work is pulled from right to left, rather than pushed from left to right, it means its harder for product/Go to Market/Marketing to be certain when an MVP will be reached (the launch date). The idea is that software is deployed daily as it becomes available, delivering chunks of incremental value in real-time.

And as there aren’t Sprint Goals or deadlines (in theory), it feels like short term productivity and throughput feels slower—but at the betterment of long term productivity and flow.