Mob programming - the heaven of a tester. Part2: What happens in a mob

This post continues from Mob programming - the heaven of a tester. Part1: the beginning.

I will next describe the formula of a rather common and a rather good mob development session. It consists of four parts; The initiation, The planning, The implementation, and The finishing.

_____________

1. Initiation

We started arranging the mobbing sessions by booking a few 2 hour slots for the week ahead where our aim would be to do some work in a mob. This was especially important in the beginning as the mobs did not seem to happen adhoc. Even if pretty much everyone always liked and wanted the mobs, people often did not arrange them by themselves. So this kind of forced us to do the stuff we like to do :)

Now after starting to make mobbing a habit, and starting to understand where it is especially effective, we have gotten better in initiating mob sessions ad-hoc. So these days it is the most common way to start implementing a solution for problems that seem hard to tackle, on something that is totally new, or on anything that appears to be big. Also we have started using the mob as a way to end arguments in a nice way. Like after arguing/discussing something too long in a meeting or in a flowdock thread, someone just suggests to mob it and then we go.


2. Planning

We most commonly start a session by drawing a picture of the thing we are trying to accomplish. If working on the same location we use a whiteboard, if remotely we use some simple paint tool. (Lately couple of our devs have been trying out using a iPad for easier drawing and it looks really nifty. But not much experience on that yet.) So someone graps the pen, and starts drawing the parts of what we are about to change. Simple drawing displaying the user interactions and the main components and their interactions in the scenario we are thinking of. Then we switch to a pen of another color and start drawing the new parts needed. And finally we decide which parts of those are kind of separate tasks and decide on the initial order in which to implement them.

Example result from whiteboard planning

Here it is often important to try to notice when you are starting to overplan on the whiteboard. The aim should not be to fully think of all the details, but to have a goal to start moving towards to. The details will get solved while implementing, and the goal might as well change while at it. You can keep in mind the phrase from Woody Zuill: "it's in the doing of the work that we discover the work we must do".

3. Implementation

In the beginning of our mobbing days we used to switch the person on the keyboard quite often, like every 7 minutes. But these days we often may just pick a person who will do all the writing during the whole session. I don't see a problem with this, as long as that person does not start writing something that has not already been discussed.

On the keyboard we usually (should run the existing tests, which we often forget, and instead move directly into) start by writing the tests, which is a smooth continual from the planning. We usually like to start with the user facing parts as there we really need to think of the inputs and outputs of the whole flow. This is hard, but usually leads to a smaller first increment than what you would get by e.g. starting the implementation from the db model.

Then after the tests are done (try to not write too many first - remember overplanning!) the writing of the actual code may be the easiest part of the session, partly because the hard business problems are already discussed thoroughly, and partly as there are so many capable coders present who know all the tricks. So we do not spend THAT much time in google...


4. Finishing a session

Our mob sessions last usually about 2 hours, and we would not do more than two of these a day. Mobbing is effective but also quite mentally consuming so doing too much of that may take its toll too.

So after the 2 hours are up we (commit and push if we haven't before which too often might be the case, and) agree on how to continue with the remaining tasks. If everything seem to be clear one person might just pick it up from there onwards. We might also agree that someone continues on their own on some stuff and then books a mob on the next more challenging things. Or then we may just agree to continue with the same people the next day.

_____________


There it is, the formula of a normal mob. "Why we like them so much and find them so effective" and "what is the testers role in a mob" I will go through on the next post on the series of Mob programming, the heaven of a tester.

Now I should go and book a few mobs. Recommend you do the same!