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

Misc questions

Expand Messages
  • jonas.b@home.se
    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
    Message 1 of 2 , Oct 15, 2001
    • 0 Attachment
      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
      questions.

      * 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,
      Jonas
    • 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 2 of 2 , Oct 17, 2001
      • 0 Attachment
        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 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
        decisions.
        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.

        Ken

        -----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
        questions.

        * 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,
        Jonas


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

        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.