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

RE: [scrumdevelopment] Misc questions

Expand Messages
  • Ken Schwaber
    Jonas, I just got back from a workshop on agile processes at OOPSLA2001, where our conversations included your questions. 1. The backlog needs to be kept
    Message 1 of 2 , Oct 17, 2001
      I just got back from a workshop on agile processes at OOPSLA2001, where our
      conversations included your questions.

      1. The backlog needs to be kept simple, so that the customer can assess the
      business value of each item by a one or two line description. As a backlog
      item becomes higher priority (more likely to be developed in a nearby
      Sprint) it's description becomes more and more defined, also supporting more
      and more refined estimates. Most project managers and product managers have
      lists or Excel spreadsheets that describe "what the system will consist of."
      The product backlog subsumes these lists.

      2. We spend a lot of the book presenting case studies. Scrum and all of the
      agile processes feel immensely different to people starting to employ them,
      and they often have trouble believing that they won't spin out of control.
      Scrum provides real predictability, as compared to the artificial comfort of
      a pert chart, but it take people a while to get use to it. Scrum also
      requires collaboration between the business and development team, with the
      customer "hands on" driving the project every iteration, or Sprint. This,
      too, takes a while to get used to. Customers and team members that dislike
      personal accountability are profoundly comfortable with Scrum.

      3. A question we asked at the workshop: "When shouldn't you use an Agile
      process?". In theory, nowhere we can think of. In practicality, I've run
      into the following:
      a. The team had such an inadequate development environment and understanding
      of basic software engineering principles that we delivered very little
      business value the first three Sprints. The customer quite correctly
      defunded the project because he felt that the team couldn't do the job. This
      was a project failure, but a Scrum success. Scrum made the team's
      inadequacies fully visibile to the customer and let him make relevant
      b. The project manager was a control freak and couldn't resist telling team
      members what to do during the Sprint, going so far as to maintain the Sprint
      backlog as a pert chart. He completely undermined self-organization and
      hindered the team from meeting its committments to the Sprint goal. We had
      to replace the project manager.

      Each of these cases failed, but Scrum provided early visibility into the
      cause of the failure. The projects would have failed no matter what process
      was used, but at least Scrum helped the organization minimize the damages
      and costs.

      Since Scrum is a wrapper for any engineering processes, we've been able to
      use it for any number of seemingly inappropriate projects, such a
      coordinating executive decision making for a business, Y2K release
      management and implementation control, and technology selection projects.


      -----Original Message-----
      From: jonas.b@... [mailto:jonas.b@...]
      Sent: Monday, October 15, 2001 11:47 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Misc questions

      Now I am done with the report about Scrum. It has been really
      interesting to study Scrum. Scrum really have many interesting parts
      and aspects, I must say. So I've ordered the book to see if there are
      more juicy parts of Scrum :-)
      Thanks Ken Schwaber for your terrific answers!

      But I have hard dropping the issue so I will continue with my

      * Doesn't the backlog become very complex? Is there any possibility
      to see how such a "real" backlog is contructed?

      * Where is the critique against Scrum? Everything can't be perfect...

      * In the faq on www.controlchaos.com the third question is about
      failured projects using Scrum. Is there any why of getting
      information about these failures? It would be very interesting!

      Thanks in advance,

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.