XP Explained

This week we continue with the building blocks of Extreme Programming by tackling chapters four and five in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters four and five provide a deep dive into values and principles.  Why, when we talk about frameworks or methodologies, do we spend so much time on values and principles?  Simply put, values and principles provide a rationale for the practices that are the nuts and bolts of a methodology. Without an understanding of why we do something, it will be difficult to hold on to a practice or to understand when and why to tweak a practice when things get tough.
Chapter 4: Values

Values represent a judgment of what is important. What we think is important directly impacts how we behave. XP’s values guide practitioners actions and to reduce waste through the coordination of activity. Beck points out that the difference between what is perceived as being valuable and what really is valuable  creates waste. The five values of XP are designed to focus thought and effort on what’s important to the team.  The five values of XP are:

  1. Communication

Communication is important for creating a sense of team and effective cooperation.  Communication also spreads knowledge, which keeps everyone on the same path and improves the team’s capability to deliver value. Communication is the most important of the five values.

  1. Simplicity

What is the simplest thing that could possibly work? A focus on simplicity allows a team to deliver quickly and get feedback so they can stay on track and build trust.  Simplicity exists in context; what is simple in one situation is not simple in another.  Knowledge and communication help define what is simple.

  1. Feedback

In business, software development or a family road trip, absolutes that define direction, requirements or architecture remain don’t valid for long. Change is inevitable. Without feedback, any project or effort will go off track. Beck suggests that teams use feedback to get closer to our goals rather than expecting instant perfection. Simplicity makes it easier to get feedback.

  1. Courage

Courage is taking effective action in the face of fear. Software development is an activity that is intrinsically scary.  Every time a developer, tester or business analysts begins work, they are pitting their wits against a problem that stretches their capabilities.  Without courage, it is hard to push the limits and tackle problems that we might not be able to surmount.  Lack of courage causes paralysis; however, blind courage yields recklessness.  Courage needs to be balanced with other values, such as feedback and communication, to provide balance.

  1. Respect

Software development and XP are team sports. Team members must care about each other and what they’re doing or XP won’t work. Respect reflects a judgment of value on a team no one is intrinsically worth more than any other team member regardless of the roles that are played.

All five of the values in XP are interrelated and provide reinforcement.   Beck points out that teams and organizations can choose other values or even add to the set. However, values need to be held across the team or organization.  Maintaining multiple sets of values simultaneously will cause conflict and waste.  Values provide the direction that helps teams and organizations coordinate their activities and achieve more than a bunch of individuals.


Chapter 5: Principles

Values, like high-level goals, are abstract.   They provide general guidance but are too abstract to guide behavior directly.  Principles act as a bridge between tactical behavior and the high-level vision of behavior built into values.  XP includes 14 principles:

  1. Humanity

Software development is a people-based activity.  Beck states that processes and practices of software development need to “address human needs, acknowledge human frailty, and leverage human strengths.”  Humanity also requires finding the balance between the needs of individuals and needs of the team (sounds like something from Star Trek).

  1. Economics

Software development and maintenance must have value, meet business goals and needs or no one will pay for it.

  1. Mutual benefit

Every activity should benefit all concerned, i.e. win-win solutions both in the future and now.

  1. Self-similarity

Patterns are a tool that humans have always used for efficiency and safety.  Most cognitive biases (shortcuts) are a reflection of the principle of self-similarity.  We find a shape or pattern that works and then use it as a place to start.  Software development is no different.

  1. Improvement

Perfect is a verb not an adjective. Beck suggests, “Find a starting place, get started, and improve from there.” Retrospectives are an improvement opportunity.

  1. Diversity

Teams rarely are effective if they have a homogenous set of skills, attitudes, and perspectives.  Teams with a diversity of capabilities are able see the problems and pitfalls required to solve and to implement solutions. Teams need people with a variety of skills and perspectives to reach maximum effectiveness.

  1. Reflection

Excellence requires that teams not only execute, but think about how work is done and why they are working. Reflection can be done at any time and include both reviewing data as well as thinking.

  1. Flow

Deliver a steady flow of valuable software.  Problems are more effectively solved incrementally versus a big bang approach.  I have always suggested that if a team is having trouble meeting its goals that they take smaller bites (shorten the increment they are using and move closer to a continuous flow of delivery).

  1. Opportunity

To reach excellence, problems need to be turned into opportunities for learning and improvement.  Problems are often addressed as survival events, which rarely translate into increased capabilities.  Think of turning lemons into lemonade.

  1. Redundancy

The critical, difficult problems and software development should be solved in several different ways. Said differently, create scenarios where you can test your options and choose the best one.

  1. Failure

Experiment and learn so that you can get the data needed to decide which option will better provide a path for success.  Failure provides value it if it imparts knowledge (assuming we failed because we did not know better).

  1. Quality

One of the things I learned from working with Capers Jones was that quality saves time, money and builds trust.  Focusing on quality does not mean a team should not try new things, fail sometimes, learn, and get better.

  1. Baby steps

Incremental delivery of value generates feedback, is less dangerous and creates momentum. From a practical point of view, baby steps reduce the amount of overhead required to make any change.

  1. Accept responsibility

Responsibility can only be accepted, not assigned. When responsibility and authority are not aligned people often act in a passive aggressive manner.  The classic example is the activity of estimating. If the people doing the work are assigned an estimate they are far less likely to act as if they own the estimate.

The principles provide a framework to understand the practices that are introduced in Chapter 6.  Understanding values and principles allow the practitioners of XP to understand how they can apply and tailor the practices to meet their specific contexts.


Previously on Re-read Saturday: Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3