Mob Programming: The Unruly Experience
This year 11 experience reports were presented at XP 2015. As co-chair of Experience Reports, along with Ken Power, one of my last tasks was to select a best experience paper. That was hard. We had several good experiences to choose from (I’ll report on more of them in future blog posts).
Ken Power and I independently read and reviewed each paper. At the conference we compared notes and agreed on 3 papers we would consider for this award. We also reviewed the authors’ presentations before making our final determination.
The best experience paper was awarded to Alexander Wilson for his report, Mob Programming – What Works, What Doesn’t. One thing that made this paper stand out, was its balanced view. Alex is clear about things you need to watch out for when and if you try mobbing—don’t be lulled into groupthink and be aware of overly dominant personalities.
He also gave us a close look into his company’s mob programming experience.
Mob programming is where a team of programmers swarm on a problem. They work together instead of pairing or individually writing code. One person is at the keyboard, the rest of the team helps navigate. They pay attention and guide the person at the keyboard. Team members take turns at the keyboard. When mobbing, there are more eyes on the code and more minds focused on the problem you are trying to solve.
Folks at Unruly were inspired to try mobbing after Woody Zuill talk at JavaOne in late 2014. Woody also spoke about Mob Programming at Agile 2014. You can read Woody’s experience report here.
Developers at Unruly were seasoned XPers accustomed to pair programming and test-driven development. They are responsible for the entire lifecycle of their product, from research to operational support. They are in constant touch with problems and ongoing sustainability of code they write.
They decided to form a mob to work on performance enhancements to their existing product. This involved refactoring and reworking critical code. If they made mistakes, it could result in lost data and have serious financial impacts. Mobbing for them wasn’t just a casual experiment.
After mobbing one day per week for a couple of months they found, in general, that they were pretty happy with their results. After 5 months they concluded that they don’t prefer mob programming for all user stories. They do find mobbing beneficial for complex work (where there is the potential for errors) over complicated work (where the solution is known, but is merely time consuming). They also find that tasks that are dull or repetitive were likely to cause their mob to dissolve. They only mob one day a week, unlike Woody's team who mobs every day.
Unruly settled on a rhythm of periodic mobbing that worked for them. That’s what I like about Alex’s report. He tells us: here is what worked, here is where we tripped up, here is how we adapted our practices, and here is what we’re doing now.
Teams in learning organizations perform ongoing experiments. While they settle on a core set of practices, they also try to build upon them. They keep innovating, improving, and reflecting. And how they work continues to evolve.
- Previous: What does karaoke have to do with being agile?
- Next: Future Commitment