Re: [xpe2e] Second practice: Whole Team

Kent Beck wrote, describing "Whole Team":

> 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?

> 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.

> 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?

> 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-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/