The job search chronicles
What do you think of Scrum vs. Kanban?
About this series: Looking for my next adventure I’m participating in more interviews wherein I get asked questions that cause me to reflect a bit. These are those reflections. Note: These may not be the responses I actually gave.
This one might be a little weird.
I say it will be weird because these two things are not mutually exclusive though some folks think they are. In fact chances are, if you are using an Agile framework of any type, you are using aspects of one, the other, or both.
I wish I could make tables.
All right, first things first, Scrum is defined by the Scrum Guide, not because I said so but because Jeff Sutherland and Ken Schwaber the creators of Scrum (and two authors of the Manifesto for Agile Software Development) say so…they are, after all, the authors of the Guide. Kanban, on the other hand, as a framework doesn’t really have a guide or identified creators (having said that, I will be using Essential Kanban Condensed from David J. Anderson and Andy Carmichael via Lean Kanban Inc. because it is the closest I could find to a canonical reference).
Scrum and Kanban both seek steady delivery of value to users of the product being created. Scrum focuses more on interactions of individuals while Kanban focuses on the flow and visualization of work through the system. Both can be viewed as additive or atomic in nature, which is to say they describe a base upon which to build; the Scrum Guide, however, does say if you take away any component in the guide then you can no longer say you are doing Scrum — not that you have to do Scrum mind you, just don’t say you are, it’s misleading. This atomic nature also means, much like a software system, you can plug these two things together (most people do in fact and some even call it Scrumban).
Scrum consists of 5 values, 4 events, 3 roles, 2 backlogs (product and sprint), and 1 potentially releasable product increment at the end of the Sprint. Kanban has 9 values, 6 principles, 6 practices, 3 agendas.
That’s it. No really, that’s it. Anything beyond that is an add-on to the overall product development game we are engaged in.
The task-board with to-do, doing, done (or whatever your equivalent is) that helps visualize the work flowing through the system? That’s Kanban, not Scrum.
The user stories we fill the board with? That’s Kanban (the literal definition of Kanban focuses on the card…having said that, user stories really got their start in Extreme Programming).
The metrics we use to try and measure work? Not Scrum. Mainly, from Kanban; measuring the flow of work, lead times, and so on.
Limiting work in progress? Kanban.
Having the roles of Product Owner, Scrum Master, and development team member? Scrum.
Estimations and story points? Neither Scrum nor Kanban.
The belief that you must wait until the end of a Sprint in Scrum to deliver a product is a myth, you can ship whenever you want.
Scrum specifies the frequency and means for feedback loops while Kanban allows for a fluid response to visualized data. Scrum also gives specified times for the team to celebrate the work and improve their internal processes while Kanban does not.
Scrum can cause an organization to change a lot before being able to say they are “doing Scrum” — new roles, create a backlog, and so on. Kanban, on the other hand, is more about “starting from what you do now” and making changes over time that get you somewhere…possibly even to Scrum…and then you may decide to stop doing Scrum again.
And, at the end of the day, the real questions are: What do the people doing the work think is most appropriate and comfortable for them? And why (just to make sure they’ve considered the cons as well)? (Did management say, “You will use Scrum”?)
