FotolEdhar - Fotolia
Mob programming is a new way of approaching a timeless software development problem: how to improve productivity. When software professionals struggle with unanswered questions, missing information and other dependencies, they get stuck. But one way to solve the problem may be to put the whole team to work on the problem all at once.
Mob programming: What is it?
Mob programming is a software development technique, where the entire team works together to produce a feature. They sit at a single computer screen -- often with a projector -- and take turns at the keyboard. The technique builds on pair programming, but involves four to six people instead of two, said Johanna Rothman, management consultant at Rothman Consulting LLC, based in Bedford Hills, N.Y. It's similar to swarming, with one key difference: In mob programming, the team remains together for the duration of the work. In swarming, the team collectively decides what to do. But once the work is divvied up, each member works alone, Rothman said. "Mob programming is not about one person's ability to deliver."
Mob programming: Why try it?
Mob programming was a hot topic at the recent Agile2015 conference. But it's not necessarily the next big thing in software development. It is a simple technique, a way to boost productivity and a way for a software team that's stuck to get unstuck, according to Woody Zuill, senior consultant at coaching and training firm Industrial Logic Inc., in Berkeley, Calif. "Many things that block productivity don't exist when you work together [at one screen]," said Zuill, who managed what may have been the world's first mob programming team. He tagged three issues that block productivity for software pros:
- Communication problems. "You have a question and the person is not there. You send email and the answer takes two days," he said.
- Thrashing. Someone gets taken off the team to work on another project. "It's always the best person on the team, and when you remove them, the team's productivity dies," Zuill said.
- Decision-making problems. Meetings and sign-offs destroy productivity, he said. "But when a product owner sits with the team, that person can say, 'I like it this way; do it that way.' We can do things in real time."
Mob programming: Not just coding
The term, mob programming, is a bit of a misnomer. The mobbing technique applies to all aspects of the software development process, including requirements and testing. The product owner, for instance, is not writing code, Rothman said. "But the product owner is part of the [mob programming process]." The team might decide, for example, to work on refining product features first, she said. "Let's mob on making our stories smaller."
Mob programming: How it originated
Zuill didn't set out to invent mob programming, or anything like it. The technique grew out of his belief that "the team doing the work can best figure out how to do the work," he said. When he joined manufacturing firm Hunter Industries, based in San Marcos, Calif., as software development manager in 2011, his team of six began experimenting with new ways of working. One thing they did was engage in weekly training practices, using code kata techniques to hone their skills. In a code kata -- a concept originated by Dave Thomas, co-author of The Pragmatic Programmer -- five or six people sit at the screen, taking turns at the keyboard in four-minute intervals. The team liked the technique, and began adapting and applying it to real projects -- not just time-limited training exercises. They kept at it and discovered "something really good was happening. The team had figured out how to get the work done," said Zuill, who runs the website mobprogramming.org.
The term mob programming took hold by accident. "A mob is a group of people gathered to take action," he said. "I used the term in jest. One team member liked it, and it stuck." He doesn't take credit for coining the phrase mob programming. He first encountered it in the 2001 book, Extreme Programming Perspectives, in a chapter written by Laurie Williams, a professor in the computer science department at North Carolina State University.
Mob programming: Why it works
What's most interesting about mob programming is why it works. The simple reason is "you get feedback right away and having all stakeholders present eliminates hand-offs," Rothman said. "I can work with you on this, as opposed to handing this off to you." Teams can complete more work faster. "You can get a small feature done in half a day, maybe even a couple of hours," she said. Zuill's team at Hunter Industries did not formally measure its productivity. "But we found that, working as a mob, a great deal more work was getting done," he said. What's more, management told them they were developing good software.
Woody Zuillsenior consultant, Industrial Logic
There's a more profound reason why mob programming produces good software. "There is more thinking going on," Zuill said. "Before an idea can get from someone's head into the computer, it has to go through someone else's hands." That forces everyone to think more carefully about the work -- about what it is we're hoping to do, he said.
Although mob programming has no set rules, Zuill recommends some guiding principles:
- Turn up the good. Zuill borrowed the phrase "always turn up the good" from Kent Beck, inventor of Extreme Programming, and has found it useful for teams that mob. "Notice what is going well. If you have a process that works, focus on understanding and enhancing it." This is more productive than zeroing in what doesn't work, he said.
- Be nice. Zuill and his team put in place principles that guide how team members treat one another. "We made a commitment to treat each with kindness, respect and consideration," he said. "In the process, you become a better person."
- Work at a sustainable pace. Zuill and his team made the decision to work an eight-hour a day, with an hour for lunch. "When we get to work the next day, we're rested," he said.
Mob programming: Skeptics aren't sure
The mob programming approach is new, and relatively few software pros have experimented with it. Not surprisingly, some are skeptical. "There are also some problems so technically difficult that I need maximum concentration to keep everything straight while implementing or debugging it. Having a group of programmers surrounding me seems distracting to that end," posted Dutch Gun, in a June 2015 discussion called "Mob Programming, Huh?" on the technology website Slashdot. Dutch Gun also noted that a mob programming approach might help some situations. "You're essentially programming while having a constant design and review meeting, so I can see how the quality of code would improve."
Others were more dismissive. "The more people in the group, the more each of them cares about having their ideas pass and the less they care about getting [stuff] done," wrote Anonymous Coward, posting in the same thread. Writing in a June 2015 thread, titled "Hypersupervised Programming?" a poster identified as Mr._Tulip said a mob programming approach could work for some aspects of the development process. "In my job, we do the equivalent of 'mob programming' at the start of a project, or when implementing something interesting, such as a complex framework component intended to be reused by all the developers. The other 80% of the time, it's far more efficient to sit at your desk, headphones on, and bang out code that is integrated at appropriate intervals."
Rothman said that mob programming is not for everyone, and no one needs to experiment with it unless they want to. "I would never impose it," she said. "There is no rule that you have to mob. It's just one tool in the toolbox." But when a software team is having trouble getting things done, it's important to try something new. "Maybe we could help ourselves if we do a little mobbing," she said.