James Shore

in 99 words

XP teams are self-organizing and cross-functional. This has two important consequences: first, they're responsible for their own success. This means teams define success (by interviewing stakeholders and sponsors), create plans to achieve success, and execute on those plans without explicit management direction.

Second, XP teams include all the expertise necessary to do so.

In practice, XP teams are composed of business experts ("customers"), implementation experts ("programmers"), and quality experts ("testers"). The whole team works together to create its own plans and deliver successful software. No single person is "in charge." Instead, leadership shifts fluidly with the situation.

as haiku

The soil is dry--
the irrigator has gone
I start to water

Inside This Section

• The XP Team
• The Whole Team
• On-Site Customers
  • Sidebar: Why So Many Customers?
  • The product manager (aka product owner)
  • Domain experts (aka subject matter experts)
  • Interaction designers
  • Business analysts
• Programmers
  • Designers and architects
  • Technical specialists
• Testers
  • Sidebar: Why So Few Testers?
• Coaches
  • The programmer-coach
  • The project manager
• Other Team Members
• The Project Community
  • Stakeholders
  • The executive sponsor
• Sidebar: XP Practices by Role
• Filling Roles
• Team Size
• Full-Time Team Members

Commentary

I replaced the windows in my house last year. My wife and I bought a 1939 home that needed some work. It's livable, except for one problem: the windows were coated with lead paint, and we had a newborn baby girl. Plus, they leaked cold air like a sieve. So we had to replace the windows. We knew that when we bought the place.

Windows are a big purchase. The windows we replaced had been there for nearly seventy years. I hope the ones we put in last at least as long. They're also quite expensive. So naturally, I put a lot of effort into finding a good vendor. I was looking for two things: a good price, and quality work. If I had to choose just one, given how long we expect to stay in this house, I would have chosen quality over price.

I certainly wouldn't have shopped around for the cheapest possible price I could find. Sure, I could have gotten different windows for several thousand dollars cheaper... but they would have looked it. The ones we got have nice sculptured grids (to mimic the look of the originals), smooth action, and come apart for easy cleaning. If we had cut corners, I would have noticed (and regretted it) for the next twenty years.

When you're buying something expensive and valuable that's meant to last a long time, you put real effort into it. So why is that so many companies treat software development like buying disposable tupperware? Why do they look for every opportunity to minimize cost? Sure, you can do that, but TANSTAAFL. There ain't no such thing as a free lunch. Cheap software development leads to cheap software. It's buggy, it doesn't do what you want, and it's expensive to maintain.

I particularly see this attitude when it comes to staffing teams with business experts. Sometimes the problem is with programmers--they focus on saving pennies, while sacrificing dollars. "Our business experts have better things to do," they say, not realizing that they're putting a multimillion dollar investment at risk. Other times, it's the business experts who hide, finding ways to make themselves unavailable.

It's so bad that I sometimes wonder if XP's demand for on-site customers is its achilles heel. And then I remember that you can use XP without on-site customers, just as you can use other forms of software development without involving users or business experts. You're just less likely to succeed... in either case.

When I look back at the teams I've worked with, the teams that took software seriously--the ones that saw custom software as a strategic asset, not something to cost-cut into oblivion--had no problems putting good, competent people in the customer role. They brought in high quality people, people who knew their stuff backwards and forwards, and those people had their hands full figuring out how to make the software shine. It wasn't always easy--one company flew one of their domain experts in from London on a regular basis--but they knew that good results require good investment.

Keep an eye on those companies. Software runs everything. They're the ones that will succeed.