> --- Tim Ottinger <linux_tim@> wrote:
>> I'm trying to get a handle on how communication happens when
>> project progress and features are "sensitive" and are required
>> to be locked away.

--- "madbad" <madbadrabbit@...> wrote:
> Mostly via IM, email, wiki, and spreadsheet, since the office
> layout is such a big (deliberate?) communication barrier.

If only their communication barriers were clearly successful -- then they
wouldn't have to worry about too much communication going on!

On Wed, Nov 11, 2009 at 11:25 AM, Dave Rooney <dave.rooney@...> wrote:
> You can also lay all the cards for a system out on a table/floor/wall
> and move them about easily. This provides (yet) another visual cue for
> the size of the system, and what work is most important. The fact that
> they can be easily moved about means that the people involved become
> comfortable making changes rather than creating plans that become
> ossified over time.
>

This reminds me of a story.

A colleague of mine was working with a company and having difficulty
explaing that the scope of the requirements was much larger than the
product and project managers were expecting. He tried lots of ways to
try to get everyone on the same page as far as scope. Nothing worked
until he wrote a story for every feature on an index card and pinned
them to the wall. He brought the entire team into the room and said
"That's the scope." From that point on he never got anymore grief from
management about why the project was taking longer than expected.
Until they saw the scope laid out in physical form, they really
couldn't grasp how much they were asking for.
--
Curtis Cooley
curtis.cooley@...
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf

scott preece wrote:
> --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...>
wrote:
>
>> Hello, scott.  On Tuesday, November 10, 2009, at 12:15:59 PM, you
>> wrote:
>>
>>
>>> There are multiple impediments to communication. Sitting in the
>>> same room staring at the card in front of you is no more
>>> communicative than staring at the laptop screen in front of you -
>>> it's the transmission of the idea (as represented by the card)
>>> that is useful.
>>>
>> No ... it's the discussion ...
>>
>
> How does the card engender discussion any more than the same content projected
on a screen?
>

Because the card is so small, that the people aren't really looking at
it.  They are facing each other having a discussion, rather than facing
a screen reading.

You can also lay all the cards for a system out on a table/floor/wall
and move them about easily.  This provides (yet) another visual cue for
the size of the system, and what work is most important.  The fact that
they can be easily moved about means that the people involved become
comfortable making changes rather than creating plans that become
ossified over time.

--

Dave Rooney
Co-founder and Consultant, The Agile Consortium
"Maximizing the value of your IT investments!"
E-mail: dave@...
Twitter: daverooneyca
http://www.theagileconsortium.com
http://practicalagility.blogspot.com

Hi Scott,

> > I taught a class on OO design. Most of the time I did lecture type
> > teaching, where I drew UML on the board and solicited input
> from the
> > students. When I got to CRC cards, I noticed that when I had the
> > students do a small group exercise, more students were actively
> > involved than when I lectured. Holding the CRC cards sparked more
> > interest and input. At that point I learned that when I wanted more
> > class involvement, doing a CRC exercise was much more
> effective than
> > lecturing at the white board or showing code/UML on the projector.
> >
>
> Isn't it likely that it was doing the exercise (having to DO
> something, as opposed to having you describe it) that was
> what focused the class, rather than the specific medium?

Ah! You're thinking of cards as a medium of information transmittal!

Looked at in that way, there are other media I would prefer. For
example, I learned in school to use index cards to take notes
for a term paper. I still do that some of the time when I am
preparing a talk but will often use electronic tools that are
better for the purpose.

However, in XP cards are not merely used as media for the display
and transmittal of information. They are tokens in a set of
cooperative games we play as part of making a project work.

Taking the example of CRC cards, several people can actually
*do* (not explain) design by moving the cards around a table
and making various notations on them. Somehow, these actions
pull out ideas in a way that I have not seen using other sorts
of tools - although you can approximate it with salt-shakers
and such if you don't have any cards handy.

When you need interactivity, physical devices help. Online
games may possibly come close to the same effect some day,
at least for some people. But they aren't there yet.

Charlie

Tim,

From experience coaching semi-distributed or fully distributed teams. I
believe that developer-to-developer communication can be adequately
supported this way.  I suspect this is because the interaction in pairing is
one-on-one and focussed on a task (and that promiscuous on-task pairing
eventually covers most of the bases in developer-developer communication)

However, developer-customer communication suffers quite a bit from
non-collocated communication.  I suspect this is because the interactions
are less tightly focussed, the expected results are less well defined and
there is less shared mindset than between two developers.

I am guessing that your trips maximize overlap with iteration and release
planning sessions.  If not, they really should.

On Wed, Nov 11, 2009 at 11:49 AM, Tim Ottinger <linux_tim@...> wrote:

>
>
> I'm currently a dislocated programmer (grin), and I find that it is
> possible to pair effectively as long as you are not too far apart in time
> zones. Latitude hurts, but longitude kills.
>
> I like using webex or yuuguu for screen sharing, skype or plain telephone
> for voice. I attend meetings via skype and a "sherpa" (coworker who carries
> in a laptop for me).
>
> It is not quite like being there, so I supplement it with a week-long trip
> every other month (or every third, depending on scheduling issues).
>
> I like being with my coworkers, but this is a way for me to live where I
> need to live and work where I like to work, and nobody is complaining. I am
> one of three noncolocated workers on the team. Two of us are constantly
> telepresent during common hours, one is more isolated.
>
> It isn't the same, but it doesn't totally suck. We're kinda face to face,
> but not really face to face. We learn to make it work okay.
>
>
> Tim Ottinger
> http://agileinaflash.blogspot.com/
> http://agileotter.blogspot.com/
>
>


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

----- Original Message ----
> From: Ron Jeffries <ronjeffries@...>

> Have you ever spent an extended period away from your loved ones?
>

Yes.

Strangely enough, that is the thing I avoid by remote-pairing.



  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

I'm currently a dislocated programmer (grin), and I find that it is possible to
pair effectively as long as you are not too far apart in time zones.  Latitude
hurts, but longitude kills.

I like using webex or yuuguu for screen sharing, skype or plain telephone for
voice.  I attend meetings via skype and a "sherpa" (coworker who carries in a
laptop for me).

It is not quite like being there, so I supplement it with a week-long trip every
other month (or every third, depending on scheduling issues).

I like being with my coworkers, but this is a way for me to live where I need to
live and work where I like to work, and nobody is complaining.  I am one of
three noncolocated workers on the team.  Two of us are constantly telepresent
during common hours, one is more isolated.

It isn't the same, but it doesn't totally suck.  We're kinda face to face, but
not really face to face.  We learn to make it work okay.


  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/



----- Original Message ----
> From: William Pietri <william@...>
> To: extremeprogramming@yahoogroups.com
> Sent: Tue, November 10, 2009 8:53:22 AM
> Subject: Re: [XP] Distributed Teams (was "Cards" (was: summary of the 
discusion
>
> Ron Jeffries wrote:
> > Hello, Sean.  On Sunday, November 8, 2009, at 4:21:38 PM, you
> > wrote:
> >
> >
> >> So, having criticized distributed teams, do you have any advice that
> >> would address my questions? :)
> >>
> >
> > There is no mitigation that comes close. Teams use Skype, webcams on
> > their desks, big tv conference rooms, desktop sharing software.
> > There is no mitigation that comes close.
> >
>
> I could imagine one small exception to this. I have seen a couple small
> teams who have been collocated for extended periods (6 mos - 5 years)
> work effectively with some later dispersement, and they reported no
> giant productivity dip.
>
> Of course, because they really didn't want to break up the team, they
> were inclined to believe that anyhow. :-) And there are reasons I would
> happily believe these folks are the exception rather than the rule. But
> I could also believe that stable, well-established teams would tolerate
> separation, on the theory that it's during formation and integration of
> new members that collocation provides a lot of its magic.
>
> William
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> 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
>
>
>

Hi, Curtis,

--- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@...>
wrote:
>
> On Tue, Nov 10, 2009 at 9:15 AM, scott preece <sepreece@...> wrote:
...
> How does staring at a laptop screen spark kinetic learning?
>
It wouldn't, but I wouldn't say there was a kinetic component to what was
involved.

...
> I taught a class on OO design. Most of the time I did lecture type
> teaching, where I drew UML on the board and solicited input from the
> students. When I got to CRC cards, I noticed that when I had the
> students do a small group exercise, more students were actively
> involved than when I lectured. Holding the CRC cards sparked more
> interest and input. At that point I learned that when I wanted more
> class involvement, doing a CRC exercise was much more effective than
> lecturing at the white board or showing code/UML on the projector.
>

Isn't it likely that it was doing the exercise (having to DO something, as
opposed to having you describe it) that was what focused the class, rather than
the specific medium?

> I've also actually been involved in planning sessions of various
> formats. I've used index cards and computer software. My observation
> is that the team is more actively engaged when cards are used. At one
> job the team lead actually started passing the keyboard around to try
> to get more people actively involved where had we been using index
> cards, we simply wouldn't have had that problem and maybe could have
> spent that energy solving one of the customer's.

That's what I was suggesting in terms of having appropriate collaboration tools
- you need tools that accept multiple inputs and display multiple strands of
discourse.

Ideally, you would also enable the participants to have personal views on the
strands (organize the notes individually) and to view and compare how others
organized the same notes, which you can't do with physical cards that can only
be in one place at a time...

Hi, Ron,

--- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, scott.  On Tuesday, November 10, 2009, at 12:15:59 PM, you
> wrote:
>
> > There are multiple impediments to communication. Sitting in the
> > same room staring at the card in front of you is no more
> > communicative than staring at the laptop screen in front of you -
> > it's the transmission of the idea (as represented by the card)
> > that is useful.
>
> No ... it's the discussion ...

How does the card engender discussion any more than the same content projected
on a screen?

>
> > When the communication is meant to be single-threaded (when you're
> > trying as a group to resolve one thing at a time), the projector
> > (or laptop) is a positive force, as it directs attention to that
> > one thing. In other modes, when you're working individually or in
> > small groups, you wouldn't use a single display that way.
>
> No ... groups are never single threaded ...

No, but discussions are.

...
>
> > People think in many ways. Just as some people learn better from
> > visual input and others learn better from audio input, I'm
> > prepared to believe that for some people, "having a physical
> > object in your hands ... opens up communication and activates
> > parts of the brain that are dormant otherwise," it's just not my
> > own experience.
>
> How did you measure what your brain was doing?

How did you?
...

So:
1) They think that a one-liner description of code you'll release next month
would give competitors "the edge".
2) They don't trust you not to be a spy.
3) They have mechanism to level blame and punishment.

One more question: how much fun is it to work there? Are they straining a gnat
and swallowing a camel?

Anyway, a secure location is the first thing you need.

  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/



----- Original Message ----
> From: madbad <madbadrabbit@...>
> To: extremeprogramming@yahoogroups.com
> Sent: Sun, November 8, 2009 10:01:46 PM
> Subject: [XP] Re: Distributed Teams (was "Cards" (was: summary of the
discusion
>
> "JeffGrigg" wrote:
> >
> > > The status (or specifically the status of each story)
> > > is deemed sensitive because it would tell our competitors which
> > > features will likely be in the next release of our product.
> >
> > And who is it who lets your compeditors walk through your office???
>
> I think the rationale is more: if sensitive information is leaked,
> they want to know which small set of employees had access to it,
> so appropriate blame/disciplinary action can be laid.
>
> > If your work is "sensitive," then you need a secure area in which
> > to work.
>
> Hence their mandate that everything be locked up when not in use.
> If we had a teamroom it wouldn't be an issue; but since we don't,
> and can't leave stuff out in the hallways, it forces us to use an
> electronic tool instead of physical cards and taskboards.
>
>
>
>
> ------------------------------------
>
> 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
>
>
>

Could you build a large, shallow cabinet with locking doors?  It could be
10'x4'x6" with doors hinged at left/right.  Could maybe even repurpose a china
cabinet.

It really is shocking to me.  Most agile shops bring investors, C-level
managers, and customers into our work rooms and show off the card walls to them.
The idea of hiding that is totally alien to my agile experience.

I was assuming you were working on a DoD project, where I could see the features
being kept a secret.

  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/



----- Original Message ----
> From: madbad <madbadrabbit@...>
> To: extremeprogramming@yahoogroups.com
> Sent: Sun, November 8, 2009 8:33:56 PM
> Subject: [XP] Re: Distributed Teams (was "Cards" (was: summary of the
discusion
>
> "JeffGrigg" wrote:
> >
> > A lame excuse, as you know.   ;->
> >
> > Get a team room with a locking door.  Then it's not a Public Area.  (The
> company cares enough about management to give them rooms with locking doors,
> doesn't it?)
>
> That's another impediment we face: no team room. Everyone sits
> in separate 10x10 offices. Can't effectively seat more than two
> developers per due to lack of power/LAN outlets.
>
> > Put the materials in a locked closet every night.
>
> Pull the cards off the board every night, then remember where
> they all went and put them back up each morning?
>
>
>
>
> ------------------------------------
>
> 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
>
>
>

Hello agilists,

Here at University of São Paulo - Brazil, we are doing some research about agile
methods and free software. We already have sufficiently awnsers incoming from
the free software community but we still need a lot of awnsers from the agile
community.

If you work or worked with any agile method please awnser our research, it takes
less than 5 minutes and can be found at
http://www.ime.usp.br/~corbucci/agile-survey

Thanks in advance,
Renan de Melo Oliveira

Tim Ottinger <linux_tim@...> wrote:
>
> That's so alien to me. I showed up late to the party, but can
> you recap what industry you serve?

A Fortune-500 software vendor.

> I'm trying to get a handle on how communication happens when
> project progress and features are "sensitive" and are required
> to be locked away.

Mostly via IM, email, wiki, and spreadsheet, since the office
layout is such a big (deliberate?) communication barrier.

That's so alien to me. I showed up late to the party, but can you recap what
industry you serve?

I'm trying to get a handle on how communication happens when project progress
and features are "sensitive" and are required to be locked away.


  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

--- In extremeprogramming@yahoogroups.com, Sean Corfield <seancorfield@...>
wrote:
>
> Can some folks talk about why putting the stories into some shared
> data store rather on physical cards might not be advisable? What sort
> of problems have folks run into using some simple electronic
> representation, such as a spreadsheet or some other simple electronic
> document / set of documents?

We have tried both physical and virtual on several projects with mixed results. 
It seems that a virtual taskboard is sub-optimal and is only really useful when
a team is distributed.  If the team is co-located then a physical taskboard is
the most visible, flexible and highest bandwidth for communication.

There is some discussion on this idea here:
http://agileshout.com/questions/51/agile-process-tools

Hello, scott.  On Tuesday, November 10, 2009, at 12:15:59 PM, you
wrote:

> There are multiple impediments to communication. Sitting in the
> same room staring at the card in front of you is no more
> communicative than staring at the laptop screen in front of you -
> it's the transmission of the idea (as represented by the card)
> that is useful.

No ... it's the discussion ...

> When the communication is meant to be single-threaded (when you're
> trying as a group to resolve one thing at a time), the projector
> (or laptop) is a positive force, as it directs attention to that
> one thing. In other modes, when you're working individually or in
> small groups, you wouldn't use a single display that way.

No ... groups are never single threaded ...

> However, the projector (or laptop) doesn't have to be
> single-threaded, if you use appropriate tools. You can all be
> working individually (or in ad hoc clusters) and reflecting your
> work on a shared surface.

Yes ... not much better than a table for that ...

> People think in many ways. Just as some people learn better from
> visual input and others learn better from audio input, I'm
> prepared to believe that for some people, "having a physical
> object in your hands ... opens up communication and activates
> parts of the brain that are dormant otherwise," it's just not my
> own experience.

How did you measure what your brain was doing?

> I'm sure there's an interesting study in there for a psych grad student.

I'd think so, yes.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Learn the principle, abide by the principle, and dissolve the principle.
   -- Bruce Lee

Hello, William.  On Tuesday, November 10, 2009, at 11:21:10 AM,
you wrote:

>>> I could also believe that stable, well-established teams would tolerate
>>> separation, on the theory that it's during formation and integration of
>>> new members that collocation provides a lot of its magic.
>>>
>> Have you ever spent an extended period away from your loved ones?
>>
> Yes. In various chunks, I've lived overseas 3 years.

And how did you find it, overall?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Fear is the mindkiller. --Bene Gesserit Litany Against Fear

On Tue, Nov 10, 2009 at 9:15 AM, scott preece <sepreece@...> wrote:
> People think in many ways. Just as some people learn better from visual input
and others learn better from audio input, I'm prepared to believe that for some
people, "having a physical object in your hands ... opens up communication and
activates parts of the brain that are dormant otherwise," it's just not my own
experience.
>
> I'm sure there's an interesting study in there for a psych grad student.
>

As a soccer coach I was taught that players have basically three modes
of learning, and each player is better at one than the other. The
modes are visual, aural, and kinetic, so as a coach, whenever you are
introducing something new, you explain it, demonstrate it, then have
the players execute it.

How does staring at a laptop screen spark kinetic learning?

I can not find the research, though I'm sure it's out there, I do find
it hard to believe that physical sensation and motor movement of the
hands activate the same area of the brain that the ears and eyes do.

I taught a class on OO design. Most of the time I did lecture type
teaching, where I drew UML on the board and solicited input from the
students. When I got to CRC cards, I noticed that when I had the
students do a small group exercise, more students were actively
involved than when I lectured. Holding the CRC cards sparked more
interest and input. At that point I learned that when I wanted more
class involvement, doing a CRC exercise was much more effective than
lecturing at the white board or showing code/UML on the projector.

I've also actually been involved in planning sessions of various
formats. I've used index cards and computer software. My observation
is that the team is more actively engaged when cards are used. At one
job the team lead actually started passing the keyboard around to try
to get more people actively involved where had we been using index
cards, we simply wouldn't have had that problem and maybe could have
spent that energy solving one of the customer's.
--
Curtis Cooley
curtis.cooley@...
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf

There are multiple impediments to communication. Sitting in the same room
staring at the card in front of you is no more communicative than staring at the
laptop screen in front of you - it's the transmission of the idea (as
represented by the card) that is useful.

When the communication is meant to be single-threaded (when you're trying as a
group to resolve one thing at a time), the projector (or laptop) is a positive
force, as it directs attention to that one thing. In other modes, when you're
working individually or in small groups, you wouldn't use a single display that
way.

However, the projector (or laptop) doesn't have to be single-threaded, if you
use appropriate tools. You can all be working individually (or in ad hoc
clusters) and reflecting your work on a shared surface.

People think in many ways. Just as some people learn better from visual input
and others learn better from audio input, I'm prepared to believe that for some
people, "having a physical object in your hands ... opens up communication and
activates parts of the brain that are dormant otherwise," it's just not my own
experience.

I'm sure there's an interesting study in there for a psych grad student.

regards,
scott


--- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@...>
wrote:
>
> On Sun, Nov 8, 2009 at 12:38 PM, scott preece <sepreece@...> wrote:
> >
> >
> >
> > Nor is the communication issue necessarily a stopped - all it takes is a
projector to be able to share a single spreadsheet while you work on it (or,
better, an online collaboration tool that would let everybody work on the data
at the same time.
> >
>
> The projector doesn't fix the communication problem, Instead of
> everyone sitting around staring at a laptop screen while one person
> works, everyone is sitting around staring at the wall while one person
> works.
>
> With cards, everyone is engaged, working and talking with each other.
> You can't replicate having a physical object in your hands and how it
> opens up communication and activates parts of the brain that are
> dormant otherwise.
> --
> Curtis Cooley
> curtis.cooley@...
> home:http://curtiscooley.com
> blog:http://ponderingobjectorienteddesign.blogspot.com
> ===============
> Leadership is a potent combination of strategy and character. But if
> you must be without one, be without the strategy.
> -- H. Norman Schwarzkopf
>

I applaud all attempts to take good software development in any and all new
directions, provided that the experimenter is not merely trying to adapt the
name "agile" to their old process. It is far better to "be" than to "seem."

Try whatever you like, don't let barking dogs distract you, and do be
conscientious in your application.  Measure, report, etc.

I have found remote pairing to be very successful, despite the personal belief
that it would not work, and could not be made to work.  It is not perfect, and
is second-best in many ways to being physically present, but has advantages and
trade-offs.

In the same way, try new things (and old things) in your agile adventure.
Remember that the goal is learning, and finding ways to learn better.  Avoid
learning-suppression systems and keep moving.

As regards docs:

Mockups are good.  After all, "it's always a good time to build an
example", but once the example is implemented in code or tests, it is
available to all and the original model is not useful.  I believe in creating
small docs, but only to later obviate and then delete them.

  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

Ron Jeffries wrote:
> Hello, William.  On Tuesday, November 10, 2009, at 9:53:22 AM, you
> wrote:
>
>
>> I could also believe that stable, well-established teams would tolerate
>> separation, on the theory that it's during formation and integration of
>> new members that collocation provides a lot of its magic.
>>
>
> Have you ever spent an extended period away from your loved ones?
>

Yes. In various chunks, I've lived overseas 3 years.

William



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

Clive Evans wrote:
> Well, it helps me, since it's a purely financial argument that I'm
> having. If I can prove that it will cost more money to have an off
> shore team, then I will be able to argue an on shore team. Having
> precise numbers to back me up is dreadfully helpful.
>

My standard line on this is that an off-shore team is a perfectly good
idea if you also send key businesspeople to that location
semi-permanently. The theory here is that one of the major factors in
software quality and economy is the availability of information, and
that by far the most cost-effective way to do that is XP's "put
everybody  in a room" approach.

It turns out that many businesspeople are very excited about cost
savings until it means they would be the ones moving to Bangalore or
Budapest for 6 months. Then, suddenly, in-house teams seem like a much
better idea. To be fair to the besuited, I do know somebody who actually
went to India for a year to be with his new team, so there are some that
really do walk the talk.

Alas, that's not the common experience. A while back I got called in to
look at an operation that had tried to speed things up by doubling their
technical staff, with all the new programmers in a non-overlapping time
zone. Their accountant was already suspicious, because when you included
all the costs, it wasn't as good a deal as they were hoping.

Then I showed them, based on staff interviews and their own stats, the
"doubled" team wasn't adding more than 10 or 20% to their capacity, and
might not be helping at all. Despite that, it still took them a while to
admit that it was all a mistake and unwind it all. I'm sure a lot of
places don't have the starch for that, and just keep up their off-shore
efforts because some executive or board member thinks it must be awesome.


Basically, I'd say a whole team in a cheaper location will indeed be
cheaper, but half here and half there will be more expensive, no matter
how cheap the faraway land.

William

Hello, William.  On Tuesday, November 10, 2009, at 9:53:22 AM, you
wrote:

> I could imagine one small exception to this. I have seen a couple small
> teams who have been collocated for extended periods (6 mos - 5 years)
> work effectively with some later dispersement, and they reported no
> giant productivity dip.

> Of course, because they really didn't want to break up the team, they
> were inclined to believe that anyhow. :-) And there are reasons I would
> happily believe these folks are the exception rather than the rule. But
> I could also believe that stable, well-established teams would tolerate
> separation, on the theory that it's during formation and integration of
> new members that collocation provides a lot of its magic.

Have you ever spent an extended period away from your loved ones?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you're not throwing some gravel once in a while,
you're not using the whole road.

Ron Jeffries wrote:
> Hello, Sean.  On Sunday, November 8, 2009, at 4:21:38 PM, you
> wrote:
>
>
>> So, having criticized distributed teams, do you have any advice that
>> would address my questions? :)
>>
>
> There is no mitigation that comes close. Teams use Skype, webcams on
> their desks, big tv conference rooms, desktop sharing software.
> There is no mitigation that comes close.
>

I could imagine one small exception to this. I have seen a couple small
teams who have been collocated for extended periods (6 mos - 5 years)
work effectively with some later dispersement, and they reported no
giant productivity dip.

Of course, because they really didn't want to break up the team, they
were inclined to believe that anyhow. :-) And there are reasons I would
happily believe these folks are the exception rather than the rule. But
I could also believe that stable, well-established teams would tolerate
separation, on the theory that it's during formation and integration of
new members that collocation provides a lot of its magic.

William


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

Hello, Tim.  On Tuesday, November 10, 2009, at 9:25:35 AM, you
wrote:

> My only worry is when the deployment includes a schema migration.
> I'm not sure how to do continuous deployment in the old RDBMS
> case. Maybe that is the real promise of CouchDB and its ilk. I'm
> betting CD is easier if you have adapted (or, I suppose, planned) the
architecture to support it.

Have you seen Ambler/Sadalage, "Refactoring Databases"?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Everything elegant is simple, not everything simple is elegant and
nothing complex is ever elegant. --John Streiff

Craig Davidson wrote:
> Pete McBreen proposed that great programmers are ten times more effective
> than average programmers.
> Potentially magnitudes (people) against two times (co-located teams)
> effectiveness points to great people.
> * The challenge of course is to get great people *.

I think this stat, which I'm pretty sure comes from studies of solo or
relatively isolated developers, is kinda misleading these days.

A lot of relatively ineffective developers aren't so because of some
sort of permanent flaw. It's because they don't have the right habits or
learnable skills. Even after a lot of years of doing this, I'm still
amazed at the extent to which developers bring their games up when
working in an XP-ish context.

That's not to say that the great ones don't get better still, but it's
the less-great ones who often make the largest proportional gains.

William

----- Original Message ----
> From: George Dinwiddie <lists@...>
> Just thinking... You could have two environments with a load balancer in
> front.  Keep one environment offline with the load balancer, deploy to
> that, and switch which one is live.  If the load balancer was set to
> keep a given session on the same machine, then current sessions would
> continue on the old system after deploying the new.
>

My only worry is when the deployment includes a schema migration. I'm not sure
how to do continuous deployment in the old RDBMS case. Maybe that is the real
promise of CouchDB and its ilk. I'm betting CD is easier if you have adapted
(or, I suppose, planned) the architecture to support it.

  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

Curtis Cooley wrote:
> On Mon, Nov 9, 2009 at 7:19 AM, Ron Jeffries <ronjeffries@...> wrote:
>>
>>
>> Hello, Chris. On Monday, November 9, 2009, at 10:12:03 AM, you
>> wrote:
>>
>>> On the last the research found no statistical evidence of
>>> geographic distance having an impact on quality It appears the
>>> smallest co-location measure they used was "in the same building"
>>> So does this indicate that geographic location is not an factor in
>>> poor quality? Or that being in the same building and not working
>>> closely together as XP recommends is just as bad as being
>>> geographically dispersed?
>> The impact of 2X that is widely reported occurs when the team works
>> in the same ROOM, not the same building.
>>
> And to clarify, this link from Ron's list,
> http://www.umich.edu/news/index.html?Releases/2000/Dec00/r120600a
> found War Room to be 2X more productive than normal cubicle type
> development, cubicles technically all being in the same 'room'.

Also see http://biblio.gdinwiddie.com/biblio/StudiesOfColocation which
contains a link to the full article.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hello ROGER

I'm reading the art of agile development too. Maybe reading the chapter 9,
Developing (pg. 276), would be helpful for you.The subtopic "customer
review" (pg. 279) has enlightened me.

On Wed, Oct 21, 2009 at 9:01 AM, Ron Jeffries <ronjeffries@...> wrote:

>
>
> Hello, ROGER. On Wednesday, October 21, 2009, at 2:09:22 AM, you
> wrote:
>
>
> > it's an interesting point of view and very helpful for future :-)
> > i understood that documentation is not the main point in such
> > method but something must be written down to at least have a trace for
> future.
> > basically, you release v1.0 but on what will you base your next
> > version development if you do not have at least basic
> > documentation like UML diagrams / stories (in XP) ?
>
> Documentation such as you describe is a means for creating a team of
> people who understand the software, would you agree?
>
> When you release v1.0, you have a team full of people who understand
> the software already. They don't need formal documentation, though
> the team walls may well be full of pictures, diagrams, whatever they
> do need.
>
> Why not proceed from there to v2.0?
>
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Don't confuse more exact with better. -- Brian Marick
>
>
>

--
Renan Ivo Martins
Web Developer


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

Hey all,

Anyone from this group attending the Agile Development Practices
conference in Orlando this week?

I've been a little bit out of touch from the Agile community lately.
Hoping to get back in touch with some folks and make some new connections.
Particularly anyone in Florida, especially South Florida.

I'm planning on being at the conference Wed. through Fri. Feel free to
email me a private message at j a s o n <at> n o c k s <dot> c o m if you
plan on being there.

--
Cheers,
Jason Nocks