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

36911RE: [scrumdevelopment] A tale of two Scrums

Expand Messages
  • Roy Morien
    Mar 1, 2009
    • 0 Attachment
      I think that you have made some very compelling points. It has long been a practice to deliver the smaller, easier things at the start. This does have some advantages which are real and should not be deprecated. It can have a substantially positive psychological effect on many project participants, and create a not unrealistic atmosphere of confidence, good progress, well-being. Not to be underestimated as beneficial!.
       
      It can also have quite negative effects. By doing the easy things first, we are not testing the complexities and difficulties of the project to see if there are any substantial, or even mortal blockages ahead. That feeling of confidence and progress can be ephemeral, and mask reality.
       
      I like to have a combination of things. Get some people started on actually delivering something (as a confidence builder) but at the same time identify the difficult things and work to overcome them, before too much has been done. I think in this day and age there is very little that is impossible and can't be overcome, but that doesn't mean they needn't be addressed as soon as possible.
       
      But, however you do it, forget about predictability and it's bedfellow productivity. Notions of productivity is always at risk because of unpredictability. We can only do our best to mitigate future risks, we cannot eradicate them.
       
      Regards,
      Roy Morien   
       

      To: scrumdevelopment@yahoogroups.com
      From: jens.meydam@...
      Date: Sun, 1 Mar 2009 23:03:23 +0000
      Subject: [scrumdevelopment] A tale of two Scrums

      Many of those who post questions on this list seem to aim for a very
      high degree of predictability.

      There is a lot of good advice, starting with the popular practice to
      fill the (top of the) backlog with small, relatively well understood
      user stories. Such small stories can already be estimated quite well
      even without decomposing them into tasks.

      To make progress even more predictable, it is often recommended to
      double-check the estimates of the selected backlog (usually in story
      points) by decomposing all stories up front into tasks (during the
      second half of the sprint planning meeting), estimating the tasks
      (usually in hours) and then adding up the task estimates to see if the
      result really seems doable.

      A sprint is then considered successful if the selected stories all get
      done as promised, perhaps plus or minus one story.

      This is Scrum, right?

      Well, today I picked up "Agile Software Development with Scrum" by Ken
      Schwaber and Mike Beedle and re-read some passages, and I noticed how
      very different their notion of Scrum is compared to Scrum as it is
      often described and practiced today. The leitmotiv of that book is
      the complexity and unpredictability of the work, and how much courage
      and determination it takes just to get started, let alone to promise
      anything concrete.

      Rather than committing to the delivery of a number of well-understood,
      fine-grained user stories, the team tries to achieve a single
      important goal, the scope of which is deliberately left vague. The
      team is not expected to be able to say precisely how much it will
      deliver. In fact, the work might be so difficult that it might be
      perfectly acceptable for the team not to achieve the sprint goal at
      all, as long as important knowledge has been gained.

      A few months ago, Ken Schwaber said in one of his comments on this
      list that Scrum was really created for situations where "more is
      unknown than known" (quoted from memory). I suppose this points to
      the view of Scrum that is documented in "Agile Software Development
      with Scrum".

      So there seem two quite distinct types or styles of Scrum, with
      different practices, meant for different situations:

      Scrum I:

      - emphasizing knowledge generation
      - development can be described as achieving break-throughs in the face
      of substantial uncertainty and risk
      - if you make precise commitments you are fooling yourself

      Scrum II:

      - emphasizing (at least short-term) predictability and speed of
      development
      - development can be described as growing a system feature by feature

      I wonder what you think about this.

      Jens




      Explore the new Windows Live. Looking for a place to manage all your online stuff?
    • Show all 25 messages in this topic