Ode to XP
Part 1 — Revisiting the Values, Principles and Practices
“Extreme Programming Explained,” the seminal book on Extreme Programming (XP) written by Kent Beck, was released in 1999. XP was the basis for the first agile development process I ever worked with; as a result, it’s is still near and dear to my heart. And it turns out I’m not alone. In just the last few weeks, I’ve had conversations with several Slalom Builders about XP and the guidance it provided to early agile adopters who were seeking both a better software development process and, more importantly, a way to love their work and their life. Given the recent reminder of how foundational XP has become, and to celebrate the 20th anniversary of “Extreme Programming Explained,” I’ve written a multipart series on XP.
Part 1 of the series revisits the values, principles and practices outlined in “Extreme Programming Explained (2nd Edition)” to highlight the core ideas that have spurred a decades-long software development revolution. Part 2 of the series examines the software development challenges that many organizations still face and how XP’s guidance and vision, two decades later, is still applicable and relevant to solving their challenges. Part 3 of the series reflects on XP and outlines an updated set of values, principles and practices for the decades ahead.
Based on the company letterhead above my handwritten notes, I likely read “Extreme Programming Explained (2nd Edition)” for the first time within my first five years of professional software development. At the time, I was searching for a quick fix. Though I was early in my career, I had seen the same delivery challenges on a number of waterfall projects and was looking for an alternative. Common symptoms included: upfront planning that was cumbersome and almost immediately in need of revisions; the develop phase slipping right, eating into the testing phase; a death march toward a due date, with a toll on team morale and product quality; too many defects discovered too late, and a “patch” release being planned almost immediately after we “hit” our deadline. What I found in XP was a simple set of practices to support our team’s journey to greater agility, higher quality, and more sustainable delivery.
I bring up that bit of personal history with XP because, in my haste to find delivery answers, I missed the most important aspects of the book the first time through. I didn’t capture any of the values or the principles outlined in “Extreme Programming Explained (2nd Edition),” just the practices. The practices were extremely helpful to those, like me, who needed to quickly move a large team from a waterfall mentality to an agile mentality. And for those of us who paid close attention, the XP practices foreshadowed new techniques that emerged over the subsequent two decades. While the practices were important to development teams adopting agile, they’re also the most malleable and the shortest-lived element of XP. Practices are meant to evolve as new ideas, new technologies, team experimentation, and team reflection occur. It’s the XP principles and values that promote the behaviors that allow the practices to change and empower teams to change them.
What set XP apart at the time, and why it’s worth revisiting after two decades, was its attempt to bring the personal and the technical into better alignment. The incongruence between waterfall and humanity’s intrinsic drive to collaborate, experiment, and learn caused a great deal of anguish for development teams. XP attempted to bring people together, to structure their work in such a way that allowed them to be more communicative, more collaborative, more connected, and more productive. By more closely connecting the human with the technological, high-trust can be established and high-performance will usually result. It’s a worthy aspiration, an aspiration that XP pioneered for the software development world, and a foundation that can be extended well outside of software development.
XP Values
A missing element in my notetaking, and one of the three key aspects of XP, is values. In Kent Beck’s words: “Values are the large-scale criteria we use to judge what we see, think, and do. Making values explicit is important because without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction.”
I would rephrase this more simply to say the XP values are the “why” behind the XP principles and practices.
While these values were absolutely shared among the great people I worked with early in my career, they were not reflected in our software development processes. That disconnect between the values of the people and the values of the process caused substantial discord at times. It wasn’t until years later that I realized why our code reviews, for example, were so contentious. The process we followed required code reviews to occur prior to testing. Because our months-long development increments were followed by weeks-long testing increments, and because those months-long development increments were almost always underestimated, reviews covered very large chunks of code and were conducted much later in the development cycle than they should have been. The push to “get through” the code reviews so that testing could start undermined the real purpose; to gain and act on feedback. Communication was tense; any rework would further delay an already-lagging development increment. Simplicity was lacking; each person would bring pages and pages of source code to markup. Feedback wasn’t truly the purpose of the exercise; the purpose was to get through a required gate for testing to begin.
The code review vignette exemplifies the values gap that existed between people and process prior to XP. People prefer immediate feedback, provided in manageable chunks, so they can react. That preference was at odds with the gate-heavy waterfall process we were following. The disconnect between personal values and process values seems obvious now, but at the time there wasn’t a widely accepted alternative for development teams to follow. XP incorporated personal values into the development process, and did so with such clarity and simplicity that it provided me with the courage to try something new.
XP Principles
Another missing element in my original note taking, and the second of the three key aspects of XP, were the XP principles. Kent Beck explains that, “Bridging the gap between values and practices are principles. Principles are domain-specific guidelines for life.”
The principles that drive XP provide a software development-focused rationale for the practices and link those practices back to values. If values are the “why,” principles are the “how.”
For example, “how” might you demonstrate that feedback is truly valued? By working in baby steps, teams optimize for faster and more feedback. By viewing failure as an opportunity to gain knowledge, teams embrace trial, error, and reflection (i.e. a full feedback cycle). By taking the knowledge gained from feedback to make improvements, teams receive mutual benefit by accepting responsibility to explore something new. Applied to the code review scenario I outlined in the previous section, the XP principles make it obvious that both our software development process and our code review process were lacking a connection back to XP values.
The XP principles also provide an assessment framework for new principles that a team may experiment with and eventually choose to adopt. For example, reflection and improvement are, by definition, the purpose of a sprint retrospective. Though “Weekly Cycle Retrospectives” is not an XP practice, it’s clearly a practice that builds on XP principles and, as a result, ties back to XP values. When we first adopted XP, we supplemented the XP practices with sprint and release retrospectives since we, as a team, valued feedback and wanted to promote an environment where courage and respect would allow that feedback to be meaningful. This new approach is just one example of how a set of principles, tied to shared values, can be used to examine existing practices and experiment with new practices.
XP Practices
What I focused on heavily in my notetaking were the XP practices, both primary and corollary, and how they could be adopted to rapidly transform a waterfall team into an agile team. At the time, I needed a recipe to increase delivery success, and XP’s practices provided that initial productivity boost. My focus exclusively on practices was short-sighted. What I’ve learned since that time is that practices must stem from a set of core principles; without agreed upon principles, it’s difficult to assess the viability of practices. Likewise, principles must stem from a set of core values; without agreed upon values, it’s difficult to identify the principles and practices a team will find palatable.
XP’s primary practices were notable because they were so well-aligned with a set of principles and values.
As you’ll see, XP’s corollary practices were also notable because they were ahead of their time. The technology available today to enable and support these practices make them more impactful while also lowering the bar to adoption. Consider the daily deployment practice. While daily deployment is now a popular metric for a team’s software delivery productivity, it was not the norm (far from it) at the time “Extreme Programming Explained” was published. However, since it flows naturally from the XP principles (baby steps, improvement, reflection, redundancy) its adoption quickly followed the advent of improved tooling to enable it.
XP Today
It’s amazing to me that twenty years have elapsed since “Extreme Programming Explained” was first published. The intent of XP, to make the software development processes more people-centric, was and still is a worthy goal. The XP values outlined in the 2nd edition of the book are important because they provided the basis for a software development process that reflects the values of the people and the organizations utilizing those processes. The XP principles outlined an approach for software development that was applicable to growing, managing, and successfully delivering with high-performing technology teams. The XP practices demonstrated how the XP values and XP principles could be translated into a simple set of activities teams could use to replace a popular, but misaligned, development approach, providing a clear vision for the future of technology organizations.
That alternative vision, 20 years later, has been realized by many organizations. For those who haven’t fully realized the XP vision, Part 2 of this series will show how XP values, XP principles and XP practices are still a great starting point.
