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

Re: [scrumdevelopment] bugs and sprint resets

Expand Messages
  • bschatz@primavera.com
    We faced this issue many times when we began using scrum and we chose to solve it by creating a scrum team that focuses primarily on customer support issues,
    Message 1 of 6 , Aug 6, 2004
    • 0 Attachment

      We faced this issue many times when we began using scrum and we chose to solve it by creating a scrum team that focuses primarily on customer support issues, and when they're not doing that, they work on other innovative projects that always seem to be on the sidelines. We rotate the team every month using people from other teams. This has worked extremely well for us and has resulted in increased customer satisfaction, increased ability to respond quickly, better appreciation for the customer's pain from the development team, and we've made much better progress on moving some of these side initiatives forward. In addition, the backlog of items that always seem to get stuck in the queue is shrinking rapidly. We put out quarterly patches for most issues, and if there is a priority 1 item as you described, we provide a quick patch. The team follows the same scrum process and reports out to the stakeholders at the sprint review. We've even included a member of the Support staff on the team.

      Bob Schatz
      Primavera Systems, Inc.


      "mikeborozdin" <EZXS@...>

      08/05/2004 05:35 PM

      Please respond to
      scrumdevelopment@yahoogroups.com

      To
      scrumdevelopment@yahoogroups.com
      cc
      Subject
      [scrumdevelopment] bugs and sprint resets





      I'd like to know how people deal with the following situation:

      In the middle of a sprint your customer finds a bug in the version
      that is distributed and of course needs a patch or a fixed version
      right away.

      Several things that the team can do at this point:
      - Create a patch.  This will obviously create thrashing. Still from
      the customer perspective waiting 3 weeks for a fix to a data loss or
      a data corruption bug is unacceptable.

      - Add the item to the current sprint.  This could be good if the bug
      doesn't stop the main function of the software.

      - Split up the team to people who go off and fix stuff and have
      other people go according to the sprint plan.

      - Scrap the entire sprint, fix the patch and then start the sprint
      over.

      And I am sure there are many more other ways of dealing with this.  
      I am curious what people do in those cases.  Thanks!



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


      Yahoo! Groups Sponsor
      ADVERTISEMENT
      click here




      Yahoo! Groups Links
    • Rand Bradley
      Bob - this is a great idea. It would seem to address the issue of Developers getting stuck in the Sustaining Engineering role. ... From:
      Message 2 of 6 , Aug 6, 2004
      • 0 Attachment
        Bob - this is a great idea. It would seem to address the issue of
        Developers getting stuck in the "Sustaining Engineering" role.


        ----- Original Message -----
        From: bschatz@... <bschatz@...>
        Date: Fri, 6 Aug 2004 09:18:46 -0400
        Subject: Re: [scrumdevelopment] bugs and sprint resets
        To: scrumdevelopment@yahoogroups.com


        We faced this issue many times when we began using scrum and we chose
        to solve it by creating a scrum team that focuses primarily on
        customer support issues, and when they're not doing that, they work on
        other innovative projects that always seem to be on the sidelines. We
        rotate the team every month using people from other teams. This has
        worked extremely well for us and has resulted in increased customer
        satisfaction, increased ability to respond quickly, better
        appreciation for the customer's pain from the development team, and
        we've made much better progress on moving some of these side
        initiatives forward. In addition, the backlog of items that always
        seem to get stuck in the queue is shrinking rapidly. We put out
        quarterly patches for most issues, and if there is a priority 1 item
        as you described, we provide a quick patch. The team follows the same
        scrum process and reports out to the stakeholders at the sprint
        review. We've even included a member of the Support staff on the team.

        Bob Schatz
        Primavera Systems, Inc.



        "mikeborozdin" <EZXS@...>

        08/05/2004 05:35 PM

        Please respond to
        scrumdevelopment@yahoogroups.com


        To scrumdevelopment@yahoogroups.com

        cc

        Subject [scrumdevelopment] bugs and sprint resets





        I'd like to know how people deal with the following situation:

        In the middle of a sprint your customer finds a bug in the version
        that is distributed and of course needs a patch or a fixed version
        right away.

        Several things that the team can do at this point:
        - Create a patch. This will obviously create thrashing. Still from
        the customer perspective waiting 3 weeks for a fix to a data loss or
        a data corruption bug is unacceptable.

        - Add the item to the current sprint. This could be good if the bug
        doesn't stop the main function of the software.

        - Split up the team to people who go off and fix stuff and have
        other people go according to the sprint plan.

        - Scrap the entire sprint, fix the patch and then start the sprint
        over.

        And I am sure there are many more other ways of dealing with this.
        I am curious what people do in those cases. Thanks!



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



        Yahoo! Groups Sponsor


        ADVERTISEMENT




        ________________________________
        Yahoo! Groups Links
        To visit your group on the web, go to:
        http://groups.yahoo.com/group/scrumdevelopment/

        To unsubscribe from this group, send an email to:
        scrumdevelopment-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



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



        Yahoo! Groups Sponsor

        ADVERTISEMENT


        ________________________________
        Yahoo! Groups Links

        To visit your group on the web, go to:
        http://groups.yahoo.com/group/scrumdevelopment/

        To unsubscribe from this group, send an email to:
        scrumdevelopment-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



        --
        Kind Regards,

        Rand Bradley
        PROJECTWAY, LLC
        Phone: (415) 409-9709
        Mobile: (415) 939-6883
        Email: rbradley@...
        http://www.projectway.com
      Your message has been successfully submitted and would be delivered to recipients shortly.