Editors Note: I am unable to blog as I am traveling and my schedule has blown up, but I do have stuff to share; here is an article I read that I thought was pretty interesting. I like the concept and the name. This is reprinted in full from Infoworld.
Introducing Mob programming: The best team technique you've (probably) never heard of
Mob Programming extends Pair approach for productivity, quality gains in software development
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.
One of the newest approaches is Mob Programming, an outgrowth of Pair programming, an Agile technique where two programmers work together, sharing a single computer and taking turns at the keyboard.
"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.'"
Working as a team, it's a lot easier to see patterns and to act on them.-- Woody Zuill
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.
The place that Mobbing has helped the most is merging code when people have been working alone and in pairs.-- Matthew Dodkins
"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."
The productivity payoff
Mobbing may sound counterproductive in terms of the use of developers’ time, but consider that “most organizations have frequent meetings with six or more people,” Zuill points out. "Think of these as working meetings rather than information-sharing ones. Software development isn't about being at a keyboard -- that's just how we get the work into the computer. But the work is thinking, and translating ideas into code."
Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want.-- Nancy Van Schooenderwoert
"If you measure by features or other classic development productivity metrics, Mobbing looks like it's achieving only 75 to 85 percent of individual or Pair output for, say, a team of six or seven working for a week," acknowledges Massey. "However, there's more to productivity than that. In the course of that programming, everyone has contributed their knowledge, so there's no need for training at the end -- nor need to merge. And merging is the most difficult task -- you have to understand the code you are merging. Individual work may have unpredictable problems, or need work to fit together."
"Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want," says Lean-Agile's Van Schooenderwoert. And mobbing can be contagious (in a good way, of course). "If you deliver code to a customer, you may get them into mobbing as a way to review the code with them."
Mobbing is catching on
Mobbing is still in its early growth phase, but it's catching on quickly, says Industrial Logic’s Zuill: "A year ago I did a conference talk in Sweden about Mob Programming -- and this past week, I saw listings for two sessions in Sweden from teams talking about how they had gone about it. In 2013, I gave a talk on Mob Programming in Stockholm at Ericsson, and when I gave another talk there the next year, three other groups did presentations on how they were using Mob Programming. And I know of at least two or three dozen companies doing a substantial amount of Mob Programming."
And Mobbing isn't just for software development, notes Simon Clements-Hawes, an embedded systems tester at Bluefruit. "You can use Mobbing for training, education and other tasks. I've used it for educating, and for project and task completion."
Similarly, Zuill notes, "I've talked with people who aren't involved in programming, like project management groups, real estate managers, and finance companies who are using the Mob method. Mobbing is about working together on knowledge-based or thinking-intensive tasks."
How to get started with Mobbing
"Getting started with mobbing is very simple," says Zuill. “I and others offer workshops on this, but Mobbing is an easy enough concept that you can experiment with it simply from watching online videos."
Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. -- Paul Massey
"There are a few simple guidelines, but the core is 'learning to work well together,'" advises Zuill. "You need a few mechanisms to share information, which is why the driver/navigator model of any idea going through somebody else's hands is important -- the people trying to solve the problem have to explain it to somebody else. This enforces clarity of thinking, versus somebody trying to unravel intent from code. And we want the code to express that intent -- that's about the quality."
Mobbing has two important real-world requirements: a room with a large enough space, and a projector or other large display to allow everybody in the room to see the code on the "driver's" screen. (A blackboard or whiteboard wouldn't hurt, either.)
While Pairing and Mobbing are usually done live, "we have experimented with Pairing remotely, as long as you have good communications," notes Bluefruit’s Massey. And, adds Lean-Agile's Van Schooenderwoert, "remote Mobbing and Pairing is easier to do if the people have already worked together."
"Agile is all about feedback loops. Mobbing is an extension of it," says Bluefruit's Dodkins. "And getting people together in a room is more collaborative. You can look at each other and gesture and express things better than online."
"Knowing we wanted to do mobbing influenced the layout for our new office," says Massey. "We made sure we had a space for teams to spontaneously mob."
"It was helpful to be shown the ropes, but Mobbing is pretty straightforward," says Massey. "Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. This is the most self-propelled practice I've seen. Within a few weeks after training, we were using it successfully."
No silver bullet
Mobbing can't be the only tool in your arsenal, of course, and it isn't a replacement for solo activity. "We don't do this exclusively -- maybe only about a tenth of our time is spent 'mobbing,'" says Bluefruit's Dodkins.
"As with any practice, too much of one thing can be bad," adds Bluefruit's Massey. "For us, the Agile process is a set of principles, and Mob Programming is another tool in the toolkit, along with Pair programming, Test-Driven Development, Behavioral-Driven Development, and a dozen or so others."
"One drawback of mobbing is that while you get the benefit of all people's brains in the room you still need someone to review the code -- which should be somebody who's not in the room," says Dodkins. "If you aren't reviewing your code, good luck -- all code needs to be reviewed."
"Also," stresses Zuill, "I like Mob programming and feel it's good for people to learn it -- but more importantly I feel teams should work hard to figure out what works well for themselves. To figure out their own process by frequently reflecting, tuning and adjusting."
And, says Zuill, there's an unexpected social benefit to Mobbing: "We have found at our workplaces that, by working this way, everybody on the way feels more fulfilled in their lives. We work as a team all day long, and we are uplifting each other and helping each other have a better life. We didn't expect that. And I see this at many places where Mob Programming is being done."
· Read more about Mob Programming at MobProgramming.org.
· Learn about Mob Programming workshops by Industrial Logic
· Want to see Mobbing in action, watch the time-lapse video below of a day of Mob Programming.