Mob programming or Pairing programming... why not both!

A lot of teams have heard of pairing. Some have even heard of mobbing. Me? I've found both to be useful -- the spoiler is that it's tied to the maturity of a team which should be used, and when.

First, a "team" it starts out as a collection of people, a grouping. Sure they work together - sort of and sure they combine their efforts from time to time. At some point, pairing becomes a suggestion for the sake of spreading knowledge and getting others up to speed on the way things are done or more often, the silly things needed to get things to work -- I call this lock giggling. If you've ever had a lock or some mechinism that requires a special, precise sequence to work, that's lock giggling.

Anyway, when I get a hold of a team group of people, we start by mobbing on whatever problem is in front of us. Everyone, all of us are required. It doesn't matter if your a product owner, tester, developer -- everyone means EVERYONE. At first, this is uncomfortable for a number of reasons. The biggest one I've seen occur time and time again : All of those small errors we all make, every single one of them ...will now be visible

After a day or two of mobbing, a team begins to form. Those little errors we're all scared of go away -- team empathy kicks up because solutions are found and the team is better for it. A group that once had no idea who was good at... what starts to become more T shaped on all ends. Exposure becomes natural and welcome, conversations are more focused and inclusive. "You could do that faster with a keyboard shortcut", "hey I got a script for that", "I hate this, can someone find a better way to do this?" Eventually, a question comes up around needing to continue as one big mob. This is where I introduce Diverge, Converge.

Mobbing is still at the core, but with a twist - a divergence of the main group into smaller mobs or pairs. As the mob understands the area with most risk/unknowns, there's a point were the break is natural. For example, let's say a data structure is the biggest unknown -- the mob digs into that area, discovers the data isn't what they need, but the parts are all there. Since there's a front end part of this, it's decided these can be worked on at the same time and the divergence begins. Some assumptions are made or up front decisions decided (the json format, the object structure, what's in the request, etc) and the mob breaks into two mobs or pairs.

These mini-mobs or pairs must be in constant contact -- decisions will come quickly so both sides need to know or be involved. As the feature comes to a close, there's another decision point : do you combine efforts to finish or is another item picked up? There's a risk with picking up a new part - WIP (work in progress) increases, others could miss out on discovery / learnings, etc. I prefer to keep a low WIP and as a team becomes ...well, a team, they can confidently decide one way or the other.

I've also found this to scale really well and even be effective on things that aren't well defined. Start with a big ugly problem, give it to a team or a group of teams and follow the same pattern. Attack the highest risk or unknown area first and watch the breakdown of work. Sometimes this will fall out as parts are identified that need created, modified or investigated further (for prototyping, customer interviews, etc).