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

Re: [scrumdevelopment] Outsourcing and Trust

Expand Messages
  • daswartz@prodigy
    Hello Gert, ... As others have noted, my first question is: What are the measurements of amount of code checked in, and test code coverage used for. Are good
    Message 1 of 9 , Oct 1, 2009
    • 0 Attachment
      Hello Gert,

      Tuesday, September 29, 2009, 3:43:58 PM, you wrote:

      > During a user group meeting this week one of the software managers
      > complained that he noticed that his figures for test code coverage
      > jumped radically. After investigating he found a lot of ASSERT(true)
      > scattered throughout the newly improved code, as well as a lot of
      > additional blank spaces to increase new code checked in.

      As others have noted, my first question is: What are the measurements
      of amount of code checked in, and test code coverage used for. Are
      "good" numbers somehow used to rate the team, or team members?

      If so, then, while reprehensible, the observed behavior should have
      been expected. What we measure and how we use the measurements impacts
      what happens.

      Personally, I've never found a measure of "how much code was changed"
      to be useful for anything, except correlation with areas of a system
      which tend to have more problems. In that case, more changed code is
      generally bad.

      Code covered by tests can be a useful metric, if the team uses it for
      itself to gauge how much of the code is at least executed by the test.
      As a "management" measure I believe it is worse than useless.


      --
      doug Swartz
    • Gert Wallis
      Doug, I don t think anybody would disagree that having well crafted test cases that truly exercise the code is a good thing. Measuring coverage and encouraging
      Message 2 of 9 , Oct 1, 2009
      • 0 Attachment
        Doug,

        I don't think anybody would disagree that having well crafted test cases that truly exercise the code is a good thing. Measuring coverage and encouraging team members to improve it is also good.

        It is also true that because it is quantifiable that managers could use it as a stick in bad ways. Regardless of the environment my interest lies more in the psyche of the developer that deliberately undermines the value for personal gain.

        When I did my SCRUM training Ken spent a good portion of the time on trust and not micromanaging every individual. Give them the responsibility and allow them to perform to the best of their ability.

        When I tried to "sell" TDD to a large internal outsourced team, the management response was that they will "cook the books". If you have that level of distrust SCRUM (or waterfall) will fail, or produce mediocre results.

        My interest is more on the personality traits and motivation of the individuals. Is this more prevalent in outsourced vs. co-located teams? What role does culture and personal ethics play for success?

        I personally believe personality and technical depth of team members are the primary contributing factors for success. SCRUM and good leadership will definitely improve the odds but I think technical managers tend to spend too little time on our people skills.

        Gert

        --- In scrumdevelopment@yahoogroups.com, "daswartz@..." <daswartz@...> wrote:
        >
        > Hello Gert,
        >
        > Tuesday, September 29, 2009, 3:43:58 PM, you wrote:
        >
        > > During a user group meeting this week one of the software managers
        > > complained that he noticed that his figures for test code coverage
        > > jumped radically. After investigating he found a lot of ASSERT(true)
        > > scattered throughout the newly improved code, as well as a lot of
        > > additional blank spaces to increase new code checked in.
        >
        > As others have noted, my first question is: What are the measurements
        > of amount of code checked in, and test code coverage used for. Are
        > "good" numbers somehow used to rate the team, or team members?
        >
        > If so, then, while reprehensible, the observed behavior should have
        > been expected. What we measure and how we use the measurements impacts
        > what happens.
        >
        > Personally, I've never found a measure of "how much code was changed"
        > to be useful for anything, except correlation with areas of a system
        > which tend to have more problems. In that case, more changed code is
        > generally bad.
        >
        > Code covered by tests can be a useful metric, if the team uses it for
        > itself to gauge how much of the code is at least executed by the test.
        > As a "management" measure I believe it is worse than useless.
        >
        >
        > --
        > doug Swartz
        >
      • daswartz@prodigy
        Hello Gert, ... In 30 years (has it really been that long?!) of software development jobs, I ve met very very few developers who I believe consciously did a
        Message 3 of 9 , Oct 2, 2009
        • 0 Attachment
          Hello Gert,

          Thursday, October 1, 2009, 10:07:08 AM, you wrote:

          > It is also true that because it is quantifiable that managers could
          > use it as a stick in bad ways. Regardless of the environment my
          > interest lies more in the psyche of the developer that deliberately
          > undermines the value for personal gain.

          In 30 years (has it really been that long?!) of software development
          jobs, I've met very very few developers who I believe consciously
          did a bad job. I've known some who are highly motivated by personal
          advancement and money, and I've worked with some who I felt chose the
          wrong career because they simply were not very good at their jobs.
          Personal gain, however, isn't intrinsically a bad thing, and I believe
          I've known people who would add blank lines to their code (without
          actually decreasing the quality of the code itself, or slowing down
          productivity) if management were stupid enough to count lines of code
          as a meaningful good thing.

          <personalAnecdote> 25+ years ago I was working as a mainframe developer
          at a relatively large (100+ developers) shop. One day a VP
          called my team leader into a meeting and asked him "Why do Doug and
          Gary run two to three times as many compiles as every other
          programmer in the shop?". My team leader explained that Gary and Doug
          were two of the most productive developers he had ever worked with.
          Neither Gary nor I changed our behavior, but if my next raise had
          depended on it, I might have (while I looked for a new job).
          </personalAnecdote>

          > When I did my SCRUM training Ken spent a good portion of the time
          > on trust and not micromanaging every individual. Give them the
          > responsibility and allow them to perform to the best of their ability.

          Trust is a two way street, takes time to establish, and, especially
          early in a relationship, is easily undermined. I have no visibility
          into the situations you've described, so can't comment specifically.
          Here are questions I would ask

          Do the outsourcing firm and the contracting firm have a good history.
          Is that good history reflected in contract terms which encourage the
          outsourcer to work closely with the customer to create the best
          possible system, or are the terms more like: "deliver exactly to spec,
          exactly on-time, with a bonus for automated test coverage".

          Do the developers have a cultural history of disincentives of various
          sorts for "thinking", or a history of being encouraged to step up to
          take on responsibility? Is there a history of "development silver
          bullet of the year", with management words usually not matching their
          actions, and no real evidence yet of long term commitment to "this
          agile thing"?

          > When I tried to "sell" TDD to a large internal outsourced team, the
          > management response was that they will "cook the books". If you have
          > that level of distrust SCRUM (or waterfall) will fail, or produce
          > mediocre results.

          What is an "internal outsourced team"?

          Low trust levels certainly contribute to mediocre results. And yet,
          I'm interested in what books could be cooked? For books to exist,
          something must be measured. Honestly, I can't imagine a measure of TDD
          that would be meaningful.

          > My interest is more on the personality traits and motivation of the
          > individuals. Is this more prevalent in outsourced vs. co-located
          > teams? What role does culture and personal ethics play for success?

          I find this area interesting as well. My college psychology professor
          had one primary rule "People vary.". Individuals will have differing
          attitudes and reactions. I believe company culture is a large factor.
          I suspect national/ethnic culture is a much smaller factor.

          > I personally believe personality and technical depth of team
          > members are the primary contributing factors for success. SCRUM and
          > good leadership will definitely improve the odds but I think
          > technical managers tend to spend too little time on our people skills.

          Absolutely. "Individuals and interactions over processes and tools"


          --
          doug Swartz
        • Archer, Jonathan
          ... I m a Brit working in the US who has worked with teams in both those countries as well as Germany, Belarus and India. In my opinion, culled from my
          Message 4 of 9 , Oct 2, 2009
          • 0 Attachment
            This piece of the conversation is interesting to me:

            >> My interest is more on the personality traits and motivation of the
            >> individuals. Is this more prevalent in outsourced vs. co-located
            >> teams? What role does culture and personal ethics play for success?

            > I find this area interesting as well. My college psychology professor
            > had one primary rule "People vary.". Individuals will have differing
            > attitudes and reactions. I believe company culture is a large factor.
            > I suspect national/ethnic culture is a much smaller factor.

            I'm a Brit working in the US who has worked with teams in both those
            countries as well as Germany, Belarus and India. In my opinion, culled
            from my experience, you will definitely find a wide variety of attitudes
            and behaviors within a single national/ethnic culture. Nonetheless,
            understanding the general outlook that permeates a culture can help with
            understanding and cooperation within a team with a diverse make up.
            There definitely are differences and personally I found myself much less
            frustrated once I better understood this.

            For example, I see much greater willingness to be critical of things and
            offer suggestions from people I've worked with in Belarus than in India.
            This makes certain aspects of agile thinking (retrospectives :-) harder
            for some folks from India initially. However, a colleague of mine who
            has worked with teams there for longer than me says that with the right
            approach it's quite possible to get folks to overcome their reluctance
            in this area.

            This website has some short but useful profiles of various countries
            that I certainly found helpful in understanding this kind of thing:
            http://www.worldbusinessculture.com/ (no, not affiliated to them in
            anyway... :-)

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