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

RE: Re[2]: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? "

Expand Messages
  • Mike Cohn
    Exactly. There are very few things that we can t do in parallel. There may be a few things may be better done in a specific sequence but that s normally
    Message 1 of 9 , Nov 18, 2003
    • 0 Attachment
      Exactly. There are very few things that we can't do in parallel. There may
      be a few things may be better done in a specific sequence but that's
      normally because we're comfortable working a certain way (e.g., add columns
      to a database table before coding a change that uses them).

      -----Original Message-----
      From: Michael Feathers [mailto:mfeathers@...]
      Sent: Tuesday, November 18, 2003 8:59 AM
      To: Mike Cohn
      Subject: Re[2]: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain
      compare? "


      MC> One thing I will sometimes do differently from "by the book" Scrum is,
      MC> as you point out, look at task (story) dependencies. However, I don't do
      MC> that for critical chain planning. Rather, I do it to avoid achieving a
      MC> local optimization to the work of a sprint. Suppose a sprint includes 26
      MC> things to do, labeled a through z. They can be done in any order except
      MC> a, b, and c must be done in order. As a ScrumMaster I train the team to
      MC> look for sequences like that and make sure they start those types of
      MC> tasks as early as possible in a sprint. There are normally very few of
      MC> these in a sprint so this is a pretty small change and it's really just
      MC> how we think about the work of a sprint. However, it helps avoid a
      MC> situation where the sequential tasks a, b, c are all left for the last
      MC> day and even though there are three developers and three days left of
      MC> work we just can't do the work in one chronological day.

      One thing that I get a real kick out of when I work with new teams is
      showing them how software related sequencing dependencies are an illusion.
      If you can define an interface, you can work in parallel. That just
      leaves tooling tasks where someone is going to use something developed
      earlier in an iteration to do additional work in an iteration. As
      much as possible, I like to get teams to finesse those by having someone
      sign for both the creation and the use.

      It's hard medicine, but I really like to push it because I run into
      teams all the time who believe that they have sequencing dependencies
      when they really don't.



      Michael Feathers
      www.objectmentor.com



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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.