Life in the mob

Our team consisted of four people. We worked together in an Agile manner, which means that every two weeks we jointly formulated new goals for our sprints.
Here’s a brief digest of "living in the mob" for several months – day in, day out. We almost exclusively used the ‘strong’ mob approach where we had the ‘driver’ sitting at the keyboard and the group as ‘navigators’ telling the driver what to do. For screen-sharing we used Microsoft Teams.

• mob is a great way to share knowledge between peers and establish working approaches: coding style, best practices, tools, IDE settings, git(hub) working approaches, bash hacks etc.
• mob makes onboarding people easier – throw them in at the deep end and let them rotate between driver/navigator roles :)
• the team can solve common setup troubles together, as everybody needs to get dev topics working locally: every developer machine needs to work in similar ways to be able to participate as driver
  
  • Terraform, GCP, Java, SDKs etc.
  • scripts need to run everywhere, not just in the CI/CD-pipeline (Linux, Mac, Windows)

• there’s no pressure to perform as driver
  
  • just listen to what your navigators say
  • no need to think and type
  • less pressure on the driver than in a classic "I share my screen and do all the work" setups
  • people will be more willing to act as driver, especially juniors as they do not need to ‘perform’ in front of the group

• navigators need to express their thoughts to everybody including the driver
  
  • so everyone can follow more easily (and the ten times developer ‘black-belt’ developers don’t run away)

• the team can solve questions/challenges on the spot instead of later (read: “probably never”)
• the team develops a shared feeling for the team sprint goal
• a high ‘bus factor’ develops – everybody knows what is going on and anybody can take over in case of a sudden absence
• there’s no need for additional sync meetings as everybody is already in the loop
• no peer reviews are needed as every Git commit gets a ‘reviewed-by’ from the navigators
• it’s easier to develop common ground for code standards/style, architecture, ci/cd and testing, as the team members can share their opinions with everyone instantly
• it’s easier to get to know your (new) colleagues when launching a team from scratch!

Tools we use:

• greenfield on Google Cloud Platform (GCP)
• APIs with two neighbouring teams, currently async; messaging via GCP Pub/Sub, later REST and UI integration into the big ‘supplier portal’
• Java, Spring Boot, Docker, Terraform, Github (Actions), CI/CD, Google Cloud Platform (Pub/Sub, Cloud Spanner), DevSecOps (‘you build it, you run it’).

After more than half a year in the mob, as I mentioned we’re thrilled with this form of collaboration. But of course, there are also some challenges and you need to be aware of these before you decide to try out this programming approach.

Our challenges summarized in brief:

• ‘hiding’ in the mob: it can be harder to evaluate new team members as there is a chance for them to ‘seek cover’ in the mob
• potential high pressure to perform when joining the mob, especially for people who are used to working on their own and deliver a ‘fixed’ product
• over-detailed discussions – somebody needs to moderate and focus on the story and sprint goals
• hard to leave the mob behind – I work part-time so there is always that point in the afternoon where I have to say "see you tomorrow"
• hard to parallelize on stories as the mob works on one story at a time
• living in the mob can sometimes be hard and exhausting – focusing, discussing, and coding together can and will drain your batteries
• there’s a danger of leaving people behind who cannot follow and express their thoughts
• you quickly get used to working with other people, which can trigger a fear of working and/or deciding on your own without input or backup from the mob
• it’s harder for junior team members to actively discuss topics in the mob approach.

When we started programming in the mob, I had already gained some experience. Half a year later, however, we are much smarter and have learned a lot!

Our most important learnings:

• before you start, give a clear intro to the mob sessions and explain the ‘why’
  
  • set the stage so that everybody feels comfortable
  • give everybody the chance to show ‘weakness’
  • there is nobody in the world who knows everything and nobody is perfect
  • failure is part of the business #failfast

• make sure everybody is able to screen-share (sufficient Internet bandwidth at home, good enough camera, quiet space, etc.)
• rotate often (15 min.) – we use the Cuckoo timer 
• create a dedicated MS Teams channel to host your mob sessions, e.g. named ‘mob sessions / calls calls calls’

• start a video session where everybody can join (Devs, Agile Master (AM), Product Owner (PO)                   etc.) and knows where you are
• give the video sessions funny names :)

• AM and PO can join the mob session for your daily stand-up
• git commit message with ‘reviewed-by:’ mob members (use template)