36911RE: [scrumdevelopment] A tale of two Scrums
- Mar 1, 2009I 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.
Date: Sun, 1 Mar 2009 23:03:23 +0000
Subject: [scrumdevelopment] A tale of two ScrumsMany 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
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
So there seem two quite distinct types or styles of Scrum, with
different practices, meant for different situations:
- 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
- emphasizing (at least short-term) predictability and speed of
- development can be described as growing a system feature by feature
I wonder what you think about this.
Explore the new Windows Live. Looking for a place to manage all your online stuff?
- << Previous post in topic Next post in topic >>