XP to TeamUp

Extreme Programming, sometimes referred to as Pair Programming, isn’t new. Some people swear by it and others loath the idea. So what is it? XP is a way of doing software development. There is a deeper write up here that goes into this concept much deeper. The gist of it is two of the following are required: developers, keyboards, mice, and monitors. It must also consist of one computer.

The idea is that two developers working together can produce better code. Taking turns being the navigator and driver (two roles in XP). This concept has some practical benefits. Need to enable a new developer? Have them pair up with an experienced senior developer to show them the ropes. No better way to ramp someone up than coding with them on new functionality.

This does come with some limitations. First you have to be co-located which can be hard to sustain for a long period of time. Like it or not XP is an intimate activity. You are sitting next to someone daily and breaking for lunch, coffee, or the restroom at the same time. Sure it isn’t intimate like your relationship with a significant other. But it still requires you to have some level of emotional availability. So if we tone down the level how can we leverage some of the benefits of XP? And without the level of emotional availability. Enter TeamUp.

The TeamUp is a similar concept. It relies on two individuals working on the same code base and the same set of functionality. They can be co-located or then can be remote. Sure the level of enablement isn’t as high as XP, but the level of intimacy is a lot lower.

So how does this work exactly? Well, let’s take Rich and David for example. One works in Chicago and the other in Atlanta. They will be our TeamUp for this example. Rich is the senior of the two and David is new to the company. They are tasked with adding a bit of new functionality to a micro-service. First let’s outline the areas they are going to be working on:

• Controller
• Service
• Command
• Provider

Each of these layers will need new code added to it.

The day starts off with a quick Zoom or phone call between Rich and David. Rich being the senior of the two reads through the requirements of the user story. Rich asks David start on the controller and work towards the provider. Whereas Rich starts at the provider and works his way towards the controller. They end the call and start working writing their unit test and developing.

Keep in mind David can instant message (or call) Rich at any time for questions. At mid-day they break for lunch and after that they sync up. This is where both can check where they everyone is at and start to review some code.

The first few code reviews should be done on a Zoom or call. Once the team gets rolling this can be done offline. Each time, both developers review one another’s code. Then, Rich ensures all standards have been met and they check in their code for the day.

This is just a simple example of TeamUp. But this isn’t how it is going to go every day. Let’s say David was struggling on the service layer. Rich can stop where he is at and help unblock him. Know this can happen and velocity will take a hit as a result.

Rotation of team members can be helpful. Exposing new team members to others helps with the nuances of an existing code base. Also, team members should set some boundaries. If one person on the team needs to take a long lunch inform your teammate. Lastly. set some goals. If it is on-boarding then set a few numbers to hit. TeamUp is a process I have used with clients and it seems to be a great way to do enablement remotely.