Introduction
Hello, developers! 🚀
I’m a big advocate of eXtreme Programming, as most of you already know: since the first time I read “eXtreme Programming: Explained”, this methodology has become part of my daily job as a Software Developer and it’s the core of what I typically bring as suggestion when I’m technical coaching.
Then, remote work became a habit and it seems that the direction where this type of work is going is diverging from the values and principles of XP itself; most people think that XP (and Agile) practices are not compatible with remote - but is this actually the truth?
Let’s dive into the issue and discover what I think about this!
💡 This is the "sequel" of an old article: I will expand and explore the topic with this new article, focusing more on XP, but if you want, you can read the first part 👉 here.
Values and principles are universal
XP was my first step into the Agile world, and it was enlightening. I always tell this story: when I first heard about a methodology called “eXtreme Programming”, I immediately thought it was related to coding for hours overnight like in some movies - the word extreme in the name is pretty misunderstandable, to be honest.
Then I read the book and the reason for the name became more clear:
It’s called “eXtreme Programming” because the idea is to take all the things that have proved to work well in programming and take them to their extreme.
Do writing tests work? Do it first!
Does working together work? Do Pair Programming all the time!
Does releasing more often work? Do it every day!
… and so on
The idea is simple, yet revolutionary: if a thing works well, let’s do it more often. Let’s do it always! Why not?
From a high-level perspective, XP is something everyone can easily agree on: the 5 values (communication, simplicity, feedback, courage, respect) are something that most developers themselves can think of as ideal values for their work. We all want effective communication, simplifying our work, and respect - and we can easily discover the importance of feedback and courage.
Similarly, principles are still enough high-level that most people will easily agree: if you ever meet someone who doesn’t agree with principles such as humanity, mutual benefit, improvement, diversity, etc… - well, run away as fast as you can!
It’s great that XP is based on such universal concepts, of course: this can help in setting up a conversation about it because we can easily start with a shared agreement on them. On the other side, this is just too high level: making values explicit is important because, without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction.
Practices, on the other hand, are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of value. Practices are clear.
Principles bridge the gap between values and practices. Principles are domain-specific guidelines for life, that starting from values can lead to practices that respect all of them.
By far, IMHO, everything related to XP Values and Principles is “location independent” - meaning that remote work has no impact on their application: we want our organization to be respectful, communicate well, favor diversity, etc - no matter if we are remote or not.
XP practices for remote teams
Practices are the kind of things you will see XP teams doing daily.
Applying a practice is a choice: XP offers a collection of practices that work and work even better together, and they have been used before, and those are the practices listed in Kent Beck’s book. Practices only make sense if related to principles, otherwise, they become rote; pairing just to make your boss happy is frustrating, but if you recognize its values in communication, feedback, simplicity, courage, and respect it makes a lot of sense.
But remember that practices are situation-dependent: if the situation changes, you will choose different practices to meet those conditions.
Values don't change, and principles can be used to figure out something new.
Today, I want to focus on some of the practices suggested by XP: I will focus on the most important (in my opinion, of course) but also on the one that can more easily be seen as harder when remote, to share my thoughts about the impact of remote work on them.
Sit Together
Let’s start directly with one of the easiest practices to put into discussion when working remotely: “Sit Together” means that people should work in a shared space big enough for the whole team. Of course, this is just not possible if we are working remotely… but the reality is that we don’t have to interpret this practice in such a concrete way.
Kent Beck itself, in the 2nd edition of the book, added some additional notes related to remote work, and states that multisite teams can do XP: the point is that practices are just predictions - here, for example, the prediction is that the more face time you have, the more human and productive the project will be.
But today, technology can easily help and make teamwork remote: we can easily set up virtual rooms, with both video and audio and also the chance to share screens and documents - and we can also move some of that conversation async (not all, not even most, only some!).
Of course, if you have problems related to teamwork think about ways to sit together, even if it requires traveling.
Pair Programming
My dear Pair Programming! It always comes back in my writings, at some point. I’m referring to Pairing because it is explicitly quoted in the book, but this point can also be applied to Ensemble Programming (aka Mob Programming, which we can simplify to “pairing with the whole team” - and what is Mob if not the “extreme” version of Pairing? 😉
Pair Programming is already hard enough to make a habit when working in the same space for a lot of developers - which is sad, in my opinion - so it is no surprise that even more people think it’s harder when working remotely.
I think that, if we have a good enough setup, it’s the same: we can easily share a screen today, or use a collaborative tool that allows multiple people to change the code together; we can easily have a webcam always on so that we can always see each other and talk to each other; we can easily share an online board like Miro for some brainstorming or sharing ideas; technology is growing and evolving daily, and it will help always more.
There is only one thing about Pair/Ensemble Programming that is still important when in person, but it becomes fundamental when remote: taking breaks! When working remotely, we have the additional fatigue coming from all the conversation happening on a screen, typically also with headsets - so having regular breaks is not just a good idea, it’s required to keep the work healthy.
Code and Tests
This practice is not much known as the others, but I think it’s important to share some thoughts about how we can adapt XP practices keeping values and principles in mind: “Code and Tests” suggests that code and test should be the only piece of work maintained from the team; any other document should be generated from them, and we should rely on social mechanisms to keep alive the important history of the project.
This practice is a companion for the Agile principle of “working software over comprehensive documentation” - we should be able to make the team only work on code and tests, and any other artifact such as documentation should be generated from them.
First of all, this description is ideal and it’s very hard that we can do that, no matter where the members of the team work from. But still, it should be our target. That’s why is a good idea to generate a Swagger doc from annotations in the code, for example.
The main issue with this practice when going remote is that “social mechanisms” are different, and sharing information is harder and less natural; on one side, we can fight this by working in sync - I know that the industry goes the opposite way, but remember: async is good only for some things, not all, not even most of things. On the other side, we need to invest some time in writing down information and making it accessible - but be careful, this doesn’t necessarily mean writing down documentation.
Do we need to share how to set up the project? Let’s create a script to automate that - it will make it easier to onboard new people, and they will still be able to read the script code to discover what it does.
We need to document decisions? Implement ADRs in a dedicated repository using MD files - and you could even build automation to publish them and make them searchable.
This kind of approach has a much higher ROI compared to simple documentation.
Continuous Integration
Continuous Integration means that our code has to go into the main branch at least once per day. It is a synonym of Trunk-Based Development, and it is the opposite of Feature Branches. It is also not the best friend of Async Pull Request, but they can live together if the team is responsible.
I know that Feature Branches are something that also teams working in the same place do most of time - for some reason, this way of working has become so popular - but I feel that it’s even more used by remote teams. In general, remote teams tend to accept isolation of work for individuals for a long time - this helps the work-life balance, they say. It’s just not true.
Anyway, there is no specific solution related to remote here: my suggestion is just to try to force yourself to have branches that live 24 hours at most, and see what happens - you will discover a powerful technique.
Additional point: since your team will have a good number of reviews if you start having 1-day branches, people will collaborate more in a natural way - and you can even consider a different approach to PRs such as “Skip/Ship/Show”.
Real Customer Involvement
The last practice I want to talk about is about involving customers in our daily work: we should make people whose lives and businesses are affected by your system part of the team. Visionary customers can be part of quarterly or weekly planning.
You will get different results with real customers involved. When you act trustworthy and have nothing to hide, you are more productive. This is already hard and rare enough in general, and it can appear harder to achieve in a remote work context.
I believe that if your company has a culture of involving the customers, you will be able to do it independently from being remote or not. Again, if the customers are tech-savvy enough, technology can easily help nowadays - and if customers are not that tech-savvy to do it on their own, you can invest some workforce in helping them share their thoughts in other ways.
Conclusions
I think we can safely say that we can try to implement eXtreme Programming even if we are working remotely; the most important thing is that we need to be sure to respect values and principles, that are the foundation of a good, healthy company and tech culture.
Once we are aligned on those, we can easily pick the practices that we all agree on, and start from there; then, we can respond to our issues by testing other practices or by creating our own.
Embrace XP, you will never regret it!
Until next time, happy coding! 🤓👩💻👨💻
XP is about social change. It's about letting go of habits and patterns that were adaptive in the past but now get in the way of us doing the best work.
Go Deeper 🔎
📚 Books
-
Extreme Programming Explained: Embrace Change - this is just THE book on the topic - make sure to read it before starting your XP journey. It’s clear, simple to read, and gives a lot of inspiration about our work in general.
-
Extreme Programming: Installed - The book consists of a connected collection of essays, presented in the order the practices would be implemented during a project. Ideal as both a start-to-finish tutorial and quick reference, the book demonstrates exactly how XP can promote better communication, quality, control, and predictability.
-
Agile Technical Practices Distilled - This book uses the term Agile as a wide umbrella and covers Agile principles and practices, as well as most methodologies associated with it - XP included.