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

Re: [agile-usability] Re: Remote versus collocated teams.

Expand Messages
  • Jon Kern
    two things... * Yup. Although I d say some of those factors (e.g. closer customer collaboration, common code ownership, etc.) will pay off more for co- located
    Message 1 of 146 , Jun 3, 2007
    • 0 Attachment
      two things...

      * Yup. Although I'd say some of those factors (e.g. closer customer
      collaboration, common code ownership, etc.) will pay off more for co-
      located teams than they will for distributed ones.

      Why do you think this is so (esp. code ownership vis-a-vis -- no pun
      intended -- collocation or not)? Of course, much lies in the assumptions
      one places on the types of conversations and frequency of face-to-face
      meetings. When needed, I and others meet with the business folks.

      * Just hypothetically - if you all lived in the same area do you think
      you'd co-locate? Do you think you would work better if you all did?

      We might meet more often. Like at the beginning of each iteration and as
      often as was necessary for design discussions. Right now iteration
      planning mtgs are about 2-3 hours of phone/IRC/netmeeting/jira on the
      browser for closing out an iteration and planning the next. Sometimes
      (most times?), design discussions are more effective sketching on a
      whiteboard in person.

      but, do we need to be heads down right next to each other 24x7? No. That
      could likely be less effective due to chitchat and more frequent
      interrupts. (Don't overlook the cost of interruptions to knowledge
      workers. Very expensive to have people collocated and with poor habits
      or lack of concentration skills -- if not mitigated.)

      (Ineffectiveness can be especially prevalent in cultures where meetings
      are de rigeur. Don't get me started on that sort of "benefit" to being
      collocated in an ineffective/dysfunctional corporate culture -- having
      development team members go to mindless meetings.)

      How we cope:

      1. We use IRC to get the virtual collocation to have everyone in the
      same room.
      2. The confluence wiki is the whiteboard and cubicle walls upon which
      we hang stuff and scribble
      * kills less trees
      * and E-size plotters led to lousy systems <g>
      3. Jira is the project/team/personal to do list.

      And, when it makes sense:

      1. we fly/drive people to be together
      2. we use the telephone!
      3. I tend to meet people more often -- especially the business --
      than the whole team. however, the business is always represented
      in our daily meetings on phone.

      one of my rigors is to do *just* enough up front work to:

      * Know basically what we are building (swag at overall scope for
      release)
      * Have a technical architecture/code skeleton of a working thin slice

      This sets us up for success. Refinements emerge over time, but the
      overall picture and architecture is put into place early on.

      jon
      blog: http://technicaldebt.com



      Adrian Howard said the following on 6/3/07 3:56 PM:
      >
      >
      > On 3 Jun 2007, at 14:37, Jon Kern wrote:
      >
      > > re: /"that co-located groups are more effective."/
      > >
      > > admittedly, if i took the same group of top-notch distributed people
      > > that i use on a project and collocated them, we might be more
      > > effective.
      > > but being effective is a very personal thing... a happy developer at
      > > home with the dog and kids might be more effective than one who fought
      > > thru 1 hour of traffic to get to work each day. others would prefer an
      > > office versus the distractions of being at home.
      >
      > Very true. There are certainly circumstances when the productivity of
      > an individual is going to be better better/worse. It's an interesting
      > question on how that individual affects the team as a whole.
      >
      > > but collocation in and of itself means little.
      > >
      > > after all, if collocation was *the* answer, why has software
      > > development
      > > been in such an abysmal state of low rates of success during the days
      > > when collocation was most prevalent?
      >
      > I don't think anybody is trying to paint co-location as a cure for
      > all ills.
      >
      > > So, holding all other variables constant and changing only the
      > > collocation variable... you are more likely to get improved
      > > effectiveness. at least for part of the time the team is together.
      >
      > Yup.
      >
      > > i also submit that there are much, much, much bigger factors for
      > > success
      > > and failure than the collocation aspect.
      >
      > Yup. Although I'd say some of those factors (e.g. closer customer
      > collaboration, common code ownership, etc.) will pay off more for co-
      > located teams than they will for distributed ones.
      >
      > > however, i would pit my distributed, ad hoc teams of kick-ass
      > > developers
      > > and architects and style of tackling projects in an agile way against
      > > any collocated team. we are pretty darn effective at yielding dramatic
      > > savings versus "standard cubicle dwelling" internal development teams.
      > > And we leave behind the teams with lots of learning and mentorship
      > > as well!
      > >
      > > btw: we do "collocate" at strategic times on the project.
      > > Especially in
      > > the beginning stages. It is simply much more effective. And I
      > > frequently
      > > travel to the client sites and serve as a bit of glue and bridging for
      > > the team. But being physically collocated every minute of every day is
      > > not required.
      >
      > Glad it works for you!
      >
      > Just hypothetically - if you all lived in the same area do you think
      > you'd co-locate? Do you think you would work better if you all did?
      >
      > Cheers,
      >
      > Adrian
      >
      >
    • kswaters1
      Here here Ron! Remote teamwork may be possible but it certainly isn t ideal. Close collaboration without co-location is a compromise, sometimes an essential
      Message 146 of 146 , Jul 11, 2007
      • 0 Attachment
        Here here Ron! Remote teamwork may be possible but it certainly
        isn't ideal. Close collaboration without co-location is a
        compromise, sometimes an essential one, but not one you'd advocate
        as part of any methodology.

        I sometimes like to think of this in terms of new business
        startups. How many people would start a business and think, "I
        know, let's base our development teams in multiple locations and
        have the business owners of the product we're building in a
        different place to the developers." For logistical reasons, sales
        and other field-based teams maybe, for product development I think
        not.

        Kelly Waters
        http://www.allaboutagile.com


        --- In agile-usability@yahoogroups.com, Ron Jeffries
        <ronjeffries@...> wrote:
        >
        > Hello, Owen. On Sunday, June 3, 2007, at 11:01:30 PM, you wrote:
        >
        > > I realise that many people aren't in my position such that they
        would
        > > want hard facts to decide. Many are going to trust the opinions
        of other
        > > people they may think have seasoned opinions, because they
        haven't got
        > > the time or the interest to decide for themselves. However, if
        John
        > > Kern's business, as a case in point, can demonstrate that the use
        > > communications tools to facilitate a remote team discussion is
        possible,
        > > then shouldn't the Agile community be a little less hard on
        remote
        > > teaming?
        >
        > Owen, even Jon said that together would be better. Why would we
        want
        > to recommend something that wasn't the best we know?
        >
        > Ron Jeffries
        > www.XProgramming.com
        > The fact that we know more today, and are more capable today,
        > is good news about today, not bad news about yesterday.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.