It has been a couple of months since we started inserting small controlled experiments into our workflow at Recovr. It all started with the introduction of retrospectives, following a similar method to the Six Thinking Hats, although we only kept four (Facts and Figures, Critical thinking, Positive Thinking, and Solutions).

Our latest experiment has been 3 days of Ensemble Programming. And I loved it, so let me tell you what ensemble programming was for us, what worked well and where we could still tweak it.

Ensemble for us

From what I gathered talking to people around me, Ensemble programming means different things to different people. So here are the rules we had for our first ensemble day and how the rules ended up for the last day (three days later).

First Day

On the first day, we heavily influenced ourselves by the book Code With the Wisdom of the Crowd.

Roles: We decided that there would be two roles: the Typist and the Rest of the ensemble. The Typist's responsibility is to transcribe the ensemble's intentions.

Timings: We started with every typist being at the keyboard for 15 minutes

Retrospectives: We decided to have regular retrospectives throughout the three days; these informed the changes we reached for the other days

Second day

After a retrospective on day two, we discovered what seemed most problematic on day one: We got off topic and lost half a day chasing our tails.

As a consequence, we decided to add another 'rule' which was:

Structure: We can only advance following a to-do. If we run out of to-do items or we need to deviate, a new to-do must be created

This allowed us to advance with more purpose on our second day.

Third and final day

On our last retrospective, we realized that the timings for the typist were too short, and the switching machines cost too high in proportion.

To fix that, we decided to increase the timings for the typist from 15 to 25 minutes. Here is how the rules looked in the end:

Roles: Typist and Rest of the ensemble. The Typist's responsibility is to transcribe the intentions of the ensemble.

Timings: 25 minutes on the keyboard for each of us. If we must discuss something for a long time, the timer is paused.

Retrospectives: regular retrospectives

Structure: A to-do must always be up-to-date and active to advance.

What worked for us (in my opinion)

Retrospectives

Within the three days we had three retrospectives, one at the first half day, and in the morning of each of the other two.

This was the most impactful thing we did, it allowed us to have each day improve on what we had built the previous day.

Breaks

We forced ourselves to take breaks quite regularly, especially after we finished the first day knackered. This allowed us to be fresher and more efficient during the working parts.

Level of care

I found that the level of care and attention to detail was higher as a group than as 5 distinct individuals.

I attribute this to the fact that as a group, someone's care was always high, even when it decayed on someone else.

I believe the end result of what we were coding was something we can be prouder that if it was coded individually.

Learning

We are organized as a team with a distinct front and back end. In order for this to work, we decided to have the front and back work together.

This meant that we not only were learning how to work as a group, we were all also all learning a new language.

Everyone had quite an open mind to it, and recalling our first rotations and our last ones, the instructions went from dictating the specific syntax to more general we should do X.

Flow and coordination

One area where we definitely gained a lot of time and quality, was in the coordination among the front and back (and more generally the team).

If we wanted a shape to our API, it was decided on the spot by everyone, so we did not have to revisit things due to misunderstandings.

The same can be said about the architecture of our code.

Code and architecture quality

Since we were deciding things by committee, there were less sunk cost galàxies that come into play when a review is done after the fact.

What could still be improved (in my opinion)

Switching costs

Most of us preferred to work on our machines, and while it has advantages, mainly everyone working in a familiar environment, it does mean that there is an inherent cost of switching the machines and pushing/pulling the code.

We did find ways to make that s bit faster with each switch, but progress could still be made in that front.

Cost of the experiment

While I am convinced now that doing ensemble work regularly would be a net positive, this first experiment did have costs.

The big elephant in the room is that we spent 15 programmer-days for this experiment. At the end of the three days we did a budgeted work of ~8 programmer days. I believe the advantages in reduced coordination costs are well worth it. And with more ensemble experience, I believe the two numbers will get closer to each other.(Edit: after the fact I realized that it is quite common for us to miss our mark when estimating and being of by 50% so the amount of work produced was roughly on par)

The two other minor costs we incurred were:

On one hand, we ended the days quite tired (although less with each passing day).

On the other, since we were working in an unfamiliar way we were not as efficient as we could have been.

I am quite sure that the cost will lessen as we keep doing ensemble programming.

Getting stuck

I had the impression that we got stuck on minutiae a couple of times, especially when two of us felt quite strongly about one thing or the other.

I suppose there are a few ways to fix that, first that comes to mind is after X time, pick one direction and test it.

I look forward to see how this evolved in the future.

Conclusion

I believe the experiment was a net positive, not only is the code quality higher, I think that the 'time' we lost due to inexperience will be offset by the reduced coordination and review costs.

The team seemed quite enthusiastic about the experiment and we are working on integrating ensemble programming into the way we work.

If you, dear reader, have never tried it, I can only recommend you do, remember to adjust along the way and to keep an open mind.