Kanban’s Problem?

[Click for full size]

I’ve been using Kanban at the enterprise level as a way to engage executive leadership visually to see an entire PMO project portfolio (and I’m sharing a story about this at AgileDC in October for my Scaling Product Ownership talk). What has come up through these assessment sessions has been very interesting to say the least. Now, applying Kanban to bug remediation and defect resolution processes is somewhat straightforward. What if we look at how software development really works?

Kanban, a system based off of manufacturing inputs and outputs, doesn’t say much about re-queuing things. What I mean is, we look at Kanban, work in progress limits, etc etc, and see the card go through the line. Then it’s done.

In the software development world we have reusable processes, we have repeatable steps, and we have recycled stories. Kanban doesn’t really address the whole re-queuing thing.

So the thought in my mind is: “So let’s talk about versioning.” 

“You can always create a new version of the repeatable card, story, or step.”

But this doesn’t seem to sit well with me. I’m not so sure I’m convinced.

So what happens when you need to send that repeatable story through the line… several times, or even greater, what about an entire multi-story process?

Tell me I’m missing something… and yes, I have several books on the subject (like Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson)… so don’t flame me too hard. Hell, I even use kanban at home.

If you’re a real Kanban/Lean Manufacturing NINJA you should get:

Japanese Manufacturing Techniques: Nine Hidden Lessons in Simplicity

Yes. It’s from 1982 and you can buy it for 1 CENT on Amazon.com + $9000 for shipping… I keed I keed!

So tell me, what’s goin’ on here? Am I taking it too literally?

24 Replies to “Kanban’s Problem?”

  1. Ok, I have to admit, maybe I’m just blowing hot air because there are no explicit policies around this. Or… maybe I’m just frustrated that tools haven’t picked up on this yet.
    Or… maybe I’m just being dogmatic about the whole kanban process.
    Or… …

    1. Excellent point. You’ve stopped to ask the question. Many of us have been doing this “in the flow”. For example, our volunteer team uses leankit Kanban for monthly PMI ATL Agile LIG meeting preps.

      There are repeatable tasks and we create a new card every time!
      It would be great if tools or kanban flow can recycle the task.

      I hear ya and will keep watching this thread for more ideas and suggestion. Really loved our talk on Kanban and your insights we had a month back.

      1. Interesting point there Sameer. Right? Tools don’t allow for good recycling… but we must not let the tools GET IN OUR WAY! people over tools.

        I need to marinate on this a bit more. ….

    2. Perhaps I’m just working in a different development environment, but there are no exactly repeatable cards on my teams’ Kanban boards.

      Your teams’ value streams are the repeatable process. As you put features, stories, tasks, whatever through the value stream, I fail to see why you would ever have a repeated one.

      In my use of personal Kanban however, I run into this. For this, I have a separate section of the board dedicated to recurring tasks, and they get recycled through those steps in their own separate value stream.


  2. I cannot say I’ve had experience with the repeatable problem.

    With regards to multi-story, it seems you can break things down in such a way that they are themed much like I do with Scrumban or Scrum.

    For example, these purples cards represent all of the stories that make up feature x, and then you simply track them visually through the columns.

    I don’t think you are blowing hot air, and I find that writing about the problem helps me think of it in a different light.. as well as gather input from my peers.

    1. Thanks for your support David. This was a post more for my own self-learning of sorts. It does help me think of things differently when I write.

      I have yet to figure out a good way to move repeatable processes through the board. It seems so redundant.
      We could put it as part of a system definition of done… but that… not so sure on just yet.

      Themes can work… maybe themes matched with DOD measures…

  3. Peter – I’m just starting to learn about Kanban (in fact reading the book by David Anderson you noted in your post) and I have to say the same exact thoughts popped into my head. So your definitely not alone in your thinking. The challenge of how to deal with this is out there for others as well! Unfortunately my knowledge in Kanban is not great enough at this point to offer any real ideas, but I’ll have to let you know if anything pops in there as I expand my knowledge base and get the old noggin thinking about this challenge!

    1. Thanks for your honesty! I come across conundrums like this all the time. Some, I have answers for. Many, I do not. Scaling Kanban to the enterprise is different every time.

      Different teams react differently. Different teams figure out how to ‘work the system’ or be ‘worked by the system.’ I prefer the former.

  4. There’s a more fundamental problem here. If the team is recycling cards (stories), something is wrong. The card is too complex, too big, too risky, too something. The team needs to discard the card and re-group. This is not a kanban issue. It’s a planning issue.

    In a lean manufacturing environment, when a problem is discovered, production stops and the problem is assessed and resolved. The faulty component will be removed from the production line and either repaired or trashed.

    Similarly, if a story is defective, it needs to be re-worked. Simply sending it through again is not the solution. Make sense?

  5. Good evening Peter,

    I won’t claim having THE answer, but these ideas might help you:

    * The original kanban solution at Toyota is precisely about repeatable tasks: cards are recycled as the process consumes the parts it represents.

    * Depending on the needs I recycle the card (putting it back at the beginning of a new cycle), or I create a new card each time (so I can track specific metrics and discover if/how I improved).

    * But somehow if the tasks are repeatable, maybe they don’t belong to the same value stream?
    If this happens to be the case, then another visualisation, like the “sequestering approach” might be a better option:

    * One approach I am trying now is replacing time-based actions by quantity trigger (for example instead of deploying weekly I deploy as soon as I have five story ready). So far, it seems to work fine 🙂

    Hopes this helps,

  6. To be honest I sometimes get the feeling that Scrum and Kanban advocates try so hard to be purists that they throw the baby out with the bathwater. There are already tried and tested protocols around version control and release management that seem to get forgotten.

    My approach ->

    a problem stops me working right now (read bug fix). Get it on the board and get it dealt with;

    an issue hinders me in some way (read enhancement or new feature). Put it in the master product backlog for the next release.

  7. So I am fishing to get all of what is here, I think. I am not sure I see the tension suggested.

    Processes are very much about doing repeatable things… But there is both deliverable work and tasks to support the system. Running the build, running the regression test, creating branches and versions – these are repeating tasks – but generally details of the activities/practices… (Not always – but typically)

    If the repeated things are ritual/practice, rework, or new work… these differences matter in how/if they are represented on the board.

    If you are focusing on rework – To the extent that you ask the board to support a lean style delivery, you also want to allow the activities a best chance at completeness. Going backwards was a failure in achieving DONE, usually. Using ATDD to minimize rework on requirements, code, and tests… using TDD and static analysis to minimize mediocre design and automated build/CI to catch things before they are merged to the main code line(s)… Using special tasks(Spikes, Tracers)to uncover needed info… Swarming to get a piece of work done – versus separating to siloed functional bits of work… other techniques… and then getting the work to really flow quickly thru the system so that time-based induced work is not added; These are strategies in software that help create the lean concept of mistake-proofing and protect against work that must be redone.

    Add to this perhaps a separate swim lane/SLA for defects, CRs, production issues, other work types.

    Every situation is different and larger enterprises multiply the complexity – managing against dependencies and legacy challenges comes to mind. But the board alone should still be used with an eye toward addressing the problems it surfaces… and there may be other techniques to add. Technical and other practices are still part of the toolset in doing this well.

    Processes can always get better… And software development will always surface interesting problems. The board should fit reality as much as possible – and the process/board should evolve to help that; But you will still probably also have to be aware and creative once in a while.

    1. Jeff, agree with you here. If we think about these process frameworks in themselves we can get muddled up. What makes sense as you say is that other techniques need to be added.

      There is no one way to slice it and look at it. You have to take things here and there and fit them in as they provide value. Good points.

  8. This is a very interesting post. I have never worked in software development, so I can’t speak to that. I can’t think of a time I have ever had the problem of a repeatable task.

    Although along those similar lines, I have had tasks that were large and when I finally moved it into the completed lane I realized, there was more to do with the task, therefor I had to move it back into the wip lane to get the step done that I missed initially. When this happened to me, I switched up the writing of my tasks a bit, I went to what I called ‘piggy backing’ the tasks. I made a post it with the main task on it and added smaller post it’s to the original post it with the tasks I thought made up the completed bigger task. This way I made sure that I completed all the steps to completing the big task. Here’s an example from my photostream of what I am explaining: http://www.flickr.com/photos/swimmor/5679120523/in/set-72157625937171559

    This post is the one of the reasons I love using Kanban so much. It is constantly changing and evolving to fit yours(as with personal kanban) or your teams needs. I plan on checking back to continue to read added comments. Great post Peter!

  9. Pingback: Kanban’s Problem? | Agile | Syngu
  10. In non IT implementations it is somewhat common to the same card. For example, you might be part of a communications team that gas to put out monthly newsletter (ignoring potential claims that this activity would be deemed non value adding). You can either replicate the card with the month/date or laminate the card and recycle it.

    Another example would be doing a series of blog entries where the quota for the team is say five per month. In this instance I would colour the card differently to indicate an ongoing task, put it in ‘in progress’ and every time a blog is done put a star on it (or laminate and write the date the instance is done).

    Tldr, try some options and see what works.

  11. Hi Peter,

    I’m working with Kanban for a while now and I had the same problem you described. My solution was to stop doing things by the book.
    I talked to other practitioners and they did the same. David’s book is just one version and I prefer Henrik Kniberg’s way anyway: do what is good for your team and you. Don’t let a book stop you from being awesome, if you know what I mean. We even took the liberty to introduce circulation in our case: http://bit.ly/oPD7a7

    What I would do in this case:
    – If you would like to see how your team is improving with the periodic tasks you should write a new work item for them, measure the lead time and compare them time to time. If the lead time decreases than you have a nice indicator of continuous improvement.
    – If you don’t care about the things above just circulate the work items in the value stream.

    In both cases the work item is visible and is part of the WIP limit, so Kanban is “up and running”, at least the first two core principles and most of the teams are satisfied with it.

  12. Peter
    As I read it, your original post references a few diifferent types of recurring work. One is standard activities that go into processing many of the customer value deliverables (ie stories) the team works on. Of course these can be represented as lanes if they are extremely standard. They might also be represented as checklist items in a lane policy. Or, I have seen some teams that use a set of task cards that are continuously recycled within a swimlane. The stories move across and off the board but these tasks cards get re-used for each story that comes along. Important to exclude the lanes where these recycled cards live when running analytics since they are never done!

    This standard card set approach is also used by many of our customers to track routine weekly activities. They’ll have a swimlane for ‘housekeeping’ activities where the same set of cards cycle over and over.

    In my mind, rework on a story should be new card (so you can track the number of defects ) perhaps associated with the parent story with a sticker (physical) or tag (electronic). Each re-use of the component is for a new delivery of customer value. It’s the value that’s flowing through the board, not the component.

    The reuse of a component isn’t something that should, IMO, directly reflect on the board. There’s no harm in tagging cards that use a common underlying component for future search ability. But I wouldn’t treat the component as a card that I keep pulling out of the archive.

Leave a Reply