Agile Zone is brought to you in partnership with:

Kevin Rutherford, PhD, is a UK-based extreme programmer and agile software coach with over 30 years professional experience. He developed the Reek code-smell detector for Ruby and co-authored "Refactoring in Ruby". Kevin is a DZone MVB and is not an employee of DZone and has posted 12 posts at DZone. You can read more from them at their website. View Full User Profile

Reflections on a Day of Mob Programming

12.05.2013
| 5291 views |
  • submit to reddit

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?
Published at DZone with permission of Kevin Rutherford, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)