http://www.estalea.com/blog/ en cotterpop@gmail.com Copyright 2010 2010-07-30T17:26:07+00:00 http://www.estalea.com/site/scrum_vs_kanban/ http://www.estalea.com/site/scrum_vs_kanban/#When:17:26:07Z I’ve been getting asked a lot lately about Scrum vs Kanban and which is better?  In short, the answer really depends on the situation.  A longer answer follows. I have found that Kanban tends to emphasize the task at hand, while Scrum tends to emphasize the team and what each person is working on. A daily Scrum meeting tends to go person by person, a daily Kanban meeting tends to go task by task. You might also hear the term Scrumban, which tends to take parts of each and merge them together into one method. For the past few years I have been implementing Scrum and Kanban in various roles at a number of companies and have come to a few conclusions as to when to use which method. Scrum, which has perhaps the greatest adoption (and mis-adoption) among tech companies, is not always best solution in all circumstances, and in some cases, I have seen its introduction do more harm than good, but that's another post. The following is a rough outline that I use to determine which method to try. When to try Kanban. High Interrupt Systems like a TechOps / SysOps team, or a Design Team or Sales Team. These teams generally have either lots of ASAP projects, or will have to deal with changing requirements up to the last minute. Non-Release Dependent Teams like a TechOps / SysOps team, or development teams that release per feature, or outside of a set schedule. These teams tend to release things as soon as they are done, rather than waiting and grouping them together to release every 3 weeks or month or other "arbitrary" time block. When to try Scrum. High Interrupt Systems: (wait, didnt I just say Kanban for this?) Sometimes, Kanban and High-Interrupt doesn't work and just leads to churn at the front end of the process. In cases like this it can sometimes help to use Scrum, or specifically the sprint period, to "freeze" changes for a week or two (the length of the sprint cycle) until you get things under control, and are able to turn it into a Low Interrupt system. The Paradox here is that sometimes you will want to use Kanban to deal with a Scrum process that is churning (lots of changes coming in mid-sprint), basically if you are unable to stop the Interrupts. Low Interrupt Systems: Generally this occurs when the management team has a clear long term vision. This allows everyone to develop a 3 week or even 3 month plan, and stick to it. Many Primary Stakeholders: In this situation, where there are multiple high level stakeholders competing for resources, it can help to let them fight it out internally for a few weeks before settling on a properly ranked backlog for the next sprint. Essentially, you are freezing the backlog once every 3 weeks or so. This works most effectively when you have a CEO or head of Product that can be the ultimate owner and facilitate over the ranking of issues. Release dependent processes: Some processes require set, timely releases. Although you can still achieve this using Kanban (or even Waterfall), Scrum gives you the time-boxed sprints and burndowns that allow you to present a feature set and velocity most transparently. This can be extremely important when the end customer needs to be able to schedule work on their end to absorb your work. The end customer could be external or internal to your organization. This is not meant to be an exhaustive list, just some thoughts I had on the subject. As with either of these methods, make sure you keep doing what works, and stop doing what doesn't, and have regular retrospectives to evaluate your progress. 2010-07-30T17:26:07+00:00