The inefficiency argument

Let us take a step back and consider the following assumptions and circumstances.

The story that we need to implement is nontrivial, a lot of the following stories will be based on this implementation and we’re dealing with a lot of complexities and unknown factors here.

Now also add to the fact that the estimation process in software engineering is very often anything but precise. Rather the contrary as soon as we need to estimate features, that have never been implemented in one form or the other previously. A single developer can quickly become a bottleneck at some point or even completely lose track, getting lost in implementation details.

We also need to add the cost of reviewing as well as having to read and understand the code, in case the next story is being implemented by another developer. Add the hidden long term cost of code quality. The latter always being better, the more programmers get to read and review.

You can solve a lot of the aforementioned problems by taking the “team programming” approach. In essence, mob or team programming consists of at least three programmers, one computer, one keyboard and a projector. There is a core team, with other programmers jumping in and out of the process, depending on what else they have on the agenda, and if it makes sense for them or the team to join the session.

We, at 25th-floor, have fully adopted this approach for the last three sprints and have been very successful with it.

The benefits and advantages became very clear when we tackled the complex stories.

Very little distractions and roadblocks, as there was always someone on the team who knew how to solve a pending problem. No need for reviews, as the team had written the code, no after discussions about implementation details and code style as everyone had been involved from start to finish.