Does Kanban hurt Agile teams by decreasing iterative development?

Workers welding on an automobile assembly line.
Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Author: Davin Granroth

Davin is Chief Operating Officer for Covenant Eyes, Inc. in Owosso, MI, USA, where he gets to mix his background in user experience design, research, and strategy with the operation of a software company. For more, see his LinkedIn profile.

3 thoughts on “Does Kanban hurt Agile teams by decreasing iterative development?”

  1. Had a discussion about this last night.
    I think the success of Scrum or Kanban depends more on mindset and culture than on which method you actually choose. The blending of one into the other over time is quite typical, and it works both ways.
    The main risk of Scrum is that you rethink your roles, do the timeboxes and ceremonies, and as this feels like a big change, you think you’re done… Kanban is much easier to start: create a board, define WIP limits… And some think they’re done with changing.
    Bottom line: both methods should be used to continually challenge the status quo. Quoting Tobias Mayer: If you’re not doing that, you’re probably an impediment to it. Scrum is a rather revolutionary, Kanban a more gentle start. If you don’t move on from there… Don’t blame the tool.
    You are not alone. Good post!

  2. I agree with Olaf that in practice a hybrid of frameworks tends to evolve to fit the organizational culture.

    Interestingly I have been trying to decide if I have ever seen a recursive or iterative story whether in Kanban or SCRUM. I have seen many stories that are exploratory and generate team knowledge but not truly iterative stories. I would be interested in having a discussion with someone with that type of experience.

  3. The Lean movement is really pushing for iterative, inspective processes.

    While KanBan is a pull based WIP system for moving something from A to B; using it in the framework of lean means each bit of the WIP is inspected at each point. Is this piece of work wasteful? Does it add real value? Should it be killed? Should it be modified?

    Really though, inspect and adapt should be applied no matter what you’re doing, regardless if it is part of the ‘official’ framework.

Leave a Reply

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