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

36918Re: A tale of two Scrums

Expand Messages
  • aacockburn
    Mar 2, 2009
    • 0 Attachment
      Nice! I am just teaching a Scrum course this week, and your post fits
      well with what I'm encountering, and is a good reminder. The drive of
      newcomers for certainty is at odds with certain aspects of Scrum.

      Nothing more to add at this point - looking forward to others' posts.


      --- In scrumdevelopment@yahoogroups.com, "jens.meydam"
      <jens.meydam@...> wrote:
      > 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
      > 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
      > result really seems doable.
      > A sprint is then considered successful if the selected stories all
      > done as promised, perhaps plus or minus one story.
      > This is Scrum, right?
      > Well, today I picked up "Agile Software Development with Scrum" by
      > Schwaber and Mike Beedle and re-read some passages, and I noticed
      > 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
      > 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-
      > 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
      > 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
      > I wonder what you think about this.
      > Jens
    • Show all 25 messages in this topic