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:
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.
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.
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.”
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”:
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.
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.
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/