Experimenting with mob programming to rebuild the gov.uk Verify front end
identityassurance.blog.gov.uk
identityassurance.blog.gov.uk
Suddenly no one wandered off into the weeds to deliberate on some inconsequential aspect of the code (this is a charitable euphemism for went off reading news sites!) The group drive to progress was greater than the individuals. As one individual's attention would wane, another would pick up the slack, keen to show they were engaged in front of their peers and that would have a self righting effect on the interest of the person who started to drift.
So for a while we plundered on, amazed by the power of our new tool. Productivity was up to where it should be, quality was excellent again, the junior dev was getting a real education too.
I started reflecting on why this was successful - I wondered if there was some insight I could reuse elsewhere. I slowly came to realise it was just a neat partial solution to an underlying much bigger problem.
Fixing the underlying engagement problem turned out to be a journey but it was good fun.
Mob programming has earned a place in my toolbox of life experience, but there's an inscription on the handle to remind me that its effectiveness could be a sign of deeper project issues.
To be clear I'm not saying this is the case for the OP's team! It was just one life experience point I thought was worth sharing.
But as always we are people and people like different things, but with mob programming I think you have a really good chance of succeeding. Just remember to take 5 min to explain how to do it before you start.
So if you go with mob programming and have one guy doing 50% typing whilst the other guys are thinking. In theory it could be just as efficient, with the added benefit that everyone understands the system and is onboard with the design. Plus the usual benefits of pair programming: you can train juniors, many eyes to catch the bugs, etc...
In my own team, we periodically pair up to do peer review and testing, and sometimes prototyping of new features. I try and avoid doing this more than about once a week, though.
Okay, now I understand. It's a way to solve the problem of very few people understanding the design. Seems an expensive solution, but the expense of your programmers not understanding the design of what they're working on can be pretty high as well, and good documentation is hard to write and sometimes hard to make people read. I don't know if it's that hard, but this would work as an alternative.
I suspect this only works when the problem being solved is pretty simple, or isn't actually a "problem" but only a question of layout and design.
I've been in a workshop with Woody Zuill, talks by Arlo Belshee, and my team has some mob programming under our belt. We don't use it exclusively, but it's a great tool to have in your toolbelt.
We have a skill-diverse team -- a tech lead, 4 web and backend developers, 2 iOS, 2 Android, and 2 QE (one of whom is moving toward a backend developer.) At any time. we may have 1-2 support tasks and a project. We have a range of junior to senior developers.
Sometimes, we have sufficiently broken-out work that we can keep everyone engaged at a single-stream, but even that's a polite fiction. The junior developers get stuck, which has them spinning their wheels for periods of time until they realize they're stuck, then bring in a more senior engineer whose work is then interrupted. Sometimes, the senior engineers get stuck in analysis paralysis where a discussion would be more productive. That jumps into an impromptu meeting which solves the problem but interrupts half the team as anyone interested hashes the problem out.
Then, there's the tech lead (me) who gets interrupted constantly to the point that it's not worth taking tasks sometimes. There's production support, cross-team support, and intra-team support. That isn't to mention the meetings. :)
And sometimes, the tasks on a project aren't parallelizable, especially at the beginning. It used to be that everyone would get into a giant room and discuss design, then break it out into tasks and go. Mob programming can replace that phase by having everyone in that room do the work to flesh out the idea.
Then there is the work to peer review a decision and test it. When a ticket is in peer review or test, that developer is in full interrupt mode. They may get work done on the next ticket, but it is historically a period of low productivity for a developer.
The fundamental hypothesis of mob programming is that the interruptions of a team combined with the overhead of process are high enough that condensing to a single workstream+ actually doesn't reduce productivity.
If a team is working on a mob, and a production support request comes in, I (or one member of the team) can peel off of the mob and figure it out. If a support ticket comes in, a member of the team can peel off and work on it, have it reviewed by another in the mob, then tested by another, and the single stream workflow is still going. It becomes easier to catch up on what has happened than return to it.
When working on hairier problems, it turns out that a distributed memory works better than holding it in one individual's head. It turns out that it can feel slower but the work happens quicker. Sticking points are resolved quicker rather than devolving into analysis paralysis.
It seems counter-intuitive that the work doesn't slow down, but the decrease in peer review and testing time (because QE has been involved from the beginning thinking about testing scenarios and how to test) that the reduction in overhead compensates for more people working on the same problem.
There are other paths to streamlining a team's efficiency, but this is an interesting one worth trying in some cases.
so it's pair programming, but with 10 people in front of the same computer ?
I still don't get why this 'multiple people on one computer' thing would be helpful though. I mean, couldn't a team working on the same site on multiple computers do pretty much the same thing with the bonus of a quicker turn around? Seems like micromanagement gone insane...
In my view mob/pair programming is a very inefficient way to work. I guess it depends on the people, but personally I think much more clearly alone than in a group setting. Have many eyes on code is great and I'm all for peer review, but a mob making decisions is a recipe for group think and the less dominant personalities (and probably best coders) being ignored.
How are you going to get your skills recognized by your teammates, if you avoid working with them? Of course you're being ignored by them: you're ignoring them the rest of the time!
In my experience, in a context of technical arguments, great speakers with doubtful technical skills don't last very long against shy highly-skilled techies pointing out relevant weaknesses in the proposed solution, and asking tough questions.
Why are the less dominant personalities probably the best coders?
I like this as a disrupter of rote and a way of getting many eyes rapidly in the same place.
Now we just need a Twitch channel...