“How remote 🅼🅾🅱🅱🅸🅽🅶 improved software product delivery.”
At first, it was an unknown territory for a remote developer like me exploring the world of consultancy for overseas clients. I am part of a team working remotely from South Africa for a client in the Netherlands that had to develop code in a well-calculated project timeline that needed to yield good results in a very short project life cycle space. We had to come up with a plan to achieve great code but also great testing solutions and the only way we could achieve that was to test out the concept of Mob programming.
At first, it was an uneasy approach, we had to split up into tackling sprint board tasks as a team and quickly realized after one sprint that it was very unproductive when we paired up in mobs with more than two to three employees.
So, the conclusion was that it was the most productive when we paired up in groups of two to three employees working on one task. It was quite an interesting experience because we were all on a joined Microsoft teams meeting “mob sessions” as we called it for 8+ hours a day with half-hour break times for lunch. We could easily see how the driver (“person sharing his\her screen of code and typing the code”) being intimidated by the navigator (“person helping to navigate and direct”) and the 3rd member catching (“third eye/person watching to have instant review of the code or a trainee”) the missed coding and testing implementations and that it was putting the driver on the spot to make good decisions and just being navigated for hours.
Mobbing best practices per session:
| # | Role | Description |
|---|---|---|
| 1 | Driver | Person sharing his\her screen of code and typing the code. |
| 2 | Navigator | Person helping to navigate and direct |
| 3 | Third eye (Optional) | Third eye/person watching to have instant review of the code or a trainee |
Our team of three had different backgrounds and different technology expertise but what was interesting is that we always had one out of the three members discuss the better testing solution and the better coding implementation the better refactor approach to make the code simpler and more readable so that we could write documentation for other teams to implement with instruction. It did not take us long as a team to figure out that there was one smarter person on a certain topic and then we all could follow the lead and the same implementation or even if we had some suggestion and refactored solution. It took us about 1 sprint to already be in a sequence and everybody were on the same page and had the same implementation and it grew from there onwards. When we moved to another topic or mob session group joining to tackle the next Epic item on the board, we were already awaiting to get into sync with each other.
From the practical example, it took us only a couple of sprints to get so far ahead with the project schedule that our team were separated to go and help other teams that were behind.
With that said Mob programming is the one approach of many but it worked for us, and I would recommend this as a standard for any remote team even if you are not a programmer. It helped produce better code delivery and we could easily see how we advanced in the implementation of code from Backend API code right through to the Angular Frontend.
Thus, I would give Mob programming a go-ahead approach for any company wanting to achieve great productivity in a remote working environment and if you are not a programmer still do the mob sessions and learn from it, it will increase your team delivery.
Clearing out a myth that circulars around in the industry:
Laying down the facts:
There are some advantages and disadvantages of mobbing we picked up from our experience the last couple of months namely:
Advantages:
- 1.
- The team produces better quality code in a shorter period.
- 2.
- Team members with the size of 2-3 members are the most productive.
- 3.
- Problem-solving is done constantly and instantly.
- 4.
- Refactoring will happen sooner, and it will speed up delivery after a short period.
- 5.
- Team members bond.
- 6.
- Team members learn from one another and improve code skills in shorter periods.
- 7.
- The team is in sync at all times.
- 8.
- Team members become good automated testers too.
- 9.
- Architects, Team Leads can access the mob sessions and can instantly help and drive when needed.
- 10.
- After getting a new person (“Third eye/member”) up to speed, delivery time increases again.
- 11.
- No need for handovers due that knowledge is always transferred between a team’s members.
Disadvantages:
- 1.
- Never have more than 2-3 people in a mob session, reduces the time to complete something, and you could have allocated resources to another mob for productivity purposes.
- 2.
- Mob programming reveals a weakness of each team member.
- 3.
- Mob members must manage conflicts on the spot.
- 4.
- Mob members must manage workplace politics and cultural differences on the spot.
- 5.
- Upgrading of skills do slow down the expected completion time at the current task not known, but not overall.
- 6.
- Never have the same Driver for each task.
- 7.
- If a team member leaves the company and a new employee joins the team it takes a sprint or two (maybe longer) to get a new person up to speed.
Some good practices for Mob programming
- Decide which Storyboard Task item to be completed for the day.
- Select the driver and Navigator and in some cases the third eye/member.
- Always review your code and discuss refactoring options.
- Have a different driver per task.
- Use the TDD approach as a base and if you cannot do TDD then implement your different tests religiously to become better testers.
- Take regular and small breaks for health reasons but stay focussed on your 8 hours a day.
- Most importantly have fun.