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

Re: [XP] Collocated vs Dispersed...which is better?

Expand Messages
  • Jon Eaves
    ... Not at all. ... I have deliberately omitted a number of things we measured mostly because it s not appropriate for this forum. Not that you wouldn t
    Message 1 of 471 , Aug 1 10:21 PM
    • 0 Attachment
      davenicolette wrote:
      > Hi Jon,
      > Good story. I hope you don't mind if I speculate a bit. You can set me
      > straight if I make bad assumptions.

      Not at all.

      > I'm a strong advocate of team collocation. I felt I should say that at
      > the outset, because the rest of this may well sound otherwise. I guess
      > my point is that if we're going to compare two things objectively, we
      > have to measure them and not just look for circumstantial evidence
      > that appears to support the conclusion we prefer.

      I have deliberately omitted a number of things we measured mostly because
      it's not appropriate for this forum. Not that you wouldn't understand it,
      but because it's not for sharing.

      > So, we have a team that has the following positive characteristics:
      > Then, things change in certain key ways.
      > 1. Team is divided into two sub-teams along the lines of traditional
      > role siloes, and not in a way that preserves cross-functional
      > membership on each sub-team. That smells like a velocity hit to me.
      > Here's why: After 70% of the iterations are complete and everyone has
      > grown into certain habits, the need emerges for more formality in
      > communication, since neither of the teams includes the full complement
      > of necessary roles to drive any given User Story through to
      > completion. The two teams can't just communicate at iteration
      > boundaries, they have to communicate almost constantly because of the
      > siloed roles. They aren't used to it, and until they figure out how to
      > handle it smoothly, velocity is bound to suffer.

      This is correct. However as I said, we can mitigate this, but at additional
      cost. Remember we're talking about "what is best", not "what can be made
      to not suck".

      > 4. We have to expect a velocity hit at least in the first couple of
      > iterations at the new locations, all other considerations aside, just
      > because everyone is setting up their workstations and organizing their
      > team room spaces and all that jazz. It's like Iteration Zero all over
      > again.

      Minor pick here. Site 2 developers used Site 1 resources for development.
      There was no additional setup. Their client machines were already set up.
      They had been "stolen" to Site 1 to work there, until they went back to
      Site 2.

      > With those points in mind, I have to wonder whether the observed
      > difference in delivery effectiveness was *entirely* due to natural
      > characteristics of collocated versus distributed teams. Seems to me
      > other factors were at play here, too. Doesn't that make it hard to
      > reach a conclusion one way or the other about the relative value of
      > collocation based on this situation?

      Nope. All of the fine things you have mentioned are _exactly_ why
      co-location is better than distribution. You've picked up every single
      point we raised in the retrospective about why it is _worse_.

      If you distribute, you have longer feedback loops, need to add additional
      staff, introduce additional processes.

      When you hold the project the same, the staff the same, the environment
      the same and the only variable changes is the physical location - does it
      not suggest that single variable is significantly contributing to the
      change in output?

      I'm personally unaware of a better experiment that could be derived than
      the story I've outlined to highlight the issues with distribution. The
      team had the best possible opportunity to make the greatest advantage with
      the 70% startup (personal links to the project team, familiarity with
      everybody including the customer, no complicated technical things to explain
      over a telephone/video link) - and yet it was still significant degredation
      in capability.

      Yes. There are things that can be done that make it better. Good is the
      enemy of great.

      -- jon

      Jon Eaves <jon@...>
      Co-Author of "Apache Tomcat Bible", "Professional Tomcat 5", "Beginning JavaServer Pages"
    • Keith Ray
      By the way, Classes and Objects referring to patterns of electrical charges in modern day CPU and Memory chips (or past and future equivalents) is a
      Message 471 of 471 , Sep 8, 2008
      • 0 Attachment
        By the way, "Classes" and "Objects" referring to patterns of
        electrical charges in modern day CPU and Memory chips (or past and
        future equivalents) is a metaphor too.

        C. Keith Ray, IXP Coach, Industrial Logic, Inc.
        http://industriallogic.com 866-540-8336 (toll free)
        Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
      Your message has been successfully submitted and would be delivered to recipients shortly.