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."
Resources
No comments:
Post a Comment