Ron Jeffries wrote:
> Vancouver has been done, and is brilliant. As for Europe, we have
> Euro conferences already.
>

Vancouver has been done? I must have missed that one. Which year?

William

Hello, William.  On Wednesday, July 30, 2008, at 9:23:49 PM, you
wrote:

> Ron Jeffries wrote:
>> Vancouver has been done, and is brilliant. As for Europe, we have
>> Euro conferences already.

> Vancouver has been done? I must have missed that one. Which year?

I know I went to a conference in Vancouver. Maybe it was OOPSLA?

Ron Jeffries
www.XProgramming.com
He who will not apply new remedies must expect old evils.  -- Francis Bacon

Chris Wheeler wrote:
> On Wed, Jul 23, 2008 at 9:00 PM, William Pietri <william@...> wrote:
>
>
>> For the team I coach that is actually doing this, the point isn't really
>> to punish. The late person has wasted the time of teammates who were
>> standing around waiting. The fine is just a token to acknowledge the
>> error and to offer compensation. At least for me, the cash is relatively
>> unimportant compared to the hazing that comes with having to pay up.
>>
>>
>
> Is showing up to a meeting on time important? If so, treat it as important.
> Eventually, these games wear thin. A few things you can do:
>
> 1) Don't hold meetings
> 2) Hold meetings but start them exactly on time, regardless of who is
> involved
> 3) #2, and address a persons tardiness separate from the meeting.
>
> If it's not important for a meeting to start on time, then just do nothing.
> When everyone's ready, call the meeting together.
>

Not an unreasonable theory, but perhaps you apply it too widely. The
team who's doing this has been doing it for 18 months, and are very
happy with it. It's not like they don't think the few meetings they have
are important; that's why they have them.

The fines are very rarely needed, but when it happens, they relish it.
It turns an annoyance into an enjoyable chance to poke fun at the
slacker. And they like their opportunities for fun quite a bit.

William



[Non-text portions of this message have been removed]

Hello David,

I think they are referring to: http://www.lero.ie/xp2008

Wednesday, July 30, 2008, 6:54:51 PM, you wrote:


>>>> Vancouver has been done, and is brilliant. As for Europe, we have
>>>> Euro conferences already.


> Are we talking about Agile 2010 or something like XP days 2010?
> Because I would like to know when we had a Agile 200X in Europe?

> -d




--
Best regards,
  Chet                            mailto:lists@...

[Non-text portions of this message have been removed]

On Wed, Jul 30, 2008 at 9:27 PM, Ron Jeffries
<ronjeffries@...>wrote:

> I know I went to a conference in Vancouver. Maybe it was OOPSLA?
>

Mustabin. OOPSLA was in Vancouver in 2004 and  a few years earlier too, I
think.

Chris.


[Non-text portions of this message have been removed]

Any place with chocolate... <grin>

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of William Pietri
> Sent: Monday, July 28, 2008 6:04 PM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Agile 2010: west coast?
>
> I see mention that Agile 2009 will end up in Chicago again. Anybody
> know
> how that decision gets made, and how it can be influenced for Agile
> 2010?
>
> I ask because counting Agile 2009, there will have been 2 in the east,
> 3
> in the midwest, 1 in the south, and 2 in Canada. And depending on how
> you count, 2 in Utah. But there have been none on the west coast.
>
> What would it take to make it happen in San Francisco or Seattle?
>
> Curiously,
>
> William
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-
> unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

At 08:40 PM 7/30/2008, you wrote:
>Any place with chocolate... <grin>

extreme chocolate:
http://www.amazon.com/Dreaming-Chocolate-Christmas-Marcel-Desaulniers/dp/0764599\
003/
(just picked it up from the library).

---
vice-chair http://ocjug.org/

Joseph Little wrote:
> Hypothesis:
> A team is about 2x more productive doing agile collocated than dispersed.
>

That would roughly match my experience and intuitions.

I think it depends a lot on the need for innovation, the extent to which
the domain and technologies are well understood by the entire team, the
pace of the particular market, the individuals involved, the
technologies chosen, and the strength of their existing relationships.

> I have a client who believes they have facts that say a dispersed
> team (in this case, mostly working at home) is "better" than a
> collocated team. "Better" for them has a different meaning that productive.
>
Here you lost me. If to them "better" means something other than
productive, then why are you focusing on productivity?

William

If that's all it takes, let me know where to send the bribes. San
Francisco has some excellent chocolate, from the well-known Ghirardelli
to smaller specialty chocolatiers like Scharffen Berger, Charles
Chocolates, and TCHO. If it will help, I'll even throw in some of our
fine local cheeses.

Seriously, anybody know how the decision gets made? They ever let any of
you Agile Alliance board members in on the secret?

William

Kay A. Pentecost wrote:
> Any place with chocolate... <grin>
>
> Kay Pentecost
>
>
>> -----Original Message-----
>> From: extremeprogramming@yahoogroups.com
>> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of William Pietri
>> Sent: Monday, July 28, 2008 6:04 PM
>> To: extremeprogramming@yahoogroups.com
>> Subject: [XP] Agile 2010: west coast?
>>
>> I see mention that Agile 2009 will end up in Chicago again. Anybody
>> know
>> how that decision gets made, and how it can be influenced for Agile
>> 2010?
>>
>> I ask because counting Agile 2009, there will have been 2 in the east,
>> 3
>> in the midwest, 1 in the south, and 2 in Canada. And depending on how
>> you count, 2 in Utah. But there have been none on the west coast.
>>
>> What would it take to make it happen in San Francisco or Seattle?
>>
>> Curiously,
>>
>> William
>>
>>
>>
>> ------------------------------------
>>
>> To Post a message, send it to:   extremeprogramming@eGroups.com
>>
>> To Unsubscribe, send a blank message to: extremeprogramming-
>> unsubscribe@eGroups.com
>>
>> ad-free courtesy of objectmentor.comYahoo! Groups Links
>>
>>
>>
>>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>
>



[Non-text portions of this message have been removed]

William Pietri wrote:
> Seriously, anybody know how the decision gets made? They ever let any of
> you Agile Alliance board members in on the secret?
>

Somebody was kind enough to spill the beans off list. If anybody in the
San Francisco Bay Area is interested in supporting an attempt to bring
Agile 2010 to the region, let me know off list as well. My guess is that
sponsorships, volunteers, connections and advice would all be things
that would make it more appealing to the conference organizers.


William

On Thu, Jul 31, 2008 at 7:00 AM, William Pietri <william@...> wrote:
> William Pietri wrote:
>> Seriously, anybody know how the decision gets made? They ever let any of
>> you Agile Alliance board members in on the secret?
>>
>
> Somebody was kind enough to spill the beans off list. If anybody in the
> San Francisco Bay Area is interested in supporting an attempt to bring
> Agile 2010 to the region, let me know off list as well. My guess is that
> sponsorships, volunteers, connections and advice would all be things
> that would make it more appealing to the conference organizers.
>
Would you mind sharing it here or pointing out where we could find
that information? Because I am more than interested than having Agile
2010 somewhere outside the USA so I would want to go and lobby myself
:)

Thanks

-d
--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

David H. wrote:
> Would you mind sharing it here or pointing out where we could find
> that information? Because I am more than interested than having Agile
> 2010 somewhere outside the USA so I would want to go and lobby myself
> :)

I was advised to look up the current organizers while at Agile 2008.
Drop me a line off list if you need more info.

However, I should say that I'd be surprised if the Agile 20xx series of
conferences moved out of North America. There's an equivalent European
series that has been going on even longer. I haven't been to the
European ones, but I hear excellent things about them, so I suspect
people wouldn't see a need for Agile 20xx to muscle in on their turf.

For more info on your friendly local Agile conference, I'd start with
this URL that Chet mentioned:

http://www.lero.ie/xp2008

William




[Non-text portions of this message have been removed]

On Thu, Jul 31, 2008 at 7:58 AM, William Pietri <william@...> wrote:
> David H. wrote:
>> Would you mind sharing it here or pointing out where we could find
>> that information? Because I am more than interested than having Agile
>> 2010 somewhere outside the USA so I would want to go and lobby myself
>> :)
>
> I was advised to look up the current organizers while at Agile 2008.
> Drop me a line off list if you need more info.
>
> However, I should say that I'd be surprised if the Agile 20xx series of
> conferences moved out of North America. There's an equivalent European
> series that has been going on even longer. I haven't been to the
> European ones, but I hear excellent things about them, so I suspect
> people wouldn't see a need for Agile 20xx to muscle in on their turf.
>
I see agile 200X as _the_ international conference wich covers every
aspect of "Agile" as such I would want to see it traveling all over
the globe. I am familiar with most european conferences and neither of
them have te quality or scale that agile 200X has now in my eyes. That
is the reason why I said that, thank for the hints.

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

>
> Somebody was kind enough to spill the beans off list. If anybody in the
> San Francisco Bay Area is interested in supporting an attempt to bring
> Agile 2010 to the region, let me know off list as well. My guess is that
> sponsorships, volunteers, connections and advice would all be things
> that would make it more appealing to the conference organizers.


William,

By 2010, I'll have spent a decade traveling to XP/Agile conferences.
Walking, biking or BARTing to Agile2010 sounds about right.

Industrial Logic would be happy to help.  We could even have some
pre-conference meetings at the Scharffen Berger Chocolate Factory which is
just down the block from our office.

best
jk
---

Industrial Logic, Inc.
Joshua Kerievsky
Founder, Extreme Programmer & Coach
http://industriallogic.com
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Learn Code Smells, Refactoring and TDD at
http://industriallogic.com/elearning


[Non-text portions of this message have been removed]

Hello, William.  On Thursday, July 31, 2008, at 2:58:01 AM, you
wrote:

> I was advised to look up the current organizers while at Agile 2008.
> Drop me a line off list if you need more info.

When I was on the board, the new location was chosen essentially
unilaterally by the existing conference committee. The presentation
to the board amounted to "We have looked at a lot of locations,
including the End of the Universe, the Pits of Hell, and Washington,
D.C. Washington is best."

My recollection is that they had actually bound an agreement with
the venue prior to any report at all but I could be wrong about
that.

I did not find that process to be quite as participative as I might
have expected as a board member but my concerns of that kind
regarding the conference fell largely upon rocky soil and withered
for lack of moisture. Or, too much moisture, but that's another
story.

> However, I should say that I'd be surprised if the Agile 20xx series of
> conferences moved out of North America. There's an equivalent European
> series that has been going on even longer. I haven't been to the
> European ones, but I hear excellent things about them, so I suspect
> people wouldn't see a need for Agile 20xx to muscle in on their turf.

Nor, the last I knew, was there any desire to move the conference
out of North America. We always thought of it as the North American
conference, except when it was one of the two. Now of course it is
again one of two, as there is some kind of upstart conference in
Orlando.

You never know what will happen. Certainly the conference has a life
of its own and in my experience the conference tail wags the
Alliance dog pretty significantly. If a person worked on the
committee for a couple of years, with the intention of getting on
the inside, there is no limit to what might happen.

Ron Jeffries
www.XProgramming.com
Don't confuse more exact with better.  -- Brian Marick

Hi William,

--- In extremeprogramming@yahoogroups.com, William Pietri
<william@...> wrote:
>
> That would roughly match my experience and intuitions.

Thanks.


> I think it depends a lot on the need for innovation, the extent to
>which ...

What is "it"?  Or, why does it depend?  If you mean collocation is
even more valuable in those circumstances, I think I agree.

> > I have a client who believes they have facts that say a dispersed
> > team (in this case, mostly working at home) is "better" than a
> > collocated team. "Better" for them has a different meaning that
productive.
> >
> Here you lost me. If to them "better" means something other than
> productive, then why are you focusing on productivity?

Simple.  I am trying to help them see things they are overlooking
(they are overlooking productivity because they don't know how to
measure it).  And I think that is the first and most important thing
(assuming some other factors are reasonable).  ...Also, as I said a
bit later in that post, even if better were "employee satisfaction", I
think collocation should win.

Thanks, Joe

--- In extremeprogramming@yahoogroups.com, "Kay A. Pentecost"
<kayp@...> wrote:
>
> Any place with chocolate... <grin>
>
> Kay Pentecost


I'm glad to see *someone* around here has her priorities straight.

Dave

Joseph -

I'm in the process right now of getting a team working together in a
team room (people can be in the same building, and still not be
collocated :).

What I am noticing as one of the biggest benefits is reduction in the
communication lag time.  Getting developers to type code is usually not
the constraint.  It is getting the right thing done-done right, which
means you need dev, QA and customer.

Issues that would linger in back-and-forth in emails or scheduled
meetings "later this afternoon or tomorrow", are now immediately
resolved through face-to-face communication.  And there is less
rework.  Not to mention the people in the room who help unexpectedly
because they have some bit of knowledge, or are working on something
tangentially related.

And I have yet to see code that isn't better with more than one person
contributing.

And have you asked the question "why are people getting interrupted
when they are at work"?

- Marty

On Wed, Jul 30, 2008 at 4:29 PM, Joseph Little <jhlittle@...>wrote:

> Hi all,
>
> I am looking for evidence....
>
> Here's my hypothesis, assumptions and basic arguments.  What facts /
> experiences do you have to refute or confirm the hypothesis?
>
> Hypothesis:
> A team is about 2x more productive doing agile collocated than dispersed.
>

I don't know about 2x. What I think is possible is that a team can get good
at either mode of working. For instance, my wife works almost exclusively
from home. Her company is fairly advanced at the art of dispersed
collaboration, and I'm not talking advanced tools - she uses email,
conference calls, phones, no video, etc.standard tools that anyone has
access to. However, her and her co-workers have become masterful at
communicating across the divide, and I wish I could place my finger on it,
but you would have to really observe it to see how it's done.

So, while my experience is mostly with co-located teams, I think it's
entirely possible to become just as productive across a distance.

Chris.


[Non-text portions of this message have been removed]

--- In extremeprogramming@yahoogroups.com, "Chris Wheeler"
<christopher.wheeler@...> wrote:

[snip]
> So, while my experience is mostly with co-located teams, I think it's
> entirely possible to become just as productive across a distance.
>

I find that statement interesting. I can certainly see that it's
possible to become "productive" across a distance, but I have doubts
about the "just as" part.

I wonder if it's an example of a more general issue with changing the
way we work. When people have been successful using whatever methods
they're accustomed to, they tend not to see much value in changing the
way they work. When people are experiencing frustration and "failure,"
they are more open to suggestions.

I've worked on teams that were dispersed. I enjoyed working from home,
and we were successful in delivering what we were charged with
delivering. We didn't "fail." Actually, we felt pretty good about what
we accomplished. I suppose we must have been "productive," whatever
that means, although we didn't measure our productivity as such.

Since then I've had the opportunity to learn about agile methods and
I've experienced a different way of working that is clearly more
effective. So, to me it isn't an academic or theoretical question.
It's literally a matter of choosing methods that are known to be more
effective than others.

That being the case, why would anyone choose the less-effective
approach? Maybe it isn't a complex question. If a person has never
experienced any particular problems with those "other" methods, it
probably wouldn't occur to them to turn everything they do upside-down
just to see if it would work "better." As far as they can tell,
nothing is "wrong" with the way they work.

WRT people working successfully and happily at home on dispersed
teams, I can see personal reasons to work that way that have nothing
to do with "productivity." I can't fault anyone for that. I might make
the same choice myself, depending on what was going on in my life at
the time.

WRT the assertion that a dispersed team may be "just as productive" as
a collocated team, I can see how that could be true if we recognize
that not all teams are equal. There's a range of effectiveness that
may be achieved using one approach or the other, and it wouldn't
surprise me to learn that the ranges overlap somewhat. That is, the
best-performing dispersed teams probably deliver better results than
the worst-performing collocated teams. My guess is that says more
about the particular teams than about the two approaches.

Dave

Hi all,

You may want to check out the following write-up from Scott Ambler a
few years ago:

http://www.agilemodeling.com/essays/communication.htm

Funny thing is even with "proof" people will still do what they want
until there is some reason to change -- and that is not always
logical :).

This kind of thinking leads a lot of people (including me sometimes)
enjoying life on "Fantasy Island."
(http://www.implementingscrum.com/blog/2008/05/27/tattoo-not-toto-wizard-of-oz-s\
till-scrum-shaken-not-stirred/
).

Thank you,

- Mike Vizdos

            Web:      www.implementingscrum.com
                            www.michaelvizdos.com

=========
For a complete list of my upcoming workshops and public appearances
please visit www.michaelvizdos.com/enroll.




On Jul 30, 2008, at 4:29 PM, Joseph Little wrote:

> Hi all,
>
> I am looking for evidence....
>
> Here's my hypothesis, assumptions and basic arguments. What facts /
> experiences do you have to refute or confirm the hypothesis?
>
> Hypothesis:
> A team is about 2x more productive doing agile collocated than
> dispersed.
>
> Dispersed = no two people are in the same location. eg, each person
> is working at home.
>
> Assumptions:
> a. Disruption impediments are handled to the degree that disruption
> is equal in either case.
> b. There is no physical reason why the team cannot collocate (eg, no
> extreme commutes).
> c. There is no significant cost advantage to the firm in dispersion
> (or collocation) other than the productivity effect.
> d. A collocated team can get the advantages of a team room of a
> comfortable size, and also have space nearby for reasonable privacy.
> e. A dispersed team has "the best" dispersed support, except for high
> quality continuous video-conferencing. Video conferencing can be
> done on a shoe-string (web cams) and, on rare occasions, in an ok
> set-up.
> f. No other factor is different (I can't think of any other
> differences, but perhaps I am overlooking something...tell me if you
> think I am).
> g. The two teams are doing essentially the same form of Agile with
> the same "goodness".
> h. The two teams are relatively new to Agile and relatively new as
> teams.
>
> Discussion:
> I have a client who believes they have facts that say a dispersed
> team (in this case, mostly working at home) is "better" than a
> collocated team. "Better" for them has a different meaning that
> productive.
>
> An argument is made that people in large offices get interrupted a
> lot; more than at home. I am assuming that, to the degree that that
> might be true, the SM and the Team reduce that impediment so that the
> disruption is equal. I further assume that the cost of dealing with
> that impediment is small.
>
> Let me add that...disruptions at home an infinitely less visible to
> the team and SM, so that they seldom are addressed ("unless the coder
> tells his wife to go to hell", as someone once put it).
>
> I have an additional hypothesis that collocation is also better in
> all respects (except in a few people's opinion), but let's do that
> one later.
>
> I do think that non-collocated teams can work, and sometimes be very
> productive. Jeff Sutherland has data to support that.
>
> I am just saying that no team should be allowed to give up on
> collocation "just because" (ie, without some powerful reasons), since
> they are cutting off half their productivity.
>
> My personal experiences are that collocation is so obviously better
> for new teams learning Agile, that no data is needed. But I also
> want to have data (if you all have some), to convince others.
> I personally find it extremely difficult to be effective as a coach
> if the team is not collocated.
> Collocation helps a new team do Forming, Storming, Norming (better,
> faster).
> My experience is that non-collocated "teams" never really form as a
> team. Or, if we call it a team, it has nothing like the same
> intensity and spirit.
> Xebia does high-quality high-productivity distributed (2 pod)
> development. BUT only after collocating each team for 10 weeks. I
> note that they do *not* do dispersed development (no two people in
> the same location). See Jeff Sutherland's paper on this.
>
> Evidence:
> The following would be helpful.
> a. studies, papers on studies, books on studies, etc
> b. references to web sites
> c. your personal experiences
> d. references to experts
> e. references to previous threads here or in other lists
> f. other??
>
> Thanks!
> Joe
>
> Joseph Little
> Agile coach, MBA, CST
> Kitty Hawk Consulting, Inc.
> 704-376-8881 (Charlotte)
> 917-887-1669 (cell)
> http://www.kittyhawkconsulting.com/
> http://leanagiletraining.com/
> Blog: "Agile & Business" (Google that)
>
> [Non-text portions of this message have been removed]
>
>
>



[Non-text portions of this message have been removed]

Hi Joseph,

I don't think that's necessarily true. My company falls somewhere
between "dispersed" and "distributed", and if anything, we are *more*
productive than many collocated agile teams.

But that's not because we're distributed -- it's for other reasons. In
fact, I think that "distributed agile development" is usually a
contradiction in terms. Distributed development poses an enormous
range of problems for agile in particular, and I could easily believe
that a collocated team's productivity would drop by half if they
suddenly switched to a distributed environment. But that doesn't mean
highly productive distributed development is impossible, just that
it's damn hard to do.

Dispersed teams have a number of advantages:

* The organization is completely flat. You can reach one person as
easily as any other. All distributed teams I've seen come to heavily
rely on instant messaging. IM can transcend barriers that are common
even to agile teams (a team room helps but not everyone is in the team
room). Note that IM just doesn't work as well in a collocated setting
because people are often not at their desks, but in meetings or off
helping others.

* Interruptions are controlled. Interruptions in a distributed team
usually come in the form of e-mail or instant messaging. You don't
have to break flow to respond to them. Depending on their priority,
you can finish what you're doing and address the interruption at a
convenient time. This reduces the total number of context switches and
therefore improves productivity.

* The quality of life is higher for employees. This is not always
true, of course, but most people don't live anywhere close to where
they work. This means 30 minutes to an hour of driving time, each way.
In most cities, it's nasty, unpleasant, stuck-in-traffic driving time
that drains people of energy. The cost of working far away from home
is compounded for developers who have families (things just come up
and you have to deal with them).

* The cost is lower. You don't have to lease office space (or can
lease less space, if you're not completely dispersed). This is a small
cost for small teams but can easily be tens of thousands of dollars a
month for larger companies. That money can go toward lowering costs
for customers or toward better benefits for employees (or some
combination thereof). Maybe even profit if you don't have much
competition.

* It's easier to be... agile. In the sense that you can add developers
quickly, or seamlessly move developers to work on different projects,
without all the usual physical costs involved.

* It's possible to produce software faster at a given level of
efficiency. The normal approach to producing software faster is to add
more developers. This scales, somewhere less than linearly and
somewhere more than logarithmically. But it approaches logarithmic
scaling with increasing number of developers. This is a hard limit.
However, a dispersed team can get around this limit if they're located
in time zones that permit continuous, round-the-clock development. In
the best case, a dispersed team can achieve the same level of
efficiency with N developers that a collocated team can achieve with N/
3 developers, whilst producing software 3 times as fast.

* There is less repetition. Because text is used more as a medium of
communication than voice, most "conversations" are logged and you can
simply forward them on to others. In a collocated environment, you
often need to repeat conversations or explain the same thing to many
different people.

* It encourages companies to focus on intrinsic motivation, real-time
collaboration, and transparency, all of which are valuable to agile
software development.

Now you have to balance all these benefits with the extremely serious
handicap common to all dispersed teams: low-bandwidth communication.
What other people are doing is not highly visible, like it is in an
agile team room. The problems developers are encountering are hidden
(unless they ask for help). Facial expressions, body language,
gestures, background discussions, and a hundred other things all
communicate valuable information, and for the most part, a dispersed
team loses that information. Trying to communicate a concept through
voice or text is inherently more time consuming and error-prone than
trying to communicate it in person.

These problems have not been solved through tooling, though I expect
they do have solutions. For example, UNA (my company's real-time
collaborative development environment) helps two or more developers
work together on programming, jointly editing the same code. Instant
messaging helps keep people connected at low cost. Video conferencing
helps fatten the communication pipe, but the technology is far from
peaking.[1]

Overall, there's an enormous amount of work to be done before tools
will remove the handicap of dispersed development (and even in the
utopian scenario, I expect that working side-by-side with the rest of
the team will still have some small benefits that cannot be obtained
by any tools). However, the incentive to develop such tools, and
improve the ones we already have, is very strong, because of all the
benefits that dispersed development has.

In my experience, most agile coaches have given up on distributed/
dispersed development. It's just too hard, and too many things can go
wrong. I completely understand that -- coaches are brought in to
improve the development process, so it's not surprising they avoid
high-risk scenarios that are not well studied nor widely practiced in
the agile community. Personally, I take the opposite approach: that
is, I assume that distributed development is an unstoppable force that
will eventually engulf most of software development. Then I try to
find ways to make it work. The problems I encountered doing
distributed development have actually shaped UNA (and will continue to
do so), but as I mentioned before, we're in the early stages and much
work remains to be done.

So, when all is said and done, I basically agree with the advice
you're giving your client. They brought you in to improve things.
Trying to teach "dispersed agile" to this already-dispersed team seems
risky. Get them all together, and let them experience agile as it's
done best -- in a collocated environment. Then they'll have a higher
chance of actually sticking with it when you leave, and a better
foundation for dispersed development should they decide to re-disperse
later on.

The one negative I see is that most people really like working from
home more than working from the office, and they may resent having to
come to the office (especially if they've been dispersed for some
time). As a result, they may be more hostile toward the ideas you're
introducing. But you should have no problem spotting that early on, if
it turns out to be the case -- although dealing with it could be tricky.

[1] I can imagine an interface that lets me see a continuous, real-
time video stream of everyone on the team, tiny and compact. Clicking
on an icon video feed blows it up and opens an audio channel; clicking
on another feed blows that one up and opens another audio channel, for
3-way conferencing, etc. All done in an unobtrusive manner that lets
people work while they're communicating. Probably not possible without
ultra-fast Internet connectivity.

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]


On Jul 30, 2008, at 2:29 PM, Joseph Little wrote:

> Hi all,
>
> I am looking for evidence....
>
> Here's my hypothesis, assumptions and basic arguments. What facts /
> experiences do you have to refute or confirm the hypothesis?
>
> Hypothesis:
> A team is about 2x more productive doing agile collocated than
> dispersed.
>
> Dispersed = no two people are in the same location. eg, each person
> is working at home.
>
> Assumptions:
> a. Disruption impediments are handled to the degree that disruption
> is equal in either case.
> b. There is no physical reason why the team cannot collocate (eg, no
> extreme commutes).
> c. There is no significant cost advantage to the firm in dispersion
> (or collocation) other than the productivity effect.
> d. A collocated team can get the advantages of a team room of a
> comfortable size, and also have space nearby for reasonable privacy.
> e. A dispersed team has "the best" dispersed support, except for high
> quality continuous video-conferencing. Video conferencing can be
> done on a shoe-string (web cams) and, on rare occasions, in an ok
> set-up.
> f. No other factor is different (I can't think of any other
> differences, but perhaps I am overlooking something...tell me if you
> think I am).
> g. The two teams are doing essentially the same form of Agile with
> the same "goodness".
> h. The two teams are relatively new to Agile and relatively new as
> teams.
>
> Discussion:
> I have a client who believes they have facts that say a dispersed
> team (in this case, mostly working at home) is "better" than a
> collocated team. "Better" for them has a different meaning that
> productive.
>
> An argument is made that people in large offices get interrupted a
> lot; more than at home. I am assuming that, to the degree that that
> might be true, the SM and the Team reduce that impediment so that the
> disruption is equal. I further assume that the cost of dealing with
> that impediment is small.
>
> Let me add that...disruptions at home an infinitely less visible to
> the team and SM, so that they seldom are addressed ("unless the coder
> tells his wife to go to hell", as someone once put it).
>
> I have an additional hypothesis that collocation is also better in
> all respects (except in a few people's opinion), but let's do that
> one later.
>
> I do think that non-collocated teams can work, and sometimes be very
> productive. Jeff Sutherland has data to support that.
>
> I am just saying that no team should be allowed to give up on
> collocation "just because" (ie, without some powerful reasons), since
> they are cutting off half their productivity.
>
> My personal experiences are that collocation is so obviously better
> for new teams learning Agile, that no data is needed. But I also
> want to have data (if you all have some), to convince others.
> I personally find it extremely difficult to be effective as a coach
> if the team is not collocated.
> Collocation helps a new team do Forming, Storming, Norming (better,
> faster).
> My experience is that non-collocated "teams" never really form as a
> team. Or, if we call it a team, it has nothing like the same
> intensity and spirit.
> Xebia does high-quality high-productivity distributed (2 pod)
> development. BUT only after collocating each team for 10 weeks. I
> note that they do *not* do dispersed development (no two people in
> the same location). See Jeff Sutherland's paper on this.
>
> Evidence:
> The following would be helpful.
> a. studies, papers on studies, books on studies, etc
> b. references to web sites
> c. your personal experiences
> d. references to experts
> e. references to previous threads here or in other lists
> f. other??
>
> Thanks!
> Joe
>
> Joseph Little
> Agile coach, MBA, CST
> Kitty Hawk Consulting, Inc.
> 704-376-8881 (Charlotte)
> 917-887-1669 (cell)
> http://www.kittyhawkconsulting.com/
> http://leanagiletraining.com/
> Blog: "Agile & Business" (Google that)
>
> [Non-text portions of this message have been removed]
>
>
>



[Non-text portions of this message have been removed]

On Thu, Jul 31, 2008 at 1:21 PM, davenicolette <dnicolet@...> wrote:

> --- In extremeprogramming@yahoogroups.com, "Chris Wheeler"
> <christopher.wheeler@...> wrote:
>
> [snip]
> > So, while my experience is mostly with co-located teams, I think it's
> > entirely possible to become just as productive across a distance.
> >
>
> I find that statement interesting. I can certainly see that it's
> possible to become "productive" across a distance, but I have doubts
> about the "just as" part.
>
>
>
> WRT people working successfully and happily at home on dispersed
> teams, ...
>
> WRT the assertion that a dispersed team may be "just as productive" as
> a collocated team, I can see how that could be true if we recognize
> that not all teams are equal.



I wish I had more time to respond - I'm leaving for five days, and so won't
have any opportunity except for now to enter into this discussion - too bad,
as it's interesting.

I will point out a couple of things - please excuse any tone of
confrontation that may result: I am under duress from my wife to pack our
stuff into the van at the moment so a polished response isn't possible.

First, I've never liked the argument that 'teams aren't equal' because it
seems to dismiss the outlier experience of one of the teams.

That said, I've seen my wife work with her colleagues - they are productive
- as productive - as others who are co-located. And it's not because they
are special: people come and go. I think it's because they've learned to be
productive and to change their ways of communicating. I'm not practiced in
this mode, so I can't comment on how it's done. What I do know is that I've
witnessed it, I've seen real people do it, and I do claim they are a
productive team.

Once again, sorry for the less-than-polished tone as I'm in rush, so take no
offence, I beg. Perhaps the discussion will contunue when I'm back
Chris.


[Non-text portions of this message have been removed]

On Thu, Jul 31, 2008 at 7:34 PM, John A. De Goes <john@...> wrote:
>
> Hi Joseph,
>
Hello.

> I don't think that's necessarily true. My company falls somewhere
> between "dispersed" and "distributed", and if anything, we are *more*
> productive than many collocated agile teams.
>
That is a bold statement to make. Are you planning on publishing a
paper on that?

<snip>

> Dispersed teams have a number of advantages:
>
> * The organization is completely flat. You can reach one person as
> easily as any other. All distributed teams I've seen come to heavily
> rely on instant messaging. IM can transcend barriers that are common
> even to agile teams (a team room helps but not everyone is in the team
> room). Note that IM just doesn't work as well in a collocated setting
> because people are often not at their desks, but in meetings or off
> helping others.
>
What happens when somone does not log in? When the communication
breaks down? When a message is lost?

> * Interruptions are controlled. Interruptions in a distributed team
> usually come in the form of e-mail or instant messaging. You don't
> have to break flow to respond to them. Depending on their priority,
> you can finish what you're doing and address the interruption at a
> convenient time. This reduces the total number of context switches and
> therefore improves productivity.
>
That assumes that communication neccesitates a complete switch of
context. This is not necessarily true. There are recent studies, which
suggest that, as long as you are associative to the topic you are
working on at the omoent, communication which pertains to that topic
neither necessitates interrupting what you do nor switching context.
So I feel this statement is not necessarily true. Not to mention that
the problem you are introducing here, is that there is no way for you
to tell whether a certain piece of information is important before you
have acknowledged that piece of information. That is exactly the
reason why email is so inefficient as a form of communication.

> * The quality of life is higher for employees. This is not always
> true, of course, but most people don't live anywhere close to where
> they work. This means 30 minutes to an hour of driving time, each way.
> In most cities, it's nasty, unpleasant, stuck-in-traffic driving time
> that drains people of energy. The cost of working far away from home
> is compounded for developers who have families (things just come up
> and you have to deal with them).
>
As you said that is not true. I actually enjoy hanging out and seeing
the people I create something with. Not to mention that I enjoy going
out with them. That is an important social component and in the long
run it helps reduce cost, reduce the amount of sick days, build a
feeling of belonging, etc etc.

> * The cost is lower. You don't have to lease office space (or can
> lease less space, if you're not completely dispersed). This is a small
> cost for small teams but can easily be tens of thousands of dollars a
> month for larger companies. That money can go toward lowering costs
> for customers or toward better benefits for employees (or some
> combination thereof). Maybe even profit if you don't have much
> competition.
>
To me that is false ecomony. "Well if we had been in the same office I
could have overheard what A was telling B, and we would not stuck with
tis 5 million loss now, because we made a really stupid decision".
Those are rather common scenarios and again there are multitudes of
studies out there where a communication break down, be it direct via
phone, email, in documents clearly is documented to have cost a vast
amount of money, something which could have been avoided trhough face
to face commuication or passive communication.

> * It's easier to be... agile. In the sense that you can add developers
> quickly, or seamlessly move developers to work on different projects,
> without all the usual physical costs involved.
>
So you are interested in building a working group quickly? Because
what you are describing there will not build you a team.

> * It's possible to produce software faster at a given level of
> efficiency. The normal approach to producing software faster is to add
> more developers. This scales, somewhere less than linearly and
> somewhere more than logarithmically. But it approaches logarithmic
> scaling with increasing number of developers. This is a hard limit.
> However, a dispersed team can get around this limit if they're located
> in time zones that permit continuous, round-the-clock development. In
> the best case, a dispersed team can achieve the same level of
> efficiency with N developers that a collocated team can achieve with N/
> 3 developers, whilst producing software 3 times as fast.
>
Once more you are describing a working group and something like a
production line, but not an agile team.

> * There is less repetition. Because text is used more as a medium of
> communication than voice, most "conversations" are logged and you can
> simply forward them on to others. In a collocated environment, you
> often need to repeat conversations or explain the same thing to many
> different people.
>
Could you elaborate how you come to that conclusion? I am asking
because ti goes against all common wisdom in Communication Science.

> * It encourages companies to focus on intrinsic motivation, real-time
> collaboration, and transparency, all of which are valuable to agile
> software development.
>
how does it encourage a company to focus on intrinsic motivation?

> Overall, there's an enormous amount of work to be done before tools
> will remove the handicap of dispersed development (and even in the
> utopian scenario, I expect that working side-by-side with the rest of
> the team will still have some small benefits that cannot be obtained
> by any tools). However, the incentive to develop such tools, and
> improve the ones we already have, is very strong, because of all the
> benefits that dispersed development has.
>
Unless you are going to invent hologrpahic communication which also
allows you to transfer the pheromones and electromagnetic waves we
exhibit when communicating, the immediate loss of face-to-face will
always be present.

\> In my experience, most agile coaches have given up on distributed/
> dispersed development. It's just too hard, and too many things can go
> wrong. I completely understand that -- coaches are brought in to
> improve the development process, so it's not surprising they avoid
> high-risk scenarios that are not well studied nor widely practiced in
> the agile community.

I think that some of us coaches and I will happily add myself to that
list are simply realising that certain approaches, albeit noble, are
just too expensive compared to what tey return.

I appreciate your efforts, you and your collegues run an incredible
clever company, I quite enjoyed your puzzles when they were out, but
with all due respect, some of this sounds more like a sales pitch,
than anything else.

-d



--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

> I appreciate your efforts, you and your collegues run an incredible
> clever company, I quite enjoyed your puzzles when they were out, but
> with all due respect, some of this sounds more like a sales pitch,
> than anything else.

And, in all honesty, your response sounds a lot like what waterfall
people tell me when I talk about agile.

When someone tells someone else, "these are the obstacles in your
way", I tend to listen. When someone tells someone else, "it can't be
done" then I believe that person is going to have a huge advantage
over their competitors.

I see a team succeeding in the path of a technology that's only going
to get better for them. In my book, that's something worth learning from.

Chris,

I don't detect any animosity in the tone of your post. Don't worry
about it. (OTOH, I'm not very touchy-feely and I don't always notice
such things.)


--- In extremeprogramming@yahoogroups.com, "Chris Wheeler"
<christopher.wheeler@...> wrote:
>
[snip]
>
> First, I've never liked the argument that 'teams aren't equal'
because it
> seems to dismiss the outlier experience of one of the teams.

I'm not sure what you mean. I thought it was proper to drop "outliers"
when trying to analyze statistical data in search of a general result.


> That said, I've seen my wife work with her colleagues - they are
productive
> - as productive - as others who are co-located.

I believe you when you say your wife and her colleagues are
productive. What's unclear is when you could possibly have had the
opportunity to observe a collocated team doing approximately the same
sort of work at the same level of detail that you've been able to
observe your wife's work. I don't dispute the assertion they're
"productive." I'm just wondering about the "as" part. On what basis
can you quantify it? I'm not asking rhetorically on the assumption you
can't quantify it; I'm just asking how you made the comparison.


> And it's not because they
> are special: people come and go. I think it's because they've
learned to be
> productive and to change their ways of communicating. I'm not
practiced in
> this mode, so I can't comment on how it's done. What I do know is
that I've
> witnessed it, I've seen real people do it, and I do claim they are a
> productive team.

Sure, I'm with you. I've worked as a member of a dispersed team on
occasion, too. We were productive. It was a rewarding mode of work,
too. In my experience, projects on collocated teams have been more
effective in delivering customer-defined value than those other teams.

Maybe your wife's team has discovered something about dispersed work
that the rest of us ought to learn.

Cheers,
Dave

Hello, Chris.  On Thursday, July 31, 2008, at 12:10:38 PM, you
wrote:

> However, her and her co-workers have become masterful at
> communicating across the divide, and I wish I could place my finger on it,
> but you would have to really observe it to see how it's done.

> So, while my experience is mostly with co-located teams, I think it's
> entirely possible to become just as productive across a distance.

You really think they wouldn't be substantially better together?

Ron Jeffries
www.XProgramming.com
A man hears what he wants to hear, and disregards the rest. -- Paul Simon

My manager forces me to write data-driven tests. Although, that allows me to
vary test data it, the test code doesn't speaks its intention. I'm writing
those tests in Microsoft's unit test framework and using Excel sheets as
data. Can any of you find a better way to have both.

Regards,
Amol


[Non-text portions of this message have been removed]

At 03:12 PM 7/31/2008, you wrote:
>My manager forces me to write data-driven tests. Although, that allows me to
>vary test data it, the test code doesn't speaks its intention. I'm writing
>those tests in Microsoft's unit test framework and using Excel sheets as
>data. Can any of you find a better way to have both.

you may find some ideas here:
http://xunitpatterns.com/Parameterized%20Test.html or
http://ddtunit.sourceforge.net/

thanks

---
vice-chair http://ocjug.org/

Joseph Little wrote:
>
>
>> I think it depends a lot on the need for innovation, the extent to
>> which ...
>>
>
> What is "it"?  Or, why does it depend?  If you mean collocation is
> even more valuable in those circumstances, I think I agree.
>

Sorry; I meant the productivity boost from collocation would vary
significantly based on those factors. In certain circumstances, I could
imagine it would be minimal; for some circumstances, radically higher
than 2x.


>> Here you lost me. If to them "better" means something other than
>> productive, then why are you focusing on productivity?
>>
>
> Simple.  I am trying to help them see things they are overlooking
> (they are overlooking productivity because they don't know how to
> measure it).  And I think that is the first and most important thing
> (assuming some other factors are reasonable).  ...Also, as I said a
> bit later in that post, even if better were "employee satisfaction", I
> think collocation should win.
>

That seems reasonable.

I have the most luck getting people to adopt a suggested path when it
solves some problem they already think they have, and in a way in line
with their values. If they aren't thinking much about productivity, then
it can be worth raising. But if they still don't care much about it,
then I've never found words to change that.

It was a shock to me when I first realized it, but there are some teams
that really don't care about productivity, or if they do, it's pretty
far down on their list of values. For those teams, Agile methods may not
be a good match.

William


[Non-text portions of this message have been removed]