Loading ...
Sorry, an error occurred while loading the content.

151178[XP] iterations vs continuous flow, kanban ...

Expand Messages
  • Jeff Grigg
    Aug 2, 2009
    • 0 Attachment
      --- Arnaud Bailly <abailly@...> wrote:
      > I join the choir of appraisal to Ron Jeffries for starting
      > this interesting thread.

      Me too.

      > [...] AFAICT ([...]), kanban is "just" a signaling technique
      > to constraint the size of queues in a process. Define process
      > cycle time, queues, inputs/outputs, you got a nice Markov
      > process which you can solve to define the optimum number of
      > kanbans, ie. the optimal number of work items transiting at
      > a single point of time in all the process.

      We tried kanban on a number of teams at my previous employer. I was not impressed.

      The biggest problem I had with kanban is that since it's designed to manage the size of the handoff queues between work processes, teams will add queues (IE: handoffs) to the process in order to have something to manage with kanban. In other words, we create a problem because we happen to have selected a tool that manages that problem. "We need a separate testing phase," they say, "so that we can manage the number of work items waiting to be tested." And then we need an analysis phase, a design phase, and a code review phase after the coding phase, etc. Waterfall anyone?

      I've seen kanban work well in operations groups -- those who respond to randomly arriving service requests which can each be completed and delivered independently of each other. But if you're going to package up and deliver a new version of a working system every month (or every two weeks or whatever), then I don't find it helpful to deny the actual release heartbeat in favor of an unhelpful flatline flow.
    • Show all 187 messages in this topic