|
|
RE: [xpe2e] Second practice: Whole Team: msg#00010
programming.extreme-programming.xp-explained2
|
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
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 Links
|
|
