Mob ProgrammingA Whole Team Approach

Woody Zuill and Kevin Meadows

This book is for sale at http://leanpub.com/mobprogramming

This version was published on 2016-10-29

This is a Leanpub book. Leanpub empowers authors andpublishers with the Lean Publishing process. Lean Publishing isthe act of publishing an in-progress ebook using lightweight toolsand many iterations to get reader feedback, pivot until you havethe right book and build traction once you do.

© 2013 - 2016 Roy L. Zuill

Woody Zuill

Eugene Zuill - My dad. A brilliant engineer, businessman, and kindhuman being. From him I learned a great deal about collaboration,teamwork, selflessness, and “kindness, consideration, and respect”.

Kevin Meadows

Gene and Nadine Meadows, for showing the virtue of persistence.

Contents

Part One: Introduction . . . . . . . . . . . . . . . . . . . . 1

1.1 What is Mob Programming? . . . . . . . . . . . . . . . 2How We Started . . . . . . . . . . . . . . . . . . . . . . 3Why this Book? . . . . . . . . . . . . . . . . . . . . . . 3

1.6 Quick Start Guide . . . . . . . . . . . . . . . . . . . . . 5

Part Two: The Details . . . . . . . . . . . . . . . . . . . . . 14

Part Three: Productivity . . . . . . . . . . . . . . . . . . . 15

Part Four: A Few Other Things . . . . . . . . . . . . . . . 16

4.6 Turn Up The Good . . . . . . . . . . . . . . . . . . . . . 17Something that Works Well: Turn Up the Good . . . . . 17Solving Problems - What’s Wrong with That? . . . . . . 17Turn Up The Good . . . . . . . . . . . . . . . . . . . . 18

Part Five: Experience Reports . . . . . . . . . . . . . . . . 20

5.1 Teaching Mob Programming . . . . . . . . . . . . . . . 21

Part One: Introduction

This part of the book will introduce Mob Programming, which forbrevity we sometimes refer to as “Mobbing”, and give an overviewof its approach. We explain the basics, show you what it looks like,and explain how it all got started. When you finish this section youshould have an understanding of the big picture of Mobbing.

1.1 What is MobProgramming?

Mob Programming is a software development approach where thewhole team works on the same thing, at the same time, in thesame space, and at the same computer. This is similar to pairprogramming, where two people sit at the same computer andcollaborate on the same code at the same time. However, with MobProgramming, we extend the collaboration to everyone on the teamwhile still using a single computer for writing the code and doingother work.

In addition to software coding, the team works together to doalmost all the work a typical software development team tackles,such as defining stories, designing, testing, deploying software, andworking with the customer, business expert, or Product Owner.Almost all work is handled as “working meetings” or workshops,and all the people involved in creating the software are consideredto be team members, including the customer/product owner. Wework this way more or less all day long, every day.

In other words, this is an evolutionary step beyond the ExtremeProgramming concept of pair programming.We strive to accentuateand amplify concepts such as face-to-face and side-by-side commu-nication, team alignment, collaboration, whole team involvement,

1.1 What is Mob Programming? 3

continuous code review, and the “self-organizing team”, to name afew.

HowWe Started

We did not set out to invent a new way to work, or to extendthe idea of pair programming. We simply noticed some things thatwere working well for us and expanded on it. We had been holdingpractice sessions using a Coding Dojo approach where everyoneuses a single computer with a projector and passes the keyboardaround.

At one point we needed to restart work on a project that had beenput on hold for several months. We gathered to take a look at thisproject and decide on how to take on the work.We started by takinga look at the details of the project and it was natural for us to passthe keyboard around as we worked. We held a retrospective at theend of the day and we all felt the experience was very positive.We decided to continue working together, in the same way, thenext day. We haven’t stopped since and have successfully deliveredmany projects and enhancements over the ensuing years since westarted doing “Mob Programming”.

Why this Book?

In a way “Mob Programming” itself is the story of how one teamdiscovered how they wanted to work. As people started finding outabout our “new” workstyle, we shared it. We invited people to visitus so they could see for themselves, and we started getting invitedto share at user group meetings and Agile conferences. This book isa result of that sharing.

Mob Programming grew out of a few simple ideas:

1.1 What is Mob Programming? 4

1. The people doing the work can best figure out how to do thatwork

2. We can get a lot of benefit out of studying and practicingtogether

3. Getting good at getting good results from retrospectives isimportant

4. Pay attention to what’s working, and look for ways to “Turnup the good”

Mob Programming itself is an outgrowth of paying attention toproviding an environment where everyone can excel in their work,and in their life. It’s our hope that your team can benefit from un-derstanding and applying the idea of creating and protecting suchan environment, and perhaps something like Mob Programmingwill happen for you.

In other words - Mob Programming isn’t necessarily universallyapplicable, but the idea of working well together just might be.Follow along on our journey as we share the ideas of what we’vedone and what we’ve learned. We’d love to hear about the journeyyou are on, and the successes (and failures) you are having.

1.6 Quick Start GuideTo make it easy to begin, let’s begin at the beginning.

Keep it simple. Take baby steps. There is no “one right way”.

It’s important to be flexible because nothing we are telling you iswritten in stone. These are just ideas for a place to start. There is no“one size fits all” set of rules. It will work better if you pay attention,notice what is working, and adapt as needed.

Here are some ideas that have worked well:

• Size of team: 4 or 5 people• Attendance and participation are voluntary• Arrange a physical setup that is comfortable, simple to puttogether and use

• Follow the Driver/Navigator model• Use a rotation time of 4 or 5 minutes• Work on an exercise• Do it weekly: for 2-3 hours, or daily for 1-2 hours• Invite anyone who is interested• Try to show Kindness, Consideration, and Respect• Hold a short retrospective after each session

We’ll cover each of these in a bit more detail - but they are almostself-explanatory.

Size of team: 4 or 5 people

It is easier to start small and scale up as you gain experience. Gettinga frequent turn at the keyboard is comforting to folks who are used

1.6 Quick Start Guide 6

to spending all their time at the keyboard. Also, we need to get usedto quickly taking the keyboard, and then quickly releasing it. With4 or 5 members everyone gets more practice doing this.

If you have more than this number who wish to start then considercreating another team and experimenting with approaches to seewhat works best.

Attendance and participation are voluntary

An important point is that no one is forced to join. Everyone isinvited, and can attend and participate if they choose. They are alsofree to stop participating if they choose.

A physical setup that is comfortable, simple toput together and use

If you can provide a permanent workspace for Mobbing that isgreat. However, it might first be necessary to use a temporary space.We’ve seen a variety of setups, and they all seem to work well.[NOTE: If your teamworks remotely, this can also be done virtuallyusing video conferencing and screen sharing tools]

The first choice for many teams is the standard conference room,where there is a long table with a screen at one end. This is notvery good, as it is difficult to switch Drivers, and the seating is sub-optimal for comfort. It often results in back, neck, and eye strain.

If you must use a conference room and have the freedom to changethings, have everyone sit on the long side of the table with a largescreen either on the table or on the wall in front of them.

Any sort of monitor or projector that you have available willprobably be workable if you put a little thought into it. Usually, it’sbest to have a monitor that is large enough for everyone to easilysee, but you can use several smaller monitors. Try to be flexible.

1.6 Quick Start Guide 7

Our preferred setup

This is a setup we have found to work very well and have seen it ata number of companies. You can have one, two, or more monitors.Experiment with monitor height to make sure it is at a height thatworks well for everyone.

A laptop and larger monitor on a table

This is easy to set up and then remove whenever you want toquickly put together a Mobbing station. It also works well for apermanent setup.

1.6 Quick Start Guide 8

The “triangle” setup

This uses 3 monitors with three keyboards. One or two people cansit at each monitor/keyboard station. This works well when youdon’t have a large monitor. As with the other setups, there is onecomputer, and the monitors are all mirroring the same display.

1.6 Quick Start Guide 9

Follow the Driver/Navigator model

The Driver/Navigator (DN) model is our preferred approach forMob Programming. This is a brief introduction but you can finddetails in the chapter that describes DN in depth.

The basic arrangement is that one member of the Mob team is theDriver doing the typing while the others are the Navigators doingthe thinking, discussing, diagramming and sharing of the ideas thatmight be translated into code. The Navigators are responsible forthinking through the logic and purpose of the ideas and the Driveris responsible for translating that into code.

The main point is that “for an ideato go from someone’s head into thecomputer itmust go through someoneelse’s hands” - Llewellyn Falco

This allows for better explanation and review of ideas that willbecome code. After an agreed-upon time, the roles switch and

1.6 Quick Start Guide 10

someone else becomes the Driver.With practice, the rotation shouldbecome easy and natural.

There are other ways to work, and you are likely to find some otherworthy approaches. Regardless, it is worthwhile to practice thesethings:

• Allow others to speak• Seek their ideas• Ask questions as needed• Pause occasionally during the work to have discussions with-out coding

This does not always come naturally and it takes an effort to alloweveryone, especially the quiet voices, to have their say.

Use a rotation time of 4 or 5 minutes

We cover the rotation specifics in a later chapter but we suggestrotating the Driver every 4 to 5 minutes when you first beginMobbing. This particular interval allows everyone a frequent turnas the Driver while also keeping the Driver role short-lived so theDriver does not begin to try to work without direction from theNavigators. Once you gain experience you can always experimentwith different intervals. Remember: Not everyone needs to take thekeyboard.

Work on an exercise

We suggest it’s good to begin Mobbing with code that is safe to al-low you to experiment in a sandbox without concern for somethinggoing wrong. Simple exercises, like coding a game of Tic-Tac-Toe,can be a great place to start. While we can work on production codeor other actual work for learning Mob Programming, it’s likely the

1.6 Quick Start Guide 11

Mob team will be more relaxed, have more fun, and be more opento learning if they are not under the additional pressure of workingon production code.

Where can you find simple exercises to work on? One great sourceis Emily Bache’s excellent book, “The Coding Dojo Handbook”,available from Leanpub.com. She provides a catalog of interestingand simple exercises called “Code Katas”. You’ll come upon the term“Code Kata” when you search for simple exercises to use. A CodeKata is a small, fun problem that shouldn’t take you more than anhour or two to solve. (Conceptually, a Code Kata is a bit biggeridea than just the exercise itself. We won’t go into that here, youjust need to know that they make excellent, simple exercises forlearning Mob Programing with your team.)

There are also many websites that provide simple exercises thatyou can use. A quick internet search will yield many sites withinteresting and fun Code Katas and exercises.

Additionally, you can do the same exercises more than once, andyou can try them with different Mobbing setups so the team canexperiment and determine which setup produces the best result.

Once the Mob gains experience and is fluent with the basics theycan choose to graduate to live code.

Do it weekly: for 2-3 hours, or daily for 1-2 hours

The idea here is to start small and scale up as you gain experience.As with anything new it generally flows more smoothly when it isintroduced gradually. This gives the team time to reflect on theirexperience and make the adjustments that they wish. There is nohard and fast rule but a few hours per day or per week will probablybe sufficient to start understanding the Mobbing process.

Of course, the Mob team may find that they are making rapidprogress and wish to scale up to more hours. That is their prerog-

1.6 Quick Start Guide 12

ative and they should not be required to scale up unless they areready.

Invite anyone who is interested

Perhaps just your programmers will be interested at first. That is notuncommon. However, you might want to consider including a crosssection of team members, such as coders, testers, product experts,managers, coaches, you name it. This can be a real bonus becauseyou are getting a diversity of perspectives. Mob Programminghas worked well for us by taking advantage of this collectiveintelligence.

Strive to make it comfortable for those who can’t code, or arenot willing to take the keyboard. This isn’t a problem. No onehas to take the keyboard. Mob Programming is about quicklysharing ideas, discussing them, and proving them. Work to keepeveryone involved as an active participant in the discussions andidea generation - it’s not important that everyone writes code.

Try to show Kindness, Consideration, andRespect

This is a key feature of Mobbing, the ability to treat each other withKindness, Consideration, and Respect. We cover this in detail in alater chapter but for now, let us state its importance to the successof Mobbing.

Why? Working as a team means we will spend a lot more timeinteracting with each other than we normally would. If we treateach other with Kindness, Consideration, and Respect it means wecan avoid the resentments, anger, and unhappiness that can oftenburden a team. It isn’t always easy and it isn’t always instinctivebut things will flow much more smoothly if you try your best.

1.6 Quick Start Guide 13

Hold a short retrospective after each session

After each session take the time to do a short retrospective. Askyourselves: what went well and we want to do more of it? What didnot go well and we want to change it? This will be helpful as youexperimentally find your way to a Mobbing approach that worksbest for your particular team. The team will be making the timeto reflect, tune their approach, and make adjustments for the nextsession. Taking this kind of iterative, evolutionary approach willhelp the team be more successful in Mobbing.

Part Two: The Details

This part of the book will dive into the details of Mobbing. Wedescribe how a typical Mobbing team is structured, what theirwork environment looks like, the details of the Driver/Navigatormodel, and address questions regarding why we want to workthis way. When you finish this chapter you should have enoughunderstanding to attempt Mobbing in your work environment.

Part Three: Productivity

This part of the book will address one of the fundamental issuesof Mobbing: its productivity compared to other types of team ar-rangements. Specifically, we address how a group of programmerscould be more productive than individuals working alone (Hint:Productivity is not as meaningful as effectiveness. That is, if weare very productive producing something no one wants, is thateffective?). We examine how some problems that affect other typesof team arrangements simply faded away when Mobbing. Whenyou finish this chapter you should have an understanding of theproductivity benefits of Mobbing that will help you decide if youwant to pursue it in your environment.

Part Four: A Few OtherThings

This part of the book will address a number of miscellaneous topicsrelated to Mobbing. We examine some commonly asked questions,look at concerns that often arise for individuals as they considerbecoming part of a Mobbing team, and whether we think Mobbingwill work for you (Hint: we don’t know). When you finish thischapter you should have answers for some typical questions as youconsider Mobbing.

4.6 Turn Up The Good

Something that Works Well: Turn Up theGood

This concept comes from Kent Beck and Extreme Programming.The basic idea is to pay attention to what is working nicely and tryto find a way to make it even better.

“When I first articulated XP, I had the mental image of knobs ona control board. Each knob was a practice that from experience Iknew worked well. I would turn all the knobs up to 10 and see whathappened. I was a little surprised to find that the whole package ofpractices was stable, predictable, and flexible.” - Kent Beck

This is a profoundly different way of thinking about how we do ourwork.

Solving Problems - What’s Wrong withThat?

There is nothing wrong with solving problems. We rightly focuson things that are not working and should be fixed. This is very

4.6 Turn Up The Good 18

effective and there is no reason to abandon this approach. Whenthere is something that needs to be fixed then let’s figure it out andfix it.

But what if we also ask “What is good and we want more of it?”

Turn Up The Good

It’s deceptively simple: Notice what is working well, and find a wayto turn it up.

Turning up the good is not about solving problems. It is aboutaccentuating the things that are going well. Amplifying any nuanceof goodness that we notice.

“Ac-Cent-Tchu-Ate the Positive” –Johnny Mercer

Noticing the Hint of Goodness Whenever We Can

It isn’t always natural to look for the good and bring it to the fore.It takes the conscious practice of paying attention. Become good atnoticing anything different. If something has even a faint glimmerof goodness, capture that, ponder it and reflect on it. Mention it outloud: “Did you notice that? How canwe get more of that next time?”As we get good at this, we start seeing the good in everything.

Exploring Ways to Turn it Up

Once we’ve discovered something good that we think is worthturning up (andmost of it is), we can start exploring the possibilities.It’s been useful for us to ask “what” questions such as:

4.6 Turn Up The Good 19

• “What would it be like if …?”• “What would it take to …?”• “What would have to be true for …?”

Here’s an obvious and relevant example:

“We noticed that working together during this meeting was good.What would it be like if we worked this way all day long? Whatwould it take to make it easy to do that? What would have to be truefor us to want to continue doing this?”

Being Resolute in Searching for the Pocket ofGoodness

“Real life” and “Practical concerns” often distract us from followingup on little things that might be good if they had a chance to growand mature. It can be easy to let things drop. Watch for this andfind ways to keep the good things in mind so they don’t wither.

When you find something good, make it visible. Put it where thewhole team can see it. Refer to it on a regular basis. “These are thegood things we’ve been noticing” and “Here are the things we’vebeen trying”. Take time to review the ideas that concepts that areemerging from this collection of goodness.

Nurture and Grow the Goodness

Emerging goodness requires protection from things that can devourgoodness before it becomes established. It requires conscious effortto be protected.

“Protect new ideas from those whodon’t understand that for greatness toemerge, there must be phases of not-so-greatness.” - Ed Catmull

Part Five: ExperienceReports

This part of the book provides the reports that teams in the fieldhave experienced while implementing Mobbing in their work-places. Each team has a slightly different experience and theirinsight might be helpful if you are considering Mobbing. Whenyou finish this chapter you should know what Mobbing was likefor other teams.

Got an experience of your own that you want to share? Pleasecontact us at MobProgramming@gmail.com.

5.1 Teaching MobProgrammingby Nancy Van Schooenderwoert

A team can learn Mob Programming in just one hour.

I’d been invited by the team’s manager to offer ideas that wouldhelp tech leaders to emerge more quickly. I said I’d like to try doinga Mob Programming intro session.

Before the intro session, I talked with the team’s tech lead to explainthat I wanted to try a group coding exercise that might help themwith their learning crunch. They needed a way for team membersto learn the tools and codebase faster. I asked him to pick outsome real work that needed to get done, but something most ofthe team would find familiar. Then we’d use it for trying out MobProgramming.

I wanted mobbing to be the only new element – everything elsewould be known territory.

The team already had a solid Agile foundation in place – decentcode management system, test runner, and incremental build tool-ing all in daily use. Their manager(s) were open to trying new prac-tices and were fine with letting it be the team’s decision whether to

5.1 Teaching Mob Programming 22

use Mob Programming or not. They were well experienced in howto grow good Agile teams.

With the team assembled for an hour’s worth of “some new thingfrom the USA”, I covered these bits:

• There is a team in SanDiego that started coding together withall the team members at one computer – I know it soundscrazy, but they are doing this because they want to. They’regetting a lot more work done, and they go months withoutany bugs getting into production.

• This method didn’t come from consultants, or academics, ormanagers. The team came up with it. (visible interest/curios-ity on all the faces at this point).

• They started this in 2011 and have worked this way all dayevery day since (even more curiosity now), and the practicehas been spreading.

• Their management doesn’t even know they work this way– all they see is good solid code coming out and they don’tinterfere!

• Want to see what that looks like? (We watch the 3-minutevideo “A Day of Mobbing”)

• Mob Programming is so simple – just 3 rules:– Driver does not think– Navigator verbalizes all ideas– Shift every 4 minutes (Navigator becomes Driver, etc.)

• We could debate all day about whether this can work – orwe could just try it on some of your stories that you need toimplement. Want to try it? (yes they do!)

• Woody’s team is using the roles of Driver and Navigatora little differently than I’d like to use them to start off.We’ll start with shorter turns and only one person at a timenavigating.

• One sure way that Mobbing will fail is if you don’t talk.Llewellyn Falco has a saying “An idea has to go through

5.1 Teaching Mob Programming 23

someone else’s hands to get into the computer”. I think ofit like the team acting as a virtual brain, and hearing eachother’s ideas is what makes it able to think. Only I mean realthinking here, not ‘group-think’.

All the above points took 15 - 20minutes to cover. Thenwe spent thenext 45 minutes mobbing. Occasionally someone would say “I don’twant a turn at the keyboard – I can’t type fast”, or “I’m skeptical –I’ll just watch”. No problem. Let them decide whether or when toget involved.

At the end of the session, I asked what they thought of it. Couldthey envision using it for their real work? Yes, at least for learning,they agreed. People took turns commenting and many compared itwith pairing saying that it seemed easier. A few didn’t like it verymuch, but might use it occasionally for specific reasons like a verydifficult task, or to train someone.

This scene happened with four different teams. They had verysimilar starting situations – already using Agile software practices,working for managers who were supportive but not mandatingMobbing. In each case, the teams continued using Mobbing becausethey chose to. Not 100% of the time, but when its benefits wereobvious. Now, more than a year later, all four teams are stillMobbing.

At a company in the UK, they were organizing an office move whenI introduced Mobbing, and team members immediately asked theirmanager to create Mobbing spaces for every team.

They quickly developed some variations, such as “Mob merges”where the whole team would gather to complete a complex mergeof code that would be tricky to communicate to all. It’s a situationwhere clear team-wide communication about a complicated oper-ation is very important but only for a few hours. Once the merge isfinished and fully tested, there is no further need for its details. Soold-style prose documentation would be especially inappropriate.

5.1 Teaching Mob Programming 24

The company also used Mobbing when delivering completed codeto customers. By Mobbing with their customers’ engineers, theycould quickly show them how the test suites worked, and this alsointroduced their customer to Mob Programming.

Mob Programming does not go viral like this with every team. Forthose who aren’t using TDD, or who haven’t got a robust Agilebuild process in place, that makes for a lot of barriers. There mightbe other reasons too.We are learning by doing. There is no thoroughresearch into this question at present.

I do believe that any team – even a non-Agile team – can start tolearn Mobbing the way Woody’s team started. All they need is thewill to begin learning together and to act on what they learn infrequent retrospectives.