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

Re: [XP] Re: Distributed XP

Expand Messages
  • Ron Jeffries
    ... One of my favorite sigs seems to me to be apropos here, from Mary Doria Russell, in her marvelous book /The Sparrow/: Wisdom begins when we discover the
    Message 1 of 82 , Apr 1, 2006
      On Saturday, April 1, 2006, at 4:42:44 AM, Philip Doherty wrote:

      >>I suspect that you use analogies often, though implicitly, as you
      >> do here with "mix" and "fit".

      > You're right, I suppose I dont have a problem with them if they make sense

      One of my favorite sigs seems to me to be apropos here, from Mary
      Doria Russell, in her marvelous book /The Sparrow/:

      Wisdom begins when we discover the difference between
      "That makes no sense" and "I don't understand".

      I'm not here to sell analogies, but it seems to me that the point of
      analogies is to discover and exploit shared understandings and
      values between the parties. That discovery is always at least an act
      of will on the part of the listener, and perhaps a matter of ability
      as well. One hopes that the listener will choose to think, perhaps
      along these lines:

      We're talking about how cost is very important to organizations,
      that build software, and Analogy Guy is saying something about
      value. He gives me this silly analogy where I'm in a low paying
      job. Let me think about that ...

      OK, I'm working in a low-paying job. Everything I want seems to
      cost too much. Someone says to me "Think! The problem isn't that
      everything costs too much. What you need to think about is that
      your current job doesn't have very high economic value."

      So ... OK ... if my job had higher economic value ... I could
      get more money ... and then things wouldn't cost so much,
      relative to how much money I would then have.

      OK, now how does that apply to software groups like mine?

      Ah. Software organizations are, or ought to be, concerned about
      profit, or how much value they can deliver from their software.
      Costs can only be reduced so far, and probably they'll go up over
      time no matter what we do, just like they will for that poor devil
      in the six dollar an hour job. It's a losing proposition for him
      to shop at cheap stores, the prices even go up there. He needs to
      deliver more value to the world, so he'll make more money.

      What about us? If we focus on delivering value, the sky's the
      limit. But we still have costs that have to be covered. What about
      the six dollar guy? Right ... it isn't enough that he be a
      valuable person, he has to find a way to get paid for being
      valuable ... he has to get a better job.

      So we have to get better contracts ... we need to sell our
      contracts based on value, not just cost. How could Agile methods
      help us do that? Must think ...

      So Six Dollar Guy goes looking for a better job. He sells himself
      and his special abilities to people who needs them. So we could
      look for customers who can be helped by our kind of company rather
      than a remote off-shoring company. What's a problem with an
      off-shoring company? They can't talk to the customer every day. We
      can. Let's find customers who value that.

      What else?

      We can deliver software every week. Let's find customers who
      value that.

      Our software is shown to work by tests the customer specifies.
      Let's build on the concern that every customer has that the
      software won't work.

      We're delivering the software in little bitty pieces, and we're
      not over-committed to either the past or the future. We can be
      responsive to change! Let's sell that to the customer.

      Holy Increasing Revenue, Batman! We're so much more than a cheap
      job shop! We're so much better than a company that's far away and
      can only communicate with email! We can charge more, not because
      our costs are higher, but because our value is higher!

      If we can increase revenue for the same amount of work ... if we
      focus on that rather than on squeezing every last nickel out of
      the pockets of our own people ... we can grow faster, make more
      money, make more fun, and become known as a company that really

      Thanks, Six Dollar Guy! Thanks, Analogy Guy! I see things
      differently now -- I figured it out on my own. Wow! Life is good!

      Of course it doesn't always work out that way. But when it does,
      we've done more than just hand someone a fish.

      Ron Jeffries
      It's easier to act your way into a new way of thinking
      than to think your way into a new way of acting. --Millard Fuller
    • Jason Nocks
      ... ... ... The book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency strikes me as oddly relevant, particularly the
      Message 82 of 82 , Apr 7, 2006
        On Tuesday 04 April 2006 6:05 am, Keith Braithwaite wrote:
        > --- In extremeprogramming@yahoogroups.com, "Keith Ray" <keith.ray@...>
        > wrote:

        > Lets be careful with these numbers. I find the paper a bit incoherent,
        > seems to jump around a lot between the general, the specfic, personal
        > anecdote and focused experience reoprt, but section 6 seems to be the
        > meat.
        > It states that an (unspecified, no citation) colocated SCRUM team did
        > 959 Function Points in 54 person months, or 17.8 FP/person-month.
        > Whereas the distributed team described in the paper did (via a
        > slightly fishy reverse lookup) 12673 FPs in 827 person months, or 15.3
        > FP/person-month. A 16% difference. How bad is that? Depends on your
        > prefered figure of merit.
        > Interestingly, the paper compares these figures against an industry
        > average FP/person-month for projects _of that size_, whereby the
        > colocated SCRUM team is 42% more productive that the industry average
        > for projects of 1000FPs or so. But the distributed team is around 400%
        > more productive than the industry average for projects in the 10,000's
        > of FPs.
        > Assuming that the colocated team could maintain their 17.8 FP/pm for
        > the whole duration, and all other things being equal, the 4.5 person
        > [sic] co-lo team would have taken slightly less than 160 months to
        > complete the 12000+ FPs. The distributed team took 14.5 months.

        > Something to think about.

        The book, "Slack: Getting Past Burnout, Busywork, and the Myth of Total
        Efficiency" strikes me as oddly relevant, particularly the "Myth of Total
        Efficiency" part. Just my $.02.

        > Keith

        Jason Nocks
      Your message has been successfully submitted and would be delivered to recipients shortly.