Pants. I put them on every weekday

I use Kanban when I can’t make promises. For example, when I first spun up the design team at Company Y99, the headcount was 100% allocated to client product development and marketing had no resources on its own. But there were unpredictable short spans of downtime, depending on the vagaries of the clients’ opaque internal mechanisms. Kanban was fine for maintaining a prioritized backlog of collateral requests. The only thing I promised was that the top of the pile would be worked on next, whenever that was.

 

I didn’t make promises in Kanban because Kanban is terrible for managing unpredictable tasks. It’s fine for managing unpredictable demand for known tasks. That’s what it was built for. Kanban came out of Just-In-Time supply chain management for manufacturing. Every task in a Kanban manufacturing process represents a new instance of an already known self-contained process loop. We need 50 new widgets. The R&D of what a widget should be, what it does, what it’s made of, and what it looks like is not part of that supply chain feedback loop.

 

In software development, the manufacturing part of our supply chain is instantaneous and essentially free. When you design and engineer a car, the bulk of the work is the laborious fabrication and assembly of each individual copy. When you design and engineer an iPhone app, the duplication of the prime instance into the many copies onto customer iPhones is not your problem. Apple handles your Just-In-Time manufacturing. 

 

So we spend 100% of our time on the design and engineering side. In new product development, that means we have no blueprint of what to expect. The central problem of managing software is keeping promises—promises to the business, to the customer, to each other—in a complex and ambiguous environment. Which is exactly what Kanban sucks at. Kanban is good for, “What am I going to do today?;’ it is terrible at “What all are we going to deliver over the next quarter?” Because Kanban is myopic and one dimensional. Kanban’s single dimension is relative priority, which is useless for predicting when a large, complex new product will be ready to go out the door.