[Techniques] "Mobbing"
Closed this issue · 7 comments
What change would you like to make to the tech radar?
Move "Mobbing" to adopt.
Why do you believe this is valuable to Redgate?
Several teams have done lots of experiments with mobbing and it seems to have worked really well. Following Woody Zuill's workshop most if not all teams are planning to do a lot more of it. Therefore I think it can be moved out of "Explore".
Like any techniques, it shouldn't be applied blanket style, but we've found it works well in the following scenarios:
- You're working in an unknown area of the codebase
- You're trying to onboard a new starter
Where should this be on the tech radar?
Adopt
If this should be in the Explore ring, who is committed to exploring it?
Is there any useful guidance you could give on when mobbing is/isn't a good thing to do?
We wrote a blog post on mobbing in the Orca team a while back, which has some advice: https://medium.com/ingeniouslysimple/a-mob-of-orcas-fdfe0bbdc599
I've got some further thoughts since then which I'll try to collect and write here
Edit: Some more thoughts:
- Mobbing is exhausting
Even more than pair programming, mobbing is hard work. It requires a high level of engagement from everyone involved for long periods of time. - Mobbing is exclusionary
Unlike the promise of mobbing, it's very easy for some people to get "left at the back of the room" as passive observers, not feeling like they can contribute for long stretches, which is super demoralizing
We found can mitigate both of these to some extent, by taking breaks and switching drivers regularly, making sure everyone takes a turn and is included. You'll probably need to get some external timer (eg https://tomato-timer.com/) and be strict about sticking to it.
- Mobbing is very context-sensitive
We did a lot of mobbing in the Orca team because we were brand new in a brand new domain, didn't have a lot of work to do, and didn't really have a choice to do anything but mob. As the team matures we've been doing less and less mobbing over time. After Woody's workshop I think we want to address whether this is still appropriate, though.
To add to the above:
One big thing I picked up from Woody Zuill's workshop today is that mob programming requires really good team communication.
Woody suggested that teams actually start off practicing a strict Randori Kata where the team cycles through driver, navigator and observer roles every few minutes. The catch is that (at least to begin with) only the navigator can speak - the hard part is practising patience when you have a really good idea but possibly need to wait twenty minutes to suggest it! However this kind of discipline is vital if you want to have properly productive discussions in discussions in freeform mob programming.
After some in-person discussion I should clarify I still think we should adopt mob programming - these are just concerns about how it can go wrong. I think working through and addressing these concerns is a part of a team getting good at mobbing.
One big thing I picked up from Woody Zuill's workshop today is that mob programming requires really good team communication.
We could turn this on its head: Teams should be striving for good communication, and mob programming is one way to expose problems.
I understand there are some problems - and I totally agree with everything said. I'm not sure if mobbing will be done solely by any team, but it does seem that we have explored and it should now be adopted as an extra tool for the toolbox
This has been updated on the tech radar, so let's close this issue.