One Team.

One Keyboard.

One Task.

One Story.

Software Engineering is fascinating, just consider the different practices that keep developing and evolving around it. You never stop learning. Not after doing it for five, ten or twenty years. You keep learning new things, new concepts, even if they are actually old sometimes.

The concept of one team working on a single computer is an approach we have gotten to learn and appreciate during the last couple of months here at 25th-floor.

Have you ever heard of the term “mob programming”? We neither. But it’s a concept that has been here for at least five years now and even has a dedicated website for it.

Imagine a team of five or six developers sitting around a single computer, staring at a large screen and working together on a single story. This doesn’t sound very efficient at first, even crazy when seeing it from a customer point of view. Paying not for one but for five or six developers, which could be concluded as having to pay six times as much.

The same arguments have been thrown at Agile, at Scrum, at pair programming, at everything that seems new, strange or inefficient at first glance.


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.


How does it work?

Actually, in essence, it’s very simple. To begin with, you can consider the following:

  • One computer
  • One keyboard
  • One projector
  • One Task at a time
  • One Story from start to end
  • Everyone has to drive (control the keyboard)
  • Change the driver every fifteen to thirty minutes
  • Don’t exclude any team members
  • No grabbing the keyboard when you’re not the driver - Respect the driver
  • Respect your colleagues

Also watch the time lapse video and read what Woody Zuill, who came up with the term mob programming, has to say.

The concept is easy to implement given the following circumstances:

Every team member is open to the idea of programming with others, not trying to keep information or knowledge to self.

Management that is open to the idea, that more programmers doesn’t simply mean more costs, but can also evaluate and see the quality and benefits as well as the business value that comes with it.

Customers that are interested in quality not just price dumping.


Try it — To see if it actually works

If you are in the right environment, meaning having a team culture that enforces collaboration, a management that understands the benefits and customers that love the quality you deliver, than you should give it a try.

Of course you will not start off by choosing this concept for every story or feature (no matter how trivial) at start, but rather simply begin with the next very complex story or key feature in your backlog or upcoming sprint.

Try team or mob programming for a couple of sprints and reflect on the results. It might or might not work, but you will need to give it a try to see if it actually works for your team or company.

Best case scenario is highly motivated team members, a strengthen in team focus and collaboration, quick on boarding of new or entry level programmers. You might even invite your product owner or your customer to join the session.


Interested in finding out how we work at 25th-floor or want to talk about your experiences with team programming? Don’t hesitate to connect.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.