Generally speaking, it's a safe bet that most would welcome being called “lean” or “agile.” It would be harder to argue that most people, by definition, would willingly enjoy being called extreme. When it comes to extreme programming (or XP), however, there are more than a few adherents.
Since agile came on the scene in 2001, other agile-flavored ideologies have surfaced: kanban and scrum chief among them. XP is, well, the more extreme child of the bunch.
Taking a deeper look into some real-life examples, including a case study from one company and an analysis from another industry pro, one thing is clear: it would be a miscategorization to call XP the bad-boy brand of software development. Its success, much like the other Agile-based methodologies that have sprung up in the last 15 years, relies on the foundations of Agile—which belie the fast-moving, furiously programming layers above it.
Like its agile siblings, proponents of XP say it improves the software-development process through collaboration between teams. XP focuses on small projects and, like its siblings, adopts the practice of daily standup meetings to ensure everyone is moving toward the same goal. Other overlapping elements include several short development cycles (iterations), where each iteration ends with a testable, workable version of the software. XP also adopts the test-and-deliver method. Broadly, these methods are meant to ensure the product isn't simply presented to a client at the end of the whole project, waterfall style. Furthermore, steering away from the specialized worker-bee approach ensures all members of a team have a holistic picture of the project, regardless of each person's tasks from one day to the next.
It may not sound exhilarating yet, but Sarah Wood, writing in a piece for LinkedIn Pulse, describes XP in the appropriately fast-paced way it applied at Unruly, a startup that adopted XP. The early adoption was due in large part to the company's CTO, Matt Cooke, who Wood says was a pioneer of the methodology as early as 2000.
"[XP] turns up the dials on good discipline and allows us to move fast in small, safe steps. Developers code in pairs, follow a rapid two- to three-week planning cycle, and practice continuous delivery, releasing new features several times a day so we quickly learn what does and doesn't work."
The thrust of Wood's article, in fact, is how XP gave her startup the all-important X factor. Ultimately, the success of XP at Unruly was in the way the company embraced XP principles across the company: from marketing, to design, to HR.
Another Pulse author and web developer, Jim Lynch, gives XP the edge in terms of team success. Among them: teams toe the line between not planning and over-documenting, over-whiteboarding—ultimately planning more than programming a working product. They release in increments, espouse pair programming, and ensure all players on the team share ownership of the code, all key tenets of agile philosophy.
But one of the most interesting of Lynch's observations was the idea that XP teams truly embrace change:
"...in the top XP teams, I’ve seen meetings where someone reads aloud an email from an actual teenager playing the game they were making. The lead programmer says, 'Oh my god. That’s a great idea,' and the the other senior programmer says, 'Yeah, we could put this other feature on hold and put that in before the end of this sprint.' The lead programmer responds, 'I like your thinking. Let’s you and I set up the infrastructure for it before lunch.' Then they high five each other and excitedly start talking about what design patterns they should use. It’s clear to see how the top XP teams can harness change to their advantage while others dread and fear it."
Not all feedback-email scenarios end up this positively or this productively, of course. But upping the ante on change, while resting on the fundamentals of Agile, appears to be the X factor of XP.
Agile practices have seen tremendous growth in recent years, especially among enterprises. But for many organizations that have seen success embracing agile practices, these early advances have only begged the question: How do we scale this success to our entire organization? This white paper explores exactly that.
