When Worlds Collide: Agile Vs Kanban

By 4 commentsagile, Development, kanban, lean

When-Worlds-CollideI’ve witnessed a sort of agile/lean clash incident at our standup. Reviewing our kanban board, as tasks completed, others were left on the board. Instead of completing the tasks in progress, a developer decided to pick new tasks to work on, entering them into process.

The Clash 

Agile promotes team empowerment. Developers are encouraged to pick their next tasks, based on their best judgment. In this case, the developer picked tasks that were easy and quick to complete – clearly using his best judgment.

Lean teaches us to minimize work in progress. If there’s a task in the pipe, it makes sense to complete it first prior to starting another task. Adding value.

I don’t think there was a violation of the process here – there was no task prioritization, and the work limit was not breached.

But it does show that a mindset change is required to travel between the two realms. Which is kind of ironic, because agile is all about successful change.

Gil Zilberfeld

4 comments on “When Worlds Collide: Agile Vs Kanban”

  1. Yuval Reply

    I don’t think there is a clash between worlds.

    Lean/Kanban Limited WIP needs to be such that it allows an empowered team to use judgement. If its better for the team Throughput and quality to take small tasks and get them over with, rather than swarming to a task that is in progress, then that is what the team should do.

    Limited WIP asks you the difficult question of whether that is INDEED the best thing to do, or is it the comfort zone of the developer.
    The WIP limit should be such that it challenges the comfort zone, but not too restricting. Just right… Like goldylocks…

    Beyond that, Agile/Scrum/XP also does the same, just in a different way. XP One piece flow is kanban to the extreme. Pair works on a story. Until its done, not taking other stories. Scrum team commits to a sprint content. And if developer finished the tasks he “Wants” to do for the sprint, he cannot take other tasks from the next sprint, until the sprint commitment is safely in the bag.

    Its the same “challenge” just in a different form. kanban via WIP limit, Scrum/XP via the iteration timebox.

  2. Gil Zilberfeld Reply

    Yuval,

    Thanks for the feedback!
    Maybe I was a bit over-dramatizing stuff 🙂

    I do try to learn about behavior change, due to adopting new processes. Successful changes incur mind and behavior shifts, and these basically depend on the individual’s point of view.

    I’m interested: Did your view of how kanban relates to agile change over time?

  3. Elad Reply

    As someone who went through a similar learning process (agile vs. kanban, scrum with kanban, etc…) I can share my experience.
    At first the two seem at odds with one another and it sounds like you need to choose one.
    As you begin using each system you learn to filter the mechanics from the principles and focus on those, choosing the right tools for your specific context.
    Some examples can be:
    1. Do I use iterations or go continuos flow all the way?
    2. Do I limit WIP? At what level do i limit WIP (task, story, feature…)?

    I think that at the end of the day, the two complete each other, and are much more powerful when combined.

  4. Gil Zilberfeld Reply

    Elad,

    Thanks for the input.I can see your point. Going back to the values behind the technique is wise, no matter what you practice. But that requires time and discipline. I expect some people get there faster than others.

Leave A Reply

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