Practice: Team Continuity

[Kent Beck]

Keep effective teams together. There is a tendency in large organizations to
abstract people to things, plug-compatible programming units. Value in
software is created not just by what people know and do but also by their
relationships and what they accomplish together. Ignoring the value of
relationships and trust just to simplify the scheduling problem is false
economy.
Small organizations don't have this problem. There is only one team. Once
you gel, once you earn and offer trust, nothing short of shared calamity can
pull the team apart. Large organizations often ignore the value in teams,
adopting instead a molecular/fluid metaphor for "programming resources".
Once a project is done they go back "into the pool". The goal of such
scheduling is to get all the programmers fully utilized. This strategy
maximizes micro-efficiency but undermines the efficiency of the organization
as a whole, striving for the illusory efficiency of keeping individuals busy
typing while ignoring the value of enabling people to work mostly with those
they know and trust.
Keeping gelled teams together doesn't mean that teams are entirely static.
I have been astonished at how quickly new members begin contributing to
established XP teams. They insist on signing up for tasks the first week and
they are independently contributing after a month. By mostly keeping teams
together and yet encouraging a reasonable amount of rotation, the
organization gets the benefits of both stable teams and of consistently
spread knowledge and experience.

[Brad Appleton]

I assume you mean to keep effective teams together /for as long as they
are effective/. Im sure we've all seen teams that were very effective
turn into an ineffective team due not to changes within the membership,
but to changes in the members themselves. Im reminded of the many
legendary music groups/bands and their rousing successes and eventual
breakups.

So how do we keep the team effective? How do we maintain that effective
ensemble? Are there ways to do that which might involve incrementally
rotating some people in or out over time?

Kent Beck wrote:
> Keep effective teams together. There is a tendency in large organizations to
> abstract people to things, plug-compatible programming units. Value in
> software is created not just by what people know and do but also by their
> relationships and what they accomplish together. Ignoring the value of
> relationships and trust just to simplify the scheduling problem is false
> economy.
> Small organizations don't have this problem. There is only one team. Once
> you gel, once you earn and offer trust, nothing short of shared calamity can
> pull the team apart. Large organizations often ignore the value in teams,
> adopting instead a molecular/fluid metaphor for "programming resources".
> Once a project is done they go back "into the pool". The goal of such
> scheduling is to get all the programmers fully utilized. This strategy
> maximizes micro-efficiency but undermines the efficiency of the organization
> as a whole, striving for the illusory efficiency of keeping individuals busy
> typing while ignoring the value of enabling people to work mostly with those
> they know and trust.
> Keeping gelled teams together doesn't mean that teams are entirely static.
> I have been astonished at how quickly new members begin contributing to
> established XP teams. They insist on signing up for tasks the first week and
> they are independently contributing after a month. By mostly keeping teams
> together and yet encouraging a reasonable amount of rotation, the
> organization gets the benefits of both stable teams and of consistently
> spread knowledge and experience.
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here
> <http://us.ard.yahoo.com/SIG=129pqtgop/M=298184.6018725.7038619.3001176/D=groups/S=1705007207:HM/EXP=1109865964/A=2593423/R=0/SIG=11el9gslf/*http://www.netflix.com/Default?mqso=60190075>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>
> * To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
> <mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>

--
Brad Appleton <brad-***@public.gmane.org> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost

[Luiz Esmiralha]

Brad,

I feel that most people improve over time. Maybe a lot of this loss of
effectiveness can be explained by the environment the team is immersed
in rather than a change in the team itself. In the case of artists,
much pressure comes from producers and record companies and that is
certainly a key reason for breakups, creative paralysis and/or drug
addiction.

My point is that if we take care of the team and provide it an
encouraging, but not overwhelming, environment, it will renew itself
just like a tree in good land.

See ya,
Luiz

On Thu, 03 Mar 2005 00:42:20 -0600, Brad Appleton <bradpro-***@public.gmane.org> wrote:
> I assume you mean to keep effective teams together /for as long as they
> are effective/. Im sure we've all seen teams that were very effective
> turn into an ineffective team due not to changes within the membership,
> but to changes in the members themselves. Im reminded of the many
> legendary music groups/bands and their rousing successes and eventual
> breakups.
>
> So how do we keep the team effective? How do we maintain that effective
> ensemble? Are there ways to do that which might involve incrementally
> rotating some people in or out over time?
>
>
> Kent Beck wrote:
> > Keep effective teams together. There is a tendency in large organizations
> to
> > abstract people to things, plug-compatible programming units. Value in
> > software is created not just by what people know and do but also by their
> > relationships and what they accomplish together. Ignoring the value of
> > relationships and trust just to simplify the scheduling problem is false
> > economy.
> > Small organizations don't have this problem. There is only one team.
> Once
> > you gel, once you earn and offer trust, nothing short of shared calamity
> can
> > pull the team apart. Large organizations often ignore the value in teams,
> > adopting instead a molecular/fluid metaphor for "programming resources".
> > Once a project is done they go back "into the pool". The goal of such
> > scheduling is to get all the programmers fully utilized. This strategy
> > maximizes micro-efficiency but undermines the efficiency of the
> organization
> > as a whole, striving for the illusory efficiency of keeping individuals
> busy
> > typing while ignoring the value of enabling people to work mostly with
> those
> > they know and trust.
> > Keeping gelled teams together doesn't mean that teams are entirely
> static.
> > I have been astonished at how quickly new members begin contributing to
> > established XP teams. They insist on signing up for tasks the first week
> and
> > they are independently contributing after a month. By mostly keeping
> teams
> > together and yet encouraging a reasonable amount of rotation, the
> > organization gets the benefits of both stable teams and of consistently
> > spread knowledge and experience.
> >
> >
> > *Yahoo! Groups Sponsor*
> > ADVERTISEMENT
> > click here
> >
> <http://us.ard.yahoo.com/SIG=129pqtgop/M=298184.6018725.7038619.3001176/D=groups/S=1705007207:HM/EXP=1109865964/A=2593423/R=0/SIG=11el9gslf/*http://www.netflix.com/Default?mqso=60190075>
> >
> >
> > ------------------------------------------------------------------------
> > *Yahoo! Groups Links*
> >
> > * To visit your group on the web, go to:
> > http://groups.yahoo.com/group/xpbookdiscussiongroup/
> >
> > * To unsubscribe from this group, send an email to:
> > xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
> >
> <mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscribe>
> >
> > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> > Service <http://docs.yahoo.com/info/terms/>.
> >
> >
>
> --
> Brad Appleton <brad-***@public.gmane.org> www.bradapp.net
> Software CM Patterns (www.scmpatterns.com)
> Effective Teamwork, Practical Integration
> "And miles to go before I sleep" --Robert Frost
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
> ________________________________
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/xpbookdiscussiongroup/
>
> To unsubscribe from this group, send an email to:
> xpbookdiscussiongroup-unsubscribe-***@public.gmane.org
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Kent Beck]

Brad,

I'm still struggling to consistently solve the problem of helping a team
become effective in the first place. However, that doesn't keep me from
having opinions about how to keep them effective :-)

I think a certain amount of rotation among teams is good. I've been
surprised at how little turnover costs XP teams. Also, I would encourage
teams to do something completely different every once in a while. Perhaps
the company could donate the team's time to a local charity for a week of
custom application building a couple of times a year. Learning, training,
and rest are important for keeping all the team members energized. I'm not a
big fan of out-of-office socializing, but I've enjoyed being on sports teams
with colleagues.

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: Brad Appleton [mailto:bradpro-***@public.gmane.org]
> Sent: Wednesday, March 02, 2005 10:42 PM
> To: xpbookdiscussiongroup-***@public.gmane.org
> Subject: Re: [xpe2e] Practice: Team Continuity
>
>
> I assume you mean to keep effective teams together /for as
> long as they
> are effective/. Im sure we've all seen teams that were very effective
> turn into an ineffective team due not to changes within the
> membership,
> but to changes in the members themselves. Im reminded of the many
> legendary music groups/bands and their rousing successes and eventual
> breakups.
>
> So how do we keep the team effective? How do we maintain that
> effective
> ensemble? Are there ways to do that which might involve incrementally
> rotating some people in or out over time?

[Stephen Freeman]

Bob Taylor (director of the original CS lab at Xerox PARC) used to
make a point of keeping turnover low but regular. There are other
risks for long-lived teams, such as developing tunnel vision or being
closed to new developments in the discipline.

On the other hand, I heard a great simile recently. Some management
like to transfer people from an effective team to "seed" improvements
elsewhere. An alternative view is that it's like trying to make a
carthorse faster by grafting on a couple of legs off a racehorse.

S.

On Thu, 3 Mar 2005 22:35:40 -0800, Kent Beck <kentb-***@public.gmane.org> wrote:
> I think a certain amount of rotation among teams is good. I've been
> surprised at how little turnover costs XP teams. Also, I would encourage
> teams to do something completely different every once in a while. Perhaps
> the company could donate the team's time to a local charity for a week of
> custom application building a couple of times a year. Learning, training,
> and rest are important for keeping all the team members energized. I'm not a
> big fan of out-of-office socializing, but I've enjoyed being on sports teams
> with colleagues.