Skip to content
 

Mob Programming Basics

Some info about our Mob Programming Approach

Mobbing work area

Basic Mob Work Area

Most of our work is done sitting together in the group work area. We try to make it as comfortable as possible. There is plenty of room and we can easily have others join us whenever needed.

Our work area is configured out of some standard cubicle walls, and is about 16ft x 18ft. It works pretty nicely, although earlier we worked in a separate room for a while and found that to be even better.

The Computer

There is only one computer in use for programming. We also have other computers sitting around that we use while we are mobbing for researching, looking at databases, writing emails, etc. in parallel with the programming. There will often be more than one person searching for information about some problem or new technology we are trying to use. We all stay together and communicate continually about what we are learning.

Projectors

Mob Screen View

There are two projectors which we use as dual monitors. We project onto a wall we have had painted with a matte white paint that works well for this purpose. After experimenting with the height, distance, brightness, and other settings we have found a basic setup that works nicely for everyone. The projectors are the same model as each other and are pretty high quality.

Keyboard/Mouse

There are two keyboards and two mice so everyone has a choice that works for them. We experimented with several different keyboards and settled on two different setups (a “regular” one and a “natural” one.) Hand sanitizer is always available.

Chairs and Tables

We use our “own chairs” which we move around as we take on the different roles (Driver or Navigator). This way we don’t need to constantly readjust the chairs. Our chairs are good quality.

Our work surface is a couple of tables that are comfortable to sit at. We put the computer, keyboards/mice, projectors, phone, speakers, and a few other things on the tables.

We also have a rolling magnetic whiteboard we use for keeping track of the work we are doing, as well as a few other whiteboards and easels, and a couple of file cabinets that are desk height.

Driver/Navigators

We follow a “Driver/Navigator” style of work, which I originally learned from Llewellyn Falco as a pair programming technique. Llewellyn’s approach is different from any other I have been shown, have seen, or have read about (and I think he invented it or evolved into it.)

In this “Driver/Navigator” pattern, the Navigator is doing the thinking about the direction we want to go, and then verbally describes and discusses the next steps of what the code must do. The Driver is translating the spoken English into code. In other words, all code written goes from the brain and mouth of the Navigator through the ears and hands of the Driver into the computer. If that doesn’t make sense, we’ll probably try to do a video about that or a more complete description sometime soon.

In our use of this pattern, there is one Driver, and the rest of the team joins in as Navigators and Researchers. One important benefit is that we are communicating and discussing our design to everyone on the team. Everyone stays involved and informed.

The main work is Navigators “thinking , describing, discussing, and steering” what we are designing/developing. The coding done by the Driver is simply the mechanics of getting actual code into the computer. The Driver is also often involved in the discussions, but her main job is to translate the ideas into code. Of course, being great at writing code is important and useful – as well as knowing the languages, IDE and tools, etc. – but the real work of software development is the problem solving, not the typing.

If the Driver is not highly skilled, the rest of the team will help by guiding the Driver in how to create the code – we often suggest things like keyboard short-cuts, language features, Clean Code practices, etc.  This is a learning opportunity for the Driver, and we transfer knowledge quickly througout the team which quickly improves everyones coding skills.

Rotation

We rotate the Driver every 15 minutes. Using a list of who is working, we “rotate” through the list – so every 15 minutes the current Driver moves away from the keyboard and joins the Navigators, and the next person on the list moves to the keyboard to start typing. As the day goes whenever we get to the bottom of the list we just start over again at the top. We’ve written a little application that takes care of this for us.

Telephone and Email

All team related telephone calls and email communications are done “as a team”: We sign our emails as “The Dev Team” and have a group email address. When we make or take phone calls we mention to the other party that there are other team members present: “Hi Mary, this is Woody on speaker phone with a few of the other team members”.

Ergonomics

We are trying to pay attention to ergonomic factors.  Natural Keyboards, limited time at keyboard/mouse, ability to stand and work, changing positions, limiting eye strain, and so on.  This is an area where we’ve had some training, yet we still have a lot to learn.  Overall, it is important to us and something we focus on throughout the day.

Private Work Area

We each have our own work areas to use whenever we need to. There are small desk areas in a separate annex to the Mob area and it’s also made from standard cubicle walls. These are configured as either sit-down or stand-up depending on what the individual prefers.  Each work area has a computer with dual monitors, drawers, phone, etc.

6 Comments

  1. [...] had access to the source code repository.  This was a great excuse to try a technique known as Mob Programming that is gaining more publicity on the internet and twitter.  Basically, the entire team solves one [...]

  2. [...] Mob Programming Basics Mob Programming admin | No comments | Tags: Agile Magic Gemba Tour [...]

  3. [...] must have heard about MobProgramming. There was a method we followed to analyse the requirement and come up with Data [...]

  4. [...] recent Code Climate blog post introduced us to the concept of mob programming, the basic outline of which [...]

Leave a Reply