The performance of one of the teams I work with as a Scrum Master has been stalling for while. Things are taking longer than expected. Problems are being bypassed instead of solved. "We have to produce features as fast as we can" is the usual explanation. But there is also some “fear of the unknown” as people don't like to go out of their comfort zone.

I’ve tried many approaches to solve this. Highlighting problems during retrospectives. Suggesting tackling this or that problem during the sprint. Offering to network with some “experts”. Encouraging owning problems instead of finding an external owner to push it onto. And so on. But sofar, the team managed to wiggle itself out of the problems.

A few weeks ago, I stumbled upon this video from Henrik Kniberg. It prescribes the optimization of flow before the optimization of resource utilization:

I suggested to reflect on this topic during one of our retrospectives:

  • We first zoomed in onto our current flow and utilization levels, via a self assessment. As expected, utilization was high whereas flow was low.
  • Then I used a production-line metaphor to introduce the notion of slack time.
  • Finally we devised on how we could invest this time to improve our flow.

But first things first, we had to find out what our actually is. Here are some of the things that destroy our productivity and thus our flow:

  • Hand-offs between developers, teams or departments
  • Waiting for other developers, teams or departments
  • Meetings that inherently prevent ad-hoc decisions
  • Unfinished code that you're not actively working on
  • Unclear understanding between team members
  • Delayed feedback on errors you've made
  • Integration problems of various kinds

How long would it take to develop a user-story if those productivity killers were not slowing us down? This is the major question we asked ourselves. To find this out, we decided to use mob-programming:

Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer (Wikipedia)

For one week the 8 team members sat together in front of a projector, rotating at the keyboard. We worked one task at the time. Our team comprises developers, testers and analysts. The three disciplines unfortunately don't overlap much yet. Even though some people felt like not being able to contribute much at some time, they remained in the mob. One constraint we gave ourselves was to write down as much observations as we can.

In one week, we delivered 1/2 of the output of a normal week. Which is better than the 1/4 or worse some had expected. We wrote down a lot of issues and even solved a few ones. We've suggested improvements in some areas we do not control. We also realized that nobody (except me) in the team is observing "how we work".

I didn't give the team much guidance on how to mob. I kind of expected them to GoogleBing it (any "ZiW-Member" reading this? :P)... which they did not. One of the big lessons they learned was the rotation of the driver. We rotated the "driver" on a task basis (30-60 min). We realized that he/she was burning out very fast, while others were falling asleep. Who would have thought that it is quite hard to code, think and communicate with 6 other persons at the same time?

All in all, mob-programming is proving itself very effective once again. All the dysfunctions of the team surfaced with this organizational change. We are observing a lot of issues and it is hard to ignore them. Thus, we are improving.

For me, this has been a silver bullet once again. I hope the team will start mobbing right away in the new year. I will sure advocate for continuing this experiment for at least a few months... until we tweak our flow to new heights.

Have you done mob-programming before? What's your experience with it?

Photo by rawpixel on Unsplash