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

RE: [scrumdevelopment] Re: Critical Chain estimating

Expand Messages
  • Clarke Ching lists
    ... micro-detailing of tasks and micro-analyzing inter-task dependencies. That is definitely against Scrum s way of working. I think you ve misunderstood
    Message 1 of 44 , Jul 4, 2005
    • 0 Attachment
      Alistair wrote:
      >  ... One of the core elements of the Critical Chain as written is micro-detailing of tasks and micro-analyzing inter-task dependencies. That is definitely against Scrum's way of working.
      I think you've misunderstood Critical Chain just a little Alistair.  Goldratt specifically says not to break tasks down into micro-detail.  He recommends keeping them at a high level.

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of aacockburn
      Sent: 04 July 2005 22:33
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Critical Chain estimating

      Three things ---

      First, I agree with Steven. Kevin is using the Buffer Management
      practice extractd from Critical Chain. One of the core elements of
      the Critical Chain as written is micro-detailing of tasks and micro-
      analyzing inter-task dependencies. That is definitely against Scrum's
      way of working.

      So what Kevin demonstrated is interesting, that the Buffer Management
      idea from Critical Chain can be applied under a completely separate
      set of rules, i.e., skip the baton-handoff task dependency stuff, and
      just watch the buffer.

      Second, as Laurent questioned, the 50% probability mark isn't the 50%
      time mark. I'm curious as to whether it makes any difference which
      you use, but Kevin used the 50% time mark (if I got that correctly
      from his posting).

      For those who haven't read Critical Chain, you halve all the
      estimates per task, and take all those second halves of each estimate
      and keep them in a big pool, called the buffer. According to
      Goldratt's theory, you should probably eat about 1/2 way into that
      buffer by the end of the period.

      Therefore, you watch the buffer and watch the rate at which you eat
      into it.

      to eat into that buffer! If you do not eat into that buffer, then
      there is something else wrong somewhere and you are supposed to go
      and find it!  DO NOT MISS THIS POINT.

      It is indeed a hazard (and in my project interviews I found it,
      exactly on cue) that the manager drives people to not eat into that
      buffer, by forcing overtime work onto them --- and then measuring
      work time in weeks (not even days), instead of hours. ... and showing
      crowing about how much work time they saved.

      This gets me to my third point, and the one I really wanted to post
      about ... the potential for abuse of this technique. In this forum,
      and with Kevin's experience, I think there is a really good
      opportunity to experiment with it.

      So, Kevin, here's the question --- did you measure time in worked
      hours or worked days/weeks? Did anyone work overtime?

      And here's the reason for the question.

      If nobody is working overtime (or you measure in hours so that
      overtime work shows up properly), and you indeed found that you
      didn't eat into all of the buffer, then indeed you have found
      something very interesting and I think you should examine it more
      closely and write up a short paper on it.

      If they are working overtime and you didn't measure in hours, then
      please either stop the overtime or do measure in hours and say what
      the result is then.

      I see the estimation/buffer management aspect of Critical Chain as
      one that is incredibly easy to misuse, to the detriment of the team.
      The team suckers up for honest estimates and cuts them in half, then
      are held to those estimates by management. A few projects later, the
      team, being not complete idiots, doubles all their estimates because
      they are tired of getting beaten up and working overtime. i.e., the
      technique backfires on itsel.

      You didn't report on anything that sounded that way, Kevin, which is
      why I find your post so interesting, and am requesting more

      Both from a morale standpoint, and the absence of micro-analyzing the
      tasks (per Scrum), this was an interesting experiment with an
      interesting result. I look forward to your replies,


      --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@m...> wrote:
      > I don't think it's antithetical to Scrum. Goldratt's "The Goal" is
      > listed in the bibliography to the Schwaber/Beedle book. I suspect
      it's there
      > for a reason.
      > Mike Cohn
      > Author of User Stories Applied for Agile Software Development
      > www.mountaingoatsoftware.com
      > On 7/4/05 1:49 PM, "Steven Gordon" <sagordon@a...> wrote:
      > > I believe what you are talking about is "Buffer Management",
      which is just one
      > > aspect of Critical Chain.  I am not sure whether it is unique to
      > > Chain, but, as you have shown, it is quite valuable as an
      > > technique.
      > > 
      > > The most characteristic aspect of Critical Chain, using task
      dependencies to
      > > plan in detail in what order resources should be applied to which
      tasks in
      > > order to complete the project as early as possible with the given
      > > is antithetical to Scrum, at least according to my understanding
      of both.
      > >
      > > -----Original Message-----
      > > From: scrumdevelopment@yahoogroups.com on behalf of Kevin
      > > Sent: Mon 7/4/2005 11:19 AM
      > > To: scrumdevelopment@yahoogroups.com; tocsoftware@yahoogroups.com
      > > Cc:
      > > Subject: [scrumdevelopment] Critical Chain estimating
      > >
      > >
      > >
      > > Hi all,
      > > I know it's been covered a number of times before, but I just
      wanted to report
      > > on a real-life experience of Critical Chain estimating.  On this
      > > project, just over a month ago, I decided to try an experiment.
      Our process
      > > involves taking user stories and breaking them down into small
      > > tasks which, being small, should be relatively easy to estimate.
      But iteration
      > > after iteration we were squeezed at the finish post because some
      tasks had
      > > taken way too long. I had no idea what the cause might be, but in
      my mind I
      > > coupled it with the team's overall apparent lack of urgency.
      Things just
      > > drifted along.
      > >
      > > So just before the next iteration's planning meeting we had a
      team workshop. I
      > > explained the critical chain view of estimates
      > >
      , and
      > > we decided to give it a go. The team recognised that historically
      all of its
      > > task estimates had been conservative. Fear of being late had made
      us create
      > > estimates that were universally over at the 90-100% end of the
      range of
      > > possibilities for each task. That is, each estimate created a 90-
      100% chance
      > > of "being right", of finishing within the estimated time. So we
      had stacked
      > > each iteration with 15-20 small tasks, each of which had only a
      small chance
      > > of being late. And each time, one or two were indeed late. No-one
      knew why,
      > > and yet those few late tasks ate up the iteration's slack. Every
      > >
      > > So we removed the pressure on any individual task to be brought
      in "on time",
      > > and we switched to estimating every task at the 50% point. That
      is, we did our
      > > usual conservative estimates and then halved them! The results
      were amazing,
      > > and have been repeated now over three iterations:
      > >
      > > Most tasks are now finished by the 50% point (partly because the
      > > treat the estimate as a timebox - "I'll do what I can in that
      amount of time,
      > > and then see where we are.") And those that go over just eat into
      the project
      > > buffer a little. In fact, we're now getting a whole load more
      tasks done in
      > > the same time. Critical chain estimating has eliminated the
      effect of
      > > Parkinson's Law and simultaneously created a sense of urgency.
      > >
      > > I'd love to know whether this works or has worked for other
      software teams.
      > >
      > > Cheers,
      > >    Kevin
      > >
      > > --
      > > http://silkandspinach.net
      > > http://agilenorth.org.uk
      > >
      > >   _____ 
      > >
      > >
      > >
      > >
      > >
      > > To Post a message, send it to:   scrumdevelopment@e...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@e...
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

    • Ron Jeffries
      ... Yes. I think I should have gone above them all, to the CIO. That would have brought the situation to a head, one way or another. ... That s interesting ...
      Message 44 of 44 , Jul 7, 2005
      • 0 Attachment
        On Wednesday, July 6, 2005, at 5:03:19 PM, Simon Baker wrote:

        > The situation you describe is indeed similar. I was both the coach
        > and acting scrummaster. My difficulty was, i couldn't escalate to
        > management because, sadly, they really didn't want to know. They had
        > bigger issues deciding on strategies and company direction. It was a
        > huge time of flux. As i intimated, in the situation a decision had
        > to be made given the bigger picture, and unfortunately i was the
        > only one inline to make it. Ultimately, scrum did fail in this
        > environment because of the politics.

        Yes. I think I should have gone above them all, to the CIO. That
        would have brought the situation to a head, one way or another.

        > As an independent coach, the biggest challenges i encounter usually
        > relate to product owners.

        That's interesting ... how about a new thread on that?

        Ron Jeffries
        It is not because things are difficult that we do not dare,
        it is because we do not dare that they are difficult. --Seneca
      Your message has been successfully submitted and would be delivered to recipients shortly.