XpManagementFaq

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 AcceptanceTests. 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.