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

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

Expand Messages
  • davenicolette
    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. I m a strong advocate of team collocation. I
    Message 1 of 471 , Aug 1, 2008
      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.

      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.

      So, we have a team that has the following positive characteristics:

      1. Cross-functional; all necessary skillsets represented, including
      the customer proxy.

      2. Collocated; low communication overhead; easy to collaborate; no
      need for much formality in communicating requirements or sharing
      feedback on acceptance tests.

      3. Settled into a certain routine of working together over the course
      of several iterations; interpersonal dynamics among this particular
      group of individuals are well established.

      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.

      2. We now have a scrum-of-scrums arrangement (whether under that name
      or not) to coordinate the work of the two teams. That naturally
      introduces communication overhead that didn't exist in the original
      single-team configuration.

      3. Say there were 12 team members initially, and we now have a team of
      7 in one location and a team of 5 in the other. I don't know if those
      were the actual numbers, of course. In any case, although all the team
      members know each other and have been working together, this is in
      effect two brand new teams that haven't worked together in just that
      configuration before. Every new configuration of individuals is a
      "new" team from the standpoint of interpersonal dynamics. If what I
      learned in the good 'ol CSM course is correct (and applying this
      particular lesson on real projects over the years suggests to me that
      it *is* correct), we can expect about a 40% velocity hit on both teams
      during their first productive iteration in their new locations just
      from that factor alone, with improvement thereafter as the
      interpersonal dynamics of each "new" grouping get settled.

      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

      5. The developers are now physically separated from the customer
      proxy. This introduces logistical challenges in end-of-iteration
      demos. Separation of the teams also creates logistical challenges for
      effective retrospectives and for iteration planning. All these
      activities that used to be easy to do in a single team room now call
      for a level of planning and coordination that hadn't been necessary

      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?


      --- In extremeprogramming@yahoogroups.com, Jon Eaves <jon@...> wrote:
      > Hi all,
      > Here are my experiences.
      > Without going into the specifics too deeply, we ran an internal project
      > that started as a co-located agile team, that was to be distributed
      > Approximately 70% of the iterations were done at Site 1, and the
      > 30% of the iterations were done split between Site 1 and Site 2. Site 2
      > contained the development team, with the BA, Testing and Customer
      Proxy at
      > Site 1.
      > The team members did not change significantly during the course of the
      > project. There was the standard Person X on holiday, and Person Y left
      > the company, but nothing more than you'd expect, and none of it was part
      > of the split (ie, they occured either before, or overlapped).
      > After the project team split, we had significantly lower velocity,
      > significantly higher defects, significantly less adherence to quality
      > standards and practices and longer times to rectify these issues.
      > When I'm talking significantly, I'm talking 50%+ additional worsening
      > to these factors.
      > There are some factors to this, such as lack of support and experience
      > for Site 2, but that would involve duplication and additional cost.
      > There is no doubt in my mind that co-location is the cheapest and most
      > effective means of performing any software development activity. As
      > soon as you split the team, you are adding cost and delays. There are
      > things you can do to mitigate the additional costs and delays, but it
      > will always be more costly, and take longer.
      > This is real world experience. I hope that helps.
      > Cheers,
      > -- jon
      > Ken Boucher wrote:
      > >>> I also can't imagine having the words "offshoring/outsourcing" in
      > >>> the question helped matters.
      > >> "Helped matters" in what way? Would you like the survey results
      > >> better if they were the other way?
      > >
      > --
      > Jon Eaves <jon@...>
      > http://www.eaves.org/blog/
      > 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
        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.