Re: [agile-usability] Re: Remote versus collocated teams.
- 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
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
* 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.
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.
> > 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?
- 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
--- In firstname.lastname@example.org, Ron Jeffries
> 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
> > want hard facts to decide. Many are going to trust the opinionsof other
> > people they may think have seasoned opinions, because theyhaven't got
> > the time or the interest to decide for themselves. However, ifJohn
> > Kern's business, as a case in point, can demonstrate that the usepossible,
> > communications tools to facilitate a remote team discussion is
> > then shouldn't the Agile community be a little less hard onremote
> > teaming?want
> Owen, even Jon said that together would be better. Why would we
> to recommend something that wasn't the best we know?
> Ron Jeffries
> The fact that we know more today, and are more capable today,
> is good news about today, not bad news about yesterday.