36918Re: A tale of two Scrums
- Mar 2, 2009Nice! 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 email@example.com, "jens.meydam"
> 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.the
> 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.get
> A sprint is then considered successful if the selected stories all
> done as promised, perhaps plus or minus one story.Ken
> 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 noticedhow
> very different their notion of Scrum is compared to Scrum as it iscourage
> 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 promiseunderstood,
> anything concrete.
> Rather than committing to the delivery of a number of well-
> fine-grained user stories, the team tries to achieve a singleface
> 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 riskfeature
> - if you make precise commitments you are fooling yourself
> Scrum II:
> - emphasizing (at least short-term) predictability and speed of
> - development can be described as growing a system feature by
> I wonder what you think about this.
- << Previous post in topic Next post in topic >>