Skip to content

Latest commit

 

History

History
64 lines (42 loc) · 4.62 KB

mob_programming_manual.md

File metadata and controls

64 lines (42 loc) · 4.62 KB
Raw

The Manual of Mob

A guide to mob programming

The Manual of Mob provides guidelines for mob programming. Mobbing is similar to pair programming but with a roomful of people. The RGSoC group The Standard Librarians, who created this guideline, found this guide an incredibly effective tool to refer back to while mobbing. Mob programming keeps everyone on the same page while they are working and the project keeps moving forward through aggregated knowledge. Mobbing allows for an incredible learning environment where a group of people with varied experience levels, including a beginner or a new comer, can help make progress on a project from the very first day. This guide is meant to be a flexible tool for you to use and change to suit your needs. It is a great way to start and a good thing to come back to after you work together for a while.

==================

Values

Kindness • Consideration • Respect

We mob in a round robin fashion. Everyone is seated around the room; they physically switch chairs at the end of ten minute increments of time as recorded by a buzzer. The code is projected on a screen that all can see. The person at the computer is called the Driver. The person to their right is the Navigator. The Standard Librarians have established roles and rules to prevent some of the earlier challenges they encountered while mobbing. This document is in flux as they figure out better and more effective ways to work together. They value effectiveness over efficiency.

==================

These are the roles that have been defined and the expectations for each.

Roles

Driver

Learning Goal: practice keyboarding, listening, and translating commands

  • An intelligent keyboard.
  • Doesn't type unless directed.
  • Has a backseat driver role.
  • The driver can say, "IDK, I need help."

Navigator

Learning Goal: articulating actions/next steps, solving programming problems

  • Express high-level intent to the driver/keyboardist.
    ie: say “show all files including the hidden ones” instead of “ls -a”
  • They work on the problem at hand to move the group and the project forward.
  • If they are not sure of how to solve the problem they can ask the group for assistance
  • If the Driver has made a spelling or syntactical error wait until the last possible moment to correct them.

Backseat Driver/s

Learning Goal: learning to listen, absorbing information and being engaged enough to help if the navigator needs assistance.

  • If the primary navigator doesn’t know what to do next, they can ask the rest of the group.
  • Raise you hand and wait for the Navigator to ask for you help. Sometimes the Navigator needs a few moments to consider the problem and come up with a solution.
  • Be ready for your turn navigating.
  • Search for solutions but try to be present above all.

Rules

  1. No reaching in when someone is at their keyboard. If someone reaches in, you yell “Hot Potato”.
  2. Keep a learning journal, recap what you learned at the end of the session.
  3. Be kind with other people’s equipment, and be gentle with keyboards. Make sure your hands are clean.
  4. Keep regular breaks.
  5. When people work remotely, loop them in with audio, video and screen share.
  6. Respect the timer, but be flexible about times when someone is finishing something.
  7. If some people are more familiar with the project being worked on they can be put at the beginning of the mob rotation cycle so the new comers can get up to speed with the issues at hand. The new comers will figure out the next steps as they come along instead of the entire project being explained which takes time away from working on the project.
  8. If there is a big group keep the rotations short so everyone gets a chance as Navigator and Driver.
  9. Give the navigator quiet time to figure out the problem at hand, you will get your turn soon enough. Being "on the spot" like this really helps your knowlege grow. It is at this point where you realize if you know what you are doing. If you don't know what to do at that time try not to just defer to someone who does. Instead ask a lot of questions until you can figure a direction. Run the tests again or review the intent of the issue. Give yourself a chance then ask the Backseat Drivers if you are really stuck.
  10. Rules can be added at will as incidents arise.
  11. ASK QUESTIONS. Take times to review concepts.

This is a guide to help the mobbing session run smoothly and for everyone to have the chance to contribute not just the most knowledgeable, loudest people in the room. It is an Agile guide that can change to meet your purposes.