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