Agile is a set of principles for creating software. It doesn’t prescribe a specific methodology. So Agile says, “it is good to reflect on how things are going,” but doesn’t say specifically how to do it. Scrum and Kanban on the other hand are methodologies or frameworks for doing the actual work.
Scrum was created out of Agile, while Kanban comes originally from systems developed by Toyota for managing assembly lines starting back in the 1940s. Scrum is based around iterations while Kanban is based around flow. An iteration in Scrum might be a week long and start with a planning phase where the stories for the iteration are selected followed by development and end with a demo and retrospective. These iterations are typically called sprints. The idea is to get a cadence of a set of features being delivered on a regular basis–typically 1 to 4 weeks. The amount of work that can be in process at one time is limited because the number of stories committed to in an iteration is limited.
Kanban’s focus on flow is more concerned about moving stories through to completion smoothly. There are no iterations and work is limited based on the work in process limit placed on the different types of work. So the development column on a Kanban board might have a work in progress limit of 4 which means the team can’t pull another story into development until something gets pulled out of the development column. This is done to make sure that stories flow through the system and don’t get backed up in front of one resource or one type of work. The people responsible for work in one particular column pull in work from the column to their left when they have capacity. This ripples up stream as columns get an empty slot and can pull from their upstream column. In effect, one story being completed sends a signal up stream than another story can be pulled off the backlog and have work started on it.
Scrum has a Story Board with cards moving across it. Kanban has a Kanban board. Both look very similar, but the way they are used is very different. In Scrum the Story Board is a visual representation of what is being worked on where. In Kanban it is a visual representation, but also a control mechanism to manage the flow of the work. It controls how fast work is released from the backlog. In Kanban, it would be common to create another column to start gathering metrics whenever the team finds some type of impediment. That wouldn’t normally happen with a Scrum Story Board.
For an analogy of the differences between Scrum iterations and Kanban’s flow, you might think of Scrum as being similar to carrying a bucket of water between two points. The water represents work and the bucket represents the iteration. In Scrum you take the bucket to the destination and then talk about how you could do it better, then go back and do it again. Maybe this time you use a slightly different sized bucket, etc. Kanban is more like a gutter running between two points. You pay close attention to any areas that start backing up the water and make sure you don’t pour more water in than is coming out the other end to make sure it doesn’t build up and spill at a curve.
The team I’m currently working with is using Kanban so we have continuous flow for the development. However, we still use iterations for things that can benefit from a cadence–most notably the demos and retrospectives. We also continue to have daily standup meetings. So basically what we’ve done is removed the iteration based work from scrum and replaced it with the continuous flow of Kanban while still keeping the other parts of Scrum.
I’ve heard some people refer to this as Scrum-ban. I’m hesitant to use that term because it sounds silly to me…but I suppose no more silly than Scrum or Kanban.
Howdy Mark, recently I enjoyed and plan to implement your blog post on VisualVM. Very well done BTW. Notwithstanding, I can’t agree about modern XP/Agile/User Story/Scrum (aside: an integrated term would be nice). Recently, I audited a so-called XP/Agile/User Story/Scrum class hosted by a large airline. The target of the class was to implement the 300+ stories generated as ‘new’ code software to consolidate some even dozen disparate systems. The scrum masters and User Story experts consistently pushed the notions of: what, where, when and why. All the while excluding the ‘How’. I soon discovered the reason for excluding the ‘How’. Old code from a previously failed project was introduced as a type of framework around which the complement of developers (including me) were to use as a basis for resolving our individual story assignments. Do you agree with this use of XP/Agile/User Story/Scrum?
So you were at a training class at an airline and in the class they presented old code as a framework? What exactly were they trying to teach in the class?