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

36915Re: A tale of two Scrums

Expand Messages
  • jens.meydam
    Mar 2, 2009
      Hi Roy

      --- In scrumdevelopment@yahoogroups.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
      unpredictable complexity."

      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."
    • Show all 25 messages in this topic