Transcripted Summary
You may have heard about mob programming.
It's...
Quote
All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer
This whole team approach was initiated by Woody Zuill's team back at Hunter Industries. His approach is not only about programming. You can also do mob testing, mob code review, mob everything.
So, as working in a pair is often simply called pairing, working in a mob is often called mobbing — not intending to hint at any negative connotations this term may have.
The basis of mob programming can be found in a strong-type pairing, as described in the previous chapter.
You have the driver at the keyboard taking instructions and taking care of their implementation. In the beginning, you might have a designated navigator to lead the way. This is rather considered a training role and it will dissolve in more experienced and mature mobs.
And finally, you have the mob preparing for their turn as navigator, providing suggestions, researching, taking notes. When navigating, the same rules as when pairing apply. Try to talk at the highest level of abstraction. So, start with the intention and only if the driver doesn't understand it, provide the location or maybe details until every key stroke.
However, details will be picked up quickly, so make sure to return to the highest level of abstraction as soon as possible. You rotate frequently in a mob, either on time or on task, whatever works for you.
There are a few things to note.
You're at the right place if you're either contributing or learning in the mob.
If you have two ideas, bias to action. Try them both! It's a good idea to try the idea of the more junior one first.
Apply the “yes, and…” rule of improvisational theater. Don't destroy ideas of others before you but try to build upon them.
The general guideline is to remember that the mob should be a safe learning zone, so be kind, considerate and respectful with each other.
Basically, it's about finding your own way how to work well together in your context and turning up the good.
Whenever I talk about the mob approach, questions and concerns about productivity come up.
I mean, how productive can it be to have all people working on the same topic? Now Woody Zuill flips this around and he asks: How productive can it be to have all people working in silos? Who has ever proven that working in silos is more productive?
So, let's rather focus on effectiveness.
In a mob, you have all brains in.
It's not about getting the most out of everybody, but about getting the best out of everybody.
The whole team only has one topic in progress, so no one has to switch context. Also, you don't have to wait for answers on your questions as you have all people available. So, you're never blocked this way.
There's no need for daily sync meetings as the whole team is synchronized all the time. Working in a mob might be perceived as slower sometimes, however, slow allows for thoughtful thinking, and we can quickly go in the right direction and align on conventions right when they arise.
So, the benefits from strong-style pairing are multiplied here, especially when it comes to implicit knowledge sharing as you can instantly share that with the whole team. Compared to pairing, the mob is an even safer environment where power dynamics are mitigated better as the whole team is there to regulate.
Also, it's less intense than pairing. You can take personal breaks without stopping the work. You can also easily opt out for tackling some private tasks and just rejoin the mob and get quickly up to date again.
Vacation replacement is no worry anymore if you're working in a mob.
One of the best things to get started is to check out the Mob Programming Guidebook available on Lean Pub (linked in the course resources).
_*Now here's the story of what my current team did… _
We tried it by the book at first. We had a designated navigator, driver, the mob. We were rotating every four minutes. The driver was not allowed to think.
But there were a few things where we stumbled.
We had to book a meeting room for each mob session, which turned out a problem as meeting rooms were hardly available at our company.
Also, all of us had different operating systems, differently defined shortcuts in the IDE, different keyboard language layouts.
The story scope to start with did not feel right. Some stories we tried were perceived as too small, others as too complex. For some stories we did only parts in the mob and for others we did work in the mob from start 'til end.
What we didn't face were issues like talking over each other. Or not getting the chance to talk at all. Or not trying ideas from more junior people. But overall this approach felt a bit too formal for my team, so they wanted to try out other ways and adapt it to their needs.
We changed our approach every time we've tried it, and we learned what worked for us.
For example, we now use our own office. We don't have to book meeting rooms anymore. We just have a TV screen in our room we can use. We have a table and some space in front of the screen. It's already prepared, and this made it really easy to start mobbing.
We still rotated of course, but we used longer rotations, like every 15 minutes. We also did not use a timer anymore but rotated when finishing a task.
Everyone was allowed to contribute including the driver. The only rule was that you had to suggest the next step, not rushing ahead and already implementing it.
We also allow partial mobs. We didn't force anybody to stay on the mob. It was hardly possible to find longer time slots without any meetings anyway, which would have hindered us from mobbing at all. Interestingly, by allowing more freedom, we noticed that people were trying to get back to the mob again as soon as possible. They felt they would miss out otherwise.
Different companies, teams, people have different approaches when they mob.
Back at Hunter Industries, where this practice evolved, they still have full-time mobs.
Other companies use it as a method in their toolbox — to solve tricky problems, to share knowledge, to create a shared understanding and knowledge base when introducing new techniques or technologies, for onboarding team members, for learning across teams and many more.
In the case of my current team, we had a very intense phase where we mobbed a lot of the time. As of now, we still mob, but not as frequently as before. We have two ways to initiate a mob, so either we mark a story for mobbing in advance, or we simply call out a mob spontaneously whenever we see that the demand or value for it.
Introducing the mob approach had a side effect. We now pair up a lot more! Before, developers always hesitated a bit to pair up. They only asked for support in case support was needed. But after experiencing the benefits of mobbing, they didn't shy away from pairing on a story anymore, also from the beginning or appearing in different constellations across roles.
The mob approach is also a great tool in other occasions. For example, when learning in the testing community in our company. Or having cross-team, cross-role, maybe even cross-location mobs to learn with and from each other. So, people are volunteering here to join a learning experiment, which might just be the first allies you need in the teams to start mobbing.
This is mainly about learning, but it can also be used to tackle cross-team problems together, like defining interfaces.
Resources
Mob Programming. A Whole Team Approach by Woody Zuill and Kevin Meadows
Increasing Quality Skills and Collaboration Through Mob Programming-The Clearlink Experience
