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

Re: [XP] Iterations harmful? -- small vs large batch process bottleneck

Expand Messages
  • Trond Wingard
    Kent, As far as I understand queueing theory (although it s 15 years since I had it as a subject), it s the variability that is the killer. The work you have
    Message 1 of 50 , Sep 18, 2005
    • 0 Attachment
      Kent,

      As far as I understand queueing theory (although it's 15 years since I
      had it as a subject), it's the variability that is the killer. The
      work you have to do is at least as big as the minimum processing time
      for the batch size, and the extra bit is the variability. Now,
      variability increases as the batch size increase - non-linearly. With
      a smaller batch, there are fewer things that can go wrong, and you
      might be able to get a continuous (more or less) flow through the
      integration or the release process, for example. With a larger batch
      size, the time it takes to get the batch through integration or
      release is less predictable.

      (And hi to all - it's been three years or so since I last was active
      in this group.)

      Trond Wingard
      Independent consultant, Norway


      --- In extremeprogramming@yahoogroups.com, "Kent Beck" <kentb@e...> wrote:
      > My understanding of queueing theory is that it is not the duration
      of the
      > process step that matters so much as how much work the step is
      doing. These
      > match closely in most physical manufacturing processes but not
      necessarily
      > in software development.
      >
      > Big-bang integration is the example I have in mind. As you pile up
      more and
      > more un-integrated programming work, the integration process becomes a
      > bigger and bigger bottleneck. You might have 9 months of programming
      that
      > takes 3 months to integrate, but the bottleneck is still the
      integration. By
      > matching the programming cycle and the integration cycle closely,
      you can
      > reduce the overall integration effort. If you program for 6 hours, 2
      hours
      > is more than enough time to integrate (or 20 minutes of integration
      after an
      > hour of programming).
      >
      > I only have a lay understanding of queueing theory. I would appreciate a
      > correction from someone who knows more than I do.
      >
      > Kent Beck
      > Three Rivers Institute
      >
      > > -----Original Message-----
      > > From: extremeprogramming@yahoogroups.com
      > > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeff Grigg
      > > Sent: Tuesday, September 13, 2005 7:41 PM
      > > To: extremeprogramming@yahoogroups.com
      > > Subject: Re: [XP] Iterations harmful? -- small vs large batch
      > > process bottleneck
      > >
      > > --- "Kent Beck" <kentb@e...> wrote:
      > > > I watched Mary Poppendieck speak recently and was reminded
      > > > of a general principle that I kinda/sorta knew but haven't
      > > > been applying consistently: a small-batch process feeding
      > > > a big-batch process creates a bottleneck (the same is true
      > > > with big-batch processes feeding small-batch processes).
      > > > Decoupling iteration and release cycles creates this
      > > > problem. Keith Braithwaite has described how they solve
      > > > it--use one week for both. Scrum synchronizes at a month,
      > > > but it seems some teams want more feedback.
      > > >
      > > > Kent Beck
      > > > Three Rivers Institute
      > >
      > > If there are N iterations in a release, and the release
      > > process itself
      > > takes considerably less than N (additional) iterations, then there's
      > > plenty of slack in the release process, so it won't become a
      > > bottleneck.
      > >
      > >
      > >
      > >
      > >
      > > To Post a message, send it to: extremeprogramming@e...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@e...
      > >
      > > ad-free courtesy of objectmentor.com
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      > >
    • Trond Wingard
      Kent, As far as I understand queueing theory (although it s 15 years since I had it as a subject), it s the variability that is the killer. The work you have
      Message 50 of 50 , Sep 18, 2005
      • 0 Attachment
        Kent,

        As far as I understand queueing theory (although it's 15 years since I
        had it as a subject), it's the variability that is the killer. The
        work you have to do is at least as big as the minimum processing time
        for the batch size, and the extra bit is the variability. Now,
        variability increases as the batch size increase - non-linearly. With
        a smaller batch, there are fewer things that can go wrong, and you
        might be able to get a continuous (more or less) flow through the
        integration or the release process, for example. With a larger batch
        size, the time it takes to get the batch through integration or
        release is less predictable.

        (And hi to all - it's been three years or so since I last was active
        in this group.)

        Trond Wingard
        Independent consultant, Norway


        --- In extremeprogramming@yahoogroups.com, "Kent Beck" <kentb@e...> wrote:
        > My understanding of queueing theory is that it is not the duration
        of the
        > process step that matters so much as how much work the step is
        doing. These
        > match closely in most physical manufacturing processes but not
        necessarily
        > in software development.
        >
        > Big-bang integration is the example I have in mind. As you pile up
        more and
        > more un-integrated programming work, the integration process becomes a
        > bigger and bigger bottleneck. You might have 9 months of programming
        that
        > takes 3 months to integrate, but the bottleneck is still the
        integration. By
        > matching the programming cycle and the integration cycle closely,
        you can
        > reduce the overall integration effort. If you program for 6 hours, 2
        hours
        > is more than enough time to integrate (or 20 minutes of integration
        after an
        > hour of programming).
        >
        > I only have a lay understanding of queueing theory. I would appreciate a
        > correction from someone who knows more than I do.
        >
        > Kent Beck
        > Three Rivers Institute
        >
        > > -----Original Message-----
        > > From: extremeprogramming@yahoogroups.com
        > > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeff Grigg
        > > Sent: Tuesday, September 13, 2005 7:41 PM
        > > To: extremeprogramming@yahoogroups.com
        > > Subject: Re: [XP] Iterations harmful? -- small vs large batch
        > > process bottleneck
        > >
        > > --- "Kent Beck" <kentb@e...> wrote:
        > > > I watched Mary Poppendieck speak recently and was reminded
        > > > of a general principle that I kinda/sorta knew but haven't
        > > > been applying consistently: a small-batch process feeding
        > > > a big-batch process creates a bottleneck (the same is true
        > > > with big-batch processes feeding small-batch processes).
        > > > Decoupling iteration and release cycles creates this
        > > > problem. Keith Braithwaite has described how they solve
        > > > it--use one week for both. Scrum synchronizes at a month,
        > > > but it seems some teams want more feedback.
        > > >
        > > > Kent Beck
        > > > Three Rivers Institute
        > >
        > > If there are N iterations in a release, and the release
        > > process itself
        > > takes considerably less than N (additional) iterations, then there's
        > > plenty of slack in the release process, so it won't become a
        > > bottleneck.
        > >
        > >
        > >
        > >
        > >
        > > To Post a message, send it to: extremeprogramming@e...
        > >
        > > To Unsubscribe, send a blank message to:
        > > extremeprogramming-unsubscribe@e...
        > >
        > > ad-free courtesy of objectmentor.com
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        > >
        > >
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.