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.
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.