Introduction
Today I attended a 1-day workshop organised and run by Woody Zuill who, along with his colleagues at Hunter Industries, originally developed the idea of ‘mob programming’. This workshop was part of a major conference being held in Manchester called Agile Manchester and I heard about it after attending a meetup last month called Manchester Tech Nights. I had been invited to that meetup to represent testing with a 5 minute lightning talk. It was a great experience and even better that I found out about this workshop and conference from talking to people there! After finding out, I just had to book my ticket and attend, it seemed like a great opportunity to really understand what mob programming was all about without having to travel very far.
What on earth is ‘mob programming’?
Basically, it’s the idea of taking pair programming and applying it to the whole team. So the whole team works on a single piece of work at a time, with a driver and navigator rotating at timed intervals. The proposed benefits of this idea is that when we work separately, we deliver both the best and worst of our work whereas with the whole team present, we support each other and produce the best of our work at all times. You can read a much better written description by Woody himself here.
Why was I interested in this workshop?
Barely a year ago I only just started to explore the wider testing community and start reading and listening to different experiences and ideas on testing. Through that research I came across Maaret Pyhäjärvi’s blog and her talks from previous TestBash conferences on the Ministry of Testing’s Dojo. Some of the particular topics that caught my interest were on her recent experiences of working as the sole tester within a large group of developers and the challenges in managing this situation. Through her talks and blogs she mentioned the idea of mob programming (or mob testing) as a means to both learn very quickly but also cultivate understanding and respect across a cross-functional team. My curiosity was really piqued when I had an all too brief taste of pairing with Llewelyn Falco as well hearing his lightning talk on the benefits of mobbing at TestBash Brighton 2016.
I’ve started to experience the need to adapt testing to become more integrated in development processes in agile environments and mob programming struck me as a potentially useful way to encourage the spirit of not only developers and testers working together, but also the wider team, be that product owners, designers or scrum masters. The workshop presented a great (and well timed!) opportunity to observe how it might be done and get a better idea of why exactly Woody and his team back at Hunter Industries even came up with this approach.
The workshop and what I learned
The workshop itself was the kind of friendly, fun and relaxed workshop I’ve come to expect after the high standards set for me back at TestBash! Woody was very honest and open in explaining that he was only here to explain what mob programming is and how it has worked for him in the past. He didn’t claim that this approach would work for everybody. The workshop was split into two parts - the first part was where Woody explained the context of how he and his developed this idea and we took part in exercises to observe the benefits of working together as a team. The second part was where we actually wrote code as a mob!
The main reasons that led to mob programming as an approach being developed were:
- Originally Woody wanted to encourage his developers to recognise bad code. He wanted to achieve this by allowing people to figure things out and practice their craft together regularly - in the same way as any sports team.
- He also wanted to overcome the challenge of getting access to project managers to answer questions that blocked work - involving them in the mob helped provide immediate feedback to any questions the developers had.
- However, to achieve this, he didn’t force people to participate, everyone was invited but attending was not compulsory. This allowed people to get comfortable with the idea before they attended.
- Hence, the only reason the approach of mobbing worked was because the team decided to do it. It was not forced and was developed simply by trying ideas and trying to solve problems when they arose.
I really liked how open and honest this explanation was of the context and how this approach was developed. It was exactly what I was looking to learn by attending this workshop and considering how it might be useful (or might not be useful!) back at my workplace or in future.
Coding again!
Although I’ve been writing a fair bit of Python the last 3 years I haven’t really touched any more advanced programming than that for about 6 years (since my degree basically!). I was relishing attending this workshop and throwing myself in with a group of experienced programmers and trying to keep up. Having read and heard Maaret’s experiences with mob programming as a tester and how it was a great way to learn, I really wanted to experience this and see this benefit for myself. Not to mention, to hopefully contribute something with my skills as a tester. Having said that, I was reasonably confident that I could somewhat keep up due to my background in my degree and my recent Python experience.
It was a lot of fun! I didn’t feel too ashamed by my rustiness with Java and I started getting back into it pretty quickly. It was awesome to see how quickly we started interacting as teams, at first I was concerned that having less experienced programmers (or people who didn’t know any code at all!) would drag the team down. But I actually felt the less experienced programmers got up to speed remarkably quickly! It’s really quite impressive (and not at all surprising when you think about it!) how quickly people can pick things up when they’re thrown in the deep end but given the support to perform.
Woody was a great facilitator and I learned a fair few tips on how to conduct these sessions successfully - the main points being:
- The hardest part is to shut up and let everyone have an equal say! Treating everyone with consideration and respect was key, so that the whole team is on the same page.
- The key part that I think testers (and non-technical people) really bring a lot of value to mobs is focusing the team on considering each task in the language of plain english rather than in ‘coding language’. There was an emphasis on navigators giving instructions in english rather than specifying code. Although it may be necessary to support non-technical people to guide them through typing specific characters, it means as a tester you can easily navigate as you can focus on the objective at hand rather than technically how to solve a problem.
What does this all have to do with testing?
I believe that in agile environments and with ideas like continuous development it is generally no longer very effective to conduct all (note - perhaps some is still necessary) of your testing at the end of a development cycle or separately to development. Not only does this quickly lead to ‘testing bottlenecks’ but it just doesn’t make a lot of sense to be discovering basic flaws in logic or implementation only after development has finished. We could be bringing our skills as testers much earlier in the development cycle and discovering these flaws earlier and more cheaply. If we can challenge assumptions made before the code is even written, or even as the code is written, we will surely prevent some of the major re-factoring or re-writes that sometimes occur.
I personally see mob programming as a potential tool for encouraging much better collaboration between developers and testers as well as product owners and designers. The idea that ‘everyone is a developer’ who simply bring different skills is something that makes a lot of sense to me and I believe our testing can be become much more effective when we understand more about the code we test.
However, as always, maintaining critical distance and trying to always be an advocate for the customer is key to our work. But I strongly believe we can bring those values as well as learn and contribute more from a technical perspective without compromising those values.
What next?
Now that I’m armed with some better knowledge of the context of how mob programming came about and some experience of what it’s like to be a part of and facilitate, I’ll carefully consider it as a tool to suggest in future. I can see that if a team is already collaborating and working well together, pairing and mobbing in an informal sense, that this approach may not be necessary. However, I’m looking to build a healthy stock of ideas and tools to try when the time arises and if nothing else it’s always useful to try these ideas and see if there is anything we like about them.
In the scenario of rapidly sharing knowledge about a particular technology or language, I think this formal approach of mob programming could be very very effective and I will be looking out for opportunities to do this.
In summary, I highly recommend this workshop if you’re interested in the subject! As I’ve said a lot in this blog post, Woody is great and I got everything out of the workshop that I wanted to.
