Extreme Programming Values

At Ford Labs we embrace Extreme Programming (XP) as the foundation for many of our ideas about how to do software engineering. Kent Beck describes XP in his book XP Explained as a progression of ideas: broad and abstract values that influence principles, that in turn influence concrete practices like pairing or test driven development.

At Ford Labs we like to talk a lot about the specific practices and how to do those well (and that’s good), but recently even Kent Beck himself has stated (33 min mark of the podcast) that he wishes we spent more time talking about the principles and values. Sometimes we get so hung up on the specifics of our practices that we lose sight of the ideas behind them. This carries a real danger of missing the forest for the trees- of not realizing that “there are no best practices, there are only good practices in context.” (Andrew Brown). It’s also common for new hires to learn practices without understanding the broader context behind them. To that end, I think that it’s important to know why we do what we do, and at the same time it’s also helpful to have a framework that allows us to test new (and old) ideas and think about what makes them effective (or not).

So, if we can revisit XP’s more abstract values and think about how they influence what we do today and what we want to try tomorrow, we can help make our XP teams more effective and have better conversations about experimenting with our process.

There are five of these XP values:

Communication: Communication is a hard and sometimes overlooked problem to be solved on a team. The quality and efficiency of communication amongst the team and with customers has a large impact on productivity. Generally speaking, in person communication is valued most.

Simplicity: Keep design simple and clean. You probably won’t need that complicated thing you just designed, so as best you can just design for today and keep an eye open for tomorrow (YAGNI). Try to find the simplest thing that could possibly work, and evolve as the requirements evolve.

Feedback: All forms of feedback are prized- personal feedback, feedback from tests, feedback from customers. Generally the faster the feedback loop, the better, because it keeps the team moving with the most up to date information. We want to increase both speed and quantity of feedback.

Courage: Tell the truth — about estimates, problems on the team, etc. Have the courage to throw old, unused code away, even if you loved that design. Listen to constructive feedback.

Respect: Respect all members of the team- engineers respect product side and expertise and vice versa. This foundation allows the team to work well together and to build on mutual trust. Management respects the team’s desire to have autonomy and responsibility and authority for the product they are delivering.

So how do these values apply to some of the practices we have at Ford Labs?

Standard workweek: We typically work a standard set of core hours at Ford Labs. Working a generally standard set of hours forces the team to learn time management and prioritize tradeoffs well. Additionally, particular individuals working a lot of overtime can create the “hero” problem, where one person takes on too much of the work and the context. This has a detrimental effect on the rest of the team. The best software engineers on an XP team are the ones who work to make themselves replaceable- they enable others on the team. We also recognize that we are human beings, bound by limitations of physicality. We value sustainability. The underlying values here are respect for one another as people, as well as courage when we need to say no.

Office standup: We usually kick off the day with a standup meeting for the whole office, in which we discuss if anyone needs any help with anything, or if anyone has anything interesting to share. It’s a great way to improve our communication across teams and share knowledge and expertise every morning.

Paired programming: Pairing is all about improving feedback and communication on the team. By writing code in pairs we can reduce the feedback loop of a standard code review (which doesn’t happen until the feature is nearing completion) and instead have engineers give feedback to one another at the conception of an idea. This has a powerful effect on the quality of the code. It also improves communication — onboarding is much more efficient, and spreading context about different parts of the code around the team happens naturally. For those interested in a deeper dive on the merits and tradeoffs of paired programming, read this.

Test driven development (TDD): Writing a test first, and then the minimum amount of production code required to make the test pass, is an exercise in ensuring simplicity. Only code that is required is written. Tests also give fast feedback on the health of the codebase after a refactor. Engineers can find out almost immediately if a change they made broke something else.

Continuous integration/delivery: CI/CD is all about fast feedback on the state of the code and on the product itself. If our tests pass and build is green, we have a shippable product. Continuous integration runs all of these tests and verifies our build and deploy every time we change the code. It’s important that we can ship frequently, because we need fast user feedback. Maybe we are building the thing right (with simplicity and tests and all) but how do we know we are building the right thing? How do we know users will use it, or pay for it? Usually we need to experiment to find out for sure. This is enabled by being able to quickly change the product (continuous delivery).

Retrospectives: A retrospective is a forum for team feedback — about, for example, the state of the product, the code, the interaction of the team or the process the team is using to develop. Holding regular retrospectives enables the team to take a moment to reflect on what’s working and what’s not working. Of course, this requires respect — all are treated as equals. It also requires courage to be honest and speak up about something that may be difficult to say or hard for others to hear.

Plus Deltas: A plus delta is basically a 5-minute retrospective with a small group of people (usually a pair of engineers at the end of a pairing session). It’s a forum for getting feedback from the person you’ve worked with all day on how the day went, both in terms of the work that was done as well as what it was like to pair with your partner interpersonally. I once zoned out on my pair for a while during the afternoon, and in our plus delta he respectfully asked me about it. Because of his courage in being honest I was able to understand how that impacted our work, and bringing it to my attention helped me grow at the human part of programming. Conversations like that help set a culture of personal openness to feedback and growth.

While the XP values inform the practices we typically use at FordLabs as shown above, they can also inform when not to use these practices- for example, we may not test drive every single thing we write, because some prototype-centric ideas are best sent directly to users for feedback (this pattern has been called Spike and Stabilize). It’s even more crucial, then, to know our values, so that we can make good decisions regarding the most appropriate process to use for a given product or feature.

Finally, we should consider the XP values to be a framework that guides us in improving and experimenting. If you have an idea for improving how the team works, you can consider if it would improve communication, make things simple, tighten a feedback loop, or drive respect or courage. When you try something new, do you have a way to get feedback and measure if a process change is having the desired effect? In this way these values can help us try new things, learn, and iterate, and we at FordLabs have found them very useful for doing so.