How many of you have gone through the scrum guide? If you have, then you must have observed that the word “scrum team” appears more than 40 times in that 19-page document.
Nevertheless, we work as individuals in our sprints. Do you know all the downsides to this approach?
Let’s go through them one by one
- The team has no clue what a developer is working on until the stand-up time every day.
- Only at code review time, does another programmer in the team get to know what approach the developer has taken. And if that is not the standard team approach, then the team might not meet their sprint goal.
- There is no knowledge sharing or discussions that happen at a technical level and therefore, the best practice might not always get into the code.
- Without our awareness, a dependency is created on one particular developer who writes that code. So, if that person is not available, someone else might have to take time and go through the code to fix potential bugs.
Is there a solution to avoid all these in a scrum team? Well, thankfully there is. This is where mob programming comes to the rescue.
What is mob programming?
Mob programming is a software development approach where the whole team sits together and solves a problem.
For a long time, we have assumed that software development is an activity of writing lines of code for machines to understand. But isn’t it important that the whole team, who are going to own and maintain it, know about the way it is written?
How on earth is it different from pair programming?
Pair programming is a practice where two people sit together at a shared workstation and collaborate on the same code at the same time. Mob programming is an extension to pair programming where the whole team collaborates to produce a feature with good code quality.
The advantage of having more than two people working together is to have more ideas, different approaches, different perspectives when coming up for a discussion. Even before the implementation has started. This helps for better design and development.
How does mob programming work?
When we start working as a mob, the first thing we need to do is find out what tasks need to be done to finish this story. Then, we discuss different approaches to solve this problem. It goes without saying that we will have a lot of interactions, discussions, and sometimes, arguments as to which is the best approach to solve it. But in the end, we focus on consensus and not on conflict resolution.
In our case, we are a team of 9 developers. So, we split into three mobs with each mob consisting of two backend developers and one front-end developer.
We work with a driver-navigator workflow. One developer will be typing on the keyboard (known as the driver) whereas the other two developers (known as navigators) will be instructing him/her on how to write the code. The driver should only be typing code on the keyboard whereas the navigators will be the ones who know what is going on.
Another important thing is to have rotational roles. We follow 15 minutes cycles, after which the roles get reversed. The driver changes to the navigator and one of the navigators will become the driver for the next 15 minutes.
Myths about mob programming
1) Low productivity: Mob programming might sound counter-productive as to why three people should sit at one workstation to work on a single user story. But scrum is all about faster feedback loops, right?
It is a general perception that mob programming affects the productivity of the team. But, from our experience, we can say that after a dip of velocity for a couple of sprints, the team actually starts to reap the benefits of mob programming.
2) Less focus on sprint commitments: There is a perception that the team might be diverting from the sprint commitment because of too many discussions and too much focus on quality. But, this is only true if the stories are not well-defined and tasks are not clear enough.
3) A lot of wasted time in discussions: But this is exactly what we need in scrum teams, isn’t it? The more discussions, the clearer the stories will become.
It also helps us to explore different scenarios while implementing. Which, in turn, can help us keep the bug count at a minimum.
Benefits of mob programming
Quick feedback loop
We get constant feedback from fellow developers (which can even come from the Product Owner or QAs) about what we are trying to achieve with that feature.
Sharing knowledge (domain or technical)
Constant sharing of knowledge is ensured almost instantly among the team members. When we talk more about a certain way of coding, we can have a good, healthy discussion about why that is the best way. This can also help the developers to gain new insights, new approaches, etc.
As the whole team works together, there is better collaboration. The team will figure out who is better at what and learn from them & vice-versa.
Ultimately the best approach/implementation from the team will get into the codebase.
Ensure coding standards are met
Before a story is said to be done, the team can ensure that coding standards and best practices are met. A separate code review is not required to make a note of this saving some turnaround time.
We are all different, we think differently and have different experiences. Regardless of the level of experience someone has, there are endless opportunities for everyone to discover things that are meaningful to their own improvement. Such as programming paradigms, keyboard shortcuts, design patterns, etc.
No dependency/silos in the team
Mobs help to reduce dependencies completely as everyone in the team knows what thought process went into solving a problem in the first place. This helps teams to fix issues and introduce improvements easily in the future.
The team becomes cross-functional
Developers start to think from a tester’s perspective. The POs start to give input about different scenarios that should be taken care of. Testers start instructing developers what test cases should be covered during unit testing. Over time, the team starts to become more cross-functional.
Important work practices
Now that the benefits are clear, we should also talk about some working agreements. If not done properly, mob programming can actually lead to a lot of conflicts within the team.
Here are a few work practices that have worked for us:
Treat each other with kindness, consideration & respect
Mob programming involves a lot of interactions within the team. To reach this level of communication, we have adopted a principle to always treat each other with kindness and respect.
When everyone is committed to living by this principle, it is easy to ask questions (even the silly ones 😉), become comfortable to say “I don’t know”, and to build trust.
Focus on good quality code
Simply getting a lot of work done has little value if it is of poor quality and can’t be maintained or isn’t fit for the intended use.
With mob programming, our onus is to produce good quality, maintainable code.
Assume variability, preserve options
This is straight from SAFe principles. In this approach, developers consider multiple design choices at the start. After that, they continuously evaluate economic and technical trade-offs. Then, they eliminate the weaker options over time and ultimately converge on a final design, based on the knowledge gained to that point.
Mob programming helps us to abide by this principle. There are various approaches that gets discussed before we start. We try a minimal possible solution with all those approaches. Then we eliminate ones which won’t work or are not efficient in the long run. With this, we are sure that the best implementation is going into the codebase.
Take small breaks together:
This is more to do with the attention span a human being has (though nowadays it is reducing at a drastic pace thanks to the gadgets ;)).
We usually take breaks of about 15 minutes after every 45 minutes of mob programming. This helps us to relax, reflect if we are really getting in the right direction.
Note: While these principles and practices are working well for us, we are always on the lookout for improvement.
We also realize that other groups and teams might find that this approach might not work in their context. So, it’s about finding what works for you as a mob and adhering to those working agreements.