In last week's episode I introduced the idea of Pair Programming. A software development practice that has two developers working on the same thing on the same computer. One acting as the driver - the other as a navigator - with regular role reversal. I talked about, while there is an increase to the developer-hours spent on a problem, the benefits of faster delivery, better quality, knowledge sharing and better team communications soon outweighs the cost. In this episode, I want to talk about a similar software development practice - but much more amped up - mob programming.
Or listen at:
Published: Wed, 15 Jan 2020 16:58:33 GMT
Transcript
In last week's episode I introduced the idea of Pair Programming.
A software development practice that has two developers working on the same thing on the same computer. One acting as the driver - the other as a navigator - with regular role reversal.
I talked about, while there is an increase to the developer-hours spent on a problem, the benefits of faster delivery, better quality, knowledge sharing and better team communications soon outweighs the cost.
In this episode, I want to talk about a similar software development practice - but much more amped up - mob programming.
Wikipedia describes "Mob Programming" as:
"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. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time. With mob programming, the collaboration is extended to everyone on the team, while still using a single computer for writing the code and inputting it into the code base."
So where as pair programming has two people sat at the same computer, mob programming is more likely to be between 3 & 6 - the full team.
Similar to Pair Programming, this works by one person acting as the driver - operating the keyboard and mouse - while the rest of the team take on the role of navigator. They help to direct the driver through the work.
The role of driver is then rotated through the team - generally each driver having 5-15 minutes at the computer.
Due to the number of people involved, this will generally involve a bit more setup that pair programming.
A pair can start developing generally at anyone's desk.
A mob will generally need a space large enough for them to be able to sit comfortably, a large enough monitor so everyone can see and a whiteboard. They will also likely need to instigate and evolve rules to ensure that everyone is comfortable, engaged and productive.
I'll talk about some of those as I go through this episode.
Unlike the Pair Programming episode, I don't have a study available to use as a reference.
Even though Mob Programming has the same origin as Pair Programming - one of the Extreme Programming practices - It's fair to say that Mob Programming is not as widely adopted, understood or accepted as Pair Programming.
As such, unfortunately, I've yet to find a study on its benefits.
So most of this episode will be based on my personal experiences.
One of the best descriptions of the act of Mob Programming is from a software company called New Relic.
They equated Mob Programming to tending a campfire.
Once the campfire is lit, it keeps burning as long as there are campers to tend it and keep it going. We don't need all of the campers to be there - so if a camper needs to go do something else, they can - and they can rejoin the community round the campfire once they are ready.
With mob programming, once the team start, if someone needs to pop out of the room for whatever reason - maybe to handle a live problem - the mob continues working. That individual then joins back in once they have dealt with the distraction.
While this may not seem like a lot; one of the biggest impacts on software development productivity is interruption.
I talked about this in episode 7 when I introduced Lean. Task Switching is considered a significant source of waste as each interruption takes our developers out of their mental process causing a considerable cognitive load to return back to that state. The generally accepted impact is 15 minutes for every interruption.
From personal experience, I can certainly testify that it can become impossible to make forward progress on a difficult problem if you are subject to regular interruption. This is why in my younger years, it was common for me to work late in to the night or at weekends so that I could actually get my real work done free of distractions.
In a mob, rather than mental process being maintained just by the individual, it is by the team in the room. Thus if an individual in the room has to step out to deal with that interruption, then the mob continue to retain their current thought process and can continue to progress the task at hand.
The individual can then pick up on the mobs progress on their return.
This is not something that pair programming can provide. If one of a pair steps away to deal with an interruption - the pair is immediately broken. Any progress undertaken while one is away become effectively a presentation of "this is what I've done" on their return.
Having the mob greatly reduces the impact on the cognitive process from interruption.
That means progress on the task is faster.
And that means we are in a position to deliver a return on that investment quicker.
One comment I've read is that we already work in teams to deliver software products. Moving to Mob Programming is simple the same thing, but removing all the needless conversations.
I find this an interesting point of view.
By having everyone in the room making decisions and actively contributing to the work, you simply do away with a number of activities.
You don't need the team to explain their work to each other. They will have been present during the creation process. They understand why certain things where done in a certain ways.
There can be considerable effort in keeping everyone in a team "up to speed". Lean describes that as another source of waste - hand offs.
But at the risk of sounding like a cheap salesman, the benefits don't stop there;
The benefits coming from Pair Programming can be expected to be amplified by Mob Programming;
Having more minds on the problem;
- Further reduces the chance of writers block
- Increases the likelihood of better design
- Increases the resulting quality
- And increased the suitability of the work to the problem at hand
On that last point, having a number of people in the room does help with keeping the team honest and focused on good practices. It also promotes a high level of energy.
It is considerably more unlikely that an off topic deviation or over engineering won't be called out by someone in the group.
A single developer, even a pair, can find themselves going down a technical rabbit hole chasing the wrong thing ... Largely because it interests them.
That very human temptation is much easier spotted by a group when any developer can raise the question "are we going off topic here?"
As an aside; I've known plenty of business meetings that really needed someone like that developer to ask the same question.
The Mob Programming practice can be difficult to establish though.
I find that the initial developer reaction can be quite negative.
I know when I first started on it, I was definitely nervous to be involved.
While I would definitely consider myself a very good developer, that wasn't the role I'd been brought into perform. On that team I'd been brought in as a combination of architect, team lead and general problem solver.
And I was going to mob with full time developers with considerable more experience with the software product.
I will admit that I entered Mobbing with a certain level of trepidation - not least, the fear of embarrassment to the wider team.
The truth was considerably different;
My lack of historic experience was actually a positive.
It allowed me to question historic assumptions and practices. In some cases causing a course correct; while in others allowing me to catch up the team very rapidly.
I personally found it one of the best methods of onboarding to a team I'd even been through.
Not only do you learn the product quickly, you also learn to work with the team quickly.
You learn by doing. As part of that wider group.
You get fast feedback on your understanding. Rather than making an assumption on how the system works, then labouring under that incorrect assumption of days, weeks or even months - the group can correct those assumption quickly.
And in the same way it is great for sharing new techniques.
Very much a win win.
As with many software development practices, there will be rituals and rules that help to improve its effectiveness.
The big one for me is that everyone in the room has to be engaged.
I'm not normally one for edicts - but mobile phones and laptops are not welcome (other than the one we are working on).
Mob Programming is not about the minority doing the work, while the majority are checking Facebook, answering emails or watching cat videos.
They are there to be engaged in the problem at hand.
If for some reason they aren't engaged, they should leave the room, attend to what needs attending and return when they can engage. This is why the campfire analogy is so apt.
The team will need to have a shared understanding of their rules for mobbing - rules which will be arrived at over time and experience.
Things like;
- How long before they swap the driver
- How long they run a mobbing session for
- What types of work are appropriate for mobbing
- What types of work aren't appropriate for mobbing
- How they handle breaks to allow checking facebook and watching cat videos
These are all rules that the team will arrive at naturally.
From a personal perspective, I've found Mob Programming to be better than Pair Programming.
I find with Pair Programming that its easier to reach a option stalemate. If you have two people with strong opinions - when they reach something they differ on greatly it can be more challenging to resolve. It does seem to amplify conflict situations.
The good side of that is that because it comes to the surface it has to be dealt with. Coping strategies soon evolve. Even if it comes down to a simple coin-toss mechanism to provide a deciding vote.
I found that that the stalemate doesn't seem to occur so much in Mob Programming.
Don't get me wrong, contradicting strong options do surface - and in fact should be actively encouraged for the best outcomes. But the decision making process seems less likely to get stuck in analysis paralysis.
Generally the group will pick a decision and go with it. If it turns out to wrong later, they make the necessary adjustments. Often the forward momentum is more valuable than getting it right first time.
In this episode, I have introduced Mob Programming - in which a team of 3-6 developers work on the same problem around the same computer.
I've talked about both the benefits I find and address some of the perceived problems.
I've talked from my own perspective and why I really like using Mob Programming.
Mob Programming, more than probably any topic I've covered so far in this podcast series, is probably the most controversial.
To date, most of the topics I have covered would largely be considered good practice by most of the Software Development industry.
Mob Programming is much more on the edge of accepted practice.
I suspect a lot of this is due to a lack of exposure.
Its not a widely taught practice.
And I think it can be difficult to convince management to have faith in the process.
So if there is any message from this episode, it is to keep an open mind on the practice.
I believe it can provide a great return on investment. But first your team needs to feel that it is safe to experiment with it.
Again like Pair Programming - and a number of the practices I advocate in this series - the key here is not to force it. Rather, make it understand that it is not only allowed, but that its practice is encouraged to establish if it is of benefit.