Ode to XP

Part 3 — Reborn for the Future

Photo by Bill Jelen on Unsplash

“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 still near and dear to my heart. And it turns out I’m not alone. In 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.

“Extreme Programming Explained (2nd Edition),” as I explained in Part 1 of this series, was a career-altering book for me. It was the first exposure I had to a simple but powerful idea: by making the software development process more humane, humans would develop software more effectively. The human-centric/team-centric approaches XP espoused made logical sense as I read through the chapters on Values, Principles, and Practices, though I was still somewhat skeptical about the approach. Nevertheless, as an early-career engineer who had already faced several challenging projects, it was exciting to read that software development was evolving, rapidly, to be more effective and more enjoyable.

It wasn’t until years later, as I captured in Part 2 of this series, that scientific analysis confirmed many XP practices do have a measurable positive impact on software development organization (SDO) performance. Before that scientific backing was available, I elected to experiment, over many years, to find practices that truly did improve software delivery outcomes. As I explored, I found many of the XP practices created stronger, more effective software teams. I also found some non-XP practices that had the same effect. Which raised another question, why? What about these practices made them effective? What underlying commonalities made the XP and non-XP practices well-suited to use together? That seemingly simple yet uniquely complex question drove me to read enough books, on motivation, on communication, on leadership, on automation, on testing, on trust, on agility, on solution selling, on listening, on behavioral economics, to fill a small library.

What I learned is Extreme Programming’s approach, extracting practices from principles, and principles from values is much more important than the XP practices themselves. For example, consider the XP practice of Continuous Integration. CI is an essential part of modern software development, and the foundation for Continuous Delivery (which is the centerpiece of the course I teach at UML). But the XP practice of Continuous Integration is less important than the XP principle of Improvement or the XP value of Feedback that the practice stems from. Why? Because a team that does not truly value feedback, a team that doesn’t embrace the principle of (continuous) improvement will never fully benefit from practicing CI. The teams that don’t also believe in the values and principles behind the practices are more likely to deviate from the practices. These are the teams that choose to work around their CI/CD pipelines as opposed to improving them when the pipelines don’t perform as well as they could. These are the same teams that avoid integrating security testing in their pipelines, saving security testing for the end of a release cycle. Teams that truly understand the importance of Improvement and truly value Feedback execute the CI practice differently, and more effectively.

In the short-term, failure to embrace the values and principles that practices are derived from leads to poorly executed practices. Likewise, in the longer-term, failure to revise the values and principles themselves will result in a set of practices that haven’t evolved. It follows that periodically refreshing the values and principles, as well as expanding the set of proven practices, is important, as doing so prevents development teams from becoming stagnant.

While I love XP, two decades of research and experimentation have taken place since it was first conceived. In the spirit of continuous improvement, it’s time to evolve XP’s values and principles to provide a new foundation for the software development practices best suited for the 2020s and beyond. The goal isn’t to replace XP practices but to supplement them with practices inspired by the learning that’s occurred since XP’s inception.

Values

Developers are more productive when their software delivery practices stem from a set of shared values that empower individuals and optimize the team. As the “State of DevOps 2019” highlights, an “organizational culture that optimizes for information flow, trust, innovation, and risk-sharing is predictive of [software development organization] performance.” Before discussing additional practices that may further boost SDO effectiveness, it makes sense to revisit the values from which XP practices were derived. The link between the XP values and the values outlined in this section is their common attempt to bring more humanity to software delivery. There are even a few shared values between this revised set of the XP originals. What’s different about the updated set of values outlined in this section is that they’ve been shown, since XP was first created, to boost individual performance, and more importantly, team cohesion and productivity.

The first set of values are focused on supporting energized, self-motivated individuals. These come directly from “Drive,” by Daniel Pink, and help establish the working environment for each team member. The goal of these values is to ensure each team member is inherently motivated to thrive.

• Purpose — Purpose (or Meaning) allows team members to feel a connection to what they’re working on and who they’re working with. Connecting an individual’s purpose and an organization’s purpose allows individuals to form deeper connections with their work than they would otherwise.
• Autonomy — Autonomy (or Empowerment) allows team members to have a voice in who they work with, what they work on, and where/how they operate. Autonomous teams are required for scale, and scale is required for the most impactful outcomes.
• Growth — Growth (or Mastery) allows an individual to be both challenged and supported. Individuals who can invest in and see their growth in a meaningful way are more likely to continue to want to grow and more likely to help those around them grow in return.

With that motivating foundation for the individual in place, the next set of values focuses on connecting individuals in a way that allows them to operate at peek collective potential as a team. There are two additional values that help a team operate effectively. In teams where these two values are present, firmly embraced, and intentionally cultivated, I’ve seen amazing outcomes produced by surprisingly nimble and efficient teams.

• Trust — Trust, according to the Trust Equation, is really the result of several elements. When we advocate Trust as a value, we’re implying we value all of these qualities.

The Trust Equation

• Credibility — Will you do your part, based on your previous track record?
• Reliability — Will you be dependable, able to hit your commitments week-to-week?
• Intimacy — Will you keep my (and our client’s) confidential information protected when we work together?
• Self-Orientation — A negative trait that we want to minimize (i.e. we value low self-orientation). Are you focused on “you” or “us”? Will you consider impacts to “us” when making a decision?
• Communication — Optimizing for information flow requires optimizing for strong written and verbal communication, just as XP advocated. And since the most valuable communication is bi-directional, listening (deep listening) must also be valued as well. When trust is in place, communication becomes easier. Trust erases the fear of how a viewpoint might be perceived and allows everyone to contribute ideas freely and openly (even if they don’t land the way the person contributing them had hoped). Being comfortable enough with your team to say, “This idea just popped into my head; I’m not sure if it makes sense, but I’d like to share it to get your take” is an example of how trust and communication work together. When trust and communication are firmly in place, a team can share and explore a seemingly crazy idea and evolve it, together, into something remarkable.

With a strong foundation for the individual and the team, we have an excellent start on values. The one missing ingredient is an accelerant that’s often required to help individuals and teams learn and grow more quickly than they would without it.

• Feedback — For Feedback to be the most useful, many of the values above (Trust, Communication, Growth) must be already be established. Feedback helps enhance the values listed above, when delivered effectively, and is the other XP holdover. Teams that truly value feedback, on their work, on their professional development, on their communication, on their leadership, find ways to incorporate it everywhere. This is the difference between embracing a value and carrying out a practice. Values can drive practices everywhere, not just practices related to software development.

With individuals and teams who truly believe in the benefits of the embracing the values above, an organization is well-positioned to deliver software in a modern, scaled fashion with increased efficiency and effectiveness.

Principles

Principles are the first step away from the general-purpose values toward a set of ideals that will guide a technology team. The context the principles provide, aligned with the values in the last section, support the practices in the next section. Principles were depicted in XP as the “bridge” between the general-purpose values and the software-specific practices. Each value can yield one or more principles, from which practices can then be derived. Values are applicable inside and outside of work, principles are the ideals that focus the values on effective software development.

Many of these principles are embraced by many of the most effective people I know. These are people who are easy to collaborate with, enjoyable to work with, and motivating to work for. They compel you to be your best because of how they operate, share, support, and coach. As in the last section, this set of principles includes carryovers from XP, along with some new ones. These principles establish the foundation for a highly effective environment that elevates team behavior and performance.

Purpose Driven Principles

• Self-Awareness and Self-Reflection — Finding purpose in your work (and your life) requires sufficient self-awareness to know what will resonate with you (i.e. forward looking) and sufficient self-reflection to assess what has resonated with you (i.e. backward looking).

Autonomy Driven Principles

• Self-Direction — Allowing an individual or a team discretion on how they accomplish a task is important to establishing autonomy. Equally important is to consider individual’s or team’s input on what they are asked to accomplish. A self-reflective and self-aware team, for example, is best positioned to provide input on where their time will be most productively spent.
• Outcome-Based Thinking — Self-direction without supporting goals or measures often results in an output but not an outcome. An output is what’s produced. An outcome is whether what’s produced results in the value intended. Holding individuals and people accountable for outcomes, and then letting them decide how to achieve them, provides the right balance between autonomy (in execution) and trust (that what’s delivered will produce the desired result).

Growth Driven Principles

• Continuous Improvement — This is a very wide-ranging principle that can be applied to people, teams, and organizations. At its core, it’s a recognition that the Deming Cycle (Plan, Do, Check, Act) can be applied to almost any endeavor. As Kent Beck wrote, “In software development, ‘perfect’ is a verb, not an adjective.”

Trust Driven Principles

• Skin in the Game — Skin in the Game means that two parties have enough collectively at stake to understand they will either succeed together or fail together. It’s also similar to the original XP principle of Mutual Benefit. Having Skin in the Game (SITG) inherently increases trust between two parties because it decreases the denominator in the trust equation: Self-Orientation (see graphic in previous section). SITG, by definition, shifts the dynamic from “you/me” to “us,” which leads to a stronger level of trust and eliminates the potential for a self-oriented outcome where one side wins at the other side’s expense.
• Humility and Curiosity — While SITG addresses the denominator of the trust equation, Humility and Curiosity can affect the numerator. Being humble and forthright about your own limitations helps those around you support you more effectively. This can build trust by deepening credibility and intimacy among team members. Being curious about things that are new and being fearless in exploring them can also build trust by expanding credibility (what you know) and reliability (what you can do).
• Psychological Safety — When a team values trust, an environment of psychological safety is made possible. Psychological safety has been demonstrated to be the secret ingredient in many high-performing teams, even those without the most experienced or knowledgeable team members. Trust is essential among team members and an environment that provides psychological safety supports the team in their efforts to explore new ideas and ways to continuously improve.

Communication Driven Principles

• Transparency and Visibility — Transparency means providing a no-BS assessment of a situation. Visibility means allowing others to watch and track that assessment over time at a frequency of their choosing (hi, autonomy). Together, transparency and visibility enable more meaningful communication by focusing on the reality of “what is” not “what we wish it was.”

Feedback Driven Principles

• Courage and Resilience — Asking for feedback is tough, especially when it’s feedback on a topic or subject that you know isn’t your strongest. Giving feedback can also be tough, especially when it’s corrective. Having the courage to take part in the feedback process, as the giver or receiver, builds resilience. Building resilience over time, whether it’s in people or systems, is crucial to long-lived operations. Those who choose “courage over comfort” are the ones who will grow the most, since they will likely ask for feedback most frequently and accept and act on that feedback knowing it will make them, and those around them, stronger.

Practices

Practices are the day-to-day activities that stem from the ideals outlined by the principles. The refreshed set of values and principles we’ve outlined so far still fully support the practices outlined by XP, State of DevOps 2019 and “Accelerate.” These existing practices are well-understood and proven, but they also shouldn’t be static. To supplement the proven practices, this section explores complementary practices that are derived from our updated set of values and principles.

What makes the set of value and principles we’ve defined useful is that they can be used to assess additional practices to find those that have the potential to make an impact on software delivery organization performance. From my own experiences, I believe these additional practices are worth adopting. Not only do they fully align with the values and principles we’ve covered, giving them a high potential to make a positive impact on software delivery performance, but I’ve seen them work first-hand on many large, complex projects.

Peer Code Reviews

This practice is highlighted in the State of DevOps 2019 report but is grouped under the broader practice of “Clear Change Process.” From the report, “organizations should ‘shift left’ to peer review-based approval during the development process.” While the report expressed a preference for peer code reviews over external approval processes (i.e. a Change Approval Board), there are other benefits that tie directly back to our guiding principles. Peer code reviews support the Continuous Improvement of the author of the code, who will benefit from detailed, real-time feedback. Peer code reviews allow other team members, those with Skin in the Game, to have a voice in how code is written, which will likely become code they need to integrate with, expand on, or learn from. Peer code reviews also enable Transparency and Visibility (of the code) while encouraging Courage and Resilience (in proactively seeking and receiving feedback).

SBI+ Feedback

Feedback outside of source code is also important for personal and professional growth. Situation Behavior Impact Plus (SBI+) is a framework I’ve learned and applied at Slalom for providing feedback in a way that resonates with the recipient. For complimentary feedback, SBI+ reverts to plain old SBI. For corrective feedback, the “Plus” in SBI+ expands to Inquiry, Request, and Agreement.

• The Inquiry step gets to the feedback recipient’s intentions so that person has an opportunity to provide more context (the feedback provider plays the Humble and Curious role).
• The Request step is where the feedback provider, now with the insights shared during Inquiry, asks for a change in behavior.
• Agreement closes the conversation and establishes a commitment on what will change and how that change will be tracked over time.

What makes this practice effective is that it bridges Continuous Improvement (providing feedback) and Humility and Curiosity (inquiring for more info before making a request) and Courage and Resilience (these conversations can be tough, but they’re worth it).

Project Opt-Out

Another practice I’ve been impressed with at Slalom is the flexibility provided to employees to opt-out of work with a client whose values or vision they disagree with. Allowing some level of control over what we work on speaks to the surprising level of autonomy we’re afforded, especially given that Slalom is a professional services company. We do work with a wide range of clients, so it’s not surprising there are, at times, potential engagements that would leave an employee lacking the purpose they need to be at their best. Outcome-Based Thinking is the principle that helps understand why this approach works. If we demand an employee do work for an organization they have strong reservations about supporting, we put the ideal outcome (an exceptional solution for a very happy client) in jeopardy. By staying focused on the outcome we’re after, allowing an employee to opt-out of a project because of personal reservations becomes an easy decision.

Personalized People Management

Related to the Project Opt-Out practice, each employee at Slalom is assigned a People Manager responsible for helping the employee develop and grow. These discussions cover career aspirations and goals, career development and planning, performance feedback, and oftentimes topics that take the discussion outside of work. We trust our employees’ self-awareness and self-direction, but provide intentional support to help accelerate their growth. By fostering an environment where Trust can thrive, difficult conversations (SBI+ Feedback, Project Opt-Out conversations) are much more likely to happen. This practice benefits everyone, and it’s one that I truly enjoy.

Blameless and Actionable Retrospectives

Team and project retrospectives are invaluable to the growth of a team and an organization. Avoiding a “ventfest” or a “blamefest” in favor of an outcome-based meeting is important. Leaving with an actionable set of steps to address the challenges captured by the team is a goal well-worth the time invested. The speed with which a team can execute those steps speaks to the team’s self-direction, resilience, and desire to develop to their collective best together. In my experience, a self-directed, resilient team is one that will be long-lived.

There are many other practices that can be extracted from the new set of principles and values captured in this piece. Maybe someday I’ll have time to write a book to capture more of them. In the meantime, I hope this refreshed set of values and principles inspires you to dream up new practices, allows you to better assess practices you’ve seen work well, and helps to explain why so many of the XP practices really work. The most effective practices likely share a common foundation: one where purpose, mastery, autonomy, trust, communication, and feedback are key pillars.