Skip to main content

What is Kanban : Is Kanban just Waterfall with Small Batches?

Mike Cottmeyer
Reading: What is Kanban : Is Kanban just Waterfall with Small Batches?

 

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.

Next Motivation, Insight, and Introspection

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Comments (8)

  1. Dennis Stevens
    Reply

    Mike,

    Nice perspective. I like it. But I don't think your final point is complete. I don't think you don't transform over time.

    The goal of Kanban is not just moving to single piece flow – although you will see tremendous benefits from this approach. The big key here is the sentence "drive conversation that incrementally improves how the overall system behaves." Everything we have learned from Scrum, XP, Deming, Lean, Theory of Constraints, and Organizational Psychology can be applied to the system once you have Kanban in place.

    So, pragmatically, you might identify opportunities where transforming to small team agile at key points in your organization would improve how the overall system behaves. You would then transform at that team with specific improvements in mind.

    Dennis Stevens

    Reply
  2. Mike
    Reply

    Mike,

    A thought provoking post. Like most things in life, I think the answer is "it depends".

    The most significant tradeoff would be that if an organization does not strive towards teams and transformations it is leaving money on the table.

    I like the idea of utilizing Kanban as one of the tools in an eventual transformation – a practical and pragmatic first step.

    Delaying the pain of transition to Scrum or something similar could reduce the resistance to change by making a smaller change first, and avoid the all-too-common "methodology religious wars".

    Though the danger lurks of becoming complacent and being satisfied with the initial positive results and not realizing the full potential of team-driven, Scrum-like ways of working.

    In some organizations where there is no realistic hope of garnering the management and grass-roots level support necessary to transition to Scrum or other team-driven methods, the approach suggested in your post here may be the best that is possible for that organization at that point in time.

    So it all depends on the people and their willingness to embrace change and the perceived value in a team-driven way of working. In some cases mini-batches may be the best an organization is willing to do!

    — Mike Caddell

    Reply
  3. Pawel Brodzinski
    Reply

    I think the answer for the title question is: yes and no.

    If you work in traditional environment and waterfallish process but you get a very small tasks you likely deal with them as you'd work with Kanban. And these situations happen in real life. There are projects where a lot of change requests are MMF-sized or vendor ships very often with delivering new features in small incremental batches because a client wanted so.

    There's one more thing here: planning and design doesn't scales up linearly. If you want to build feature twice as big you probably need spend thrice as much time to get the same high quality design. And no, I don't have any scientific data to support this statement. just a gut feeling. You design 'Hello world' program in a second because there aren't any hidden traps there you have to track.

    Generally speaking reducing the size takes out of our heads more than we'd tell on a first glimpse. We design small tasks faster and better. We estimate time effort needed to complete them more precisely.

    But at the same the answer for the title question is negative. Kanban brings some tricks which you wouldn't get just by scaling waterfall down, Kanban board with all its belongings being the most notable one. Visualization, limited WIP, allowed frequent priority changes or strong focus on continuous improvement are tweaks which are usually absent in waterfallish approaches and each of them has high value within Kanban.

    On more thought for the end: if I think about environment you've described – a lot of tiny, MMF-sized waterfall projects I see something close to Kanban but different (better?) in a way that someone has already done breaking the work down into small pieces and set priorities so the only thing you have to do is get the darn thing deployed and working.

    Reply
  4. Karl Scotland
    Reply

    Not sure if my comment triggered it, but this post is the other side of the coin to one you described in transforming the org model. I'm not sure Kanban is just reducing the batch size, but maybe Kanban puts more focus on reducing batch size first?

    Reply
  5. Mike Cottmeyer
    Reply

    Yes Karl, your comment did inspire this post. I've actually thought the same thing about Kanban at times. I wanted to explore the topic a bit and see who might want to weigh in. I wasn't trying have the definitive last word on this ;-)

    Reply
  6. cowboytesting
    Reply

    FYI – Alan Shalloway over at NetObectives has been positing something like this for a while. His basic idea about the differences is scrum wants to change your project management workflows to match the defined methods while kanban can be scaled and sized to match the existing workflows. It's an interesting theory that I think is personally borne out by experience. So if he's correct, kanban is not inherently waterfall (ie: iterative) but rather is flexible enough to accomadate a team using waterfall processes.

    Reply
  7. Carlton Nettleton
    Reply

    From my perspective, it is not a very interesting problem to solve since it ignores all the people stuff. While I agree that Kanban is not about small batches, value streams and WIP, it certainly has the opportunity to forget that Agile is about people and interactions, rather than process and tools.

    Reply
  8. Martin
    Reply

    Kanban assumes that you have a backlog from which you can pick the one or two most important tasks to do next. That's the key. I don't think you can define hundreds of requirements up front and then set the team to chug away for years without restructuring the backlog. As the delivery deadline comes closer (or is left further behind, as the case may be), the project manager will start redefining and prioritizing the backlog. At that point the team will not be doing waterfall anymore.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.