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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.