Kanban vs. Scrum - Lessons Learned

My team recently used Kanban for the first phase of a software platform upgrade project. After a recent release we are taking the opportunity to transition to Scrum going forward. This was my first experience with Kanban, and led to some lessons learned from a Product Owner's perspective that may be helpful for choosing between the frameworks for future software projects.

At the highest level, Kanban is a 'pull' system, where the development team takes units of work ("stories") from a prioritized queue of pending requests. When the work is complete, the team selects the next item from the pending queue. The Product Owner may make as many changes as desired to the pending list until an item is selected. In contrast, Scrum teams commit to delivering a total number of story points within a fixed "sprint" iteration. Once the sprint begins, the scope of work for the sprint is fixed. There are several sites providing an overview and comparison between Scrum and Kanban, so I won't try to improve on them here.

Kanban
The biggest advantage of Kaban came from not being bound to fixed-duration iterations (typically 1 or 2 week sprints). We moved an existing inventory of reports, which varid in size and complexity, to an upgraded environment. Our stories - typically a report or "package" of reports - didn't fit neatly into the fixed timebox of a sprint. Attempting to size the stories to make them comply didn't seem to add value to the project. Instead, pending work was queued up by business priority, and the developers simply selected additional work off the queue when the existing stories were complete, in assembly line fashion.

As a result, there was less overhead for planning and estimating. Until a report has been run in the new environment, it is difficult to predict how much rework a set of reports will require to make it work in the upgraded environment. Velocity from one set of reports does not have much value in predicting the velocity for the next set. Instead, I looked backward and took an average of the throughput time (i.e., actual time required to move through the development phase) to help gauge progress.

It is also easy with Kanban to allow an urgent request jump the queue to take priority. This is good or bad depending on your perspective. There is no need to protect the scope of the current sprint, beyond the immediate story that is in progress.

Scrum
Despite these advantages, we ultimately decided to use Scrum going forward for a couple reasons. While Scrum is still relatively lightweight on processes, it provides more structure than Kanban. The process of discussing stories and assigning story points prompts helpful team discussions. A commitment to deliver a certain amount of work is made at the beginning of each sprint, providing some additional discipline and transparency.

Best of both?
There are ways to modify either process to take on some of the qualities of the other. For instance, I'm keeping my Kanban visual board, which works equally well with Scrum. One week
sprints can also increase the team's responsiveness to changing business priorities. To make story pointing more feasible, it could have been possible to have a story for impact assessment in one sprint, allowing for a more reliable estimate on complete testing and rework in the next sprint. In fact, this is what we are starting to do now.

Generally, Kanban seems especially helpful in an operations or helpdesk type environment where sprints of any fixed duration may not be practical. Scrum is my preferred methodology for software development work given the increased structure provided, though Kanban could work for some teams as well.

I'd be interested to hear from others who have experience with both Kanban and Scrum.

See also:
Henrick Kniberg's blog - comparison of scrum and agile
Putting the Lean in Agile - What can we learn from Kanban?