Nmedia - Fotolia
Agile pros are all about teamwork, but mob programming redefines what it means to work side by side. I witnessed the power of teamwork firsthand led by mob programming guru Woody Zuill at a recent workshop in Waltham, Mass. He asked the group of 16 or so software pros "What if we stayed together and started working in the meeting?" As opposed to deciding who does what and going our separate ways.
Mob programming is a development technique where the whole team works together to produce a feature. I think of it as pair programming on steroids. About four to six people sit at a single monitor -- an 80-inch model helps -- and take turns at the keyboard.
The mob way of working feels strange at first because of the extreme degree of togetherness it demands. Staying together flies in the face of traditional teamwork, where members convene, divide up the work and go their separate ways. Can mob programming really make a team more productive? Zuill, an Agile coach for consulting firm Industrial Logic, does not promise it will. But during the workshop he led the group in a game called The Power of 13 and results suggest the answer is yes.
Fun with The Power of 13
Here's how to play The Power of 13, eveloped by Agile coach Paul Boos and four others at the Agile Games conference in 2014.. Participants divide themselves up into four teams of four. Each team has its own table, a whiteboard and a stash of sticky notes in a unique color. Each participant is given three dice. Work is divvyed up into eight-day iterations, with each day of work represented by a single role of the dice. The goal is to roll a 13 on one set of three dice; a roll of 13 counts as a completed story, represented by a sticky note of the team's whiteboard. At the end of the iteration, the team with the most sticky notes wins.
Round 1: Constrained way of working
We played the game and here's how it went down. During the first iteration, participants worked alone. If a participant rolled a 13, he slapped a sticky note on the board and got to stop working. Results were unimpressive. On day one, only one of the 16 participants rolled the lucky number and subsequent days were the same or worse. Final tallies for each team were in the low single digits. During the retrospective, participants noted the high degree of randomness in this approach and the low degree of productivity. They agreed this is a constrained way of working. I observed during round one that everyone had their heads down. They were narrowly focused on their own three dice. They appeared worried they wouldn't do well. No one smiled, talked, laughed or looked happy.
Round 2: The power of pairing
In the next iteration, team members paired up. Participants still have to roll a 13, and they can't recombine the dice. But this time around six dice, not just three, are in contention. Also, once they get their story done, participants can help other team members. No more taking the rest of the day off. At the end of first day, every team had produced at least one story. At the end the iteration, teams completed 13, 11, eight and 12 stories, respectively. During the retrospective, participants said they liked the pair way of working because it paid off. I noticed that in round two they loosened up a bit. Heads were no longer down, more conversation took place. Team members were beginning to get engaged.
Round 3: The whole team mobs
In the final sprint, the whole team worked together. Yes, they still have to roll a 13, and no, they can't recombine the dice. But this time, 12 dice are in contention. At the end of eight days, results were impressive: Teams completed 17, 16, 18 and 19 stories respectively. During the retrospective, they stated the obvious: Productivity, measured in story output, is way up. They noted that different team members were good at spotting different combinations of 13. "Some people were quick to see 6-6-1; others saw 4-4-5," one participant said. Others observed the lack of conflict among team members. And another said the pressure of worrying how well he would do was off. "We had a safety net." I saw lots of talking and laughter in round three. People smiled, and they pulled their chairs up close to their teammates. They had fun.
Will mob programming work?
I know The Power of 13 is just a game. The results I observed offer no proof that mob programming will work for you. Rolling the dice is, after all, a lot easier than doing the hard work that all software development demands. Zuill is not insisting mob programming is right for every team. He's simply saying he's seen how getting everyone working on the same project at once can help solve some of those "big nasty problems" that plague "big nasty projects."
So, try it. Play The Power of 13, and let me know what you think.
The state of Agile and DevOps has room for improvement
Maybe you can be Agile and still do your own thing
Strategies that boost effective team communication