Leaving the mob will get you in trouble

After an awesome workshop by Woody Zuill on mob programming, we wound up repeating old patterns. This is a short story about implementing mob programming.

We were already familiar with pair programming and consider this the minimum way of programming, 2 minds always beat 1 mind. 4 minds beating 2 minds makes even more sense, so we thought a workshop on mob programming could help us. We were right, Woody showed us what it is like to build the right thing in a short amount of time and thus feeling part of a highly efficient team.

Mob programming rules

The workshop had different setups each time, with different rules. We started with 1 driver (the guy with the keyboard), 1 navigator (tells the driver what to do), the rest observers (only allowed to think), where only the navigator may speak.

As an outspoken, opinionated, and loud person, this was unquestionably the hardest setup for me. Only observing and not being able to blurt out everything forces you to watch your team members figure the problems out and even get to the same or better conclusions. This thought me I should listen more and trust team members to fix the problem.

The next setup was 1 driver, 1 navigator, the rest observers, the navigator allows observers to speak if he chooses to. This brought a new vibe. Having observers help the navigator on request changes the game when being stuck. In the previous setup, you are just stuck for that round and telling the driver to google, this format made more sense.

However, the last setup was the best, 1 driver and the rest navigators. Navigators are having a continuous discussion on solving a specific problem, whereas not being bothered by implementation details like typing. The best part is you share the cognitive load of the problem and having a team consensus on the direction of the solution. Having experienced the previous steps is useful, as they teach you to be more silent and only speak when you have something to say.

Our setup

A few days after the workshop, we changed our office, moving around tables, chairs, screens, etc to do mob programming. Tables ready, tv ready, 4 keyboards, 4 mouses, 1 machine, we are ready!

And so we did, we worked on the product and mob programming worked! Better quality code, better communication, shared understanding, and shared solutions.

Slippery Slope

The plan was to onboard customers in our software within 3 weeks. This didn’t mind us as we do continuous deployment and are always production-ready. We kept working in the same manner and all seemed fine, but after a conversation with the customer, the storm dawned upon us, the domain implementation is incorrect.

And so, a deadline has arrived …..

For the first week we kept working with mob programming, but the stress and time constraints tore us apart. The first cracks in our mob programming sessions became apparent.

Because the number of problems seem to grow, we neglected to align the team on 1 problem at a time, and this moved us to look at our own screens more often.

When you look at your screen, the team discussions automatically falls short, the whiteboard became uninteresting, timeboxing stopped, no more swapping drivers, and lead to stopping mob programming.

And because of the time pressure, you cut corners, and when nobody corrects; Code quality decreased, test coverage decreased, technical debt increased, integrating code with peers went horrible, and the overall system became a mess. Sadly, you get away with this unacceptable behavior.

Before the deadline, my colleagues worked hard and told me the system worked as they did a last test of the system at 1:30 AM.

Judgment day

I had to present the product and walk the customer through the process. In the morning before the demo, I tried everything myself, and…. Ah shit! The software barely worked….
By avoiding most of the problems and putting parts of the product more to a conversational setting, there was enough to get away with. The demo ended up being embarrassing and not something to be proud of.

If we stuck to the plan, kept on mob programming, it would have been high-quality workable product and something proper to show for. Perhaps we would also deliver more, as broken functionality is no functionality.
Now we needed to dig into broken functionality, pay off technical debt, and improve code quality.

So if the times get tough, keep the team conversation going, do mob programming and solve 1 problem at the time!