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

RE: [scrumdevelopment] Handling Customer Issues in Agile

Expand Messages
  • jim.murphy@pobox.com
    Sounds like you are very responsive to your customers! In our case we have a dedicated 1st line support person that handles the day-to-day. She doesn t make
    Message 1 of 8 , Aug 22 7:23 AM
    • 0 Attachment
      Sounds like you are very responsive to your customers!
       
      In our case we have a dedicated 1st line support person that handles the day-to-day.  She doesn't make commitments to fix anything but marshals the process of answering common questions, figuring our a problem/enhancement request from a customer, escalating to dev for immediately clarification.  Once its understood we make a backlog item for it in our "Service Pack Backlog".  Then, as I said before we manage an interleaved sprint to burndown the service pack work. 
       
      This gives us 2 month response times in general - but that sounds like its too long for your situation.
       
      Jim
       
       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of deepinder singh
      Sent: Wednesday, August 22, 2007 4:32 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Handling Customer Issues in Agile

      thanks everyone for providing your valuable inputs to the query I had.

      What I could think of as a solution is give some buffer time while doing iteration planning. We cannot keep the customer issue pending i.e. without any response more than 1 day (sev1 and Sev2). so we need to work parallel with release development. So giving more buffer time while release planning may help to some extend. I am not sure how much will this help because if the flow of customer issue is high this may not be wise thing but I still have to experience it...

      Any thoughts on this?

      Thanks, ~Deepinder

      Jim Murphy <jim.murphy@...> wrote:
      Good question - usually its pretty simple when our bug fixes for service packs are simple.  Hard to characterize but imagine a few lines across a few classes is considered a reasonable change/fix for a service pack.  We don't make bold moves for service packs so re-integrating is simple.
       
      If it takes more - then we'll fold it into the next release.  Typically that's on average  2 month wait - still responsive by current standards.
       
      Jim
       
       


      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Jeff M.
      Sent: Saturday, August 18, 2007 11:38 AM
      To: scrumdevelopment@ yahoogroups. com
      Subject: Re: [scrumdevelopment] Handling Customer Issues in Agile

      I was curios about item 7, how well does that work, how hard is it to smoothly integrate the 2 branches? we are planning for this same type of approach.
      thanks.
       
      ----- Original Message -----
      Sent: Saturday, August 18, 2007 7:04 AM
      Subject: RE: [scrumdevelopment] Handling Customer Issues in Agile

      My company has the same challenges.  We ship 3-4 time a year but have a series of "service pack" style releases and escalated support cases that require developer attention to ascertain if a reported issue is a bug, user error or a mix.
       
      I think what I would like is 2 teams - 1 doing support/maintenance and the other doing next release work.  We can't justify the $$ for that so we interleave the work in the main dev team. 
       
      Here is what we actually do:
       
      1. Maintain 2 branches in source control - 1 for "services pack" the other for "next release"
      2. Dev team works on next release branch doing new stuff
      3. Support incident arrives, our support person tries to handle it, if not gathers as much info as possible then escalates to a dev point person
      4. dev point person immediately spends upt o a few hours to characterize (not solve) the problem
      5. If it is a problem we capture info into a "service pack backlog" and notify support/customer of that
      6. Once a 1-2 week sprint work of issues accumulate int he service pack backlog we inject a 1-2 week sprint into the release, entire team switched from release branch to service pack" branch to fix customer reported problems - and whatever "key bugs" we think should preemptively be fixed.
      7. The service pack is releases, we integrate the 2 branches and the release continues as normal
       
      We get typically 2-4 week response time to critical customer issues this way without thrashing the dev team too much.  Its a workable solution for our situation.
       
      Any feedback or ideas on this approach would be appreciated.
       
      Jim


      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of deepinder singh
      Sent: Saturday, August 18, 2007 7:56 AM
      To: scrumdevelopment@ yahoogroups. com
      Subject: [scrumdevelopment] Handling Customer Issues in Agile

      I think Customer Issues along with release activities is really difficult to handle in Agile if we have same resources to work on.

      Right now we do not have dedicated team for customer issues and release development. But the same team has to work on Release activities and Customer Issues. Although we do plan for a buffer time for customer issues along with release planning in every iteration. Sometimes customer issues really need more time than the buffer time allocated or the flow of customer is high. In that situation, Developer is distracted from the release activities and slips his Iteration deadlines because of customer issues. It is not that developer thinks that he cannot do his job but due to the flow of customer issue he cannot do iteration tasks.

      How can we best handle customer issues without any delays in release activities?

      Thanks,
      ~Deepinder

      Shape Yahoo! in your own image. Join our Network Research Panel today!


      Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.

    Your message has been successfully submitted and would be delivered to recipients shortly.