Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Selling XP
It's clear that you need to try to implement XP into your environment. One thing to consider before rushing out to buy the books or download the tools: selling. Implementing XP at MySoftwareDevelopmentShop.com is going to mean that you have to sell the idea to customers, management, and developers.
How Do I Sell to Customers?
I've found that customers are the easiest to sell the idea of XP to! The important thing to get across is the business value that XP brings. Customers get these benefits:
They can change their minds.
They control and have visibility on what functions are developed.
They get a system that has been developed on a solid, repeatable test framework, and quality is built in.
Deliverables are produced that have direct value to them; the process is not propped up by documents that no one reads.
The development process is aligned to their own need to be agile in the marketplace.
You're supporting their short-time-to-market driver with a "real" process (not just working hard and adding more resources).
Course corrections can be made easily; the development is bundled into small releases.
Developers are happier and therefore nicer to work with. (This is a real issue!)
Is the use of the word extreme a problem when describing the process? I've found that it takes 30 seconds to explain where the X in XP comes from. Customers are more interested in how you plan to deliver value to them. Also, they have probably had some high-level exposure to XP in the press and have a sense for the context.
Selling to management, now that's another story...
How Do I Sell to Management?
Management maybe concerned that the programmers are in charge! I heard a senior manager complaining lately that XP was "developer heaven" and "polarized customers/developers." This highlights a problem you have to overcome in your role as XP champion; a perception that extreme programming is, well, programming. Too bad about the P in XP; we're stuck with it until some corporate monster takes over and re-badges it (imagine AcmeXP). To simplify a little, upper management is concerned with a few things:
Completing the project within the budget (no funny money or black market in time here).
The customer is happy and comes back for more work.
Workers are happy and keep working.
Estimates are accurate and support the sale side.
We'll give them the benefit of the doubt on the third point! Up-skilling developers so that they can use the latest tools is almost important (yeah, right). The way to sell to management then is to explain that:
XP uses small release cycles so management is very granular.
You can XP with a fixed-priced contract.
We can complete faster by the use of all practices together.
We do some if not most of the practices now; we're just doing them in the extreme.
Management can change XP names (such as the planning game) to whatever they want for marketing or cultural-safety reasons.
XP has been tried and tested in commercial environments.
We're not throwing out the baby with the bathwater; we'll still use existing methodologies and tools where they make sense.
Management will get better control and visibility of the process.
The company will have a new weapon that most competitors don't have (at the moment, anyway).
Another tactic is to target a manager who is predisposed to the use of agile or new methods. Careful care and feeding of this manager will strengthen your case when it comes to showing your hand. Recognize that management may in turn have to explain this new approach to their superiors; create whatever tools will help them do this. Typically these tools are simple (short) presentations with supporting documentation as appropriate. A fine balance between going under the radar and seeking executive buy-in is a challenge but will reward in the end.
One final aspect. Avoid leaving management with the idea that XP is a grab bag of practices from which you can pick whichever practice you want. Reinforce that the practices work together and that the sum of the parts is greater than the whole. The alternative is that, run with only a few practices, your project fails to deliver and XP is cast as the villain. You may get only one shot at this; choose wisely!
How Do I Sell to Developers?
First, how not to sell the concept to developers: Start talking about pair programming and how great it is! I know because I did this; I excitedly espoused all of the "programmer aspects" of XP. What you say and what they hear can be quite different.
|
You say... |
They think... |
|
Collective ownership |
Oh, anyone can change my code—great! |
|
Metaphor |
No up-front design; it'll end in spaghetti. |
|
Test first |
I don't test; I develop. |
|
Pair programming |
I work best alone. I'm so fast I do the work of two.(Actual quote!) |
|
Refactoring |
I complete the work and then I redo to get it right? That's what I call rework! |
Those are shark-infested waters, folks. What do developers really care about?
Coding—the joy of programming (mostly!)
Control over their machine and environment
Freedom
Using the coolest tools
Quality of work
Recognition
Projects rather than maintenance
It's an interesting paradox. Developers who like the newest tools, betas, and bits at the same time may dislike environmental change. Your mission is to seek out the most receptive developers in your team and to weave your spell of XP on them. Here are some angles that may help:
You'll use tools that automate the boring tasks of build and test.
"Test first" sounds weird, but you have easy-to-use frameworks (xUnit) that will help.
The work week is restricted to 40 hours (overtime is infrequent).
Developers don't write any documentation! (Favorite aspect of XP.)
XP values and drives quality in code.
Meetings are very short.
Pair programming is different; why not try for a few weeks? (Have those case studies up your sleeve, just in case.)
Project managers have gone away; you get a "coach" now—someone who is technical.
Often you'll find that the more senior developers are harder to sway toward XP. Listen to their concerns, be honest when you don't know, and stay humble. If you mandate and demand, it will scatter your team. Watch out for polarization and stamp it out.
Baby Steps
You've got to start somewhere, so go ahead and move the furniture. In a recent (perhaps flawed) implementation of XP, the team was separated by walls and partitions. One pair of programmers was on either side of the Chinese wall. The ambient noise rose to train-station levels and positioning of the team outside of the lift (elevator) well didn't help communication (see Figure 1).
){kind=link}
Figure 1 Poorly implemented XP environment.
You're not likely to get the chance to skunk-works your XP in a downtown warehouse, complete with Playstations and beanbags. We're still selling XP at this stage, and this means a soft approach. No wholesale decorating. (I remember turning our sterile break room into the "lava lounge," complete with lava lamp and 70s memorabilia. I prefixed my request with, "I want to do something and it won't cost the company any money!")
In the style of lightweight (er, excuse me, agile), start with any alterations you can get away with. At the end of all of the heaving, groaning, and squeaking, you should have at least the following:
An open area where two developers can sit around each machine
Some kind of meeting area where project information can be fixed to the wall
Separation from any other noisy area
Space for the customer(s) to sit
Quick and easy access to snacks (and beer in our beer-friendly New Zealand)
Figure 2 shows what one of our XP projects looks like.
){kind=link}
Figure 2 Good XP working environment.