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 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?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)