One Year of Remote Mob Programming

Content By agilealliance .org

Mob programming is an extremely effective way to develop software, not only in-person, but also remotely. Over the past year, my team and I have been exploring ways to collaborate while working remotely. While there are some requisites to make remote mob programming effective, I have found it to be a surprisingly productive way to work. In this report I share the most important lessons learned . It uses websockets, so everyone using the timer has the same time and all the same settings almost instantaneously. Mob members can easily be added or removed from the timer list, and can be easily skipped if they are away or busy when their turn as driver or navigator comes up. This timer defaults to having designated navigator and driver roles. Mob members can change the names of these roles or add additional roles if desired. There is also a “goals” feature that our team hasn’t used, but that some could find useful.

One drawback to using an online mob timer instead of one installed locally is a lack of integration with the operating system. The biggest example of this is a feature that many installable mob timers have which blocks the entire screen when it is time to switch roles. This may sound disruptive, but is a great way to force the mob members to not ignore the timer. With online mob timers, having the timer go full screen automatically when the rotation time elapses is not possible. It is possible to have browser notifications that can optionally integrate with the operating system notification system. This helps, but is still easier to ignore than a full screen application.

Because of this drawback of online mob timers, we do sometimes find ourselves forgetting to start the timer when a new driver and navigator take over. This sometimes causes one set of mob members to have a longer rotation than they otherwise would. As mentioned above, it is also easier to miss when the rotation timer has elapsed, which causes one set of mob members to have a longer rotation. This is an area of potential future experimentation and improvement for us.

3.      What We Learned

Over the course of the last year, we have learned that many of the skills needed for in-person mob programming translate to remote mob programming. Many of the things needed for successful in-person mob programming are also needed for remote mob programming, such as having adequate equipment and having a mob timer. Some requirements for successful in-person mob programming translate mostly unaltered to remote mob programming, while other requirements need to be adapted, such as ways to be able to contribute to the code. We have also learned that there are some requirements for remote mob programming that are mostly unique, such as ensuring that mob members have the correct tools to communicate.

We have learned that remote mob programming is effective. Given the right tools and conditions, remote mob programming is as effective as in-person mob programming. We have learned that remote mob programming is a productive way to craft high quality code and deliver valuable features to our customers frequently. Remote mob programming pairs well with technical and other practices, such as test driven development, continuous integration, push button deployments, limiting work in process, and eliminating waste.

4.      Acknowledgements

I would like to thank Woody Zuill for, if not inventing mob programming, definitely popularizing it. I would like to thank those who have been on my team during this last year. Thanks Ryan, Kevin, Charles, Eric, Danny, Neil, Judson, Dani, Zac, and Nate! Thanks to Dave, Mike, Allan, Jacob and others in management positions at Emmersion for understanding and promoting the importance of mob programming and other technical practices. And thanks to the conference organizers and volunteers for their huge amounts of effort that go into organizing events and schedules, selecting presenters, and all the other numerous things required to organize a quality conference. And finally, thanks to Ademar, my shepherd, for his great input on and help with this paper.

5.      References

  1. Zuill, Woody. Mob Programming – A Whole Team Approach. Agile Alliance. 2014. resources/experience-reports/mob-programming-agile2014/.
  2. Fowler, Martin. PairProgramming. MartinFowler.com. https://martinfowler.com/bliki/PairProgramming.html.
  3. Zoom. https://zoom.us/.
  4. Slack. https://slack.com/.
  5. Kanbanize. https://kanbanize.com/.
  6. Miro. https://miro.com/.
  7. Harrer, Simon. Remote Mob Programming. https://github.com/remotemobprogramming/mob.
  8. AnyDesk. https://anydesk.com/en.
  9. Larsen, Willem. Mob Programming: The Role Playing Game. https://github.com/willemlarsen/mobprogrammingrpg.
  10. Barry, Alex. MobTime. https://mobti.me/.

Leave a Reply

Your email address will not be published. Required fields are marked *