In this post I want to address most typical questions about Kanban. Entire content of this post was an email I sent to my IT group after the meeting in which I introduced Kanban.
1. why limit work-in-progress to only a few simultaneous tasks?
2. why limit releases to one feature per release?
3. how does the board help us?
4. this is all fine but what if an urgent issue comes up, won't this game be abandoned?
5. what's in it for me? (a developer)
6. what's in it for me? (a PM)
1. Limiting WIP helps control multitasking. Multitasking costs 20% overhead per each extra task due to context switching, induces stress ("so much on my plate"), and lowers quality (things fall through the cracks, everything's done in a rush). Lower quality causes rework (fixing the issues), the rework in its turn feeds the multitasking cycle. Having less simultaneous tasks than people also means people start helping each other (teamwork!).
Next natural question is: "but if we limit WIP how do we make progress on all those initiatives" -- and the answer is: by making each trackable task as small as possible developers can take turns working on tiny useful items in each competing initiative. From higher level this will still be (pseudo)multitasking, but at the lower level each developer will never have more than one, small item on his plate.
2. "Why limit releases to one feature per release?"
Because it 1) solves the multitasking issue, 2) allows each feature to be tested right after it's developed (if bugs found they will be easier to fix since dev will still be "in the context") and 3) makes deployment simpler, faster, and less likely to break. Also, it makes prioritization and planning less big of a deal, since other initiatives don't have to wait months to get some action. With one-feature-per-release we can make incremental improvements to each of our initiatives EVERY DAY. "So what if this feature was misprioritized as high priority? It will be done in a day or two and then we can work on the right one." Finally, it will eventually enable Disney Line Planning, based on the average time each tiny item spends in the works. (Actual MEASURED time, not predicted time). So if we succeed in chunking our work in pieces that take 10 days each, from conception to PRODuction, and there are 10 other items in front of X, WE KNOW that X will be completed in 100 days. "Nice theory" you may say and I will say: Aren't computers a theory? Aren't logistics a theory? Aren't finances a theory?
3. "How is the board gonna help?"
By making our current process visible, by making the issues obvious, by forcing all requestors check their assignments to devs against each other, since they will collide on the physical space of the board.
"But why is it a board on the wall, couldn't it be a spreadsheet?" -- Because there may be multiple spreadsheets but only one Wall. Because working with stickies is simpler. Because the Wall is in your face, therefore harder to ignore. Because writing with a pen on a media you can't edit, helps ensure that only well-understood stuff is written (= no B.S.). Because working with physical cards activates spatial memory (=B.S.). Because the Wall's limited space nicely models our team's limited capacity.
4. "This is all fine but what if an urgent issue comes up, won't this game be abandoned?"
Urgent issues will be scheduled on the queue, just like everything else. The only difference, they will skip directly to the head of the queue without waiting to be promoted from low level to medium and then to high. They will still have to wait for work-in-progress to complete. If we agree on the small work item concept, this will be less of a an issue cuz the wait time will be smaller.
True emergencies will be handled outside of this system, just like they always are.
5. "what's in it for me? (a developer)"
You will be protected from craziness and mess, you won't have to do estimates, your status meetings will no longer be painful.
6. "what's in it for me? (a PM)"
If this fails, you will know you were right. If this succeeds, you will have learned something.
Tags: