Thomas Desmond has helped me get my head around an example of something I've been interested in but haven't actually been able to actively participate in... what does Mob Programming actually look like?
I understand it as a concept but truth be told, programming in my organization beyond a pair arrangement is... challenging. The biggest challenge is the fact that we are all distributed. We've tried programming as a group via Hangouts or using tmux but again, it's a challenge to get that done with more than to people. Thomas is showing how is organization sets up these massive systems with multiple big screens, with multiple keyboards on rolling desks that can go anywhere in the office. The key idea here is that all of the people (optimized to four) are in the same place, at the same time, talking together simultaneously, and all interacting on the same computer.
Thomas is describing a situation where they mob program on all production code. As in, they don't have their own desks. They work as a group on a single task; designing, coding, testing, and releasing all together. The thought of being able to do this all day, every day, on all projects both seems cool and a little weird. In the neat way, not the unnerving way.
A tool that they use is called "Mobster" (neat, need to look this up) that has limites on who can be the driver (IOW, hands on the keyboard) and who can be the navigator (guiding direction but not necessarily behind the wheel) at any given time. The goal is that the roles switch and everyone gets their turn. For an idea to be implemented one of the navigators must be able to explain the idea clearly so that the driver can implement the idea. Ideally, everything is explained, everyone else in the group can hear the idea(s), and they can comment on the idea before it actually gets implemented.
I have struggled with where I would be effective as a tester in a Mob Programming environment and now that I have seen it explained as implemented by Hunter Industries. They actually throw new people right into the mix. Counter-intuitively, they come up to speed faster this way than they would if they were to be trying to get up to speed in a traditional development environment.
Thomas emphasizes that the benefits of mob programming are:
- live code reviews
- sharing knowledge
- greater idea sharing
- fewer meetings
- more engagement
- increased code experimentation
I must confess that this is a lot more tangible an idea now and it makes me excited to see if/how we might be able to implement it. Any thoughts on how to mob while fully distributed, let me know, please :).