What is kanban? Often when I introduce Kanban to teams that are just getting familiar with Scrum, one of the first comments I’ll get is… it looks a lot like waterfall. So, here is the question, is Kanban just waterfall with small batches? Let’s say you kept all your functional silos in place, and simply started running smaller projects… small to the point of being a feature or an MMF… would you get better business outcomes?
I haven’t been in a situation where I could actually try this approach at any kind of scale, but my gut tells me that you would get better performance. You’d increase the rate at which the organization created value, you’d decrease the amount time spent doing up front planning, and you’d decrease the number of in-flight dependencies you’re managing at any one time. Decreasing the batch size would make it easier to change direction when business conditions changed.
My guess is that’s why some folks are so excited about Kanban… you get better overall performance, without having to change anything about how the organization is currently structured. You get incremental improvement without the transformation and change issues that come along with a Scrum adoption. In addition, you’d now have a way to explicitly visualize the work, manage the flow of value, and drive conversation that incrementally improves how the overall system behaves.
So… what do you think? Is this the preferred way of working? Do we abandon teams and transformation? Is adopting Kanban as simple as working on smaller batches, value stream mapping, and setting work in process limits to create flow? If we took this approach, what would be our tradeoffs? Would we be leaving anything out by not transforming?
BTW – It is worth marking the occasion… this is my 300th post on Leading Agile. That’s kind of a cool milestone.