Home > Archive > Extreme Programming > September 2005 > How to Get a Team Started in Doing XP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to Get a Team Started in Doing XP
|
|
| jsadler 2005-09-27, 9:56 pm |
| Hi All,
I am currently in the process of converting a team of developers to
doing Extreme Programming. There are 10 in the team, including myself,
but I am the only XP mentor. In my last job, I was part of a 'Agile'
consultancy specialising in XP mentoring and I had the support of my
consultancy peers. i.e. there was larger ratio of mentors to developers
and the transition was a lot easier. This time I am all by myself, and
it's a little daunting.
I am of the opinion that presentations and the like aren't all that
useful - I prefer a hands-on approach. I believe that doing rather
than watching are much more powerful means as a learning / teaching
tool. But I can't pair with everybody on the team at the same time.
Has anybody else been in the same or similar situtation? How did you
deal with it? How did you drum up the enthusiasm of the team?
I would be interested in hearing what you have to say.
I am also interested in hearing about any hands-on training exercises
that can be done in an afternoon that teach pair programming,
test-driven development and refactoring in a fun, useful way.
Best Regards,
James Sadler.
| |
| Stéphane tavera 2005-09-28, 6:58 pm |
| j ler wrote:
> Hi All,
>
> I am currently in the process of converting a team of developers to
> doing Extreme Programming. There are 10 in the team, including myself,
> but I am the only XP mentor. In my last job, I was part of a 'Agile'
> consultancy specialising in XP mentoring and I had the support of my
> consultancy peers. i.e. there was larger ratio of mentors to developers
> and the transition was a lot easier. This time I am all by myself, and
> it's a little daunting.
>
> I am of the opinion that presentations and the like aren't all that
> useful - I prefer a hands-on approach. I believe that doing rather
> than watching are much more powerful means as a learning / teaching
> tool. But I can't pair with everybody on the team at the same time.
>
> Has anybody else been in the same or similar situtation? How did you
> deal with it? How did you drum up the enthusiasm of the team?
>
> I would be interested in hearing what you have to say.
>
> I am also interested in hearing about any hands-on training exercises
> that can be done in an afternoon that teach pair programming,
> test-driven development and refactoring in a fun, useful way.
>
> Best Regards,
>
> James Sadler.
>
From my little experience in "promoting" XP to people already
interested in it, the tools are the things that convince first.
These tools (ant, JUnit, checkstyle, ...) do not require a lot of setup.
It is a good investment to take some extra effort at the beginning of
your project to be sure that everyone will use these. You will also need
to be strict on some points, but as the people will understand all the
benefits from these new habits, it should require less and less pression
from your coach side.
I am aware that XP values do not rely on just the use of some tools or
processes. But instead of "wasting" your time in evangelization that
proves useless with some persons, try to have some facts to show to your
team in one or two months.
You should also prepare yourself to people reluctant (hum at least) to
XP values. The most common pitfall is the expert striking for
performance, genericity, ... instead of the most simple solution (that
works!!).
For the TDD adoption, I highly recommend to buy some examples of
"Test-Driven Development" by Kent Beck, and lend them to your team members.
My 2 cents,
Stéphane Tavera
| |
| Ilja Preuß 2005-09-29, 6:57 pm |
| You should get yourself a copy of the book "Fearless Change".
Cheers, Ilja
| |
| Ron Ruble 2005-09-30, 7:58 am |
| jler wrote:
> Hi All,
>
> I am currently in the process of converting a team of developers to
> doing Extreme Programming. There are 10 in the team, including myself,
> but I am the only XP mentor. In my last job, I was part of a 'Agile'
> consultancy specialising in XP mentoring and I had the support of my
> consultancy peers. i.e. there was larger ratio of mentors to developers
> and the transition was a lot easier. This time I am all by myself, and
> it's a little daunting.
>
> I am of the opinion that presentations and the like aren't all that
> useful - I prefer a hands-on approach. I believe that doing rather
> than watching are much more powerful means as a learning / teaching
> tool. But I can't pair with everybody on the team at the same time.
>
> Has anybody else been in the same or similar situtation? How did you
> deal with it? How did you drum up the enthusiasm of the team?
>
> I would be interested in hearing what you have to say.
>
> I am also interested in hearing about any hands-on training exercises
> that can be done in an afternoon that teach pair programming,
> test-driven development and refactoring in a fun, useful way.
>
> Best Regards,
>
> James Sadler.
>
Interesting problem. I've never been in that situation,
but I have trained a number of teams on technologies and
methodologies, so I have a few thoughts. I'd like to hear
what others say.
> I am currently in the process of converting a team of
> developers to doing Extreme Programming.
Is that your primary responsibility, or a secondary
concern? Trying to figure out how your time needs to
be allocated. If you have all day every day to concentrate
on getting the team going with XP, your job is easier than
if you are a developer trying to do this as part of an
overloaded schedule.
> ...I can't pair with everybody on the team at the same
> time.
Very true. Given that fact, determine what amount of time
you'd like to devote to pairing with each team member,
and some equal amount of time to sitting in with pairs,
observing.
> There are 10 in the team...
If mentoring is your full time concern, ten is a reasonable
number. Keep a file on each person, and track details that
will allow you to address their specific needs.
If it's -not- your full time concern, you won't have time
to track in that level of detail. You'll need to track
the warning signs; lots of extensive rework on a given
module, signs of friction between pair members, team
members getting into 'fixed' pairs, some team members
dominating others, other things.
> How did you drum up the enthusiasm of the team?
How enthusiastic are they now? With ten people, I'd
expect you have at -least- 4 members with a fair degree
of enthusiasm now, preferably 6 or 7.
If not, I'd worry whether the field is ready for
planting the seeds at all.
Enthusiasm tends to be something you can't force; but
it is contagious. Be enthusiastic. Ensure that people
see and feel part of small successes. talk with those
who aren't as enthusiastic; dig to find out what
their worries are, and address them with real-life
examples to reduce their fears.
Be alert that people will -not- be forthcoming
about what worries them, and many will be worried
about non-technical things. Some may worry that they
will lose their 'senior' position because the younger
guys will pick this up faster. Some may worry that
management will use early success to cut staff.
|
|
|
|
|