Recently I enjoyed working with some of my San Francisco colleagues on-site. During this visit we wanted to take time to do something a little different. So, we devoted two days to experimenting with Mob Programming on some exploratory work. Over those two days we discovered a number of things about Mob Programming as well as the work we were exploring. While we didn’t all walk away with the same insights, we all agreed that Mob Programming was a technique we were interested in trying out some more.
Exploring a Problem
The team I currently work on is responsible for our Master Planning solution for resource managers within professional service organizations. This system provides a way to identify what kinds of personnel are necessary for various projects, including the required skills, availability, and other factors. This tool also enables the assignment of specific personnel to these defined areas of need. In order to do their work effectively, resource managers need to be able to adequately filter and organize their view of projects and personnel.
We needed to explore the relative complexity of the filters we provide in our Master Planning solution. Specifically, we needed to explore three different approaches to how we might want make changes to these filters. Currently these filters rely on the Backbone Javascript framework, but all new development is targeting React. So, the three approaches we wanted to explore were; (1) how complex would it be to make a functional change to one of the existing filters, (2) how complex would it be to reimplement the filters using React, and (3) how complex would it be to reimplement the filters using a newer UI paradigm that relied on both React and a light-box presentation. In both of the latter cases we also had the secondary interest to get a sense of how complex it might be to have React-based filters work seamlessly alongside Backbone-based filters.
Ground Rules
I was tapped to help facilitate the Mob Programming and worked with our team lead to get a suitable setup. One complication that we did encounter was a need to include a single remote participant, and I will return to this complication later. In bringing the team together, we set four basic rules to help maintain a good working environment for this new technique. Since we Pair Program regularly, none of these rules were new, but we felt they were worth being explicit about.
First, we committed to step away if we felt distracted, or otherwise not engaged in the work being done. This was our way of giving everyone permission to keep up with other commitments and not feeling like they simply had to be in the room.
Second, we committed to suggest, instead of demanding. In our environment we already value mutual respect and would not expect anyone to make demands of their colleagues in a collaborative setting. But, because this was a new context and way of working, we felt it was valuable to identify this specific means of maintaining respect during the exercise.
Third, we committed to stop the session and have any design discussions as a whole. We recognized that as we are going along there may be times we need to have a conversation that involves the whole team. We wanted to give permission for the typist to step back from their role and engage fully in those conversations.
Finally, we committed to focussing on just one task at a time. We had the disadvantage of not being engaged with our typical user stories, so we felt there would be a temptation to try and do too many things at once. This commitment encouraged us to keep ourselves, and each other focussed on the small steps we needed to take to achieve the learning we wanted. This commitment also gave us regular opportunities to ask ourselves if we had completed the desired learning as we went.
Our Schedule
We decided that since we were going to work over two days we would build some breaks into our sessions. We knew, because of our first ground rule, that individuals could and would step away as they needed. But, we also wanted to provide some specific times for decompression and review throughout the process. We divided our days into, as best we could, a series of two-hour sessions. We committed the latter 15 minutes or so of many of those sessions to doing retrospectives on the time we had just spent working. This led us to make a few helpful adjustments as we were Mob Programming that helped keep us learning smoothly.
Getting Some Practice
Since none of us had ever done Mob Programming before, we decided to use a shorter session on the first day to get a little practice. This proved to be an incredibly valuable decision since it allowed us to quickly identify two problems in our approach that we changed before jumping into our main work.
We chose to do some code review on an open pull request we had on our team. In the process of doing this code review we used a timer to rotate who the typist was every eight minutes. This proved to be way too little time for a rotation, which led us to move to, and stick with, 15 minutes per person through the rest of our Mob Programming time. We also discovered that our use of Zoom and Apple Airplay introduced an unacceptable amount of latency for both our remote participant and even for our co-located team members. This led us to switch to using Tuple for our remote participant, which had its own complications, and connecting our workstation directly to our conference room television.
The practice was invaluable in helping us quickly refine those areas of our process that were causing friction. And, even in that brief practice session we gained a handful of insights about the process of Mob Programming, and how it could impact our work, both in good and bad ways.
What We Learned
Over the two days of Mob Programming we learned a lot. Most valuably we were able to provide feedback to our Product Manager on the work he was considering for the team. The overall tenor of that feedback was that none of the options were discouragingly complex. We walked away feeling more confident that we could tackle any of the approaches to our filters without introducing delays that would necessarily compromise our ability to deliver value to customers quickly. We did not all come to the same conclusions about the value of Mob Programming, but we all saw its benefits. I will save the epiphany I came to in observing and facilitating our Mob Programming experiment for a different post.
About Mob Programming
One of the things I noticed as we began Mob Programming was that the same skills that are important for Pair Programming come into play. The fact that our team has a good base in Pair Programming meant that discussing and resolving small differences in preference are quick. When we needed to stop and brainstorm on approaches the conversations also flowed very naturally and it did not feel like we were breaking context much at all. The one downside was that the same social dynamics that helped with driving towards solutions also led to chasing the occasional rabbit together. But, agreeing on when we were done was very easy to do as a group.
We attempted to impose an eight minute rotation at first, and that proved too short. We followed up with a fifteen minute rotation and while that was a lot better, I think the aim should be to move between typists in Mob Programming with the same fluidity we see in Pair Programming. Along this same line, identifying a cadence for group breaks was difficult and occasionally felt artificial.
We found that Mob Programming was a good way to introduce newer team members to code organization and concepts at least as well as Pair Programming. Any specific benefits to Mob Programming in this respect were likely diminished by the type of work we were engaged with. We also found that identifying one member of the mob as a researcher and encouraging everyone else to focus on the main coding work was very beneficial.
We observed that having product and design team members present was very helpful for decision-making, but it was unclear if their presence throughout the mobbing session would have been better. Deficiencies in workflow were more acutely painful to the mob than they would have been to a pair. And, we recognized that there were technical challenges to adequately incorporating a remote participant that we have overcome well for Pair Programming.
About Ourselves
The process of Mob Programming surfaced some interesting details about our workflow and product. We noticed that the pain of prepping our data set so we can adequately perform basic QA tasks as a mob was an issue. One suggestion that was made was to have a pair do the setup instead of conducting it as the mob. My concern with this approach would be that it would not necessarily seek a solution to the pain that is being felt, merely bandage over it. I think I favor empowering mobs to address pain points like this whenever they come up, which is something our Pair Programming sets should already feel empowered to do. It is possible that this pain point is exposing a team dynamic worth correcting even without the adoption of Mob Programming.
I noticed that the way we were addressing our work as a spike and setting aside some of our regular practices created uncomfortable friction. I was encouraged to see the discomfort, but it raised some interesting questions I want to revisit in another post on the concept of spikes. I think maintaining our normal practices, particularly the practices of TDD and starting with clear users stories, would have made the overall Mob Programming experience more informative.
About Our Work
As we worked together we learned several things about our work and the impact Mob Programming could have on our process. One thing I noticed was that frustration rose much higher when encountering constraints or friction in our process. This encouraged me that when doing regular work, a mob might be more strongly inclined to address those issues immediately, rather than deferring them.
I observed that Mob Programming seemed to more quickly surface small solutions than I’ve observed in some pairing session. I believe this was because the group exhibited a stronger social reinforcement dynamic when it came to pushing towards a working solution quickly and then iterating. I believe the rotation of the driver also provided encouragement to keep the active work focussed on keeping things working, rather than accepting the risk of attempting big bang style changes.
Where We Go From Here
Our environment was not a great one for Mob Programming. Because we were using a conference room, there was some awkwardness involved in changing the driver because of how people wanted and needed to move around the space. I think this issue could be well addressed with a more tailored space for Mob Programming, rather than simply repurposing a room designed for round-table meetings.
I observed that decision-making was very effective when we had our Product Design and Product Manager in the room. I think our experience with Mob Programming would be even better with a “Whole Team.” And, I think this would be a necessary feature to incorporate the next time we engage in this practice.
All of us agreed that Mob Programming was a valuable tool and would be worth employing again for exploratory work. We did discuss the value of having user stories to better inform our work. I am definitely a proponent of looking for more opportunities to apply Mob Programming, but there are some technical and organizational hurdles we will have to address to make that feasible. For now, I’m not confident that support for remote participants is strong enough to make that a good approach, but for fully co-located teams I think Mob Programming is a practice that should likely be tried out, and eventually adopted.
Latest comments (0)