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