A collaborative programming style that incentivizes taking small steps together and is FUN.

I stumbled across it with my colleague Brett Schuchert while pairing one day. We were in a flow state rotating back and forth while pushing code effortlessly to production. Write a failing test. Make it pass. Commit and push. Rotate. Refactor. Commit and push. Refactor. Commit and push. Rotate.

Once we noticed what we were doing, we labeled it as Trunk-Based Ping-Pong and started to experiment with it in our day-to-day work. It has now become one of my favorite practices when collaboratively programming.

How to do it

As the name Trunk-Based Ping-Pong implies, we can rotate anytime we can commit and push our changes to Trunk (main). So instead of relying upon a timer to know when to rotate, the group takes a small step that could be integrated into trunk, pushes it and then the group rotates roles. (typist/driver, navigator, etc.)

This assumes we are writing our software with micro-commits- "a tiny commit" that does "one tightly-scoped change".

Related: Trunk-Based Ping-Pong plays really well with a micro-commit notation like Arlo's Commit Notation.

In a TDD Workflow

In a normal Test Driven Development red-green-refactor workflow, doing Trunk-Based Ping-Pong means you can rotate on green. To provide an example, here is what a typical rotation cycle would look like doing Trunk-Based Ping-Pong

1. red to green: commit rotate
2. refactor: (extract variable) commit rotate
3. refactor: (extract method) commit rotate
4. red to green: commit rotate
5. red to green: commit rotate
6. refactor: (extract method in test) commit rotate
7. etc

How many step(s) before rotating?

At first to learn the rhythm in your pair/mob, stick to one commit per rotation.

Once you experience a few full team rotations of this, experiment with the number of steps before rotating. In my groups that have been doing this, if a step was super micro (e.g. rename variable), we take another small step before rotating. But for most red to green steps we'd rotate once integrating to Trunk.

Your pair/mob will find what works for your context, so start off with one-step rotations and then experiment!

Cost of Integration & Rotation

Trunk-Based Ping-Pong might sound crazy rotating on every small change if the cost of integration or the cost of rotating is expensive.

Using micro-commits will feel painful when the cost of integration is high. In this case, find ways to reduce the cost of integration. You can experiment with running your tests in parallel, or finding what tests are slow and making them faster.

If the cost of rotation is high you will not be able to do quick rotations, so experiment with ways to reduce it. For example, in the group I discovered Trunk-Based Ping-Pong with we enabled the zoom feature "multi-screenshare" to allow the next typist to start their screenshare while the current typist writes the commit and pushes.

If you can not reduce the cost of integration or the cost of rotation, taking multiple steps before rotating might make sense.

Remote Work

For a remote setup, Trunk-Based Ping-Pong solves the problem of how do we collaboratively program remotely by making the size of WIP (work in progress) smaller and incentivizing integrating our code into Trunk making it easier to pull down the most up-to-date version of the code base.

It was born out of a combination of wanting easy rotations (via screenshare of typists IDE over Zoom) with true CI (Continuous Integration) via micro-commits to Trunk.

We originally were using the fabulous mob.sh tool, but found it was incentivizing us to take bigger steps as it added an extra step to commit and push.

Benefits

Trunk-Based Ping-Pong is a practice that helps us "take small steps together".

As we can only rotate on code that can be integrated into Trunk, we are incentivized to take small steps. The smaller the step, the faster we can rotate. The more we rotate, the more engagement we feel as a group.

It incentivizes the entire group to think in small steps, working together to break big problems into small incremental steps.

Small Steps

In case you aren't sold on taking small steps, Gee Paw Hill's Many More Much Smaller Steps is a great article walking through the benefits of taking small steps.

To list a few reasons why taking small steps is essential to my workflow

• interruptability - it allows us to work in a way that accepts the reality that we will be interrupted while working by minimizing the damage it can do.
• incremental - we can focus on one piece of one part of the problem at a time.
• poised to embrace change - it is much easier to change direction when we keep our WIP (work in progress) small.
• reversibility - by continuously taking small steps and getting them into our version control we can easily reverse our changes! (I am liberated to run git reset –hard and I do it multiple times a day)

Challenges

When taking the next small step is difficult

Trunk-Based Ping-Pong can be challenging when it is difficult to take the next small step. For example, when trying to identify the root cause of a bug it can take some time to figure out what is the first small step to fix the issue.

However, it incentivizes the group to keep in the back of their heads "what is the next small step", which still brings value even if we don't explicitly rotate as often.

Taking Breaks

One thing I like about rotating on a timer is that it's easy to remember when to take breaks. Using a technique like Pomodoro, you can easily plug it into your existing mob rotations.

With Trunk-Based Ping-Pong, it can work the same by working it into your rotation, but it requires more thinking as the rotation times are not always uniform. (In ensembles of 3-4 people we would do two full rotations then break)

There have been a few occasions when using Trunk-Based Ping-Pong that we have forgotten to take a break. To remedy this, I recommend setting an independent break timer. And since you are working to be interruptible it should be easier to take the break once the timer goes off!

Conclusion

Trunk-Based Ping-Pong has been very effective for me and the teams I have been working on. It creates a flow that bridges the gap between working collaboratively and working in small-steps.

Experiment with Trunk-Based Ping-Pong, it's super fun and can bring a new perspective on how your team approaches their work.