Heather McLean

It seems that now we have agile processes in place, we’re starting to look at lean as well. The topic of lean software development within the Scrum framework came up at a meeting earlier this week at my office and sparked a lot of discussion. Oddly enough, the topic also came up on David J Anderson’s blog this morning as well.

In particular, some of our Scrum Masters were talking about possibly adapting and adopting Scrum-ban¹, which uses the principles of the kanban² lean production process to implement a pull methodology in Scrum. This looks very interesting on the surface as it affords greater flexibility for inidividual tasks that are under development, but I have some reservations as well.

There are some advantages here that I see as appealing. One of the problems we sometimes run into with Scrum (and perhaps a symptom of our particualr implementation of it) is that occassionaly some team members will be over-allocated and others under-allocated. When we do our sprint planning, we assign stories to particular team members at that time, which obviously has the flaw of not really knowing (especially at this stage of maturity) how well each team member is actually utilized or if they’re going to get distracted with administrative or support tasks during the sprint. Scrum-ban emphasizes only assigning a minimum amount of work-in-progress to get started, then as tasks are completed, team members can pull a new task off the “ready” list. In this way, Scrum-ban seems to be even more “agile” than regular Scrum.

On the other hand, there’s a couple big stickers for me on Scrum-ban. First, it seems to throw iterations out the window on a surface level. As team members constantly pull tasks from the “ready” list, it seems that there is no well-defined start or end to ongoing work without artificially halting the process at some point. This could create a situation where some team members are idle while waiting for others to catch up with the end of the iteration.

Another one is that it seems to move in the opposite direction as Scrum regarding “individuals and interactions over processes and tools.”³ In level 2 Scrum-ban, the process divides up the task queue into several chunks: backlog, ready, specifiy, complete, and done.² (Some of my colleagues proposed additional classifictions, but I will only address the ones described in the article.) I’ll admit I’m just looking at this from an academic standpoint rather than the experience of actual practice, but it appears that this adds more administrative overhead. First, someone has to define what things like “ready,” “specify,” “complete,” and “done” really mean in the particular domain. Second, someone has to be constantly monitoring the ready queue to make sure it has a suitable amount of tasks classified as “ready” available to the team. Third, team members have to do two iterations of each task, first specifying and then completing the actual work. I would argue that specification should have been done before the task was classified as “ready,” though this admittedly depends on your definitions of “ready” and “specify.” Lastly, someone must confirm that “done” items are really done pertaining to the established definition. I think that Scrum-ban at this level is making Scrum more complicated than it really should be.

I’m going to take some time in the near future to analyze Scrum-ban in depth. I think I might be able to use the Scrum/kanban hybrid approach effectively, but it will need to be different than what Scrum-ban proposes to address my particular needs. I’ll post more on that later.

Additional reading:
Managing Change Requests Using Lean Methods and a Kanban Board
KanbanCon