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

Re: [XP] my dev team has too much support

Expand Messages
  • Brian Spears
    At some point, customer issues that cannot be solved by front line support end up handled by the development team. We have a second line of support between the
    Message 1 of 13 , Feb 1, 2007
    • 0 Attachment
      At some point, customer issues that cannot be solved by
      front line support end up handled by the development team.

      We have a second line of support between the front-line
      support and the development team. They are more technical,
      more experienced, and more expensive.

      And issues still come to the team when the second line of
      support cannot solve them. When there are too many coming
      to us, that means either we've made the product too
      difficult to use/too buggy, or we don't have enough
      well-trained second line support people and need to invest
      in more. Either way we have a problem.

      Good luck!

      Brian

      --- eliga_repoleved <eliga_repoleved@...> wrote:

      > My dev team has way too much support load. We currently
      > change
      > support rotation every week. That is -- one person
      > handles production
      > support for a whole week, then it is shifted to the next
      > developer.
      > Support calls can come any time of the day or night. And
      > there is an
      > expectation to answer all of these calls.
      >
      > I get annoyed with the support interuptions, because it
      > distracts my
      > current release work.
      >
      > I don't buy in the concept in any way shape or form, that
      > being
      > bombarded with support requests in the middle of the
      > developer bull
      > pen is some how supposed to make the product better.
      > Whoever came up
      > with this idea should be shot.
      >
      > There is a first level support group, but these are the
      > people who are
      > often coming to the on-call support person on my dev
      > team.
      >
      > Anyone know how to handle this problem? Is there a way
      > to get out of
      > this support load interuption trap?
      >
      > All people involved work for the same company in one
      > office. The
      > software is created, supported, and mainained by people
      > who work in
      > the same company in one office.
      >
      >




      ____________________________________________________________________________________
      Have a burning question?
      Go to www.Answers.yahoo.com and get answers from real people who know.
    • William Pietri
      ... I agree. On the one hand, I like to stay focused while working. On the other hand, feedback is one of the fundamental XP values, and support is where the
      Message 2 of 13 , Feb 1, 2007
      • 0 Attachment
        Brian Spears wrote:
        > At some point, customer issues that cannot be solved by
        > front line support end up handled by the development team.
        >

        I agree.

        On the one hand, I like to stay focused while working. On the other
        hand, feedback is one of the fundamental XP values, and support is where
        the user feedback comes in.

        I think rotating a developer can be a good way to handle that,
        especially if many of the support requests are urgent. If not, then
        perhaps a queue would help, so that the lucky developer can handle
        things in batches.

        Is the problem perhaps that the developer assigned to support doesn't
        have a sufficiently light workload to do it well? Maybe the problem
        isn't the sort of work, but that there's too much.

        William
      • Chris Wheeler
        ... If by bombarded you mean that the support calls are frequent, and if by support calls you mean that the software is buggy or unusable enough that it
        Message 3 of 13 , Feb 1, 2007
        • 0 Attachment
          >
          > I don't buy in the concept in any way shape or form, that being
          > bombarded with support requests in the middle of the developer bull
          > pen is some how supposed to make the product better. Whoever came up
          > with this idea should be shot.
          >
          > Anyone know how to handle this problem? Is there a way to get out of
          > this support load interuption trap?
          >



          If by 'bombarded' you mean that the support calls are frequent, and if by
          support calls you mean that the software is buggy or unusable enough that it
          causes frequent interruptions, then here's a thought:

          Stop building new software and fix the stuff that people are complaining
          about. That, or go out of business as people get frustrated with your
          product. BTW, I worked for a company like that, and they chose to go out of
          business.

          Chris.


          [Non-text portions of this message have been removed]
        • Steven Gordon
          What percentage of the support issues that reach your team a repeat of an issue that was previously seen and resolved? If the percentage is high, somebody from
          Message 4 of 13 , Feb 1, 2007
          • 0 Attachment
            What percentage of the support issues that reach your team a repeat of
            an issue that was previously seen and resolved?

            If the percentage is high, somebody from your team has to take the
            time to properly train the prior levels of support staff and/or
            create/improve the FAQ.

            If the percentage of repeat problems is low (and yet still
            overwhelming in numbers), then the quality or usability of the
            software is the problem. Continuing to just play wack-a-mole with
            these problems won't work for long. Unless your team figures out what
            the root cause of a steady stream of new problems is and fix it,
            support demands will eventually prevent any new features from being
            delivered.

            Steve

            On 2/1/07, eliga_repoleved <eliga_repoleved@...> wrote:
            >
            >
            >
            >
            >
            >
            > My dev team has way too much support load. We currently change
            > support rotation every week. That is -- one person handles production
            > support for a whole week, then it is shifted to the next developer.
            > Support calls can come any time of the day or night. And there is an
            > expectation to answer all of these calls.
            >
            > I get annoyed with the support interuptions, because it distracts my
            > current release work.
            >
            > I don't buy in the concept in any way shape or form, that being
            > bombarded with support requests in the middle of the developer bull
            > pen is some how supposed to make the product better. Whoever came up
            > with this idea should be shot.
            >
            > There is a first level support group, but these are the people who are
            > often coming to the on-call support person on my dev team.
            >
            > Anyone know how to handle this problem? Is there a way to get out of
            > this support load interuption trap?
            >
            > All people involved work for the same company in one office. The
            > software is created, supported, and mainained by people who work in
            > the same company in one office.
            >
          • Slava Imeshev
            ... I know what Eliga is talking about. There are really big names (you likely used them once or twice) that put burden of support on software engineers. It
            Message 5 of 13 , Feb 1, 2007
            • 0 Attachment
              ----- Original Message -----
              > > I don't buy in the concept in any way shape or form, that being
              > > bombarded with support requests in the middle of the developer bull
              > > pen is some how supposed to make the product better. Whoever came up
              > > with this idea should be shot.
              > >
              > > Anyone know how to handle this problem? Is there a way to get out of
              > > this support load interuption trap?
              > >
              >
              >
              >
              > If by 'bombarded' you mean that the support calls are frequent, and if by
              > support calls you mean that the software is buggy or unusable enough that it
              > causes frequent interruptions, then here's a thought:

              I know what Eliga is talking about. There are really big names (you likely
              used them once or twice) that put burden of support on software engineers.
              It really means *everything*: operations, customer calls, network problems,
              air conditioning, restrooms, e.t.c. It is worth mentioning that no one gets any
              training.

              An aquaintance of mine recently told me the story about how he had to deal
              with a failure of a cluster of ~200 nodes. And that was the first time he dealt
              with this kind of stuff.

              The official idea behind it is that if you are really into company's business,
              you have to know how to deal with any problem. My gut feeling tells me
              that this is dead wrong because it denies efficiency of specialization.

              > Stop building new software and fix the stuff that people are complaining
              > about. That, or go out of business as people get frustrated with your
              > product. BTW, I worked for a company like that, and they chose to go out of
              > business.

              Well, I think the original poster comes from a place that proves again that
              success of a technology company does not depend on quality of software
              but rather on marketing and sales.

              The only way to fix this is to move on.

              Just my 2c.

              Regards,

              Slava Imeshev
              www.viewtier.com
            • David Carlton
              ... I would probably get really annoyed by that, too. The one thing that comes to mind: you complain twice about the interruptions. Am I correct in assuming
              Message 6 of 13 , Feb 1, 2007
              • 0 Attachment
                On Fri, 02 Feb 2007 03:15:35 -0000, "eliga_repoleved" <eliga_repoleved@...> said:

                > My dev team has way too much support load. We currently change
                > support rotation every week. That is -- one person handles production
                > support for a whole week, then it is shifted to the next developer.
                ...
                > I get annoyed with the support interuptions, because it distracts my
                > current release work.
                ...
                > Anyone know how to handle this problem? Is there a way to get out of
                > this support load interuption trap?

                I would probably get really annoyed by that, too. The one thing that
                comes to mind: you complain twice about the interruptions. Am I
                correct in assuming that, when not on the phone, the support person is
                supposed to act like a normal developer?

                If that's the case, can your team come up with things for the support
                person to do that wouldn't suffer as much from interruptions? Treat
                the support person's non-phone time as a sort of slack; that person
                can read about interesting ideas, do cleanups of things that are
                annoying you that can safely be done a bit at a time, investigate bugs
                that you haven't gotten around to digging into, talk to the front-line
                support and figure out how to help them become more effective, or
                something.

                Heck, giving the support person no other responsibilities at all
                doesn't sound like a bad idea to me, as long as there are at least 5
                or so people or your team. A bit of slack is good.

                David Carlton
                carlton@...
              • Laurent Bossavit
                Eliga, ... You seem to be implying that whoever has the support role deals with every issue immediately, as it comes in. It may be the case that some issues
                Message 7 of 13 , Feb 1, 2007
                • 0 Attachment
                  Eliga,

                  > Anyone know how to handle this problem? Is there a way to get out of
                  > this support load interuption trap?

                  You seem to be implying that whoever has the "support" role deals
                  with every issue immediately, as it comes in.

                  It may be the case that some issues can afford to be deferred for a
                  while, as long as the person raising it gets a response within a
                  reasonable time. If instead of being constantly interrupted one can
                  defer work on issues and do that in "batch", maybe set aside one day
                  of the week to do that and only that, often that is more effective.
                  Instead of calling, have people submit issues asynchronously.

                  That's the reasoning behind "trouble ticketing" or "issue tracking"
                  systems; have you looked into using one of those ? (And when I say
                  system, I don't necessarily mean dedicated software; anything might
                  do from Post-It notes on a separate board, to a shared email inbox,
                  to a full featured issue tracker.)

                  Laurent Bossavit
                  laurent@...
                • Chris Wheeler
                  ... Or demand of the market - my first job was like this one - the company was successful in spite of itself, and couldn t not be successful , financially.
                  Message 8 of 13 , Feb 2, 2007
                  • 0 Attachment
                    >
                    > Well, I think the original poster comes from a place that proves again
                    > that
                    > success of a technology company does not depend on quality of software
                    > but rather on marketing and sales.



                    Or demand of the market - my first job was like this one - the company was
                    successful in spite of itself, and couldn't 'not be successful',
                    financially. The attitude of those who were closest to the money was 'Why
                    bother changing when we are raking in the cash?'.

                    I left the company, that's how I changed it. I couldn't see a better
                    solution - it's very difficult to change a company that insists it needs no
                    changing. In those cases, I just change my own situation.

                    Chris.


                    [Non-text portions of this message have been removed]
                  • David Carlton
                    ... I don t buy that, at least not with that sort of delay. You ve inserted a large delay into the response, a delay that is pure waste from the bug filer s
                    Message 9 of 13 , Feb 2, 2007
                    • 0 Attachment
                      On Fri, 2 Feb 2007 08:03:30 +0100, Laurent Bossavit <laurent@...> said:
                      > Eliga,

                      >> Anyone know how to handle this problem? Is there a way to get out of
                      >> this support load interuption trap?

                      > You seem to be implying that whoever has the "support" role deals
                      > with every issue immediately, as it comes in.

                      > It may be the case that some issues can afford to be deferred for a
                      > while, as long as the person raising it gets a response within a
                      > reasonable time. If instead of being constantly interrupted one can
                      > defer work on issues and do that in "batch", maybe set aside one day
                      > of the week to do that and only that, often that is more effective.

                      I don't buy that, at least not with that sort of delay. You've
                      inserted a large delay into the response, a delay that is pure waste
                      from the bug filer's point of view.

                      I'm not saying that you should always drop everything and respond
                      immediately (though I think it's worth considering inserting enough
                      slack into your system to allow you to do just that), but we should
                      already be trying to break our work up into small, self-contained
                      chunks. Even ignoring the support load, I think it's always a good
                      idea to be able to come to a reasonable pause in your work within the
                      next couple of hours; if you can do that, why not do the support tasks
                      at the next pause?

                      (Assuming, of course, that they can wait that long; that may not be
                      possible.)

                      David Carlton
                      carlton@...
                    • Laurent Bossavit
                      David, I suggest thinking about how you read your mail.
                      Message 10 of 13 , Feb 2, 2007
                      • 0 Attachment
                        David,

                        I suggest thinking about how you read your mail.
                      • David Carlton
                        ... Right. When I m productive, I don t constantly read my e-mail. But I read it a lot more often than once a week. Which what I was trying to get at in my
                        Message 11 of 13 , Feb 2, 2007
                        • 0 Attachment
                          On Fri, 2 Feb 2007 21:47:20 +0100, Laurent Bossavit <laurent@...> said:

                          > David,
                          > I suggest thinking about how you read your mail.

                          Right. When I'm productive, I don't constantly read my e-mail. But I
                          read it a lot more often than once a week. Which what I was trying to
                          get at in my response: I agree that batching is frequently good, but I
                          also think that small batches are better than large batches.

                          If an important part of my job involved responding quickly to e-mail,
                          though, I would find a way to constantly read my e-mail, and structure
                          my other activities to accept that level of interruptions.

                          David Carlton
                          carlton@...
                        • Dave Churchville
                          I personally had this experience as a the manager of a team with lots of production support issues. We instituted a triage approach where emergencies that
                          Message 12 of 13 , Feb 2, 2007
                          • 0 Attachment
                            I personally had this experience as a the manager of a team with lots
                            of production support issues. We instituted a triage approach where
                            emergencies that were not stopping all work would be addressed in 24
                            hours, and important problems that impacted productivity were
                            addressed within a week. Only truly critical "stop the line" type
                            issues could cause immediate interruption of work.

                            This not only gave the team time to actually get something
                            accomplished other than fire-fighting, but it sometimes prevented
                            solving the wrong problem in the rush to turnaround a solution in a
                            few hours.

                            It also allowed time for more information to be received from the
                            customer, and for true root cause analysis. We started fixing the
                            right problems with a little more time to think, and the support
                            burden droppped dramatically over a few months.

                            --Dave

                            Dave Churchville
                            http://www.extremeplanner.com/blog


                            --- In extremeprogramming@yahoogroups.com, David Carlton <carlton@...>
                            wrote:
                            >
                            > On Fri, 2 Feb 2007 21:47:20 +0100, Laurent Bossavit <laurent@...> said:
                            >
                            > > David,
                            > > I suggest thinking about how you read your mail.
                            >
                            > Right. When I'm productive, I don't constantly read my e-mail. But I
                            > read it a lot more often than once a week. Which what I was trying to
                            > get at in my response: I agree that batching is frequently good, but I
                            > also think that small batches are better than large batches.
                            >
                            > If an important part of my job involved responding quickly to e-mail,
                            > though, I would find a way to constantly read my e-mail, and structure
                            > my other activities to accept that level of interruptions.
                            >
                            > David Carlton
                            > carlton@...
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.