A Productivity Comparison of Kanban and Scrum

• the stories and the limited WIP, which made the negative effect of large stories highly visible by stalling the kanban flow.
• There was no slack time at the end of the sprint.  Often in Scrum when a series of stories in a sprint are completed before the end sprint, the team might slow down, the team might gold-plate because it has time, or the team might decide to work on technical debt. With kanban, there is no timebox—work begins immediately on the next story, so there is less potential for waste.
• Fewer people participated in meetings, which was both an advantage and a disadvantage.  For example, the planning sessions only had the people working on the story in that meeting.  The wisdom of the group was lost, but the productivity time was gained.  Similarly with the demo:  Only those directly involved in the story attended, meaning knowledge transfer was lost.
• We had an experienced, cohesive team that could estimate accurately and didn’t have a significant learning curve.

Kanban does not come without a number of challenges, though. 

• With teams forming and reforming on a story-by-story basis, there was a danger of team cohesion being lost. Fortunately, we did not experience cohesion problems because most team members had been together for a long time.
• Several Scrum measurements were lost: Velocity, burn down, and burn up were not meaningful since there was no timebox. It was hard to gauge productivity and see where gains could be made. Kanban uses cycle time to measure throughput.
• Stories had to be small.  A large story could easily stall the project, negating the positive effects of kanban. The right size (about 5 story points) was only determined through trial and error.  While small stories are important with Scrum, the kanban process made the deleterious effects of large stories highly visible—the flow stagnated.
• It was hard to project when a certain story not on the kanban board would be completed. New stories would be added to the product backlog and priorities would shuffle frequently.

Closing Thoughts
Kanban seems like a productivity boost for Scrum: It increased our productivity by over 300 percent and gave us the chance to react quickly to business changes.  But Kanban is not without its own set of problems. Scrum’s benefits, such as sprint planning, release planning, a sense of rhythm takt, and velocity are either lost or reduced with kanban. Collaborative design is part of Scrum but not emphasized in kanban, since in our case a subteam only worked on a particular story.  Additionally, the teamlet concept can lead to a certain level of lost collaborative design, knowledge sharing, and idea cross-pollination.

Overall, kanban is worth trying in the right circumstances: small, loosely coupled stories with an experienced agile team. Industry reports ( Kniberg and Banks among others) indicate that Kanban works best in this circumstance. Kanban isn’t a silver bullet; it should be applied carefully lest the process devolves into chaos. If you want to learn more, read Corey Ladas’ book  Scrumban or David Anderson’s book on  Kanban.

I’d like to thank Linda Cook, Chris Farrell, and Johanna Rothman for their wonderful insights and assistance with this article.

Further Reading
http://drdobbs.com/architecture-and-design/218000215