Kanban Vs. Scrum
Most forward-thinking software organizations have already accepted that they need to be agile in order to compete in a market whose evolution is accelerating faster than ever before. Of course, being “agile” is a fairly vague descriptor. However, those readers who have successfully implemented agile management and engineering techniques at their organization know that for the vagary embedded in the phrase “agility,” real organizational change occurs through very specific activities. That is, agility entails much more than simply declaring one’s self to be agile. Instead, true agility is the result of dedicated observation of agile values and the committed practice of its processes.
Tomas Björkholm understands this, as illustrated in his detailed investigation of the differences between two agile practices: Scrum and Kanban. In an article recently published on the Agile Journal website, Björkholm lays out the primary differences and similarities between the two methods and then weighs in on what he thinks is most valuable about each one. Certainly, they share some important sensibilities, since Kanban is most closely identified with the Lean movement, which also influenced the development of Scrum. But what differences they have make a big difference and the author astutely teases out why, for instance, Scrum’s use of iterative work cycles (i.e. sprints) is superior to Kanban’s view of work as a continuous flow. (For starters, there’s a crucial psychological factor to sprints: Scrum’s “chunking” of work enables developers to really focus on the most immediate tasks, rather than become distracted or overwhelmed by a never-ending stream of work.)
If you’d like more information on either Scrum or Kanban or would like to see an expert dissection of the two methods, I’d recommend you check out the article.