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

Outsourcing and Trust

Expand Messages
  • Gert
    One of the primary tenets of SCRUM are that you have to trust people that they will perform their work to the best of their ability. During a user group
    Message 1 of 9 , Sep 29, 2009
      One of the primary tenets of SCRUM are that you have to trust people that they will perform their work to the best of their ability.

      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.

      In similar vein, at my previous organization we had a big outsourcing operation. One of the managers said that the coders were would "tweak" the test case and make it pass rather than fix the origin of the failure.

      Of course these types of unethical and unprofessional behavior will occur with any type of management style. Because these are anecdotal evidence, a number of questions spring to mind.

      1. Are these isolated incidents or have other practitioners encountered these types of behavior for outsourced work.

      2. Is there a cultural component to this that makes it acceptable?

      Emphasizing wrong metrics for performance measurements is always bad. Losing the business value of test cases seems unprofessional and as one manager put it, borders on fraud.
    • Michael James
      Trust and trustworthiness grow out of close collaboration toward shared goals. We looked at some code a local competitor of ours had worked on for the same
      Message 2 of 9 , Sep 29, 2009
        Trust and trustworthiness grow out of close collaboration toward
        shared goals.

        We looked at some code a local competitor of ours had worked on for
        the same customer and saw a similar thing -- a thousand green lights
        from auto-generated test stubs!

        I don't perform my work to the best of my ability every second of the
        day. The visibility of my work to the rest of my team helps keep me
        honest.

        --mj


        On Sep 29, 2009, at 4:43 PM, Gert wrote:

        > One of the primary tenets of SCRUM are that you have to trust people
        > that they will perform their work to the best of their ability.
        >
        > 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.
        >
        > In similar vein, at my previous organization we had a big
        > outsourcing operation. One of the managers said that the coders were
        > would "tweak" the test case and make it pass rather than fix the
        > origin of the failure.
        >
        > Of course these types of unethical and unprofessional behavior will
        > occur with any type of management style. Because these are anecdotal
        > evidence, a number of questions spring to mind.
        >
        > 1. Are these isolated incidents or have other practitioners
        > encountered these types of behavior for outsourced work.
        >
        > 2. Is there a cultural component to this that makes it acceptable?
        >
        > Emphasizing wrong metrics for performance measurements is always
        > bad. Losing the business value of test cases seems unprofessional
        > and as one manager put it, borders on fraud.
        >
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        > ! Groups Links
        >
        >
        >
      • venky_nk
        I don t think it is anything related to outsourcing or culture. I believe it is just that they are playing the role of humans. It all depends on understanding
        Message 3 of 9 , Sep 30, 2009
          I don't think it is anything related to outsourcing or culture. I believe it is just that they are playing the role of humans. It all depends on understanding why the outsourced developers are trying to trick the system. Most of the time it is some thing to do with the reward policy.

          In the case you have mentioned, most probably they are evaluated by the % of code coverage. For ex: If they don't meet the required % then it would be escalated to the offshore managers, who in turn batter them by reducing the performance ratings, and in turn affecting salaries.

          I have several case studies where the onsite teams too have tricked the system. I am not bringing an onsite/offshore war here, however since I have been working in this mode for more than a decade, I Have seen both the worlds.

          Thanks,
          Venkatesh
          http://agileworld.blogspot.com



          --- In scrumdevelopment@yahoogroups.com, "Gert" <pragmatic.gert@...> wrote:
          >
          > One of the primary tenets of SCRUM are that you have to trust people that they will perform their work to the best of their ability.
          >
          > 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.
          >
          > In similar vein, at my previous organization we had a big outsourcing operation. One of the managers said that the coders were would "tweak" the test case and make it pass rather than fix the origin of the failure.
          >
          > Of course these types of unethical and unprofessional behavior will occur with any type of management style. Because these are anecdotal evidence, a number of questions spring to mind.
          >
          > 1. Are these isolated incidents or have other practitioners encountered these types of behavior for outsourced work.
          >
          > 2. Is there a cultural component to this that makes it acceptable?
          >
          > Emphasizing wrong metrics for performance measurements is always bad. Losing the business value of test cases seems unprofessional and as one manager put it, borders on fraud.
          >
        • Gert
          Maybe the term co-location instead of outsourcing could be a better use of words. It is more difficult to lie to someone when your are facing them on a daily
          Message 4 of 9 , Sep 30, 2009
            Maybe the term co-location instead of outsourcing could be a better use of words. It is more difficult to lie to someone when your are facing them on a daily basis.

            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 agree whole-heartedly that using a good metric like code coverage and in a bad way shows lack of insight on the overall business objectives. Basing incentives on automated metrics or abstractions and not business value produced is never a good idea.


            --- In scrumdevelopment@yahoogroups.com, "venky_nk" <venkatesh.knowledge@...> wrote:
            >
            > I don't think it is anything related to outsourcing or culture. I believe it is just that they are playing the role of humans. It all depends on understanding why the outsourced developers are trying to trick the system. Most of the time it is some thing to do with the reward policy.
            >
            > In the case you have mentioned, most probably they are evaluated by the % of code coverage. For ex: If they don't meet the required % then it would be escalated to the offshore managers, who in turn batter them by reducing the performance ratings, and in turn affecting salaries.
            >
            > I have several case studies where the onsite teams too have tricked the system. I am not bringing an onsite/offshore war here, however since I have been working in this mode for more than a decade, I Have seen both the worlds.
            >
            > Thanks,
            > Venkatesh
            > http://agileworld.blogspot.com
            >
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, "Gert" <pragmatic.gert@> wrote:
            > >
            > > One of the primary tenets of SCRUM are that you have to trust people that they will perform their work to the best of their ability.
            > >
            > > 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.
            > >
            > > In similar vein, at my previous organization we had a big outsourcing operation. One of the managers said that the coders were would "tweak" the test case and make it pass rather than fix the origin of the failure.
            > >
            > > Of course these types of unethical and unprofessional behavior will occur with any type of management style. Because these are anecdotal evidence, a number of questions spring to mind.
            > >
            > > 1. Are these isolated incidents or have other practitioners encountered these types of behavior for outsourced work.
            > >
            > > 2. Is there a cultural component to this that makes it acceptable?
            > >
            > > Emphasizing wrong metrics for performance measurements is always bad. Losing the business value of test cases seems unprofessional and as one manager put it, borders on fraud.
            > >
            >
          • 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 5 of 9 , Sep 30, 2009
              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 6 of 9 , Oct 1, 2009
                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 7 of 9 , Oct 1, 2009
                  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 8 of 9 , Oct 2, 2009
                    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 9 of 9 , Oct 2, 2009
                      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.