May 25, 2008 Kanban: "Just set it and forget it!"
Late last year I set up a kanban system for a Yahoo! India team. They had lots of little features and bug fixes to work on, but they didn’t know how to organize it all to get it done. Scrum wasn’t working well because the nature of the work was too dynamic.
Armed with blue painter’s tape (imported) and post-it’s (imported too) I worked with the lead developer & producer to set it up. I briefly discussed the principals that makes the system work: reduce WIP to increase throughput, use the post-it’s as a signal to begin work.
Time for team indoctrination. The lead engineer explained the system to the folks on the team.
- The producer/product manager will queue up ‘things to do’, limited to 5
- The developers will take the top items from the top of the queue
- When the developers are done, they will be placed in the ‘dev done’ slot
- Then the testers will pick up items from the ‘dev done’ slot and test them
- When the ‘thing to do’ is done to the tester’s and producer’s/product manger’s satisfaction, it’s ready to release.
I sat back and just watched it unfold. Every few weeks I would go by and I’d stop in to see how things were going. The system was just like a machine; it was systematically pushing features & bug fixes through the team in a very transparent way. The tech lead moved to another project and the kanban system kept working. A new product manager came in and the kanban system kept working.
Ron Popeil sells a Rotisserie & BBQ Oven with the tag line, ‘Just set it and forget it!’ My Aunt ordered the machine. The first thing that you see when you open the box is (I’m paraphrasing from memory) “WARNING! While the slogan may be ‘Just set it and forget it!’ it doesn’t mean you can leave the machine unattended at any time. As with any kitchen appliance involving high temperatures, you must take caution.”
This team, did not literally ‘set it and forget it’. But it was a system that worked very for them with few modifications. They were largely in maintenance mode and were tasked with fixing bugs, making performance improvements, fixing production issues and making incremental improvements.
- Comments off
- Posted under Kanban Man!
Permalink #
Chris Newman
said
Very nice – simple and transparent. One question – how are they handling releases – just another item in the ‘things to do’ queue?
Permalink #
joearnold
said
How they handle releases is to create buckets that live in the ‘done’ column. Sometimes when something hits the done column it needs to be deployed immediately (like an emergency bug fix). Sometimes the team is working on two different products at the same time. The team uses different colored post-it notes for each product. Each product has its own bucket where features/bug fixes congregate — waiting for the next release for that product. As for the ‘activities related to a release’ task. I don’t think they create another ‘thing to do’ that works its way through the kanban system. When it’s time, I think the team just re-evaluates everything in that bucket before launch.
Permalink #
Anonymous
said
When a tester discovers a bug in a “dev done” item what happens? does it move back into the “under development” column?
Permalink #
joearnold
said
That’s one option. Usually what this team does is leave it in ‘test’. The developer works with the tester to fix it. This is the ‘stop-the-line’ mentality of bug fixing. If a bigger issue comes up, then another ticket is created and is prioritized by the product manager. There are a couple of other possibilities too. Check out my post on ‘What to do with bugs when using Kanban’
http://joearnold.com/2007/12/what-to-do-with-bugs-when-using-a-kanban-system/