Kundo can do mob programming

As I mentioned in a previous post, I was invited to facilitate a mob programming session at another company, namely Kundo which is primarily a Python shop. This Wednesday I took some time off and headed over for lunch and an afternoon of mob programming. I've before shared some of my experiences, but this would be the first time I actually facilitated another team.

In preparation of the session, I cautioned against mobbing on a trivial piece of code and instead adviced picking something that at least ticked a few of the following boxes:

• something new
• something unknown
• something difficult
• something there is no clear consensus around

Chatting about it over lunch the team decided on isolating the use of a third-party Elasticsearch library so that it could be replaced by a newer, better maintained one.

Before starting, I went through a few aspects of mob programming where it's good to be very explicit. For example, would conflicts be resolved by the driver having the last say or would the mob use what Llewellyn Falco refers to as strong pairing, i.e. the driver is effectively an input device without a will of his or her own? Given the small size of the mob, they decided to have the driver be an active participant with the final say if things bogged down during a rotation. I stressed the fact that it's only twenty minutes of navigation before touching the keyboard again, so even if one thought the mob went down the wrong path, that's quite alright. As expected, this proved to never be a problem at all, but I thought it was worthwhile to agree on a few initial ground rules.

Given that the mob was no larger than three developers with a fourth joining us remotely as a navigator we rotated every ten minutes. After the first few rotations I interjected that clarifying the goal of the refactoring could be a good idea as it would lead to better focus. Other than that, the team switched effortlessly between navigating and driving. If someone had to step out for a minute they could do so without stopping the progress of the mob. I couldn't have wished for a better display of the inbuilt redundancy of working in a mob as opposed to going solo.

After an hour we broke for a fika and delicious wallonbullar. Getting back, our remote navigator decided to not join us for the second part. I must admit that effectively introducing mob programming to remote workers for now is beyond me, though I know that Pat Maddox has been doing it as part of his RubySteps series. Nevertheless, the team seemed inclined to mob program again the next week when the remote developer would be in the office.

Getting back after the fika, it took a total of 10 seconds for the mob to pick up where they left off and continue working on the refactoring. Things went so smoothly when it comes to the practice of mob programming that I only occasionally had anything to facilitate, and this for a team that for a number of reasons barely ever pair program! They proved to be naturals at mob programming and I think this largely stems from the mutual respect they continously showed one another. In such a safe environment, anyone would dare to show their imperfect code.

After another few hours, we held a short retrospective during which I let the team answer the following five questions:

• what was best?
• what was most difficult?
• what have you learnt about your collective code?
• what have you learnt about your team?
• what have you learnt about yourself?

For some, these questions may well have been the answer to the second question.

In the end, the team's experience was a positive one and the participants seemed all interested in trying it again. Personally, I very much enjoyed facilitating the team's first mob programming session and I hope to hear about their future experiences and adventures.

Thanks Kundo for having me!