//Coaching
Food, also, is a hallmark of XP projects. There is something powerful about breaking bread with
someone. You have an entirely different discussion with them if you are chewing at the same time.
So XP projects always have food lying around. (I particularly recommend Frigor Noir chocolate
bars if you can find them, but some projects seem to survive on Twizzler licorice sticks. You're
welcome to develop your own local menu.)

//Intervention
First, though, the manager must search carefully to discover if there was something they should
have been aware of or done earlier to have avoided the problem entirely. The time for intervention
is not the time for donning white armor and leaping on a charger. Rather, it is a time to come to the
team and say, "I don't know how I let it get like this, but now I have to do XXX." Humility is the rule
of the day for an intervention.

//facilities
If you can, reserve a little of the nicest space off to one side for a communal space. Put in an
espresso maker, couches, some toys, something to draw people there. Often, the most effective
way to get unstuck while you are developing is to step away for a moment. If there is a pleasant
space to step away to, you are more likely to do it when you need it.

//responsabilities
If Business has the power, they feel fit to dictate all four variables to Development. "Here is what
you will do. Here is when it will be done. No, you can't have any new workstations. And it better be
of the highest quality or you're in trouble, buster."
The result of the "Business in Charge" scenario, then, is that the project takes on too much effort
and way, way too much risk for too little return.

When Development is in charge, they put in place all the process and technology that they never
had time for when "those suits" were pushing them around. They install new tools, new languages,
new technologies. And the tools, languages, and technologies are chosen because they are
interesting and cutting edge. Cutting edge implies risk. (If we haven't learned that by now, when
will we?)
So, the net result of the "Development in Charge" scenario is too much effort and way, way too
much risk for too little return.

//choice of technolofy
While the choice of a technology might seem at first to be a purely technical decision, it is actually
a business decision, but one that must be taken with input from Development. The customer will
have to live with a database or language vendor for many years, and has to be comfortable with
the relationship at a business level just as much as at a technical level.
There is another side to technology decisions, however, one that lies firmly in the camp of
Development. Once a technology has been introduced into a company, someone has to keep it
alive as long as it is in use. The costs of the latest and greatest technology are not just in initial
production development, or even entirely in development at all. The costs have to include the cost
of building and maintaining the competence to keep the technology alive

//planning game
You can't legislate this kind of relationship. You can't just say, "We know we've screwed up. We're
terribly sorry. It won't happen again. Let's work completely differently, starting right after lunch."
The world, and people, just don't work that way. Under stress, people revert to earlier behavior, no
matter how badly that behavior has worked in the past.
What is needed on the way to a mutually respectful relationship is a set of rules to govern how the
relationship is conducted—who gets to make which decisions, when the decisions will be made,
how those decisions will be recorded.

//collective ownership
Collective ownership tends to prevent complex code from entering the system in the first place. If
you know that someone else will soon (in a few hours) be looking at what you are writing at the
moment, you will think twice before putting in a complexity you can't immediately justify
Collective ownership increases your feeling of personal power on a project. On an XP project you
are never stuck with someone else's stupidity. You see something in the way, you get it out of the
way. If you choose to live with something for the moment because it is expedient, that is your
business. But you're never stuck. So you never get the sense that, "I could get my work done, if
only I didn't have to deal with these other idiots." One less frustration. One step closer to clear
thinking.

//pair programming
Pair programming is also not a tutoring session. Sometimes pairs contain one partner with much
more experience than the other partner. When this is true, the first few sessions will look a lot like
tutoring. The junior partner will ask lots of questions, and type very little. Very quickly, though, the
junior partner will start catching stupid little mistakes, like unbalanced parentheses. The senior
partner will notice the help. After a few more weeks, the junior partner will start picking up the
larger patterns that the senior partner is using, and notice deviations from those patterns.