Scrum or Kanban… it’s not Black or White
It’s been fun the past few months to watch Kanban get some traction out in the agile community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson… this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.
One of the things I find really interesting are the words some folks use to describe the value of Kanban. They are using words like ‘increased visibility’ and ‘buidling trust’ with the business. While I wouldn’t argue with any of that… I am struggling to figure out how the benefits of Kanban are any different from how we would describe the benefits of Scrum?
If both methods ‘increase visibility’ and ‘build trust’… there has to be something more. In my opinion… the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.
Let me explain…
Scrum takes the approach that the team is a black box. The business puts requirements in… and after some predetermined amount of time… they get working software out. Within that black box… the scrum team gets to self-organize… they get to self-manage. The business gets to decide what… the team gets to decide how. The processes inside the team are abstracted from the business AND from management.
Kanban software development takes the approach that the team is a white box. The business puts requirements in… but rather than leave it up to the team to figure out how best to deliver the work… management plays a role in defining the work. There are explicit workflows… work in process limits… and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.
One of the earliest agile books I ever read was Mary Poppendieck’s ‘Lean Software Development: An Agile Toolkit”. Not long after that I read David Anderson’s “Agile Management for Software Engineering”. Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months… I found myself wondering what was so new.
We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered… we are encouraged to help them get finished before we start on something new.
Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints.
For some teams… in some environments… it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That’s where I am not totally sold. For now… for me… Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.