Three Reasons Why Organizations Adopting Agile Say No to XP

If you talk to the best Agile developers, listen to what Gartner has to say, or consider what SAFe and LeSS, the leading Agile scaling frameworks recommend, you will learn that they all agree on one essential point: eXtreme Programming (XP) is necessary for Agile software development team success. So why is it that most organizations adopting Agile don’t adopt XP? NO_suitFor example, in VersionOne’s 9th Annual State of Agile survey, Scrum is the runaway lead in Agile practices in use among those surveyed (56%) whereas XP comes in dead last with less than 1% of survey participants using it. What makes this even more perplexing is that the co-creators of Scrum, Jeff Sutherland and Ken Schwaber, independently and repeatedly insist that you will not achieve the high performing development teams promised by Scrum on development teams if you don’t also use XP.

So why it is that organizations who choose Scrum don’t also choose XP? Here are three key reasons.

Three Reasons Why Organizations Say No to XP

1. The IT industry is project management-centric.

For most of our brief industry history, IT software investments have been funded as discrete projects. Executive sponsors have traditionally viewed project performance through the eyes of their project managers and believed the key to project success is good project management. It should then come as no surprise that, when executive sponsors decide to invest in Agile, they see Agile solutions in project management terms and often commission former project managers to lead the Agile adoption program. This helps explain why Scrum, an Agile project management framework, is the predominant (if not exclusive) feature of many Agile initiatives. Seeing Agile through the lens of project management makes it more difficult for buyers to think in anything but project management terms.

2. Software development competency has got no respect.

Software development as a competency has the weakest of underpinnings. Degree programs in engineering schools focus on computer science, while in business schools they focus on business analysis and (unsurprisingly) project management. For the most part, schools ignore the craft of developing software. There isn’t even basic agreement on what the craft of software development is. Most often software development “skill” is characterized in terms of technical knowledge about platforms and languages. Only in the last decade has it begun to catch on that software development is more about design than construction. The project orientation discussed above makes matter worse. Software development has traditionally been seen in terms of transient project costs rather than as a profession to invest in and to develop as a core competency.

What all this means is that when organizations throw their Agile adoption parties, those that represent the professional interests of software developers are not always invited. And if they are invited, they rarely have the influence of more powerful stakeholders. XP is an investment in software development competency. However if you don’t recognize software as an important competency, why would you choose to invest in it?

3. XP is hard to grasp and seems counter-intuitive.

It’s always been hard for non-developers to grasp what software developers are doing. When it comes to XP, even developers have a hard time grasping the significance of XP practices. Two examples:

  1. “So you’re telling me that if two people perform the same task together such as writing a single line of code, that is more efficient than if they each wrote a line of code separately? Yeah, right.”
  2. “I’m supposed to test the code BEFORE I write it. How does that make sense?”

To make things even more obscure, XP practices are parts of a software development system for doing work as a team—not as individuals. How XP adds value is not well understood by sponsors and therefore from the sponsor’s point of view, XP seems an awful lot like previous IT investments that they did not understand and that resulted, as far as they could ever make out, in a waste of time and money.

So What Does It Mean?

These three reasons together form a formidable resistance to investment in XP. This tendency to not do XP is especially pronounced in organizations that are doing Agile, frankly, mostly because everybody else is. In these cases, sponsors may simply want to check the Agile box off without expecting much to change as a result. If you don’t expect substantial and specific business performance improvements, you should limit your investment in XP and for that matter all aspects of Agile—because if you don’t expect performance improvements, you ain’t gonna get any.

Like a sandwich with too much peanut butter and not enough jelly, a disproportionate investment in Scrum over XP ultimately is going to make Agile hard to swallow for the developers in your organization. Of course, this problem won’t last forever. When software developers finally get a chance to digest what it truly means to do Agile development using XP, they won’t settle for anything less and won’t work where it’s not supported. At that point, developers will have their sponsor’s attention, perhaps for the first time.