Mob Programming - The Good, the Bad and the Great



What is Mob?

Mob programming is a software development approach, and by definition at mobprogramming.org, is an activity in which “All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer”

Why we apply Mob programming

Before answering this question, let's take a look at the 3 pillars in software development project as below.



Everyone knows that strictly following the review process and task assignment is good for outputs quality and on-schedule delivery. Particularly, we usually:

• Clearly assign roles & responsibilities from the beginning.
• Always try to predict all risks and dependency before the project actually starts.

It is true that these behaviors are good for the performance of each tasks. But on the other hand, making clear of roles means member will focus only on their tasks, rarely support each other; while overestimated risks prediction beforehand sometime prevents team from flexible response when unexpected problems occur.

The following two problems should be considered too for a more effective process.

• A lot of "waiting" throughout the whole work-flow → Longer lead time 
• Multi WIP (Work-in-Progress) tasks at the same time → Not enough collaboration between team members for the highest priority tasks 

The above problems might lead to too much focus on performance of each small task. As a result, we tend to create as many outputs as possible, but less outcome.

In Agile Manifesto there's a value that states: "Individuals and interactions over processes and tools". In the long run it'd be better to try out methods that can increase the collaboration in team and optimize the whole work-flow.

Ideally, applying those said methods will results in:

• No waiting time and unnecessary outputs → task completed faster. 
• Full concentration of all team members on current highest priority tasks → Limit the WIPs. (You can refer to Queueing Theory for why we need to limit the WIPs). 

Mob programming is one of those methods being applied in TBV.

How to perform?

First, let's define the role and how to proceed.

• Role definition: There are only two roles in Mob programming:
  • The Driver: the person who sits at the keyboard and types in the codes. No decisions are allowed. ⇒ This role will be assigned to one person in a Mob team, in a short period of time.
  • The Navigator: those who discuss the ideal being code by expressing it out loud. They guide the driver to action. ⇒ Other members in the team will be navigators.
• Execution and rotation:
  • Navigators start to discuss with each other and guide the driver to write the code.
  • Rotate driver after 15 minutes (or other time-box committed by team).

Next, set rules to make sure all team members will engage in the activity.

• Timed rotation: whoever is on the keyboard must move away and make space for the next one. Timer is in scale of minutes. Note: we shouldn't erase whatever we were doing when rotated, but instead improve and continue the previous work.
• No decisions on the keyboard: driver listens to the Navigators, and must trust the Navigators. Whatever happens at the keyboard is decided by Navigators.
• Highest level of abstraction: as a Navigator, express your intent while navigating the Driver with the highest level of abstraction that Driver can consume. Hint: you can tell from the lack of movement on the keyboard whether the driver needs more information or instruction.
• No acts upon bias: rather than doing something because you like, throw away all your biases and always welcome discussions between different opinions.
• Kindness, consideration and respect: we’re working closely together and we are all valuable contributors. Make space for everyone to shine.

Last but not least, retrospective and take action.

• Retrospective - Take action: make sure to save enough time to talk about what you learned in the Mob and how you could improve your experience for the next time, then take action accordingly.

Actual results after applying Mob at TBV

An environment for all team members to work together is a must. At TBV, we have a corner like in these photos below. It's called "Scrum Island" and is used for Mob programming.



This is also a great corner for Scrum teams to demonstrate working software to multi stakeholders at multi locations via TV conferencing system.

After applying, the collaboration between team members was significantly improved. Members not only focus on self-task but also understand the entire product, as well as keeping track of team's problems.

The whole team brain storm and work together. Information quickly becomes transparent. Communicating and discussing skills are increased. Everyone stays involved and informed.

Among all of that, the biggest plus for us must be experience sharing and new skills learning.

Beside benefits, there are some demerits and dissatisfaction from our team when applying Mob. Here are some retrospective results we'd like to share.

• Motivation:
  • Problem: due to lack of experience, junior members were often assigned as the Driver. Being attached to the keyboard for too long affected their motivation and confidence.
  • Action: strictly rotate Driver on time regardless of members' coding experience. Tools such as mobster.cc can be helpful for time tracking.
• Productivity:
  • Problem: all team members did only one task at a time, so the productivity went down.
  • Action: at planning phase, we will consider which task should be handled by the whole team. Difficult tasks or tasks about new technology are good targets for applying Mob programming.
• Lack of goal:
  • Problem: mob applying session without purpose / goal are likely to end up getting nothing done.
  • Action: make clear of goal and definition of done (DoD), list up items to prepare in-advance.

Comments about Mob from TBV team members

We've found that Mob is very powerful approach for team work, communication and knowledge sharing skills improvement.

In our case, still there are some points that we need to improve to make Mob more effective, especially clarifying the purpose to each members, for a better mindset and prior preparation. We also recommend that System architecture (SA) should be defined clearly before applying Mob for working software creation purpose. (And yes, using Mob to define SA is also good idea.)

In conclusion, rather than recommending Mob programming, this article is more about sharing our experiences. But we believe that it is worthwhile to investigate the concept and see if it's appropriate for your team.

So if you decide to try Mob programming, feel free to share with us, we’d love to hear about your experiences.