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

Large project, transition to Scrum, request for comments (long post).

Expand Messages
  • johneruberto
    Hi, This is a request for comments and suggestions for our initial implementation of Scrum. Please feel free to comment. Background: Our project team has
    Message 1 of 2 , May 5, 2004
    • 0 Attachment
      Hi,

      This is a request for comments and suggestions for our initial
      implementation of Scrum. Please feel free to comment.

      Background:
      Our project team has about 110 engineers (70 dev, 40 test). The
      product is about 5 years old, with 3-4 major releases per year. Our
      software manages telecommunications equipment (alarms,
      backup/restore, TL1 connections, etc.) As such, we have strong
      dependencies on the actual hardware. The schedule & quality of the
      associated deliverables varies a great deal. This variance causes
      lots of re-planning, wasted effort (our team finds many errors in the
      hardware, and rework (we often start work before the interface is
      100% defined, and the hardware is developed off site, we sometimes
      get surprised by changes only when we have actual code).

      The typical project takes about 6 months: 3 months of development &
      feature test, followed by 3 months of bug fixing & system test. At
      the feature complete stage, we typically have about 400 bugs to fix,
      and will find another 300 during system test. To release the
      product, we must have fewer than 50 bugs (and some severity
      criteria), thus the 3-month "system test" duration is filled
      by test and fixing 600-650 bugs.

      Our plan:
      We are planning to use Scrum for our next project. The main driver
      is to take a feature into a sprint only when the associated
      dependency is actually met. This should eliminate the wasted effort
      of trying to plan 6 months in advance, only to have all the
      dependencies move, and the rework associated with poor quality of the
      deliverables (design & code prior to the hardware being stable).

      Instead of the 3 months dev, 3 months bug fix & test, we are planning
      4 "development sprints", 1 sprint dedicated to bug fixing,
      followed by 1 small sprint (2 weeks) of final system test, media
      preparation, etc. Each development sprint will include feature
      testing, and have exit criteria of 100% planned test execution with a
      95% pass rate.

      The output of each development sprint will be fed to the system test
      team, who will test it as though it was a complete product (soak
      test, load testing, system test of the completed features, regression
      test, etc.).

      Questions:
      - Having a separate test team perform system test (some of these take
      weeks to execute) seems outside of the pure Scrum methodology.
      Anyone have opinions on this?
      - What should we do if the sprint is completed, but one or two
      features do not meet the exit critieria?
      - What if more than that don't meet the criteria? (we assume
      about 20 to 25 features per sprint)


      Thank you very much for your time & comments.

      John
    • Mike Cohn
      Hi John-- Here s how I d answer your questions: 1) Having a separate test team is outside of mainstream Scrum. BUT, if you can maintain a mentality on the
      Message 2 of 2 , May 5, 2004
      • 0 Attachment
        Hi John--
        Here's how I'd answer your questions:

        1) Having a separate test team is outside of mainstream Scrum. BUT, if you
        can maintain a mentality on the Scrum team that they need to deliver
        top-quality working code then it can still work. You'll have to work harder
        to instill this and make sure that no one ever leaves something to be found
        by testing on purpose. I'd also make sure to include the outside testers
        into the project as much as possible. Is there any reason you can't include
        them all the way through? In that way, you'd make them part of the team and
        would be more aligned with mainstream Scrum (which gives the benefit of
        never letting quality slip) I've had teams somewhat similar to this and to
        get them used to Scrum we would initially target "friendly first use" as our
        quality goal for each sprint. So, we didn't want to ship it to the whole
        world but we'd give it to beta sites and such. We'd then use a
        "stabilization sprint" after 3-4 sprints to go from friendly first use to
        production quality. It works well and use it as long as you need it. Focus
        mostly on the ratio of regular sprints to stabilization sprints. Maybe you
        sprint for 12 weeks then stabilize for 6 at first. Later maybe it becomes 15
        and 3. And in your environment that might be the best you get. It still
        beats your competitors likely 8 weeks of coding and 10 of testing.

        2) If you finish the sprint but miss one or two features, put the one or two
        features onto the product backlog and ask your customer to reprioritize. The
        features probably come right back into the next sprint but maybe not. Also,
        in the next sprint try to commit to only as much as you're sure you can
        deliver. If the team drops two features, how do I know they weren't the most
        important features? You're far better bringing in the 8 (for example) most
        important and then coming back from 2 more. Don't do the opposite and pick
        12 and drop 2 out of the pile because you won't know if they are the two
        lowest priority.

        3) If there are more that don't meet the criteria then you're probably
        trying to go too fast. Slow down and fully finish each feature before moving
        on. Focus on the flow of work through your system. Get stories/features
        done in small chunks and flow those to your team's tester as quickly as
        possible. Then start the next small piece.

        Because of the hardware involvement I'd suggest thinking about deferring
        decisions as long as possible. If you can choose feature A or feature B to
        code this sprint and B depends on hardware or B depends on hardware is more
        likely to change than the hardware of A, then work on A first. Mary and Tom
        Poppendieck refer to this as deciding in the "last responsible moment." See
        their excellent "Lean Software Development" book for advice in this regard
        that is totally compatible with Scrum. (I've got a review of it on my site
        at www.mountaingoatsoftware.com/reviews)

        Good luck,
        --Mike Cohn
        Author of User Stories Applied for Agile Software Development
        www.userstories.com


        -----Original Message-----
        From: johneruberto [mailto:johneruberto@...]
        Sent: Wednesday, May 05, 2004 1:13 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Large project, transition to Scrum, request for
        comments (long post).

        Hi,

        This is a request for comments and suggestions for our initial
        implementation of Scrum. Please feel free to comment.

        Background:
        Our project team has about 110 engineers (70 dev, 40 test). The
        product is about 5 years old, with 3-4 major releases per year. Our
        software manages telecommunications equipment (alarms,
        backup/restore, TL1 connections, etc.) As such, we have strong
        dependencies on the actual hardware. The schedule & quality of the
        associated deliverables varies a great deal. This variance causes
        lots of re-planning, wasted effort (our team finds many errors in the
        hardware, and rework (we often start work before the interface is
        100% defined, and the hardware is developed off site, we sometimes
        get surprised by changes only when we have actual code).

        The typical project takes about 6 months: 3 months of development &
        feature test, followed by 3 months of bug fixing & system test. At
        the feature complete stage, we typically have about 400 bugs to fix,
        and will find another 300 during system test. To release the
        product, we must have fewer than 50 bugs (and some severity
        criteria), thus the 3-month "system test" duration is filled
        by test and fixing 600-650 bugs.

        Our plan:
        We are planning to use Scrum for our next project. The main driver
        is to take a feature into a sprint only when the associated
        dependency is actually met. This should eliminate the wasted effort
        of trying to plan 6 months in advance, only to have all the
        dependencies move, and the rework associated with poor quality of the
        deliverables (design & code prior to the hardware being stable).

        Instead of the 3 months dev, 3 months bug fix & test, we are planning
        4 "development sprints", 1 sprint dedicated to bug fixing,
        followed by 1 small sprint (2 weeks) of final system test, media
        preparation, etc. Each development sprint will include feature
        testing, and have exit criteria of 100% planned test execution with a
        95% pass rate.

        The output of each development sprint will be fed to the system test
        team, who will test it as though it was a complete product (soak
        test, load testing, system test of the completed features, regression
        test, etc.).

        Questions:
        - Having a separate test team perform system test (some of these take
        weeks to execute) seems outside of the pure Scrum methodology.
        Anyone have opinions on this?
        - What should we do if the sprint is completed, but one or two
        features do not meet the exit critieria?
        - What if more than that don't meet the criteria? (we assume
        about 20 to 25 features per sprint)


        Thank you very much for your time & comments.

        John



        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.