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

Re: [scrumdevelopment] Re: Outsourcing and Trust

Expand Messages
  • Ron Jeffries
    Hello, Gert. On Wednesday, September 30, 2009, at 4:18:52 PM, you ... I tend to agree and we are not from the same culture. I would have that behavior stop
    Message 1 of 9 , Sep 30, 2009
    • 0 Attachment
      Hello, Gert. On Wednesday, September 30, 2009, at 4:18:52 PM, you
      wrote:

      > I have certain friends in the US that will excuse bad teenage
      > behavior as an "experimentation phase" in life. From my cultural
      > perspective I find this excuse totally unacceptable. In similar
      > fashion I would not excuse somebody that deliberately fakes the
      > result of test cases as "tricking the system" or "bad human
      > behavior". Again maybe my cultural perspective.

      I tend to agree and we are not from the same culture.

      I would have that behavior stop immediately, even at the cost of
      losing the people who are not doing their job properly.

      HOWEVER ... one not unlikely cause of this behavior could be undue
      pressure from "management".

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      The opinions expressed here /are/ necessarily those of XProgramming.com.
      But I might change my mind.
    • 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 2 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 3 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 4 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 5 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.