Excess WIP = WASTE<br />More WIP = longer lead time<br />More WIP = higher probability that one of the stories being worked on will change<br />More WIP = more context switches for developers<br />
Solution: Limit WIP<br />Number of WIP slots in development should be proportional to team size (factor to be determined by trial and error)<br />Each slot represents a workflow state<br />In Development (4)<br />Specified (3)<br />Backlog (4)<br />Ready for QA<br />Ready to deploy<br />
Limits help to identify bottlenecks<br />Here, the developers working on new features are starved of work because there are no more slots left in the “In Development” board section.<br />In Development (4)<br />Ready for QA<br />Specified (3)<br />Ready to deploy<br />z<br />z<br />z<br />
Temporary solution = reassign developers to parts of the board where work can be done<br />Long-term, work on eliminating the bottlenecks<br />In Development (4)<br />Specified (3)<br />Backlog (4)<br />Ready to deploy<br />
Where Kanban can borrow from Scrum<br />Daily stand-ups, always held around the Kanban board<br />Prioritisation – maybe with a fast-track across the kanban board for urgent issues<br />
Where Kanban differs from Scrum<br />No time-boxed iterations – focus is instead on lead time which can be more consistent and useful than velocity in a project where work is sporadic<br />Detailed estimation considered wasteful<br />Estimating entire backlog is also a waste<br />Scrum limits WIP per iteration; Kanban limits WIP per workflow state<br />
Possible benefits<br />Workflow states bear some resemblance to a waterfall methodology and are easy for customers to understand<br />Kanban is suited to ongoing development and maintenance rather than time-boxed, feature-limited projects. In my experience, every project we have done ends up being ongoing.<br />
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.