Is Kanban just Waterfall with Small Batches?
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.
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
John DeHope replied on Thu, 2010/06/17 - 11:02am