more effective programmers are working in pairs, he defaulted to
superlatives: “It’s amazingly powerful.”
Another source of productivity in the XP method is its intensity.
When you’re working with a partner, you’re locked into your work.
There’s no tactful way to disrupt your focus to check email or idly
surf the web, as doing so would leave your partner just sitting there,
annoyed, waiting for your attention to return.
6
Furthermore, given a
work culture in which you’re expected to
give your full attention to
the problem at hand, with a project manager shielding you from
distractions, you end up spending most of your day actually
accomplishing hard things. XP is as close to a pure deep work
environment as I’ve ever seen deployed successfully.
Given this intensity, another core tenet of XP is “sustainable
pace.” Most practitioners of this methodology stick to traditional
forty-hour workweeks, in defiance of
the Silicon Valley norm of
seventy to eighty hours. “With XP, we want you to come in, work
super hard for eight hours, then go home and think about other
things,” Woodward explained. This is not an act of generosity, but
instead a recognition of the limits of the human mind. “The average
engineer at a non-XP company may only do two to three hours of
actual
work a day; the rest of the time is spent surfing the web and
checking email.” When you’re actually
working—not sending
messages about work, not attending meetings about work—eight
hours in a single day can be quite demanding. When an engineer
joins an XP team, Woodward explained, it’s common for them to feel
“zapped.” The intensity of actually focusing for eight hours can be
overwhelming, and many XP rookies in their first week head straight
to bed when they return home from work. Some engineers never
adjust to this culture of focus or, more pressingly,
to the extreme
accountability that it fosters (there’s no slacking off, or hiding a lack
of ability, in an XP office). They soon flee for more traditional
software companies, where they can hide shortcomings behind
bluster, or default to highly visible busyness as an alternative to
actually doing the hard but satisfying
work of creating valuable
output with their brains.
—
The core of the specialization principle is the idea that less can be
more. If you design workflows that allow knowledge workers to
spend most of their time focusing without distraction on the
activities for which they’re trained, you’ll produce much more total
value than if you instead require these same workers to diffuse their
attention among many different activities. This latter course is often
the more convenient
option in the moment, but rarely the most
productive in the long term. Extreme programming underscores the
possibility of rejecting this status quo and going all in on
specialization.
I imagine that XP development teams must be a pain to deal
with in the context of the larger companies that employ them, but it’s
hard to care about such inconveniences when you see the awe-
inspiring pace at which they produce amazing results. “An
XP team
of eight to ten can do the work of a non-agile team of forty to fifty,”
Woodward told me. “I’ve seen it over and over again.” These are the
productivity boosts at stake in any number of knowledge work fields
currently suffering from a severe diminishment of specialization. The
remainder of this chapter explores strategies for reaping the benefits
of an XP-style specialization.
Do'stlaringiz bilan baham: