To Mob or Not To Mob: How we got started with (and sold to) Mob Programming
- 07 Nov, 2019
Mob Programming is one of the latest practices to come out of Agile Software Development. It takes Pair Programming (2 development team members working together on one machine) and turns the dial all the way up to 11. The entire team working together on one machine. This sounds like a recipe for a handful of disasters, but paradoxically it works amazingly for one of the teams I was working with a year ago.
The team’s journey so far
In 2016 a few of the team attended Woody Zuill’s talk on Mob programming at YOW! and that certainly piqued their interest. And when we were confronted with a massively thorny (and elusive) set of problems they had little to lose and gave it a try. But after solving the problem we stopped and went back to ‘regular’ development.
But this first taste did get us excited about Mob Programming and did give us a glimpse into the benefits. So when Woody happened to be in Australia, we immediately invited him over for an in-house workshop.
And then another big opportunity came up. A new green-field application where they could introduce new technology. One of the choices we made on the front-end was to go with Elm. But with no experience in the team we needed to get up to speed together very quickly. And we turned to Mob Programming again. And this time we didn’t stop and continued with the practice (almost) full-time for over 3 months.
Now we have a very supportive Product Owner, management team and stakeholders, who allowed them a ton of autonomy and flexibility, but even they were a bit wary and concerned that the entire team working on only one problem at a time.
So here are some of the points we have used to alleviate those (very valid) concerns.
-
Instant feedback and no hand overs When you work in a mob, your pull requests are not actually reviews anymore where feedback is going back and forth. Everyone is already on the same page. There are no handovers. Code is reviewed and checked in throughout the day.
-
Increased alignment on architectural and design decisions When we started on the application, there was no technical foundation yet. Building a new framework is difficult and when we would have approached it as individuals, it could have lead to a very long throughput time. We have been building it as a mob and feel that we are explicitly aligned to our design decisions and the foundation is robust and stable.
-
Reducing waiting times One of the bigger problems we face in our work is not productivity: it is getting answers to questions that block us. These questions can come from e.g. from team members, stakeholders and, product owners. While you wait for answers, you would pick up a new task, which increases your work inventory. And inventory is waste and increases cognitive load. When you are working together as a mob, there is no wait time on people in the development team. They are in the mob. The product owner is currently not part of the mob. So there is still an external dependency on response time by the product owner. In our case, our product owner feels more pressure to respond quickly, because a whole team is waiting for a response as opposed to one person.
-
No context switching Software development is about complex problem solving. When you make decisions on your own, you are likely not to get all of it right. And when you make a poor decision, you will get feedback at the code review (if you are lucky, in product when you aren’t).
It’s likely you will have to get back into code you created a while back, and it’s likely that you have already moved past this work and picked up something else. Context switching comes at a cost. When you are in a mob, everyone is focused on the same task. Common alignment of our understanding of the complexity of the problem is happening real-time and in sync. You are building a shared understanding on the next steps in real-time. There is no context switching.
-
Catching bad decisions early Working on your own doesn’t provide support for complex tasks. Making poor decisions, increases risks of rework later. Mobbing decreases the risk of making bad decisions. With each decision you make, you have to go through the mob in real-time. Everything is debated.
-
No interruptions when team members are away When someone goes on leave, the rest of the team is not left with a situation where there is a knowledge gap. Anyone of us can get in there and contribute.
-
Increased participation and learning When you are mobbing, you are as a team accountable for the problems. Mobbing forces you to align your understanding to get to common alignment and understanding of the problem. Each person brings a different perspective. As a mob member you are obliged to understand the problem as well as your peers. Because when it is your turn to drive, you need to understand what you are solving and translate it to code. If you don’t understand the problem, you are directly accountable for raising it with the mob.
What else?
We have learned that we can apply mob programming most of the time but not always. For trivial tasks, we have learned that it is more efficient to split up and work on those individually. We still have our regular Scrum events. Daily scrums, sprint retrospectives, planning and reviews with the team and stakeholders. Our Product Owner and Scrum Master were not part of the mob.
So far we have been really excited about the benefits. In software development it is always hard to accurately measure productivity. But we feel like we develop higher quality code faster, our product owner feels we are getting work done quicker and we are certainly more aligned and learning faster.
-
Want to learn more about mob programming, please check out these online resources and talks:
GOTO 2017 - Mob Programming: A Whole Team Approach - Woody Zuill Mob Programming: A whole team approach - Woody Zuill