I am a software engineer and have been working on extreme programming (XP) teams since 2015. Currently, I work within VMware Tanzu Labs, which has a long history of practicing XP and teaching it to clients. The COVID-19 pandemic is massively affecting how teams practice XP by forcing practitioners to operate in a remote-first world, usually from home. And many teams won’t return to full-time in-person work when the pandemic ends. While this creates new challenges, teams can still do effective XP by adapting their processes to better accommodate remote teams.
What is extreme programming?
If you’re not familiar with XP, you may still know something about it if you’ve witnessed some of the practices commonly associated with it: pair programming, balanced teams, frequent feedback, ruthless prioritization, iterative development, frequent software releases, and test-driven development (TDD) are a few common examples.
In Kent Beck’s book Extreme Programming Explained, he writes that XP is primarily about social change and is not defined by any one practice. However, many people hold the belief that XP-associated practices work best when done together, and that straying from one practice will damage the rest of them. If team members stop practicing pair programming, for example, they might not provide frequent feedback to each other.
COVID-19 and remote-first programming
So, if XP is about social change and not just about one or two practices, how should XP teams adapt to the extreme changes in how and where we work that were brought about by the COVID-19 pandemic?
One practice I hadn’t expected XP teams to ever stop doing was co-located teamwork. Before 2020, many people had only experienced co-located XP. Team members were frequently physically located in the same office, and remote work was actively discouraged by many employers.
Now, lots of us have been experimenting with remote XP from our backyards, RVs, kitchens, bedrooms, or home offices. And while co-location isn’t an explicit XP practice, it has been foundational to some of the core XP practices that rely on oral communication, such as paired programming and frequent interpersonal feedback.
Extreme programming teams should discuss how the loss of co-location has affected one of XP’s most well-known practices: pair programming. Many practitioners who have enjoyed pair programming exclusively in-person, such as myself, are finding that remote pair programming comes with challenges.
A note on space
A coworker once told me about how the space people occupy affects their mindset. I notice this when I go outside for 5 minutes after having worked indoors all morning. I have seen this reflected in differences between XP projects where I joined teams in their traditional space and projects where teams joined me in my team’s XP-focused space.
Now, though, each of us occupies our own unique space with its own unique vibrancy (or lack thereof). And we all want to work together as one team. The ability to work remotely during trying times is an overall benefit, but it comes with new challenges that need to be explored in order for teams to continue collaborating successfully.
Remote pair programming
Among all of XP’s practices, pair programming has probably changed the most during the pandemic (at least for teams that were not remote before).
Remote-first pairing has introduced new challenges:
-
My pair in another time zone has:
-
made code changes without me that I wouldn’t recommend. How do I handle this?
-
become unavailable. What should I work on?
-
become unavailable, and I don’t know how to work on our assigned feature solo. What should I do?
-
-
The network is lagging. How do my pair and I exchange keyboard and mouse control?
-
My work-from-home environment has distractions.
-
Some of my team is remote, and some is co-located. How do we collaborate together?
You may have noticed that these “new challenges” are essentially the same challenges that existed with regular old solo and remote programming!
And this brings me around to admitting that we need to change how we approach pairing in a remote-first world. Expecting to pair for eight hours a day in a remote-first world does not seem sustainable for many teams. We need to exercise our XP “social change” muscles and experiment to find what works for our teams.
Is constant pairing part of what made XP “extreme”? I would argue that having the flexibility to seek and then do what works is even more extreme.
XP without pair programming
Sometimes we will not have a pair. Let’s say a pair is made up of an engineer based on the West Coast of the U.S. and another on the East Coast. This creates a 3-hour difference in the two people’s 8-hour workdays. There may be, at most, a 5-hour overlap for pairing. With 1–2 hours reserved for team meetings, there may be 3–4 hours for pairing per day. Sometimes less!
We need to acknowledge this when beginning work on a new feature. Most importantly, I’d argue, we must put more energy into actively discussing how we want to pair:
-
Set up team-wide core pairing hours, if possible, or schedule pairing hours
-
Discuss with your pair what kinds of tasks are good for solo time
-
Discuss how you and your pair want to share context from solo time
-
Break down stories into pair tasks and solo tasks
Successful remote pairing will also differ depending on the confidence level of the pair, for which I’ll use the muddy terms “senior” and “junior”: Two senior engineers? One junior and one senior? Two juniors?
A junior engineer will have an important perspective (spoken or unspoken!) on what is a good solo task. A healthy team wants junior engineers to grow their skills.
If both engineers are senior, the primary challenge is probably peer reviewing implementation choices made when the other person is offline. Asynchronous peer review is notorious for being easily rushed.
Each person needs to be transparent about which tasks they think are OK for solo and which should require pairing. This can help a pair maintain the cooperative teaching-learning component of pair programming.
Potential solo tasks
In general, the best solo tasks are those that a pair actively agrees are good to solo on. Here are some ideas for good solo tasks:
-
Administrative tasks
-
Write documentation
-
Work on a learning course
-
Research solutions for the tricky component of a feature
-
Prepare a learning workshop to run with the team
-
Pair with a designer or product manager on something
-
Collect resources/articles for team members to review and discuss later
-
Write code for solo tasks
-
Research options for pair tasks
-
Practice solving solo tasks or pair tasks alone as a learning opportunity (without committing code)
-
Document questions to ask for when pairing resumes
-
Practice coding techniques
-
Any other work that a team agrees is fine to solo on
Potential pair tasks
The best pair tasks are whatever a pair decides they want to do together, for any reason. This will likely involve the following:
-
Complex business logic
-
Code that one person does not feel comfortable writing solo
-
Creating architecture diagrams linking different systems
-
Other tasks a team member wants help with
-
Breaking a story into tasks, and categorizing those tasks as solo tasks or pair tasks, is itself a pair task
Stand-down channel
Sharing context can feel tedious. Teams working in a co-located environment alleviated this pain point through easy oral communication.
Part of the reasoning for clearly defining pair tasks and solo tasks is to reduce the burden of context sharing later on. Discussing what you are going to do while solo creates the opportunity for your pair to say, “I want to be part of that.” It will also prevent your pair from being surprised.
The team creates a “stand-down” channel in a collaboration tool, such as Slack, Teams, or Webex. At the end of their workday, each team member writes a brief summary of where they left off on work. When the other team members filter in during their time zones’ work hours, they can catch up by reading this channel.
Remote pairing retro
Schedule a retro focused on pairing, with the goal of uncovering the team’s unique challenges or conflicts. At the beginning, establish the goal to improve the remote pairing practice. Throughout the retro, everyone should be listening to others’ experiences. Think about what pairing structures or experiments might help alleviate the team’s pain points.
Context switching and reflection
Perhaps you start the day working on some solo work. Another person comes online, and you switch context by pairing on pair work with that person. Later, you’re solo again, and you go back to solo work. Or you go to a team meeting. Or you have to handle a work-from-home distraction, like cooking. This might seem to be happening constantly.
If you’re like me, you might find yourself easily frustrated by context switching between all of these modes.
There is no surefire answer to getting rid of these distractions. But part of this frustration probably results from a desire to be constantly coding or doing hands-on work, as though that’s the only recognized form of productivity. And perhaps we need to challenge the assumption that constantly working on hands-on tasks is the only way to be productive.
Taking time to reflect on how you and your team are doing might produce better results than constantly switching between hands-on work. Reflection is essential to learning. Usually, writing code or creating designs isn’t the only challenging aspect of our jobs. And during a period of extreme change like the COVID-19 pandemic, reflection may be the best choice of action.
Try this: if you realize a day this week is going to have multiple 15- or 30-minute gaps between meetings, don’t do feature work in those periods. Instead, try reflecting or free-writing about what’s going on with your team or project’s big picture—or about the meeting or pairing session you just got out of.
Experiment more!
Change is difficult. Teams require social confidence and good communication to navigate change and to experiment with their practices without alienating one another. As individuals within a team, we each have a role to play in growing our own confidence and allowing this experimentation and change to play out.
Continue to experiment with XP practices in today’s remote, work-from-home world. Discuss them with your team at retro, the next time you pair, or schedule a separate meeting or one-on-one. And feel free to reach out to me if you have thoughts or questions.
For further reading on this topic, check out Tanzu Labs' resources for remote software teams.
