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

Re: [XP] How does pulling WIP in Kanban relate to source control?

Expand Messages
  • Pieter Nagel
    ... Pulling things from a done queue did not refer to anything we are currently doing. My question was about how things would work if we were doing Kanban
    Message 1 of 50 , Aug 4, 2009
    • 0 Attachment
      On Tue, 2009-08-04 at 11:06 +0200, D. André Dhondt wrote:

      > * If your tester is pulling things from a "done queue" then are you
      > suffering from "throw-it-over-the-wall-syndrome"?

      "Pulling things from a done queue" did not refer to anything we are
      currently doing. My question was about how things would work if we were
      doing Kanban instead of XP, and my understanding is that in Kanban work
      is always "pulled".

      I just wanted to explore a bit more what on earth "pulling" work meant,
      in practical terms, if that work lives inside a source control system.
      The metaphor of "pulling work" and swimlanes etc. evoked a picture in my
      minds eye of people actually cherry-picking feature branches to merge
      into the basline. I wasn't sure if that picture in my head was correct.

      >From the answers I got on this thread, I got the feeling that very few
      Kanban teams actually work that way. Some do, but the overal feeling
      seems to be that continuous integration, latent features, and an
      allways-deployable baseline are the preferable solution - both in XP and
      Kanban.
      >
      --
      Pieter Nagel
    • Perryn Fowler
      As user of git and Kanban I have a strong preference for hiding incomplete features than using feature branches. - We don t do continuous integration because
      Message 50 of 50 , Aug 28, 2009
      • 0 Attachment
        As user of git and Kanban I have a strong preference for 'hiding'
        incomplete features than using feature branches.

        - We don't do continuous integration because subversion makes merging
        hard. We do it because integrating stuff late is hard and risky no
        matter how nice your merge tool is. Developing features on separate
        branches and then merging them when they are done is not CI. git will
        not save you here.

        - Every time I've seen people do feature branches everyone has just
        got confused trying to avoid a huge big bang integration just before
        release:
        " OK, so branch B will regularly merge out from branch A until
        A goes live and then start merging out form Master, and C will merge
        out from both A and B, until .. wait what about bug fixes on
        Master?.... Oh dear B is taking longer than we thought - should we
        hold up C?, or maybe we should start merging out to B from C..err..."

        figuring out to "hide" incomplete stuff isn't trivial, but I prefer it
        to the alternative.

        cheers
        Perryn
      Your message has been successfully submitted and would be delivered to recipients shortly.