Introducing Mob Programming to teams


I have recently been introduced to Mob programming by Woody Zuill andLlewellyn Falco.

So what exactly is Mob programming? The essence of it is pretty well captured in this tweet (press play icon):


First time i heard about Mob programming was in November 2013 in Stockholm at Ericsson, Woody presented this method to the audience and later we had a small hands-on session. I was immediately in awe, but also suspicious. OK, it worked well with a trivial example, but would it work in a real working environment? I decided to give it a try once I got back home.

So, I tried it with a colleague of mine, or actually we just did pair programming with the strict driver/navigator rule (that is originally from Llewellyn,

Turned out it worked pretty well, we got a lot of stuff done and mostly first time right, but the risk of getting lost in the same direction was also quite high.

We tried it for a while but then we just stopped, I moved to another team so we did not have any common work items any more to pair with.

In the Spring of 2015 I attended XP conference in Helsinki, and again Woody was there presenting Mob programming. With a few twists from last time i saw him, I was especially taken when he had started to use cyberdojo by Jon Jagger as a teaching tool – I have had some experience in using that, and I recommended this to Woody in Twitter after my first session.

Anyway, this time my interest was re-ignited and I wanted to try again this with my current team. A team which consisted of people who worked individually rather than in a group – we usually had almost as many user stories open than there were team members. This led to multiple problems. If somebody was sick, that particular user story development stopped. It was extremely hard to jump in to help with a user story. And, as there usually are surprises, we often found ourselves using more time finishing the tasks we originally thought we would.

So, I introduced mob programming to the team, and at start we tried to apply it on some particular tasks of a user story. Couple of rounds of that led to people not wanting to stop, you could almost feel the flow, and it was really enjoyable to see people collaborating so eagerly. But still, something was not right. We started collectively to wander outside of the scope, and the big picture remained unclear. But there was something in the method, it showed us in practice that a team is more than sum of its parts.

A few months on we got a new team member. And, as he was new to the feature we were working on he suggested we could do some kind of code walkthrough when planning the next user story. This turned out to be the missing piece in our experimentation with mob programming. The idea was welcomed by the team, and a suggestion came up that why don’t we actually write some todos or pseudo-code to the files we needed to modify, and another suggestion that let’s do this mob programming way.

As pre-work we split the user story to tasks using a whiteboard sketches and post-it notes( Here by the way is a great way to do that:
We ordered the tasks in implementation order, had a few separate seemingly independent tracks and planned the verification steps. Next we took a meeting room with projector and started to transfer the sticky notes into todos in code. We soon realized it is good to number the stickies and the todos to be able to match them.
Some functions got hit by multiple tasks, but that was expected.

This exercise took about 3 hours, where one hour was spent with the whiteboard and two mobbing the skeleton. After this session we held a session focusing on tests, basically we wrote the test descriptions together based on input from this first mob.

What then happened was truly amazing, we transformed overnight from “user story per developer” to “everyone working on the same user story”. The tasks were done in multiple ways, some preferred individual work, some did pair programming, even some mob programming, so everything from individual to mob.

The story ended up to be about twice the size we expected, but because we all had focus on that particular story, and thanks to the skeleton mob clear common understanding how to implement the tasks and how should the end result look like, we were able to complete the thing in the time frame we originally estimated, just with double the people.

Of course the actual size of the user story was not the only surprise we encountered. Then we ran into first code conflicts. The tracks weren’t as individual as we thought, and it took a lot of effort solving the conflicts. We also bumped into other surprises where we simply had to change the solution from original design. And, as we continued, we realized there were some things we did not even know we didn’t know. All of this led to a bit of frustration, but the main learning was this: When unexpected things happen, call in the mob. When you find possible conflict points in the “skeleton mob”, take a note and do the implementation in those functions as a mob, or at least by pair programming.

We were lucky enough to get Woody & Llewellyn to visit our office after our first successful experimentation with Mob programming, and they hosted a one-hour retrospective for us, where we were able to get some tips how to make the mob work even better for the next time. So if you happen to bump in either one of these fellows don’t be shy to ask help and share your experiences!

So a couple of main benefits, learnings and caveats from this experience:

  •  Really good way to share competence
  • Easy to learn new things
  • Easier for people to ask for help since they share a common goal
  • No more wandering outside of the scope, keeping good focus from start to finish
  • Easy to get into “Flow”
  • This method really speeds up code reviews because everyone is already up to speed at all times!
  • On the learning side, commit early and often! This is especially important if people decide to work separately with the items
  • This is mainly because there will most probably be merge conflicts. Pay attention to possible conflicts already at planning!
  • Handle all merge conflicts and surprises as a mob, or not at least alone.
  • Have a short retrospective immediately after a mob. Note also all of the learnings, this is a good motivator. Make sure you will experiment with the ideas team members have.
  • And some caveats: Prepare for a editor battle! (vim vs. emacs vs. ?) As a facilitator you need be prepared to handle this.
  • Discussion might overheat on implementation details.. Be sure to keep all disagreements constructive, handle them with respect.

Saving the best part last; the biggest learning:

Start with something simple yet relevant. Something where the benefit of teamwork is apparent. If the first impression of mob programming is seen as positive and useful, chances are that people want to continue doing it.

Mob programming as such is not the only tool to have a successful planning session (or whatever your choice of simple but relevant teamwork example is), but it is a great tool for doing real collaboration with real problems. When the moment comes you’ll have a way to mob it out!
There is a lot of material about Mob programming in the internet, this article is one of my favorites:

And here’s a blog post about getting started with mob programming:

Woody’s blog:
Llewellyn’s blog:
Mob Programming Wikipedia article:
Twitter: #MobProgramming

This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s