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

Re: [XP] Re: Interruptions metric

Expand Messages
  • Gojko Adzic
    ... I spent about a year in a very similar situation, where I was officially an architect on a project, but de facto spent most of my time answering questions
    Message 1 of 583 , Feb 24, 2008
    View Source
    • 0 Attachment
      > The surprise (to me) was the one person who had phenomenal amounts of
      > interruptions ... it turned out that handling those calls and
      > interruptions was very much part of his job -- we couldn't find any
      > way to reduce to bundle them. The implication was that his expected
      > productivity simply had to be limited to account for the fact that he
      > was never going to get a lot of quiet time to work.
      >
      > Alistair

      I spent about a year in a very similar situation, where I was officially
      an architect on a project, but de facto spent most of my time answering
      questions to new people as the team was expanding, coordinating various
      threads, chasing people, interfacing with clients and attending all
      sorts of stupid meetings to get the politics out of the way. Although
      most of that stuff should have been done by a project manager, the
      nature of the project called for someone who was much more technical to
      do stuff like that... I joked about the position being actually a
      "software lubricant", oiling the machine to keep it running.

      The thing is, when I was still trying to be productive in a sense of
      producing code or some programming-related artifacts, then both I and
      several other people wasted a lot of time on all those "lubricant"
      tasks. We decided that I should take over all that, so the rest of the
      core team was able to be productive. Everyone else was given a green
      light to forward all unwanted communication to me, and the rest of the
      organisation was strictly forbidden from harassing people in the team
      (although that was not obeyed as much as I hoped). In any case, we
      managed to relieve the rest of the team from most interruptions.

      Although I still tried to cut code in order no to lose the touch with
      how things are progressing, we did not count on my involvement in terms
      of planning at all -- my time was simply written off.

      Looking back at that from a time distance of 4 months, I think that this
      was a good way to solve that problem as far as the project progress and
      team productivity is concerned. It was horribly stressful at times, so
      from a personal point I would probably try to look for ways to improve
      that tactic in the future, but proved to be very effective.

      --
      gojko adzic
      http://gojko.net
    • John A. De Goes
      Hi Dale, ... Agreed. It s comparatively easy to find a source of waste and reduce it. Logically, if you didn t introduce any other form of waste whilst making
      Message 583 of 583 , Mar 6, 2008
      View Source
      • 0 Attachment
        Hi Dale,

        On Feb 28, 2008, at 6:00 PM, Dale Emery wrote:
        > Yeah. There's an idea tickling my brain, and slowly connecting lots of
        > other loose threads: A really good way to think about productivity
        > is not
        > to think about productivity per se, but instead about cost. In your
        > example, you've eliminated a cost, and allowed people to infer an
        > increase
        > in productivity.
        >

        Agreed. It's comparatively easy to find a source of waste and reduce
        it. Logically, if you didn't introduce any other form of waste whilst
        making this change, then you must have increased productivity, metric
        or no.

        > Here's a half-baked idea: To some extent, each new request from an
        > existing
        > customer expresses satisfaction with our prior performance. (That
        > is, how
        > likely are they to recommend you to themselves?)
        >

        Hmm, I'm not so sure about this. There's a certain cost associated
        with transitioning to a new provider. There's the cost of locating
        that provider, the cost of negotiations, the cost of transferring
        assets to the new provider, the cost of allocating time in the busy
        schedule of the new provider, and the ramp-up costs of the new
        provider becoming acquainted with the existing assets. All of which,
        combined, exceed by many orders of magnitude the cost of a new request
        -- even if the cost of said request is far higher than it should be,
        and its implementation leaves much to be desired.

        If a customer starts new projects with you, however, then that does
        say something about how satisfied they are with your performance.

        Regards,

        John A. De Goes
        N-BRAIN, Inc.
        http://www.n-brain.net
        [n minds are better than n-1]
      Your message has been successfully submitted and would be delivered to recipients shortly.