What is team programming?

Team programming is a software development practice that involves two or more programmers collaborating in order to deliver a specific individual engineering task.

This often involves sharing a screen or IDE in real-time, relaying ideas to each other, and making decisions together about how the code should be implemented.

This practice is often also referred to as swarming or mobbing but we like the term team programming as it emphasises the importance of an entire team being involved.

You can read more about team programming here.

Why do we practice team programming at Legl?

We’ve all been there. There’s an incident in production and a small group of people naturally come together to swarm on the problem, knowing that time is critical and we shouldn’t make things worse.

Taking this premise one step further, one of our teams experimented with pairing and swarming for a project in the summer of 2022. The project was deemed time sensitive and sufficiently complex to do so.

The team transitioned to working more collaboratively as a squad on one area of work at a time, seeing it through together. This was different to how they usually approached things, which was working individually and having code reviewed asynchronously. This helped the team limit WIP and in most cases, remove the time usually needed for those async code reviews. One other byproduct was it enabled code to get into production more quickly.

One of the great things about our Engineering culture at Legl is that we openly broadcast to the group our curiosity and ambition to try things. If things are seen as being useful and worth giving a go, then other teams tend to try things out for themselves and we continue to learn together.

In addition to team programming, we wanted to increase our adoption of TDD, and swarming enabled us to quickly establish best practices and to educate those on the team that hadn’t previously practiced TDD.

Craig, Mario, and Nandhini, engineers from different product teams, each named after prominent women in STEM, reflect on and share their journey.

Craig:

When I joined Team Ada there was an element of pairing and occasional swarming but there was a clear desire from the team to make this the default way of working.

We didn’t really know what this was going to look like at the start so we set out with very little format or expectation, but were keen to experiment and to reflect after a few weeks in order to figure out what worked best for us.

Initially, we struggled to always get everyone in the team together at the same time – people either had meetings to attend, other commitments to take care of, or were involved in tech support issue resolution.

We realised that we needed to strictly set time aside in the teams calendar that should be held free of external interference as much as possible. This allowed us to reliably get together as a team on a regular basis.

We also initially struggled to share the load evenly when swarming. Sometimes the same person would drive the session for a long period of time and this became mentally draining.

We tried the pomodoro technique where the driver would be switched at a set interval with breaks in between and found that this helped to keep everyone involved and to reduce the burden on any one individual.

We also evaluated various tools to see if they could assist us in our journey. Engineers had been using different IDEs but we decided to all try using dev containers within Visual Studio Code following a recommendation from a colleague. We found that there was little to no friction when switching between drivers due to the standardisation of environments and we were able to speed up development time by utilising the in-built test explorer, debugging tools and terminal.

Having gone through this journey and taken time to reflect, I now feel that team programming can help to deliver solutions more quickly, help to provide education and mentorship to engineers and help to build team spirit. Team programming has become one of the many tools that we have in our tool belt to assist with daily work.

Mario:

Team Valerie led the way by becoming the first team to adopt swarming as a default method, which involves writing all code as a collective group. Initially, synchronising everyone’s availability posed a significant challenge, which required the establishment of new routines to ensure our simultaneous presence.

The primary challenge we faced was maintaining engagement among all team members while optimising our efficiency. Fast forward a few months, we have developed efficient mechanics that make us feel we work at a faster pace than when working in isolation. The entire team shares the same context, allowing us to move as one. We have been using team programming as our default way of working for a few months now, and the results have been very positive.

Nandhini:

In Team Gladys, we had engineers with varying levels of experience, and we were a relatively new team, which made it ideal to start this process. We designated time in our calendars every day to get together, which we called “collaboration sessions.” Initially, we worked on several small features, some of which some of us had experience with. It was a quick way to introduce new people to the code base.

Over the course of a few months, our team became extremely reliable. We delivered almost every feature on time with very little overhead, such as code reviews and production bugs. Our stand-ups were short and concise because we were always on the same page. Communication between the engineering, product, and design teams also became easy.

Our initial struggle was matching the skill levels and experience in the codebase. We had one or two people with a lot of experience who wanted to move forward quickly, while the new starters were still ramping up. This was brought up in retrospectives and made known to everyone. We changed our approach so that the most experienced person would take a step back and let others drive, only weighing in when others were stuck. This proved to be extremely powerful in terms of empowering the less experienced people to take charge, while still having help available before going down a rabbit hole.

Personally, pairing with other team members and observing them code and use shortcuts in the IDE taught me advanced topics and best practices.

Over time, we experienced fewer bugs to fix because there were more eyes on the code during development, not just during review. Additionally, we spent less time writing detailed user stories since we were typically on the same call and the same people who planned together also broke down the stories and coded together. In terms of communication, we experienced fewer misunderstandings and pull requests were merged quickly.

In my experience, it also eliminates bottlenecks and a single person getting siloed in a project. It proved to be a highly efficient way of working with less communication overhead.

Learnings and recommendations:

• Block off time in the calendar to allow the team to be together at the same time
• Switch driver frequently to avoid burnout and increase engagement
• Create a set rota for who is driving at what times
• Take frequent breaks to avoid exhaustion and mental fatigue
• Set the agenda for the next session to ensure alignment on the outcome
• Where possible, agree on the IDE and tools to be used. Some of our teams are currently using Visual Studio Code Dev Containers with the Live Share extension which has been found to provide a slick developer experience
• If it feels like a daunting change, pick a time frame to try this way of working and have a retrospective to discuss the experience

‍