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

Re: [XP] Re: iterations vs continuous flow and kanban ...

Expand Messages
  • Bill Caputo
    ... Or perhaps instead: We re writing and deploying computer programs? The focus on argument by analogy is what bothers me the most about this whole Kanban
    Message 1 of 187 , Aug 2, 2009
    • 0 Attachment
      On Sun, Aug 2, 2009 at 10:20 AM, Jeff Grigg<jeffgrigg@...> wrote:
      > Perhaps it's better to think of filling a UPS truck with boxes of random sizes...
      > Perhaps instead, we're filling a series of fixed size "release" boxes with products of
      > varying (difficulty/cost) sizes...

      Or perhaps instead: We're writing and deploying computer programs? The
      focus on argument by analogy is what bothers me the most about this
      whole Kanban thing - that people (not you Jeff, just ganging on to
      your post) seem really keen to re-cast everything into TPS
      terminology, so that "user stories" become "Agile Kanban cards" and
      we're not partway through a coding task, we're "WIP" so that our done
      pile becomes a "Store" that feeds another work queue...

      Is there potentially something to be learned by studying other domains
      (certainly, as Toyota showed by adapting supermarket processes to
      building cars), but does it follow that we are best served by
      recasting our entire process in that domain's image? I don't see the
      benefit, other than that it provides consultants a new way to sell
      their services (you're Agile? oh please that's so 5 years ago, no you
      need to go Kanban, and we have the industry experts on applying it. I
      can provide you 3 of them at 225 an hour starting next week...)

      This whole thread reminds me of this Dijkstra EWD:
      http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

      The core problem I've always had with over-borrowing from Lean, JIT,
      TPS, etc is that applying such analogies ends up blinding us to what
      process improvements are possible within our own domain that would be
      inconceivable in manufacturing. Just because software process got off
      on the wrong foot by borrowing from traditional manufacturing doesn't
      mean that borrowing from revamped manufacturing is how best to fix it.
      IMHO XP was an attempt to get away from the manufacturing mindset once
      and for all (there was a lot of contrasts with Taylor way back when if
      I recall) and focus on software development. Somewhere along the Agile
      path, we wandered back into it again -- maybe because contrasting with
      Taylor (e.g. Total Quality et al) was confused with good, I dunno.

      Best,
      Bill
    • Ron Jeffries
      Hello, davenicolette. On Monday, August 10, 2009, at 7:52:58 PM, ... Yep! Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Accroche toi a ton reve.
      Message 187 of 187 , Aug 10, 2009
      • 0 Attachment
        Hello, davenicolette. On Monday, August 10, 2009, at 7:52:58 PM,
        you wrote:

        >> Seems to me this is a quite valid thing to do, but that it's still
        >> managing scope.

        > That's fine. I don't want to get into a circular debate about
        > words. The key thing IMO is that we understand how to work with
        > that type of trade-off to the customer's benefit.

        Yep!

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Accroche toi a ton reve. --ELO
      Your message has been successfully submitted and would be delivered to recipients shortly.