Discussion:
[xpe2e] Second practice: Whole Team
Kent Beck
2004-10-18 16:55:49 UTC
Permalink
Whole Team

Include on the team people with all the skills and perspectives
necessary for the project to succeed. This is really nothing more than
the old idea of cross-functional teams. The name reflects the purpose of
the practice, a sense of wholeness on the team, the ready availability
of all the resources necessary to succeed. Where intense interactions
are necessary for the health of the project, those interacting should be
primarily identified with the team and not their functions.

People need a sense of "team":
* We belong.
* We are in this together.
* We support each others' work, growth, and learning.

What constitutes a "whole team" is dynamic. If a set of skills or
attitudes becomes important, bring a person with these skills on the
team. If someone is no longer necessary, he can go elsewhere. For
example, if your project requires many changes to a database, you will
need a database administrator on the team. When the need for database
changes diminishes that person no longer needs to be part of the team,
at least for that function.

An issue that often arises is ideal team size. The Tipping Point by
Malcolm Gladwell describes two discontinuities in team size: 12 and 150.
Many organizations; military, religious, and business; split teams when
they cross these thresholds. Twelve is the number of people who can
comfortably interact with each other in a day. With more than 150 people
on a team, you can no longer recognize the faces of everyone on your
team. Across both of these thresholds it is harder to maintain trust,
and trust is necessary for collaboration. For larger projects, finding
ways to fracture the problem so it can be solved by a team of teams
allows XP to scale up.

Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.



------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Johannes Brodwall
2004-10-18 17:06:12 UTC
Permalink
Post by Kent Beck
Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.
I thought you might be interested in the alternative rationale we use
for the same conclusion. In sound bit form, I say "a 60% resource
contributes only 40%, but requires 100% coordination effort" (that is,
they count as a full person towards the 12-people boundary you
describe).


~Johannes


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-10-18 19:36:38 UTC
Permalink
When the need for database changes diminishes that person no longer
needs to be part of the team, at least for that function.
This poses an interesting interaction with "Sit together". It's
something our team is familiar with in the fact that "where we sit
depends on what we're doing". But it also poses some interesting
technology questions since there are (in my experience anyway) some
political issues with roles like DBAs.

Example: Should the DBAs sit with the teams or do they sit with the
DBAs? There are many answers to this question but I'm not sure that
some situations even have a right answer. In some overly political
situations, I wonder if the right answer might even be "just don't
use a database".





------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Russell Gold
2004-10-18 20:10:54 UTC
Permalink
Post by Kent Beck
Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.
Some skills are specialized and are not needed on a full time basis.
That is to say, a team may require a low-level of DBA support over its
lifetime (or system administrator, or secretarial help, etc.). So
presumably you would say that such a person is not part of the team at
all, but rather has the team as his/her customer?


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Kent Beck
2004-10-19 20:11:49 UTC
Permalink
My intention with the practice is to encourage readers to align the
interests of everyone who strongly affects the team. If you need
infrequent support from a DBA but that support is critical when it is
needed, the team is better off with a DBA on the team who spends most of
his time on other tasks. Over time, through pairing, your reliance on
that one person should diminish. If the team gets unpredictable support
from a DBA who isn't part of the team, the whole team's effectiveness
will be diminished. Finding a way to more closely align the DBA's
interests with the team's will result in improved effectiveness.

Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Monday, October 18, 2004 1:11 PM
Subject: Re: [xpe2e] Second practice: Whole Team
On Mon, 18 Oct 2004 09:55:49 -0700, Kent Beck
Post by Kent Beck
Some organizations try to have teams with fractional
people: "You'll
Post by Kent Beck
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on
task-switching that you can see immediate improvement by
grouping the
Post by Kent Beck
programmers into teams. The team responds to the customers' needs.
This frees the programmers from fractured thinking. The customer
receives the benefit of the expertise of the whole team as needed.
People need acceptance and belonging. Identifying with this
program on
Post by Kent Beck
Mondays and Thursdays and that program on Tuesdays, Wednesdays, and
Fridays, without having other programmers to identify with,
destroys
Post by Kent Beck
the sense of "team" and is counterproductive.
Some skills are specialized and are not needed on a full time
basis. That is to say, a team may require a low-level of DBA
support over its lifetime (or system administrator, or
secretarial help, etc.). So presumably you would say that
such a person is not part of the team at all, but rather has
the team as his/her customer?
------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Amir Kolsky
2004-10-18 23:13:40 UTC
Permalink
I don't often disagree with what Kent says but... Whereas the idea makes
sense in large organizations, in small shops it's a recipe for disaster.

OK, we're done with the database part. You're fired. Bye!

That should do wonder for team morale...

Amir Kolsky
XP& Software



_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Monday, October 18, 2004 6:56 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: [xpe2e] Second practice: Whole Team


Whole Team

Include on the team people with all the skills and perspectives
necessary for the project to succeed. This is really nothing more than
the old idea of cross-functional teams. The name reflects the purpose of
the practice, a sense of wholeness on the team, the ready availability
of all the resources necessary to succeed. Where intense interactions
are necessary for the health of the project, those interacting should be
primarily identified with the team and not their functions.

People need a sense of "team":
* We belong.
* We are in this together.
* We support each others' work, growth, and learning.

What constitutes a "whole team" is dynamic. If a set of skills or
attitudes becomes important, bring a person with these skills on the
team. If someone is no longer necessary, he can go elsewhere. For
example, if your project requires many changes to a database, you will
need a database administrator on the team. When the need for database
changes diminishes that person no longer needs to be part of the team,
at least for that function.

An issue that often arises is ideal team size. The Tipping Point by
Malcolm Gladwell describes two discontinuities in team size: 12 and 150.
Many organizations; military, religious, and business; split teams when
they cross these thresholds. Twelve is the number of people who can
comfortably interact with each other in a day. With more than 150 people
on a team, you can no longer recognize the faces of everyone on your
team. Across both of these thresholds it is harder to maintain trust,
and trust is necessary for collaboration. For larger projects, finding
ways to fracture the problem so it can be solved by a team of teams
allows XP to scale up.

Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.



Yahoo! Groups Sponsor

ADVERTISEMENT

<http://us.ard.yahoo.com/SIG=1291b0m29/M=315388.5500238.6578046.3001176/D=gr
oups/S=1705007207:HM/EXP=1098204953/A=2372354/R=0/SIG=12id813k2/*https://www
.orchardbank.com/hcs/hcsapplication?pf=PLApply&media=EMYHNL40F21004SS> click
here

<http://us.adserver.yahoo.com/l?M=315388.5500238.6578046.3001176/D=groups/S=
:HM/A=2372354/rand=400998183>


_____

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=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
Ken Boucher
2004-10-18 23:22:46 UTC
Permalink
I'm not sure how
that person no longer needs to be part of the team, at least for
that function.
OK, we're done with the database part. You're fired. Bye!
On a small team, if the database role was small, the people I would
have supporting that role would be able to support other functions
as well. From a certain perspective, there is no longer anyone with
that role on the team. The same person may resume or begin some
other role, in which case they would be sitting with the same team
still.

If, on the small team, that person no longer had skillsets that would
allow them to remain a productive member of the team, the right
thing to do would help them transition to a job where they could be
productive. This may involve training, it may involve helping them
look for a new job, but paying someone to not be productive is
damaging to their long term morale and the teams morale.





------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Keith Nicholas
2004-10-19 00:51:51 UTC
Permalink
I think you missed a reality check.....

a small shop has a software project with a small "database" element. Is the
small shop going to employ a pure database specialist? no. They are going
to employ people who have a number of skills and perhaps one with an
expertise in databases. Or, the team brings in a specialist contractor who
you make part of the team, other team members learn off the contractor, at
the end of the contract you say "bye bye" and the team carries on.

Regards,

Keith



_____

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Tuesday, 19 October 2004 12:14 p.m.
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Second practice: Whole Team


I don't often disagree with what Kent says but... Whereas the idea makes
sense in large organizations, in small shops it's a recipe for disaster.

OK, we're done with the database part. You're fired. Bye!

That should do wonder for team morale...

Amir Kolsky
XP& Software




_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Monday, October 18, 2004 6:56 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: [xpe2e] Second practice: Whole Team


Whole Team

Include on the team people with all the skills and perspectives
necessary for the project to succeed. This is really nothing more than
the old idea of cross-functional teams. The name reflects the purpose of
the practice, a sense of wholeness on the team, the ready availability
of all the resources necessary to succeed. Where intense interactions
are necessary for the health of the project, those interacting should be
primarily identified with the team and not their functions.

People need a sense of "team":
* We belong.
* We are in this together.
* We support each others' work, growth, and learning.

What constitutes a "whole team" is dynamic. If a set of skills or
attitudes becomes important, bring a person with these skills on the
team. If someone is no longer necessary, he can go elsewhere. For
example, if your project requires many changes to a database, you will
need a database administrator on the team. When the need for database
changes diminishes that person no longer needs to be part of the team,
at least for that function.

An issue that often arises is ideal team size. The Tipping Point by
Malcolm Gladwell describes two discontinuities in team size: 12 and 150.
Many organizations; military, religious, and business; split teams when
they cross these thresholds. Twelve is the number of people who can
comfortably interact with each other in a day. With more than 150 people
on a team, you can no longer recognize the faces of everyone on your
team. Across both of these thresholds it is harder to maintain trust,
and trust is necessary for collaboration. For larger projects, finding
ways to fracture the problem so it can be solved by a team of teams
allows XP to scale up.

Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.




Yahoo! Groups Sponsor

ADVERTISEMENT

<http://us.ard.yahoo.com/SIG=129n12106/M=315388.5497957.6576270.3001176/D=gr
oups/S=1705007207:HM/EXP=1098227069/A=2372354/R=0/SIG=12id813k2/*https://www
.orchardbank.com/hcs/hcsapplication?pf=PLApply&media=EMYHNL40F21004SS> click
here

<http://us.adserver.yahoo.com/l?M=315388.5497957.6576270.3001176/D=groups/S=
:HM/A=2372354/rand=275176964>


_____

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=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
Amir Kolsky
2004-10-19 07:10:20 UTC
Permalink
If you know in advance where you're going you may be able to subcontract or
bring in consultants or get omnipotent programmers, but it is often the case
that the requirements for a specific skill are only discovered later in the
process and vice versa - that a skill you thought necessery is less so.

Is it better to invest in acquiring the skill in house or is it simpler to
fire and hire?

Amir Kolsky
XP& Software



_____

From: Keith Nicholas [mailto:keithn-***@public.gmane.org]
Sent: Tuesday, October 19, 2004 2:52 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Second practice: Whole Team


I think you missed a reality check.....

a small shop has a software project with a small "database" element. Is the
small shop going to employ a pure database specialist? no. They are going
to employ people who have a number of skills and perhaps one with an
expertise in databases. Or, the team brings in a specialist contractor who
you make part of the team, other team members learn off the contractor, at
the end of the contract you say "bye bye" and the team carries on.

Regards,

Keith



_____

From: Amir Kolsky [mailto:amir-***@public.gmane.org]
Sent: Tuesday, 19 October 2004 12:14 p.m.
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Second practice: Whole Team


I don't often disagree with what Kent says but... Whereas the idea makes
sense in large organizations, in small shops it's a recipe for disaster.

OK, we're done with the database part. You're fired. Bye!

That should do wonder for team morale...

Amir Kolsky
XP& Software




_____

From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Monday, October 18, 2004 6:56 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: [xpe2e] Second practice: Whole Team


Whole Team

Include on the team people with all the skills and perspectives
necessary for the project to succeed. This is really nothing more than
the old idea of cross-functional teams. The name reflects the purpose of
the practice, a sense of wholeness on the team, the ready availability
of all the resources necessary to succeed. Where intense interactions
are necessary for the health of the project, those interacting should be
primarily identified with the team and not their functions.

People need a sense of "team":
* We belong.
* We are in this together.
* We support each others' work, growth, and learning.

What constitutes a "whole team" is dynamic. If a set of skills or
attitudes becomes important, bring a person with these skills on the
team. If someone is no longer necessary, he can go elsewhere. For
example, if your project requires many changes to a database, you will
need a database administrator on the team. When the need for database
changes diminishes that person no longer needs to be part of the team,
at least for that function.

An issue that often arises is ideal team size. The Tipping Point by
Malcolm Gladwell describes two discontinuities in team size: 12 and 150.
Many organizations; military, religious, and business; split teams when
they cross these thresholds. Twelve is the number of people who can
comfortably interact with each other in a day. With more than 150 people
on a team, you can no longer recognize the faces of everyone on your
team. Across both of these thresholds it is harder to maintain trust,
and trust is necessary for collaboration. For larger projects, finding
ways to fracture the problem so it can be solved by a team of teams
allows XP to scale up.

Some organizations try to have teams with fractional people: "You'll
spend 40% of your time working for these customers and 60% work for
those customers." In this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping the programmers into
teams. The team responds to the customers' needs. This frees the
programmers from fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People need acceptance and
belonging. Identifying with this program on Mondays and Thursdays and
that program on Tuesdays, Wednesdays, and Fridays, without having other
programmers to identify with, destroys the sense of "team" and is
counterproductive.






Yahoo! Groups Sponsor

ADVERTISEMENT

<http://us.ard.yahoo.com/SIG=129o55a0e/M=294855.5468653.6549235.3001176/D=gr
oups/S=1705007207:HM/EXP=1098233508/A=2376776/R=0/SIG=11ldm1jvc/*http://prom
otions.yahoo.com/ydomains2004/index.html> click here

<http://us.adserver.yahoo.com/l?M=294855.5468653.6549235.3001176/D=groups/S=
:HM/A=2376776/rand=774685628>


_____

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=Unsubscrib
e>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
poetacaotico
2004-10-19 11:48:12 UTC
Permalink
Hi all.
I think that the XP team may be "closed whole team" or "opened whole
team". So: is a specialist, hired for a short period, part of the team
or not?
The answer can be very different, as regards with particular reality.
May be the most important question is: "is the team enough mature to
collaborate with not-team member?" ...
Thanks and please beg my poor English,

Torti Tommaso





------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-10-19 09:08:21 UTC
Permalink
Post by Kent Beck
What constitutes a "whole team" is dynamic. If a set
of skills or attitudes becomes important, bring a
person with these skills on the team. If someone is
no longer necessary, he can go elsewhere.
First, I found the way this is phrased to express
little regard or respect for the individuals
involved. There is the matter of the person being
brought in and then left to go ("he can go elsewhere"
really sounds like "he can f*ck off"). Then, there is
the matter of the people on the team: bringing in an
expert implies that it is not worth investing in
developing their own skills.

Secondly, I am not sure I agree that this is a good
thing to do. It is something that I found useful before
I used XP, but with XP, it doesn't seem to work. I now
feel the only motive for "bring someone in" is if the
team asks for coaching or mentoring. Your description
sounds as though it would also allow for bringing in an
expert to do a job, is that right?
Post by Kent Beck
For example, if your project requires many changes to
a database, you will need a database administrator on
the team. When the need for database changes
diminishes that person no longer needs to be part of
the team, at least for that function.
I think this is very bad advice. Every time I have seen
this happen, either (or both) of the following
occurred:

- it was later necessary to call the DBA back for a
specific job: his availability became a bottleneck.

- the remaining team members did some things without
the DBA, ending up in a mess or starting over.

I believe the XP team should do everything itself. This
can influence the choice of members of the team, and
conversely influence the choice of tools according to
the skills of the team.
Post by Kent Beck
For larger projects, finding ways to fracture the
problem so it can be solved by a team of teams allows
XP to scale up.
Although this sounds interesting, it begs the
questions:

- how should the problem be fractured?
- how do the teams collaborate?

Do you develop those later in the book?
Post by Kent Beck
Some organizations try to have teams with fractional
people: "You'll spend 40% of your time working for
these customers and 60% work for those customers." In
this case, so much time is wasted on task-switching
that you can see immediate improvement by grouping
the programmers into teams. The team responds to the
customers' needs. This frees the programmers from
fractured thinking. The customer receives the benefit
of the expertise of the whole team as needed. People
need acceptance and belonging. Identifying with this
program on Mondays and Thursdays and that program on
Tuesdays, Wednesdays, and Fridays, without having
other programmers to identify with, destroys the
sense of "team" and is counterproductive.
I wholeheartedly agree. In practice, in many large
organizations, this is difficult to combine with your
other suggestion that people should be brought in as
needed by a team... Having a stable team of fulltime
people is more coherent, and easy to organize.

Regards,

Dominic Williams
http://dominicwilliams.net

----




------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-10-19 09:55:09 UTC
Permalink
Post by Dominic Williams
Secondly, I am not sure I agree that this is a good
thing to do. It is something that I found useful before
I used XP, but with XP, it doesn't seem to work. I now
feel the only motive for "bring someone in" is if the
team asks for coaching or mentoring. Your description
sounds as though it would also allow for bringing in an
expert to do a job, is that right?
On C3, we brought in Jim Haungs to do some optimization work. We paired
with him as much as possible, but he did a lot of work optimizing this and
that on his own.

After he left, we removed essentially everything he did, and used the
measurement and optimization techniques we had learned from him, to do it
all over.

The result was that the team knew how to do the job we brought him in to
do.

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? -- E M Forster




------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-10-19 10:30:33 UTC
Permalink
Hi Ron,
Post by Ron Jeffries
The result was that the team knew how to do the job
we brought him in to do.
That sounds great. Given the way it was done, would you
call it mentoring?

Does Kent's description (taken out of context, I know)
encourage doing it that way, or does it leave a lot of
room for other ways that would not have such a good
result?

Regards,

Dominic Williams
http://dominicwilliams.net

----




------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->


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:
http://docs.yahoo.com/info/terms/
bernard_notarianni
2004-10-30 18:01:35 UTC
Permalink
--- In xpbookdiscussiongroup-***@public.gmane.org, "Dominic Williams"
<***@d...> wrote:
[...]
Post by Dominic Williams
Post by Kent Beck
For example, if your project requires many changes to
a database, you will need a database administrator on
the team. When the need for database changes
diminishes that person no longer needs to be part of
the team, at least for that function.
I think this is very bad advice. Every time I have seen
this happen, either (or both) of the following
- it was later necessary to call the DBA back for a
specific job: his availability became a bottleneck.
- the remaining team members did some things without
the DBA, ending up in a mess or starting over.
I believe the XP team should do everything itself. This
can influence the choice of members of the team, and
conversely influence the choice of tools according to
the skills of the team.
Post by Kent Beck
For larger projects, finding ways to fracture the
problem so it can be solved by a team of teams allows
XP to scale up.
Although this sounds interesting, it begs the
- how should the problem be fractured?
- how do the teams collaborate?
Do you develop those later in the book?
[...]

I agree with Dominic.

I feel that the idea behind the "dynamic of the team" is something
similar to a kind of "continuous team refactoring". Can we apply to
the team some patterns similar to the software itself?

Personally, I don't think this one can be.

The code and the software can be agile, but human minds are probably
far more difficult to refactor and to improve :-)

Mentoring as described by Ron Jeffries seems more appealing to me, but
indeed, It is a long term process...






------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->
William E Caputo
2004-10-19 22:28:03 UTC
Permalink
<html><body> <FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Dominic:</DIV><DIV>&gt;<FONT face="Courier New">or does it leave a lot of room for other ways </FONT></DIV><DIV><FONT face="Courier New">&gt;that would not have such a good result?</FONT></DIV><P>All advice, guidelines, rules of thumb, laws, commandments and experience reports&nbsp;(including this email) over the range of people exposed to them have this limitation. </P><P>(IOW what message works well, or less well, for some is different than for others)</P><P>Its one reason why values and that stuff about 'individuals and their&nbsp;interactions' is what we get on about in our meta-consulting -- until we start sounding like bad actors in kung-fu movies.</P><P>Such is the life of an XP Monk.</P><DIV>Best,<BR>Bill<BR><BR>William E. Caputo<BR>ThoughtWorks, Inc.<BR>http://<A href="http://www.williamcaputo.com" ta
rget=blank>www.williamcaputo.com</A><BR>--------<BR>Five minutes? It was two minutes, five minutes ago.<BR></DIV></FONT>

<br>




<!-- |**|begin egp html banner|**| -->

<br>
<tt><hr width="500">
<b>Yahoo! Groups Links</b><br>
<ul>
<li>To visit your group on the web, go to:<br><a href="http://groups.yahoo.com/group/xpbookdiscussiongroup/">http://groups.yahoo.com/group/xpbookdiscussiongroup/</a><br>&nbsp;
<li>To unsubscribe from this group, send an email to:<br><a href="mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscribe">xpbookdiscussiongroup-unsubscribe-***@public.gmane.org</a><br>&nbsp;
<li>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.
</ul>
</tt>
</br>

<!-- |**|end egp html banner|**| -->


</body></html>
Loading...