Looks like Woody Zuill (@woodyzuill) is getting pretty busy promoting the practice of Mob Programming these days. I applaud his efforts and I'm happy to see his apparent success with it. I think it's a great practice and I think more teams should at least try it on for size.
Responding to Tampere Goes Agile (@tmpgoesagile) question on why you should use mob programming, I said that mob programming has helped our distributed agile team get better by keeping everyone on the same page. @tmpgoesagile still wanted to hear more about it so here are some details on how that came to be and how it works for my team.
It's a Pattern
I think it was either Esther Derby (@estherderby) or Jeff Patton (@jeffpatton) whom I heard say something like "I didn't invent this. Other people have told me that they've done the same kind of thing before. So I guess the only thing I can claim here is to have discovered and documented a pattern." They were, of course, talking about something other than mob programming, but the same thing seems to apply here.
I first heard the practice being called "Mob Programming" at the Agile 2013 conference in Nashville, TN. A team from a company in California was talking about it in an Open Jam Huddle in the expansive lobby of the Gaylord Opryland Conference Center and I thought I'd stopped by for a quick listen while I was between sessions. A group of young guys were talking about how they did all their development anymore and how much better and enjoyable mob programming was than just plain old pair programming.
We had been doing the same thing on our team for at least a year already, except we called it "swarming," a name we'd picked up somewhere for the practice of having the whole scrum team work on a single user story at a time. I liked the ring that "Mob Programming" had to it so I started using the name with my team, too, although I still tend to say "mob or group programming" when I describe what we do to other people in our organization. Now that Woody had made the name more popular, I guess I'll go with "mob programming" from here on.
First Rule of Distributed Teams
We are a distributed team with members in Ohio, Texas, and California. Our concession to not being co-located was to require that team members be no more than three timezones apart. This gave us at least five hours in a day when nobody had to make crazy adjustments to their schedules. If we did have to schedule something that was a "little bit" early or late for one or two people on the team, we could at least avoid swinging out more than an hour or two on either side of our core work hours. Any crazy adjustments to schedules, which a few of us did anyway, were totally your personal choice and discretion.
I think if you're going to do mob programming with your distributed agile team, you have to at least have this rule in place. If you have a few guys on your team like me and a couple of my colleagues, that's fine. But make sure people agree that crazy hours are the exception rather than the rule.
Share Images to Build a Shared Understanding
In his book "User Story Mapping", Jeff Patton notes that pictures play an important part in building shared understanding in a team. This is especially true with distributed teams and it has been borne out by our experience.
The right collaboration tools are very important for distributed teams like us. Before I go on, I want to make it clear that this is by no means a thinly veiled attempt at promoting our company's products, no matter what it looks like. I assure you that I mention the tool we use purely as a matter-of-fact. I have to admit though that it is nice to be a rare case of the cobbler's kids getting nice shoes for a change.
Anyway, we use Cisco WebEx for meetings and collaborative development all the time. Most of us work from home and we love the flexibility and convenience that comes with it. At the start of our journey to agility, people would just email each other or use IM to have conversations. I nipped that in the bud. I reminded everyone that if we couldn't have face-to-face conversations, the next best thing was to have a live conversation on WebEx. We could share our screens, which we often do, and we could even share our cameras, which we still don't do very often for some reason.
I guess that's one curious observation to note: Being able to share your screen, priceless. Being able to share your face... meh.
Nowadays, our conversations usually start with the simple IM: "WebEx?"
Pair-Programming to the Extreme
As I alluded to earlier, we kind of just fell naturally into the practice of mob programming from "swarming" on a user story. As with most distributed teams, we'd been having trouble completing user stories when we divided them up among ourselves and tried to work on them concurrently. We often ended up moving stories to the next iteration to complete them. Swarming was our attempt to get at least one story fully done by the end of the iteration that it was pulled into the first time.
I'm also a big proponent of Test-Driven Development. I had first instituted the practice of code reviews which naturally led to my goal of having frequent pair programming sessions so that after-the-fact code reviews had to be done less frequently.
When we started swarming on user stories, this led to us doing group programming on WebEx for at least three or four hours a day. Yeah, we called it "group programming" and we liked it a lot. The mechanics were kind of the same for pair programming except that there was a lot more discussion and different perspectives brought to the table. Also, there were more people to do little sidebar tasks like Google for something or experiment with an API call or write documentation or whatever.
As a tech lead, I loved that we didn't have to do as many after-the-fact code reviews. I could keep my finger on the pulse of the design and head off any design choices that could potentially make trouble for us later. I could also do my mentoring on refactoring practices and design principles all at once and not have to repeat myself with other team members at a later time.
The Uncomfortable and Unspoken Rule of Distributed Teams
If you've never seen the movie "Office Space" then any claim you make to geekdom rings a bit hollow. Anyway, I think mob programming helps you avoid having any Milton Waddamses on your distributed team. It's all too easy for someone to say, "Let me work on this for a little bit then I'll get with you for a code review on WebEx tomorrow." Then next thing you know, that guy is in the basement plotting to set the building on fire. Ok, maybe that's a bit of a leap but you know what I mean, don't you? If you don't, Google and NetFlix are your friends.
Since everyone is working together for a good portion of the day, mob programming makes it almost unnecessary to even think about the Uncomfortable and Unspoken Rule of Distributed Teams, which is that "Team members will have the integrity and discipline to work even when nobody is watching."
I know we all want to assume the best of our team members but not giving anyone a chance to give in to the temptation of working alone can sometimes be the best way of establishing trust on the team. I think mob programming helps with that.
Conclusion
I'm really glad to see that Woody Zuill's efforts to spread the word about Mob Programming are succeeding. Mob programming is great for any agile team and it can be especially beneficial for distributed agile teams.
No comments:
Post a Comment