In Far From the mobbing crowd the Cucumber guys explain how they combined mob programming and remote work. Matt and Steve also explain that a mob is both resilient and fast. They explain that they sometimes have to leave the mob for 15 minutes or so. When they come back the code has changed a lot ! It’s as if the mob continues no matter who’s in.
One of them then suggests an idea.
With enough people around the world, we could run a mob that never stops!
What’s the point ?
In The Ultimate Guide To Remote Work the Zapier team explains how to take advantage of time zones and remote work. We can get a feature done faster by having a pair of programmers from different time zones work on it ! Instead of a single day of work in 24h, you get 2 ! We could get features in half the time.
In Lean Management, the time to get a feature is called the cycle time. A short cycle time has a lot of benefits. You get feedback faster. The needs of the users have less risk of changing. You’ll get less interruptions, which increases your focus and effectiveness.
Zapier found that time zones and remote work can divide the cycle time by 2. This is already a major improvement. Let’s replace this pair of programmers by a mob ! The cucumber guys explain that 4 hours of mobbing is about the most someone can do in a single day. With a mob of 5 people at any time, that’s around :
24/4 * 5 = 30
30 developers working on the same feature, full time !
What would be the effect of this on cycle time ? I don’t expect it to cut the cycle time by 30, but from my experience with pairing, I’d still expect a drastic reduction. Imagine a complex feature that you estimated to 30 days to finish. Could it be done in less than a week ?
Working on a single story at a time, we could forget merges and complex CIs ! More generally, it would lead to an important Work In Progress (WIP) reduction. Very related to cycle time, reducing the WIP also brings a lot of improvements. One of the most important is an increased throughput. Here is a great article detailing the benefits of reducing the WIP.
💡 Mob programming reduces WIP and cycle time
And what about the team structure ? Could a team of 30 be effective in this setting ? 7 is the magic count for a team size. If we could grow past this number, we could imagine completely new org charts :
- More decentralized
- More resilient
- Less synchronization and coordination overhead
Let’s try it !
As any new idea, it’s also very likely to fail miserably … The communication overhead could turn out overwhelming. The mob might not be resilient to frequent changes after all. It could work but not bring any reduction to cycle time. There is a ton of reasons for this to fail.
The best way to find out is to try !
💡 Stupid ideas that work become great ideas. [XP moto]
We just need to find enough people spread around the world to give it a try. Could we do 48 hours straight of mobbing and go twice around the globe ?
We would need people distributed across all time zones. Pairing and incremental design would be de-facto practices. It would work better with people used to XP.
We’d need at least a mob of 3 doing 5h of mobbing per day for 2 days. That would be :
24/5*3 = 15
We could go with 15 people but 30 would be ideal. Once we have enough volunteers, we’ll have to agree on a few other things :
- A date for the experiment
- A subject we can all understand
- Technologies and tools to use
- A time-schedule
There’s nothing impossible here !
Call for volunteers
If you want to participate, leave a comment below or contact me through twitter. I’ll keep you updated about the status of the experiment.
One last thing … as you’ve guessed this is an experiment, not paid work. Anything we would produce will be open sourced on Github.