For software design and development (and many, many other tasks), productivity is always a high priority -- and in pursuit of this is a seemingly never-ending supply of new methods, from Kaizen "continuous improvement" to newer ones like Agile and Lean.
[ Also on ITworld: The path to Agile: Successes and slip-ups ]
"We discovered the Mob Programming approach from what we had been doing as a learning technique," recalls Woody Zuill, Senior Consultant with Agile development firm Industrial Logic, in a phone interview. "We were using a Coding Dojo style where everyone works together at a single computer to practice solving a programming problem. The style was based on Llewellyn Falco's 'strong pairing' Driver/Navigator model of the pair programming method."
Mob Programming, says Zuill, "is basically an expansion of that approach: working in a group, with one person at the keyboard to 'drive' -- enter and edit the code -- and everyone else working together as the 'navigator,' 'guiding' what goes into the keyboard. The passing around of the keyboard was based on the principle, 'If I have an idea, I have to hand the keyboard to somebody else, so I can explain it, draw it on the whiteboard, and discuss it before it is keyed into the computer.'"
And after a few hours of working as a Mob, says Zuill, "We realized that it was working so well we wanted to keep on doing it for the rest of the day. And at the end of the day, we decided to keep working this way the following day. That was four years ago." Zuill eventually wrote write this up in a blog post titled "Mob Programming: A Whole Team Approach."
The software project that Zuill and his co-workers did their first Mobbing on was "very complex, requiring input from all the developers." So, says Zuill, "We thought that meant this approach was best suited for solving complex problems quickly. But once we got good at Mobbing, we realized that it also was useful for smaller, simpler problems, because you can often find a way to abstract or automate tasks that are easy or repetitive, like cleaning up items in a database. Working as a team, it's a lot easier to see patterns and to act on them."
Bluefruit mobs up
In November 2014, Bluefruit Software, an embedded software development firm, which had already been using Pair programming, decided to give Mobbing a try, based on the advice of Nancy Van Schooenderwoert, President of Lean-Agile Partners, Inc., a technology training and consulting firm.
"We were adding more engineers, and Nancy, who we'd been working with for several years, suggested Mob Programming as one way to mature technical leads faster," recalls Bluefruit's owner & CEO Paul Massey. "While Mobbing's having the whole team around one keyboard sounded even less efficient than Pairing, we decided to give it a go."
And it worked.
"The place that Mobbing has helped the most is merging code when people have been working alone and in pairs," says Matthew Dodkins, a software architect at Bluefruit. "In a day spent using traditional collaboration, you would have to first spend time agreeing on tasks, common goals, deciding who's doing what... and then going away to do that, write code, and come back and merge it, resolve problems."
By bringing everyone into the same room, "we try to merge frequently, and try to do almost continuous integration," says Dodkins. "A lot of code gets merged all the time. For a big code project, we try to do it all the time. When developers are programming individually, we can be 'lost in code' for up to a week. None of our mob merges last more than a day, as opposed to working for a week and only then learning you're off -- meaning several peoples' code doesn't fit together."
"We find Mobbing good for solving complex problems, and dealing with merges of code by multiple people," says Dodkins. "You get the power of everyone's knowledge on the problem. It's also a positive learning and social experience -- all the team members can learn about the project, and can contribute to difficult problems that are blocking the project."
So far, Bluefruit has used Mob techniques "on a bit of everything," reports Massey. "We've used it on projects for our blue chip clients like Electric Bike and Home Information Systems, where we may have a dozen engineers organized into multiple teams, usually with a maximum of six to seven per team. And we have a team of six, with maybe only one or two engineers, on a number of smaller programs for start-up clients -- this team may only all get together one morning per week."