36915Re: A tale of two Scrums
- Mar 2, 2009Hi Roy
--- In email@example.com, Roy Morien <roymorien@...> wrote:
> 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.
In my opinion, Scrum as described in the first book by Ken Schwaber is
incompatible with the concept of velocity. Moreover, some of the
prescribed practices of Scrum make perfect sense only in the context
of this style of Scrum.
Below I have added some quotes I found interesting in this context.
On the other hand, XP-style Scrum (requirements in form of small user
stories, velocity), which seems to be the dominant practice today, is
obviously well suited for software development in a corporate setting.
Technology is often not _that_ unpredictable any more (after having
developed a couple of applications with .NET or whatever, one can say
pretty well how long a feature takes), and management obviously loves
predictablilty and the emphasis on productivity. The main risk in
such scenarious is often to build the wrong application, or an
application that doesn't nearly serve the business as well as it could
have. This risk can be effectivly mitigated by producing something
useful as early as possible and iteratively improving it based on
The following comment to Corey Ladas' Scrumban-article can be read as
a testimony to the continuing appeal of the first style of Scrum for
genuinely creative, novel work and is very much in line with Ken
Schwaber's first book on Scrum and comments by Ken Schwaber on this
list concerning the relationship of Scrum and Lean:
"[...] I'm applying this [kanban-based organization of development
work] to game development where there is a transition from exploring
the game mechanics (fun) using Scrum to the production phases where we
develop 8-12 hours of assets using a Lean-Kanban approach. [...]
Preproduction (Scrum) iterations are ideal for a 'unifying audacious
goal' for the team. We don't know all of our tasks (often only 50%),
so we leave room in the schedule for exploration."
(You can read more on the context in the following article:
Compare this to some random quotes from "Agile Software Development
with Scrum" by Ken Schwaber and Mike Beedle:
p 48: "The reason for having a Sprint goal is to give the team some
wiggle room regarding the functionality."
p 49: "The team compiles a list of tasks it has to complete to meet
the Sprint goal. [...] Sometimes only a partial Sprint Backlog can be
p 50: "During conflicts, the military will put teams of soldiers into
insertion points in areas of operations. Each team is assigned a
mission to accomplish and self-organizes to accomplish it. [...]
Scrum was first described in similar terms [Takeuchi and Nonaka]:
'Typically, the process starts with management giving the project team
a broad goal. Rarely do they hand out a clear-cut new product concept
or a specific work plan. Thus, while the project team has extreme
freedom, it is also faced with extreme challenges embodied within the
p 51: "Scrum asks people to try to wrest a predictable product from
p 53: "Because Scrum allows the team to change the amount of work it
performs during the Sprint, the team has some flexibility, and is able
to do more or less so long as it meets its Sprint Goals."
- << Previous post in topic Next post in topic >>