Becoming Extreme
Neither a fine Coach nor skilled artisans are sufficient to move a development from the muddy shallows into smooth water. To do this requires the development of harmony in the project as a whole.
It is difficult for many people to accept that heroics, long hours, and high stress are not the most effective ways to improve the quality and timeliness of a project. It's counterintuitive to think that less difficulty and more fun can produce more enduring, more successful, and more prolific work.
Most developers are used to heroics, regarding them as professional diligence. Most managers are used to stress, regarding it as cure rather than symptom of slippage. And most customers are used to ignorance of process, regarding it as a domain of haggard savants and inscrutable science. When a corporate culture has bought in to these habits, challenges will be treated with considerable suspicion.
Indeed, when an XP group outcompetes old development styles, a hostile reaction can easily occur. Though the successful introduction of XP might promote harmony, attempting to introduce it can become a highly charged political struggle. How can XP be employed by an established development group without running this risk?
Changing group culture should always be thought of as seduction. Rather than declaring war on a culture by heated debate and displays of erudition, suggest small changes, and these only to individuals. Introduce simple disciplines and let their benefits speak for themselves. Don't preach XP; solve small problems and let the solutions grow.
Empty their minds,
Fill their bellies,
Weaken their ambitions,
And strengthen their bones. [Lao2000]
Eventually these individual practices begin to cover the process. Some developer's unit test reproducibly. Perhaps others develop a fondness for pairing. Customers see some user stories estimated, scheduled, and delivered. The Coach has conducted stand-up meetings, demonstrated a few refactorings, and conducted a CRC or two. When team members have accepted such practices in isolation, the team will naturally begin to think about how they could connect.
Some of the team will have nosed around and found out where you're coming from. Eventually you will find a champion among them. Let him or her talk. Then you need only follow diligently and fix little problems, work gently to help the practices interlock, and help the process flow.
When there is general developer commitment but the rest of the organization hasn't yet bought in, conduct an Extreme Hour [Merel+2000] involving customers and Quality Assurance (QA). Encourage skepticism, but let developers answer questions where possible. Make sure upper management expresses explicit support for the team's ability to define its own process. When your organization comes up with viable alternatives, try them out and share them with the XP community. It costs nothing to communicate process, and the feedback will be invaluable.
When XP really starts to hum, the old habits will occasionally still reassert themselves. People truly seem to seek out drama. When schedules must be defended, budgets reined in, and long hours worked, when architecture is neglected in favor of quick fixes, when corporate culture is forced onto developers, when rivalry over pay and equity, responsibility and title breaks out, the project begins to rob its customers. These are times when the rhetoric of excellence, professionalism, and team spirit is heard loudest.
When harmonious relationships dissolve
Then respect and devotion appear;
When a nation falls to chaos
Then loyalty and patriotism are born. [Lao2000]
When team members return to their old ways, an XP project will lose flow fast. Because XP provides few artifacts to fall back on, this kind of stall can seem disastrous. But because XP provides few artifacts to get in the way, it's easy to pull out of the stall. A review of process, a review of schedule, a review of standards, a rotation of engineering tasks, or, with tact, the application of the rolled newspaper, and off you go again.
The prerequisite without which XP must fail is commitment from upper management. You can't sneak XP past people who expect big design up front or cowboy coding. You can't fake a paper-heavy process with analysts, or low-discipline process with programmers. An XP proponent in a Confucian-style business may be able to take advantage of some practices in isolation, pairing and unit-testing especially, but they shouldn't expect high flow from more than a few developers or for more than a few days. If they confront Confucian forces without upper management support, they will lose touch with the team. Losing touch with the team, their effort will be wasted.