Journeyman: Sqore

It was Wednesday morning and I was in somewhat of a sour mood. The previous day's mob programming session hadn't progressed in any way I thought it would. To a greater extent than in other novice mobs I have attempted to facilitate, people had come and gone over the day. In fact, half the time the mob was down to only two developers, essentially turning it into pair programming! Part of me wanted to give up and concede defeat. Still, I wanted to find out what had happened. In failure lies an opportunity to learn.

Mob task introduction

Unexpectedly, I learnt, or rather was reminded, that I'm an impatient man. When I came in to the Sqore office, I certainly didn't expect anyone to positively answer Chu's question.

- Who wants to mob program today?

Shortly after, a mob of four had gathered in an attic conference room. Picking up from the previous day, the work on prototyping more granular access controls continued. The previous day's mob session had started out a bit rowdy, but today I didn't have to moderate the noise level nearly as much. As I had pointed out, in one's eagerness to express one's views and ideas, is all to easy to slip into a state of instructing rather than gently guiding. Apparently this mob had started to realise that and it was also one of the key points made during the retrospective held at the end of the day.

Post-mob retrospective

Sqore mob retro

Everyone that had been part of the mob, even if only for an hour or so, came to the retro. I had them individually answer three questions by writing post-its. To leave some time for the ten participants to discuss the findings, the questions were limited to:

  • What was best?
  • What would you like to change?
  • What surprised you the most?

While the surprises, in typical fashion, were varied, there was almost complete consensus that the best part about mob programming had been the knowledge sharing, whereas the most desired change to be made was the way the team communicates.

Sqore mob

Make no mistake. Mob programming is unforgiving in the sense that a team's weaknesses surface. But this is a good thing as the first step in addressing them is to become aware of them and acknowledge them.

To my delight, the team not only wanted to mob program again in the future, but decided to continue working on the feature as a mob the very next day!

In addition at least one team is considering frequent use of the format. I'm delighted and a bit bewildered that Sqore took to mob programming so well given what I thought had been a so-so start. It just shows that as a facilitator you need to be patient, pause, and let things sink in a little before admitting failure.