To start, a little bit about MobProgramming….
This week(Monday 16th Feb 2015) i attended the XP Programming London Meetup (#xprolo). Benji Webber(@benjiweber) gave a talk about how Unruly have introduced “MobProgramming” into their teams. For those who aren’t familiar with the term Benji defined it as:
“Whole Team focused on same problem using one workstation”
Benji also referenced one of the well known advocates of MobProgramming, Woody Zuill (@WoodyZuill), who’s website has lots of extensive information around the concept if you want to research further – http://mobprogramming.org/mob-programming-basics/
As the term suggests, “MobProgramming” is primarily focused around the activity of programming. This generally means a group of developers, designing and writing code into a Development IDE, as a group such as in the image below:
http://mobprogramming.org/wp-content/uploads/2012/11/MobScreenView1.jpg
On a practical level the team congregate around the screen at an agreed time and start working. The individuals in the group rotate operation of the keyboard around every 10-15 minutes so that everyone contributes code to the solution. The time spent “mobbing” can vary, Uruly have spent whole days doing it but found it can be quite draining working in a whole team activity all day.
The Benefits
Unruly have been doing “MobProgramming” for about 4 months and these are some of the benefits they have observed:
– Its fun!
– More emergent design – Team can design collaboratively as they progress
– Less synchronisation needed as the whole team are present
– Latency is reduced
– Reduction in emails and other offline communication
They have found that some problems don’t support “mobbing” for example things that fall into the Obvious domain in Cynefin. The team discuss and agree when they feel it is sensible to “Mob”. I’d like to think over the time the teams will identify some heuristics on when to “Mob” or use a model as a guide.
MobTesting
Thinking about how “Mobbing” could apply to other activities, it could work well for testing. Lets call this “MobTesting”
The same definition would still be valid:
“Whole Team focused on same problem using one workstation”
Most of the practicalities would also be the same, a big screen, one keyboard, whole team, white board nearby etc. Many of the benefits seen in “MobProgramming” would also be seen.
I do feel there are a couple of subtle differences between “MobTesting” and “MobProgramming”.
Testing is an “explorative” activity.
“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.”
http://www.satisfice.com/blog/archives/856
We are searching for useful information that we can provide the team and stakeholders to make an informed decision about the quality of a product. “MobTesting” allows us to benefit from having a whole team involved in two ways: Shared Responsibilities and Varied Perspectives.
Actors in the Mob
Firstly looking at Shared responsibilities. In “MobTesting” I see the following actors within the “Mob”:
| 1. The Driver – The person with the fingers on the keyboard/mouse moving through the application. |  |
| 2. The Note Taker – The person capturing the session. Testing and note taking is incredibly hard to do simultaneously. One of the benefits is that someone can focus on this such as producing a mind map or recording questions. |  |
| 3. The Orienteer – The person helping us keep on track and to our charter. Often it’s easy to get side tracked when testing alone so having the benefit of someone to keep the mob focused may help. |  |
| 4. The Observer – Stands back and observes what’s taking place. Often getting into the detail you can get temporary blindness. Simply observing can help see issues the driver may miss or skip past. |  |
| 5. The Runner – Synomous with the TV industry. You could use this person to get the refreshments or better, if the Mob has questions for people such as the Product Owner “Is this what you expect?” They can run to the person and get quick feedback. |  |
| 6. The Local Expert – Someone who knows the product, domain or technical detail of the Product. This helps if any questions arise from the mob. This person could drop in and out of the session or maybe pulled in at various points by “The Runner” |  |
As per Benjis example in “MobProgramning” the individuals doing these roles should rotate every 10-15minutes allowing everyone to keep engaged in the activity. It also provides a good opportunity to practice skills of observation and note taking which can be applied when working alone.
Varied Perspectives
Another great benefit of bringing the whole team together to “Mob” is the varied perspectives on offer, especially if you can include those outside the immediate development team such as customers. If you already have a varied “cross functional” skill set within the Mob this will naturally bring a varied and rich perspective. If not, you can apply critical thinking techniques within the group to ensure a more varied perpsecitve. For example each person in the group could be assigned the ‘persona of a valued person’ such as a customer. You could also apply critical thinking techniques such as Edward De Bono’s “Six Thinking Hats”
“MobTesting” is not a “BugBash”
“MobTesting” shouldn’t be confused with a “BugBash”. I’m sure many testers have been involved in large group bug hunting sessions where the objective is to find bugs. “MobTesting” is different because we are exploring the product as a whole team with the intention of uncovering information, one piece of information could be a bug, but there are plenty more pieces of information that could be found.
MobAnything!
If you can do “MobProgramming” and “MobTesting” surely you can just “Mob” anything! I’m not so sure. I think there are certain activities that make sense not to be done in large groups. Things that spring to mind are writing documentation, creating release notes and other similar activities that often fall into the Cynefin “Simple Domain”.
In addition to “MobProgramming” and “MobTesting” another activity that would be interesting is “MobDrawing”. This is where the whole team gather to draw out a design for a new product. In this case the pen could be swapped around the group every 5-10mins.
Watch out for the Mob
It’s important to watch out for bad behaviours when “Mobbing”. These include:
– Bike Shed Effect (http://en.wikipedia.org/wiki/Parkinson’s_law_of_triviality) – Unable to agree on trivial things “such as the colour of the bike shed”
– Dominant Personalities in the group such as “Watch the Master” effect which can often be seen within Pairing
– Group Think – Where people agree for the harmony of the group in order to avoid disagreements
With regards specifically to “MobTesting” you should probably watch out for “Phased Mobbing” For example: Monday = “MobPrototyping”, Tuesday = “MobProgramming”, Wednesday = “MobTesting”
“MobTesting” can be done at any point in the life of a product, in fact you don’t even need a line of code to have been written. You could do “MobTesting” on a paper prototype or a set of wireframes. Testing can also be done in “MobProgramming” and Programming can be done in “MobTesting”. The main difference is that in “MobTesting” we specifically want to focus on a testing problem.
The value of “Whole Team”
Wether we stick “Mob” on the front of an activity or not isn’t really the important thing here. “MobProgramming” and “MobTesting” simply amplify the benefits that can be found when whole teams work together on one problem rather then separately. To exaggerate the point, there is even some evidence that working as a whole team can lead to solutions faster than if people worked apart or in pairs.
You can read more about the Unruly Mob here: http://benjiweber.co.uk/blog/2014/11/30/the-unruly-mob/
Toby The Testers Blog 
