Scrum is a great agile management framework for iteratively developing complex software systems, and it works well in many circumstances. Certain problems can arise, however, such as a highly fluid product backlog, which make kanban’s emphasis on backlog flexibility a more attractive alternative. Software experts like David Anderson, Corey Ladas, Dean Leffingwell, and Linda Cook point to small, loosely coupled user stories with an experienced agile team as key factors for productivity gains using kanban. Yet, few studies exist to show concrete metrics in productivity gain. In this article, I explain our application of reasoning for using kanban and then show how I computed that our productivity gains were more than 300 percent once we started using kanban. I conclude this article with thoughts on applying kanban in your circumstance.
We were in trouble. Our project’s business side began to have difficulty keeping up with the Scrum team’s productivity, and stories were neither groomed nor well thought out enough to be effectively used as part of the sprint. The product owner was changing the backlog at the last minute, inserting stories into the top of our product backlog on the day of planning, reorganizing the groomed stories out of the backlog, and even cancelling stories that were in the process of being worked as part of the sprint. The Scrum team was often faced with the unenviable task of cobbling together a sprint full of unknowns.
To make matters worse, we were ending the phase of large scale stories and entering a phase where alpha clients would introduce small, discrete stories in the form of bugs. A stream of potentially high priority bugs was about to hit us requiring faster reaction than we could handle by collecting the bugs into two week iterations. We had to find a way to make our process more lean.
While agile encourages change, the process cannot be chaos. Scrum requires thought out stories with enough detail that allows for a coherent conversation with the product owner. In our case, the product owner represented the wishes of a number of diverse stakeholders and a constant stream of bug fixes. The product was a new acquisition and everyone, including the product owner, was learning what it should do as we rebranded and integrated the product into the company line.
First of all, the problem was really a symptom of an underlying cause that was not going to be fixed any time soon. The product was new and there were no product experts – we were all learning. The product owner, stakeholders, and development team all were unfamiliar with the product, and we had no great vision to follow. Abandoning a sprint, rejecting stories, or chastising the product owner was not going to move the project along.
We looked to apply lean principles to Scrum’s meta processes and considered ways to shorten the sprint length, the estimation sessions, sprint planning, and sprint demo length even further. This was done with the goal of keeping people working on stories that were of the highest value and well thought out enough that the utility of the stories could be explained. We found that one-week sprints promised to be too long.
After much brainstorming, we decided to use kanban as described by Corey Ladas. We broke sprints down from two-week timeboxes into a single story flow—conceptually a “sprint” became one story and we abandoned the timebox. We limited the teams working on each story to two people—which meant multiple teams were pulling from the backlog—and then kept the work in process (WIP) limited and used the pull technique. Additionally, we developed a ten most wanted list (MWL) for our stories before placing them on a kanban board, and held meetings several times a week to groom the list.