Leaving the mob will get you in trouble

Arno van Rossum
1 October 2020

After an awesome workshop by Woody Zuill on mob programming, we wound up repeating old patterns. This is a short story about our failures while implementing mob programming. Learn from our mistakes so you don't make them yourself...

Joining the mob

Mob programming is when your whole team works on the same task, at the same time, at the same computer. Together. Sounds interesting, right? It is!

We were already familiar with pair programming and consider this the minimum way of programming - 2 minds always beat 1 mind. So, 4 minds beating 2 minds made even more sense. To get a baseline in place, we thought a workshop on mob programming could help us kick things off. We were right.

Woody showed us what it is like to build the right thing, in a short amount of time, while feeling part of a highly efficient team. An awesome feeling.

Woody Zuill mob programming workshop

Setting mob programming rules

Mobbing uses the so-called Driver-Navigator Model. The driver is the only one using the keyboard. The navigator basically tells the driver what to do. But you can implement this model in different ways. Because what do the rest of the team members do...

Woody had us try out three different setups, to let us feel the real mob programming.

Setup 1

We started with 1 driver, 1 navigator and 2 observers, who were only allowed to think. Only the navigator was allowed to speak.

As an outspoken, opinionated, and basically loud person, this was unquestionably a very hard setup for me. Every time I was an observer, I had to keep my mouth shut. Only observing and not being able to blurt out everything forced me to watch my team members figure out the problems. But of course, they came to the same or even better conclusions as I would have. This taught me I should listen more and trust my team members to be able to fix problems as well.

Setup 2

The second setup was 1 driver, 1 navigator and 2 observers as well, but the navigator could allow observers to speak if he chose to.

This brought a new vibe. Having observers help the navigator on request changed the game when being stuck. In the previous setup, observers were just stuck for that round, while the driver sometimes had to google. This setup made much more sense.

Setup 3

The last setup was undoubtedly the best, with 1 driver and the rest navigators.

Navigators were having a continuous discussion on solving the specific problem at hand, whereas they didn't have to be bothered by implementation details like typing. The best part was sharing the cognitive load of the problem and at the same time reaching a team consensus on the direction of the solution. Having experienced the previous setups was very 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. We moved around desks, chairs and screens to really implement mob programming. Desks ready, TV ready, 4 keyboards, 4 mouses, snacks, coffee, 1 computer: ready, set, go!

FourScouts mob programming setup

And so we went. In our spacious car with 1 driver and 3 navigators. We worked on the product and achieved goals. Mob programming worked! We got better quality code, better communication, a shared understanding, and shared solutions. Time to celebrate!

The party was short-lived though. We might have overestimated our ability to be a member of the mob...

The mob is falling apart

Our plan was to onboard our customers in the software within 3 weeks. This is a short time frame, but it didn’t mind us. Because with our continuous deployment, we were always production-ready. So we kept working in the same manner and all seemed fine.

But then, after a conversation with the customer, a storm dawned upon us. Turned out, the domain implementation was incorrect. But the deadline was creeping closer...

For another week, we kept working in accordance to the ‘rules’ of mob programming. But the stress and time constraints quickly tore us apart. The first cracks in our mob programming sessions became apparent.

The slippery slope of mob programming

The number of problems seemed to grow. It was stressing us out. We looked at our own screens more often. We neglected to align the team on 1 problem at a time...

This was a big problem, because when you look at your own screen, team discussions automatically fall short. The whiteboard became uninteresting, timeboxing stopped, and we ceased swapping drivers. This led to quitting our mob programming rhythm altogether.

In the meantime, the time pressure got serious. Everybody started cutting corners. But without the mob, nobody corrected the mistakes. Code quality decreased, test coverage decreased, technical debt increased, integrating code with peers went horrible, and the overall system became a mess. On your own, you get away with unacceptable behavior...

The evening before the deadline, my colleagues worked hard. The last test of the system was done at 1:30 AM. It was all working.

Except, it was not...

Judgment day and a knife in your back

The next morning, I had to present the product and walk the customer through the process. Just before the demo, I tried everything myself, and... the software barely worked.

By avoiding most of the problems and putting parts of the product in a conversational setting, there was enough to show for to get away with. The demo ended up being very embarrassing to me though. Definitely not something to be proud of.

It was time to own up to our mistakes, pull ourselves together and learn from this failure.

Keeping the mob together

We didn’t even have to think that hard to realize the obvious problem.

If we had just stuck to the plan, and kept on mob programming, it would not have gone down like this. We would have been able to deliver a high-quality, workable product. A proper product, with a demo to impress with.

Now all we had was unfinished business. Because, you know, broken functionality is no functionality. So instead of being able to continue building upon the (partial) product that we had, we first needed to dig into broken functionality, pay off technical debt, and improve code quality.

What a waste of time!

There is just one solution: Keep. Your. Mob. Together.

It’s just like in the real world: Leaving the mob will get you into trouble. When the times get tough, keep the team conversation going, keep on programming like a mob, conquer all obstacles that come your way together and solve 1 problem at the time!

Our mob is now stronger than ever. How is yours?

You May Also Like

These Stories on Productivity

Subscribe by Email

No Comments Yet

Let us know what you think