Reflections on a day of mob programming

Last week one of the teams I coach was given a day to build a proof of concept for a new business idea. I thought that #MobProgramming might be a good fit for the day’s activities, so here’s what happened.

There were five of us in the team for the day: three developers, one product owner and one coach/developer (me). The product owner had done some research into the topic we were to explore, but the rest of us were relative novices in the subject matter.

We grabbed a room with a large central table and two whiteboards for the day. We set up two laptops with a projector each, projecting onto the whiteboards. On one laptop we showed the software in the text editor, and on the other we showed the product we were building. To avoid spending too much time setting up fancy sharing schemes, we simply used a github repository to share code between the two laptops: every few minutes we would commit and push from the development laptop, and the product owner would pull and refresh on the product laptop to demonstrate and explore the current version of the product. This worked reasonably well, although occasionally we did launch the product on the development laptop too, for example when we wanted to check something in the Javascript console more quickly than the github cycle would allow.

We began by discussing the product owner’s explorations, and soon we agreed a goal for the day. Our intention was to develop a very simple but useful walking skeleton that would demonstrate a single use case in the problem domain. Throughout the day we regularly revisited our understanding of the goal and compared it to our progress thus far. By 3pm we had achieved our objective, so we spent a further hour or so refactoring and stabilizing our solution, with a view to ensuring that the code would be understandable if or when we came back to it in a week or so.

We developed outside in, in very thin increments. The product owner understood this approach quickly and intuitively, and was very good at guiding us to the next thin slice. The first slice was simply a static “Hello, world!” web page, but it proved our “delivery” pipeline between the two laptops. With each further slice all of us, including the product owner, learnt things that changed our minds about what to develop next.

Occasionally the team got a little carried away and began to write code that the product owner hadn’t asked for, or that was more general than he wanted for the current slice. But as the day wore on the team became better and better at turning his requirements around quickly by doing the (often surprisingly minimal) minimum. I heard myself saying “I don’t think we need to do that” and “Commit!” at frequent intervals throughout the day.

All five of us stayed extremely focussed for the whole exercise, which lasted 7 hours with a half-hour break for lunch. At the end, all of us agreed that we were spent, and that we had greatly enjoyed both mob programming and solving the problem we had set ourselves.

I do, however, have a couple of open questions:

  • Would this have worked with a larger group? Five people felt just about right, and we all remained engaged throughout. Would that have been true for a group of six or seven, or would some team members have found their attention drifting?
  • How did the subject matter contribute? We all remained engaged for the whole day, and I wonder how much that was a consequence of working on a difficult new greenfield problem. Would the same effect have occurred had we worked on the team’s usual legacy codebase?
  • One member of the team was off sick that day. I wonder how she will feel now that everyone else has a deep and shared understanding of the prototype’s design and implementation?

2 thoughts on “Reflections on a day of mob programming

  1. Sounds really interesting – I particularly like the two laptop/projector set up and thin slices to give really fast feedback.

    However, I can’t help wondering whether the “mob” was actually more of a highly agile team with a “triple” of developers (rather than a regular “pair”). How would the outcome have differed if the team had consisted of, say, five developers? Would more or less have been achieved or would there be indirect benefits in things such as design or quality?

    Another thought is how well things would have worked if the mob consisted of relative strangers from the start? Or if a relative stranger was introduced into the mob half way through – how long before they would have the confidence to contribute?

    Interesting to note that there is no dedicated QA or DevOps role in the team – I wonder if these roles might emerge in a larger mob?

    Final thought: what would happen if you took yourself out of the team?

    Would be fascinating to hear about future mob programming ventures.

  2. I (and the rest of the team) found the day highly productive and very enjoyable, and I think the mob programming experiment was the main contributing factor. I think the fact that team were all relatively new to the subject matter and programming language also contributed to this somewhat.

    The fact that the output of the task was visible to everybody meant that it was quite easy to keep everybody focused. I would like to see how the person in the BA role would react if the output was a passing test.

    The main benefit that I think the practice brings is the extremely quick feedback loop. Having a BA as part of the mob allowed us to get a constant steer on whether our understanding of the requirement was correct, without having to go through a “deployment cycle”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s