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

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

Expand Messages
  • davenicolette
    Jon, You make a good case for collocation. Here s another consideration: Most IT projects have a scope that calls for more than one small team. Agile methods
    Message 1 of 471 , Aug 2, 2008

      You make a good case for collocation. Here's another consideration:
      Most IT projects have a scope that calls for more than one small team.
      Agile methods haven't crossed the chasm to any significant extent
      because people are still figuring out how to apply the values and
      principles at scale. Some pretty good books on that subject are out,
      and I know of a number of people in the community who have been
      applying practical ideas in the field to make agile work well at scale.

      When a project is larger than the most trivial size, there's no way to
      have all the participants together in a single work room. Many of us
      have seen agile teams start to break down above the level of about 12
      to 15 people. There is more than a rule-of-thumb basis to the adage
      about "seven plus or minus two," after all. To handle larger projects,
      and therefore to cross the chasm for good, I think we have to approach
      the IT portfolio in a different way.

      Let's consider the context of a corporate IT department that serves a
      business community within the same corporation. Currently, it's quite
      common for each major business initiative to be translated into a
      large IT initiative on a one-for-one basis. Then, the PMO or the CIO
      or whoever has the responsibility for managing the overall program
      launches these huge projects that have multiple, overlapping
      objectives and need all sorts of disparate resources. No one involved
      in these large projects has a clear idea of the big picture, and
      people try to provide big picture information through documentation;
      the documentation often has omissions, internal contradictions, out of
      date information, and is hard to navigate to find what you're looking
      for. Whether they try to use agile methods or not, it's no wonder so
      many IT projects run over time and over budget and why so many are
      simply cancelled after wasting a certain amount of time and money.

      People have been tackling the problem mainly from one direction: How
      do we make the agile team model bigger without breaking it? What if we
      tackle the problem from another direction as well (not instead of, but
      as well as the first direction): How do we decompose large initiatives
      into a set of small projects that can be run partly in parallel and
      partly in series? Then, each of the small projects can use the methods
      that work best for them. That is likely to mean "agile" for the
      projects that develop or modify software. It might mean other things
      for projects that do things other than build software.

      A business advantage to this approach seems to leap out in a painfully
      obvious way: Even the largest initiative could begin to deliver
      business value early through incremental releases.

      One key to this approach is to define the various workstreams so that
      they don't have many dependencies on each other. A second important
      factor is to coordinate the product backlogs so that some sort of
      coherent product emerges at each release point. Ideally, we would want
      a way for lessons learned in one part of the initiative to be
      accessible to people in other parts, to avoid duplicated effort and
      wasted time. I believe these challenges can be met without reverting
      to pre-agile thinking and management techniques, but to do so we may
      have to ask different questions or approach the problem from a
      different angle than we've been doing so far.

      What do you think of that idea, generally?

      After all that verbose introduction, there's a particular point with
      respect to your story: When you have to run multiple teams, each
      individual team needs to have cross-functional membership. The story
      you told split the teams along the lines of traditional role silos.
      *That* created some of the communication overhead and logistical
      difficulties. So, I would say you did not entirely cancel out all the
      variables apart from collocation versus distribution. I think we
      *must* break away from conventional organizational structure and
      assumptions about role specialization if we intend to take agile and
      lean ideas any farther than we have already done.


      --- In extremeprogramming@yahoogroups.com, Jon Eaves <jon@...> wrote:
      > 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
      > 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:
      > >
      > [snip]
      > >
      > > 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
      > cost. Remember we're talking about "what is best", not "what can be
      > 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
      > 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
      > 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
      > over a telephone/video link) - and yet it was still significant
      > in capability.
      > Yes. There are things that can be done that make it better. Good
      is the
      > enemy of great.
      > Cheers,
      > -- jon
      > --
      > 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.