From XpFaq

'''How can we Facilitate Boss Buy-in?'''

I was managing one team in a non-XP shop. Now I am the 'Program 
Manager' for the department (24 developers). As the guy in charge 
of process and schedules, I'm looking to move towards XP.

However, my boss (a great guy, by the way) is highly skeptical. He 
and I have had a few great dialogs so far, and we're both really 
open-minded and win-win oriented, so I'm feeling ok.

Tonight, I mentioned the metaphor of trying to plan your drive home 
before you start, down to the last swerve. He countered with the 
example of trying to drive off-road from Denver to LA, without having 
a map of the entire route, and finding yourself at the rim of the 
Grand Canyon, wondering how to get your Jeep across. Sharp guy. 
(My response was asking if there really are any such canyons in 
software development. He thinks there are. I don't.)

--KevinSmith

There are.  When you encounter them, you drive parallel to the rim until you
find a way across.  That's what happens when you start roaming through
uncharted territory.  

Now, if you happen to have a very detailed map of the land between here and
your destination, and you see the canyon on the map, then you can avoid it.
But what software project has such a map?  Does your boss think that the map
should be created?  Does that mean hes willing to launch a bunch of recon
satellites to find the canyons?  Or does he want to send an army of
surveyors accross the land finding all the possible pitfalls?

There are canyons.  That's part of the risk.  On the other hand, it's only a
drive of a day or two to get past them.  No need to launch a satellite
system.
 
 > His goals for our process are:
 > - Repeatability (Yeah, I think XP can do that)
 > - Efficiency (Again, I think XP is ok there)
 > - Good communications (Yup)
 > - Effective handoffs between Prod Mktg, Development, QA, and 
 > deployment (Yup)
 > - Scalability (Hmmm....)

Start small.  Change the process only when it starts to break.  You don't
want to be using a 50 man process for 5 people.

 > In addition, he voiced concerns that our relatively inexperienced 
 > programmers might go wild in the loose XP environment, so we need 
 > a more rigid structure (he's pushing for VERY light RUP) to keep 
 > things from getting out of hand. Note that he glanced at Beck's XP 
 > book, but hasn't really read it yet. But he will.

Show him the XP vs RUP paper in the 'publications' section of
http://www.objectmentor.com.  This papers shows how XP *is* a very light
RUP.  Tell him that this paper is precursor to papers that will be appearing
on the next release of the RUP CD.   

As for inexperienced developers.  XP does not allow *anyone* to go wild.  XP
is far more disciplined than RUP is.  Indeed, it is much easier to go wild
with RUP (wild writing lots of useless documents) than it is to go wild in
XP.  
 
 > We already know that scalability is a problem with XP. 

Scalability is a problem period.  Any process suitable for a small team is
not suitable for a large team.  There are no exceptions.  If you start with
light RUP (which might as well be XP) you will eventually outgrow it.
Choosing XP as a starting point is not liability with respect to scale.

 > But I'm 
 > thinking that we could have 5 teams of 12 developers each doing XP 
 > on apps, arranged to step on each other as little as possible. Has 
 > anyone see this structure work in the real world?

There is one team that I know of that is doing just that.  The jury is still
out. 

 > And what about inexperienced developers? Do they quickly enough 
 > figure out what is "good code" through OAOO and DTSTTCPW as 
 > well as pairing with old folks? Or is XP really better for 
 > people with at 
 > least a few years of good OOP under their belts?

Newbies need guidance in *any* process.  XP offers the best possible form of
guidance -- pair programming.  No process can protect you from newbies doing
stupid things.  Only your experienced engineers can do that.  

--RobertCecilMartin

 > Scalability is a problem period.  Any process suitable for a small team is
 > not suitable for a large team.  There are no exceptions.  If you start with
 > light RUP (which might as well be XP) you will eventually outgrow it.
 > Choosing XP as a starting point is not liability with respect to scale.

Processes don't scale up, but don't forget that process don't scale down either. A process that's good for fifty is not going to work well for five. In my view scalability isn't something you want from a software process. Anything that's scalable is either going to be so loose or require so much configuring (for me, that's RUP's problem) that it ends up not helping.

-- MartinFowler

"We already know that scalability is a problem with XP."

Compare the following statements:

We can't scale XP to 24 programmers.

and

We haven't scaled XP to 24 programmers.

There are certainly XP teams out there with 24+ programmers. It may work
just fine. I would look to SCRUM for ideas of how.

-- KentBeck

 > In addition, he voiced concerns that our relatively inexperienced
 > programmers might go wild in the loose XP environment,

Many managers have scars of old battles, in which a very quiet set of cubes
idly pursued a heavy methodology to ruin, misreading its literature to
elicit IntegrationHell, and with no peer review because "we don't have time for that". _This_ was programmers going wild, all the time not talking to each other, and obeying the paperwork of today's attempt at a
spiral.

Programmers in a steady but verbal, and fully collaborative, enterprise cannot keep secrets, including how smoothly code is incrementally getting better.

> so we need
a more rigid structure (he's pushing for VERY light RUP) to keep
things from getting out of hand.

The issue is not whether it works, but whether a metric of how well it works
feeds-back successfully & quickly. Management is expected to help in
authoring and running the AcceptanceTest''''''s. These will tell.

--PhlIp

This page focuses on one question far too much to be rightfully called XpManagementFaq. EditHint: Make a separate page (or pages) for this one big question and give it a good name. Faqs ideally have small answers to the questions. If more detail is needed, link to another page that explores it in more detail.