| Newsgroups |
gmane.comp.programming.extreme-programming |
| Message-ID |
<[email protected]> |
Hi Steven,
I'm sure there are many, many examples where having distributed teams
was a bad idea.
We all know that agile as (poorly) practiced ends up looking like a bad
idea in the majority of cases; it doesn't make agile a bad idea.
Distributed teams are indeed a bad idea for the kinds of folks who
wouldn't know how to build a successful team in the first place and who
don't want to truly buy into the value system of agile. Distributed
teams are also a bad idea for those who don't understand how to overcome
the inherent concessions you make by being distributed.
I disagree that distributed teams are inherently a bad idea.
Regards,
Jeff
--
Langr Software Solutions, Inc.
http://langrsoft.com
Pragmatic Unit Testing in Java (http://pragprog.com/book/utj2)
Modern C++ Programming with TDD (http://pragprog.com/book/lotdd)
Agile in a Flash (http://pragprog.com/book/olag)
Agile Java: Crafting Code with Test-Driven Development
(http://www.amazon.com/dp/0131482394)
Essential Java Style (http://www.amazon.com/dp/0130850861)
> Steven Gordon [email protected] [extremeprogramming]
> <mailto:[email protected]>
> October 18, 2016 at 11:31 AMvia Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
>
> Hi Jeff,
>
> I am sure there are counter-examples.
>
> Recruiting the members on the basis that XP will be followed would
> certain increase the chance of your outcome (over recruiting purely on
> the basis of domain or technical knowledge).
>
>
> Jeff Langr [email protected] [extremeprogramming]
> <mailto:[email protected]>
> October 18, 2016 at 11:23 AMvia Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
>
> Greetings,
>
> I was on a few different distributed teams while at Outpace for about
> 3 years. I'm not sure what the overall statistics are with respect to
> "very likely," but we built some very effective teams. Granted, we
> were all senior developers with considerable experience, but most of
> us had never worked together before.
>
> The teams we built were some of the most cohesive--and
> gratifying--I've been on. The pairing was definitely an important part
> of the team building, as were a number of other elements.
>
> We also had considerably higher stability than co-located teams, with
> almost no natural attrition in our first 2 years. (That went out the
> window when the business model proved to be a problem.)
>
> Regards,
> Jeff
>
>
> __._,_.__
> Steven Gordon [email protected] [extremeprogramming]
> <mailto:[email protected]>
> October 18, 2016 at 10:19 AMvia Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
>
> [email protected] <mailto:[email protected]>
>
> Steven,
>
>
>
> Yes, well … except that ...
>
> Mandating is probably never a really great team-building idea, and …
>
> Pair programming, as marvelous as we think it is, isn’t a proven
> path to success and in a remote situation, even if it’s as good as
> we think, may not be close to good enough.
>
>
> Ron,
>
> Distribution is an even worse team-building idea. So bad an idea that
> it is very likely that the group will effectively never become an
> team. So bad an idea that it is much more likely that members of the
> work group will leave for better opportunities at inconvenient times.
>
> Having a "bus number" of 1 is extremely risky for a distributed work
> group. The reason to mandate pairing is not necessarily for the
> traditional team-building and quality-improvement aspects of learning
> to pair well, but just to increase the chance that when a person
> leaves the work group, there is at least one other person who has some
> knowledge of any particular part of the code that later needs repair
> or extension.