Software Teaming

What is it?

Software teaming commonly refers to the practice of having a full multifunctional team work on one feature at a time on the same machine. It is also known as Ensemble Programming or Mob Programming.

Why do it? - Motivation from a team lead perspective

In order to understand why I pushed my team to experiment and try Software Teaming, I think it would be useful to understand the challenges we are facing when working asynchronously from my perspective.

Our team is composed of 5 people separated in 2 Front End Engineers and 3 Back End Engineers. A typical feature will include a Front End Ticket and a Back End Ticket.

This leads to a state where:

• Rework can and does happen frequently.

• There is a layer of coordination that needs to be added between the Front End and Back End Engineers.

• Switching costs are high.

• The waiting time for each feature is high.

Having the team perform as a team instead of a collection of individuals solves most of this issues, but also presents with an opportunity for other benefits, namely:

• A reduction of the bus factor.

• A potential to have everyone expand their knowledge of the whole stack.

• A higher overall level of care on our code.

• A more rounded perspective of our solutions.

Challenges you might face if you decide to try

While I paint what I hope is a pretty appealing picture above, if you want to try Software Teaming withing your organization, you should be aware of the challenges you might face.

First and foremost, it is a hard sell. You will be optimizing for throughput rather than output, and it goes against the traditional way of measuring performance.

It goes against an ingrained perception of the developer as the ‘sole genius' of a development. Individual progress might feel slower, as no member is fully responsable of the code, but the team is.

It can be more tiring to work as part of a group, as you don't fully control the rythm, and the level of social interaction is higher.

Finally, there might be a feeling of loss of control and loss of agency. As, while working in a group you will, most times, influence rather than decide. For the same reason, you'll have to be mindful of everyone being able to influence the group.

In Practice

The theory is all well and good, but what did it mean in practice?

Our setup

We, the five engineers worked as a tem for three days a week for three weeks. We did so in person, as we tried to do one day in remote but our remote setup made it harder.

We had one screen, one keyboard and one computer for the team on the ‘teaming’ days, and we roughly did turns of 20 minutes each as typists.

The ‘mandatory’ teaming hours were from 10 to 12 and from 14 to 16, but in practice we did whole days of mobbing.

Pain points

Our setup was not ideal, as we used a team members computer and screen, as such they were locked in the mob wether they ‘felt like it' or not.

The skill separation between Front End Engineers and Back End Engineers made some parts a bit painful when a lot of the focus was only on the backend or only on the frontend.

There was a sentiment of isolation from the rest of the company, and ‘secondary’ things were harder to keep track of.

There was a sentiment of ‘not being the most conductive setup to learning'.

Gains

The feature was in constant progress, even when not the whole team was there, wether due to emergencies or illness.

There was no waiting time, the code review was done on the spot, and we deployed (but did not release) at least daily.

We were able to change the shape of our API and make judgement calls on the spot, which allowed us to keep progressing the feature.

There was a noticeable improvement in the skills of the participants, the first days we would have to dictate the Backend to FE engineers and viceversa, later days we could express ideas as the team and have the typist mostly execute them.

We were stuck at several points, and having a wider range of skills allowed us to tackle the issues in a more effective way. Although, I must note, that a shared frustration at being stuck is not easier to bear than an isolated frustration at being stuck.

We all know the tradeoffs and choices that were made, as well as how and why our code works the way it works.

Tweaks I would make

I think that while the team being multifunctional has its interest, this exercise necessitates that people have a fair knowledge of the whole stack. While I think that time can solve the issue, it is none the less a hurdle you will have in segregated FE and BE teams.

The setup, can make or break you, if you decide to give it a go, you should pretty soon have a dedicated computer, keyboard and screen (a big one) to allow members to leave the group when they need to do individual work.

Will we do it again?

Tl:dr: maybe.

After three weeks of working mostly as a mob, we have decided that the challenges were a bit too big for the team.

We did take some lessons from this new try and might try again in the future.

As an individual, in a vacuum, I am now convinced that this is the most effective way of producing software. But it necessitates a high buy in and conviction from management and the software team.