How can 3 people be more cost efficient doing ”one mans job”?

In this article ill try share my experience of using Mob-programming to increase efficiency, quality and help build psychological-safety among the team-members. And how my view turned from "a sceptic" to a "promoter" that have been able to reap the benefit having highly efficient mob teams, with increased business value output for years now. Well its only for IT you might think and now plan to move on.. But Ill say it is not only for IT, but my thoughts on that is in the end.

But first lets understand the basics of Mob-programming.

Index:

• What is Mob-programming
• Why should you be interested in mob-programming?
• How do we do mob-programming in TUINordic
• What might also be needed or ease to get the full benefits.
• Is this only for IT and developers? I would say NO.!

The background - What is Mob-programming?

Mob programming simply explained is 3+ team-members (2 is a pair, 3 becomes a mob) sitting and working with one problem, at the same time in front of one screen, on the same device. With one team-member typing the code ("Driving") and the rest of the team is steering the problem-solving ("Navigating") by constantly discussing, thinking, reviewing whats happening and describing how to proceed to solve the problem. The Navigators do most of the talking while the Drive does the typing of the "coding".

The team-members also rotate the role of the "Driver" based on an agreed time interval. So the current "Driver" then becomes a "Navigator" and one of the "Navigators" goes into the role of "Driver". Everyone still engaged in the same task/problem.

So simply explained you have 3+ people doing one persons job.

And now you might also be a bit sceptical when it comes to the "cost efficiency" of having multiple people working on something one person could do. How can this be more efficient or better for the company you might think? And trust me i started out just with the same thoughts. After working a long time as a project manager, and management consultant, my logic stated it would be more costly. But it turned out I was wrong.

Why should you be interested in mob-programming?

Well to start with my experience is that;

1. Its was more cost efficient

Yes you read it right. =) Looking at the short term productivity of just output it is more "productive" to having the entire team working solo on separate tasks. BUT when I started to look strategically at the longterm benefits (3-6+ months) I noticed that Efficiency was dramatically increasing, and so was quality. I started to see that the all the combined benefits of the "mob programming way of working" was actually greater than the cost of 3 people doing the "one person job".

2. I got increased quality and solutions that was much easier to maintain and extend long term.

To get a high quality and maintainable solutions/services that are build so they can easily be extended or adapted to change, take some more time in the beginning but over time the benefits becomes more visible. Mob-programming gives you 6 pairs of eyes on the code at all time, so you get realtime code-review all the time, so potential issues get identified and assessed instantly and not when someone is review the solution in a later stage of the process. You also constantly utilise the combined expertise of the entire team on every problem all the time, resulting in an as good as it can get solution based on the combined knowledge of the team you have.

3. Less overhead and process time was needed and more time got spent on delivering business value.

• As mentioned above all time spent on Code reviews was gone, and problems found where addressed instantly meaning you never went down the wrong path before it was caught by a reviewer.
• And since the team focus on the same tasks all discussions are in the context of everyones interest and became more relevant and constructive than when the team worked on separate things.
• Since everyone was involved in all the work, everyone knows almost everything. Since everyone knows the big picture each individual can address every change with knowledge about the “entire landscape/services/code bases", this create the prerequisites for everyone to solve the problem in the best possible way. It also removes loads of discussions over time where the "expert team member" have to explain to the others about the things/services he/she knows most of.
• Time to start change someone’s else’s code is minimised cause everything is "everyones code" so startup time to attack the next problem/business demand became minimal. Everyone know how it all work together and all parts of the system/services.
• No handovers or explanations to the rest of the team is needed on whats happened so almost all internal handover was also gone with the wind. It happened during the collaborative work. Also Internal sync discussions became much less needed, cause everyone is working on the same thing or/and in the same context so almost all discussions drive "everyone forward" not just one individual and the task that person was working on.
• Less focus switch. This is an interesting thing since when i talk to developers usually the focus switch is the thing most people bring up as one of the key disruptors of efficiency. Focus switch is when you are "in the zone" and someone interrupt you and you have to completely switch focus and then back to where you where (you probably know the fealing since its not only happens for developers). Often resulting in loss of minutes of quarters before you are back on track with where you where in your thoughts and up to "speed again". With mob-programming working on one task discussing the same problem generate much less focus switch.
• Onboard new team-members became so much easier and much more appreciated by the new members. Basically they join the mob day one and becomes productive (really productive) within days or weeks rather than the traditional months. Also they get full time coaching since they are actively involved in everything that happens and can get instant answers to their questions or thoughts.
• No unique member dependency. Traditionally there is always key people in team that know certain parts of the system/organisation or service. And my experience is that they also do most of the work within their area of expertise, since that the easiest most efficient option for them and the team. With "everyone knowing most of everything" that knowledge dependancy on unique individuals are gone. There is of course always key people that have huge impact if they leave, but the knowledge risk in them leaving is at least mitigated.
• No handovers for new features or changes needed to support 24/7 support. This depend on your delivery process but for us at #TUINordic where we us the principle "you build it you own it". The same team that code also have 24/7 support on their services and business capabilities. So if everyone work on different things handovers are needed since there is one member on call "off hour" and that member need to know the changes that are in Production. With mob everyone knows everything even in detail so no handovers...

4. Better output quality

With 4+ eyes on the code, the brain from 2+ individuals and constant dialog, the solutions becomes much more stable and reliable.

• I have seen a decrease in defects and especially critical defects on almost all teams starting to do Mob.
• But also that the resolution time to fix issues decreased, since everyone knows the big picture and most of the details. And this is an important factor cause if we can reduce the business impact by identify Root-cause faster and deliver resolutions faster business impacts is much less affected.

If everyone is armed with as much knowledge as possible the team can attack issues regardless who is on call or working when "the shit hit the fan, in the middle of the night on a peak sales Sunday".

5. Faster route to a good solution

This is something I talk about and belive in but don′t have any real data to back it up with.

I know that for us in #TuiNordic the-overall solutions that comes out is better when developed in collaboration (Mob) than when its was previously done by just one person or multiple people working in silos.

But my (and the Product Owners) feeling is also that the time to reach to a good solution is now faster, both when looking at "longer time platform level" but also on the maybe 20% (just made a number up here) of all changes/demands that actually where/is really hard problems to solve. In the easy cases everyone know how a "good enough" answer looks like, but in the more challenging cases i belive a mob can reach a result on 3 hard problems faster that 3 individuals solving the same 3 issues by them self. However as stated in the beginning i have no data to back this up, but it is my general feeling (shared by many of the teams).

6. Constantly being forced to discuss and move forward

Having to put words to your thoughts in a group generate constructive dialogs that evaluate options, challenge "proposed solutions" and comes to result faster.

• But it also prevent people to stay "of track" or get stuck a problem too long, someone in the team will drive the dialog/solution forward. And this is also a key benefit teams constantly put light on,

-"... we almost never get stuck, there is almost always constant flow forward".

• While sitting alone it′s easy to get stuck too long on a problem before asking for help. This hardly never happens any more inn a mob.

7. Higher engagement and less stress

All of the mob teams I have had the privilege of working with say they feel mob-programming really created;

• Less personal stress, better team culture, comfort with tasks and responsibility. 

-"Its not all up to me, I know that if I get sick or getting t stuck someone else can and will just continue."

Building things together create a sense of shared proudness and responsibility where its always our code, our failure or success. Often generating "tighter teams". But most importantly i belive it have higher chances to create Psychological-safety and engaged teams.

• Higher skill-boast and wider skillsets in the teams is also a benefit that both company and team-member benefits from. Every member is usually stronger in a field or tech. By working together the team team lift the skill-level of everyone.

Now its been more than five years

Time gos fast when you are having fun and its now been more than 5y since i first encountered Mob-programming when i joined #TUINordics back in 2015 and at that time two of the Nordic web teams had already been doing Mob in over one year. However in the beginning I sceptically looked at it more as a "team playground" way of working. But starting to work closely with the teams my view started to change and now 5y later Im a big promoter and most of my teams (6 teams) run in mobs or partly in mobs. But they are not all working exactly the same and i belive every team should find their own flavour, There is no "one way fits all". Also i personally believe Mob is not the optimal way to attack all problems. More about that below.

(Im sorry i did not find any better images from our "mob-corners". Maybe after Covid-19 when Im back in office ill update the article =)

How do we do mob-programming in TUI Nordic

Below I will list some of my view on what is important, its not the view of Tui Nordic and all the Mob teams there.

Every team should find their own flavour

This I personally think is SUPER important. Just like with any "Agile way of working" its a framework and not a ruleset. Each team should test and learn what work the best for them.

• Before you start there are some material things that i belive help mobs be productive, like the use of a big screen. Since there is multiple people on one task and all need to se the code as well a big screen or projector is key. What is best you might ask Projector or screen? Unfortunately the view differs among the teams. Projectors can use laser pointers that some teams love to use to fast point at things while discussing. Screens tend to be less light sensitive, etc. etc.
• Some teams like multiple keyboards or mouses, so the other "Navigators" also quickly can explain something in code even though they are not actively "Driving".
• A common Mob Computer makes life so much easy. If you don′t have a common team computer you have the problem that every personal computer differs a bit in settings and personal flavours. Having a common computer makes it faster to align on "common team settings". Also most day someone arrives first and that person often leaves first, and if using a personal computer that will interrupt the flow. Also personal computers have personal logins etc. etc.
• A common Team AD account also makes things more easy, security departments usually hate this but there is other ways to trace who used the computer when. Also sharing a personal computer is way more wrong. One team one accountability and trust from management might be needed in the start.
• A common team mailbox and chat account, enable all in the team to see what has been said and communicated. The team has one voice towards the world both in and out. However an important thing i learned is to still be personal in the communication the receiver of the message still want to know who he/she talked to and it also helps if another team-member pick up a topic. So always have the team use their personal name as part of the reply. E.g. ".. Here is the update you wanted //Lukas, Team.xxxx". The rest of the world will appreciate it.
• Another area/table within the "mob area" where part of the team can work if they need to split up in a pair doing a test and then jump back in the mob. This goes against some "teams principles" but in nordics most Mob-teams want that extra table with a big monitor where you can just drop out and fix something and then get back in the mob. It has to be super easy to access and then to get back in the mob.
• Monitoring screens - Having that real time view and traffic lights on how the teams services preforms is so important. Allowing the teams to have a set of screens for dashboard metrics is so worth the investment. Each team in nordic has a set of monitoring screens where they can put up dashboards with the metrics that are important for them to do their work efficient. And to be able to react quickly if there is problems..
• Whiteboards - Dont underestimate the power of visualisation. Make sure the teams have whiteboards within their area.
• Try out a good tool for remote programming - Maybe if someone works from home they will not join the mob that day but in Nordics there are some teams with members that work from home 1 day a week that do remote mob frequently. When Covid-19 hit us now that means they where already setup for full remote collaboration in mob. Its has additional challenges, like lack of good whiteboard tools etc. But works surprisingly well.

Key is to be active at all time in the Mob and not "zoom out"

Key is to be active in the present and solving the problem at hand, thats why the rotation is so important. My personal reflection is that the Driver (the one typing) is less frequently zoom out (need to type so cant leave the discussions =) but the Navigators might. Thats when rotation comes into play to keep everyone active and focused and having someone more focused on typing and the rest to drive the dialog. But going back to "the team flavour" there is really no right or wrong way to do it if it works well for the team. "Woody Zuill" (the founder of Mob Programming) principle is that;

-"a thought need to go trough someone else hands to transform into code" -Woody Zuill

Forcing the Navigators to talk and put words on their thoughts and discuss for someone to then type this into code. Some teams like this rigid so the Driver hardly talk just type, while some teams have everyone talk. The important thing is to make sure the Driver dont drive without the Navigators being active and part of whats happening. The goal is to have constant dialog and discussion within the team and also generate code and a solution.

Keep focus with the right time interval for the "rotation"

This is up to the teams and many teams "adapt the interval" based on team mode and complexity of the problem. It also depend on the number of team members in the team. many team members usually require shorter time. Laborate and find what works well, and in the beginning dont have to long intervals. In Nordics the mob teams usually run 8-15 min, and the teams are 3-4 developers.

One task at the time

Make sure you dont have to much of a split focus by trying to keeping to one task at the time and do your best to finish that before picking up a new one. This is not something that is unique for Mob its a general principle i promote but its more important since a disturbance in a Mob affect the "entire team" and not just one individual.

Many team try mitigate disturbances by having a dedicated "reception/butler" (like the one just been Driving) to "protecting the team" from all incoming questions or people approaching and thereby protecting the team from losing focus.

Another thing many teams does is to "schedule time" when the team daily go trough the mail box, Chat channels etc to be able to keep focus when programming. Or some also put that on the person that just went of the Driver seat.

Not all task are optimal for Mob Programming (my personal view)

Here i might go against the principle of some Mob teams, so Im emphasising that this is my view and it might not be the right one. =)

In my view one of the key benefits of Mob is the Focus on solving the problem together. But but when there really is no "problem" to solve just a simple task to execute on (what some of my teams usually call "bread and butter programming" or "code monkey job") that simple small changes everyone know how to do/solve, there is no need for the entire team. Someone can just bounce out of the mob and do it (E.g. small layout change or simple extension in an already existing service/api).

However its important that the majority of the work is done in collaboration to not loose the benefit of everyone knowing what happens and changes. If the team split up to-much, more handover and knowledge share is needed and the risk for member dependencies increases.

If the team is a team that like to not mob all the time my recommendation is that the team still work on the same story or business demand whenever possible. If its simple things its probably more efficient to decide how to solve the problem together (the big picture in mob). Then divide tasks but make sure the focus of the goal is the same. Half team might to the new UI the other the apis, they do it in parallel so the context is still the same and discussions still happens. Also trying to work in pair is preferable and maybe even rotate the pairs over time,

The majority of the teams I have worked with are teams of 3, where it becomes a pair and a solo and then the pair might change with solo member into a "rotation". Many small changes or fixes then gets decided on high level by the "mob" and then someone just leave the mob and fix it and then jump back in.

Take brakes, especially in the beginning

Being fully focused full time is exhausting, and most teams that start mob (pr join a mob for the first time) describes it as exhausting. Just coming home from work and falling into bed sleeping. And its is more active since the focus is on so much more of the time than working alone. Due to this its important to take brakes!

How teams do this is amazingly different;

• Some love to schedule this "pip" and the entire team takes a coffee, a walk or just a brake.
• Some just bounce-of the mob when they personally feel they need the brake and just join in the rotation when they are back.

So try what works best as long as you take brakes, and slo if you try mob do it for at-least 4-6weeks before you decide if this was really your thing. =)

We also had this in place to get the full benefits.

Above is my experience of Mob programming but the benefits is also based on some other factors that do play in as important.

• Autonomous teams - For teams to be able to set their own process and freedom in ways of working has helped us overall to generate the prerequisites to work efficiently and focused with Mob. Being able to deploy at any time, all teams having their own services and codebases (no cross team alignment needed for most changes) so being in full control of their ability to move forward has been key.
• Automation on releasing - Having the automation and infrastructure in place to allow teams to release without time consumption, pain and high risk really will boost the benefits of Mob. Keeping focus on delivering actual value. Having a team create a release package manually is wasted time, just having one person doit is also quite fast waste of time if its not automated..
• Decoupled architecture - Multiple teams doing Mob-Programming on the same monolithically code bases will not have the same benefits. Quality benefits are still there and it might be a really good way to mitigate risk and minimise impact from defects. But the risk is you are stuck with to-much coordination, process time and merge work wich is not optimal as group/mob work. Resulting in waste.
• Releasing on story or function level (deploy daily) - Focus on one thing and then be done with it has for us ben important so delivering small all the way to production and then being able to let it go and start with the next thing has been important. If its "done" but need a release in a week focus will have t be switched back at a later stage again.
• Highly engaged Product Owners [PO] and UX designer - The teams PO′s sits with the teams and each team have a dedicated UX designers. This has for us been a very successful since the team can get answers directly and get input from their PO′s in discussions without having to wait. Having dedicated UX designers (some UX designers had more than one team) increase the turnaround time on changes and also get the experience from Devs, PO′s and UX designers into the work.

Is this only for IT? Or is this simply a way to collaborate solving problems/challenges?

Why Mob Programming has been a successful concept, I belive is based on the fact that you reach better result collaborating, having instant feedback loops and applying more knowledge on the problems. And that has nothing to do with IT.

I do "Mob budgeting" with some of my colleagues, I also do "mob team and people evaluations/reviews". I still need to sync much of my budgeting review work, so by actually doing a majority together from the start we get aligned instantly and even if we might not always save time its not more time needed.

But if not IT what then?

Well for me there must be a majority of TASKS that is better to do in Mobs, maybe not all roles and principles are perfect for a full time mob but I have a few examples where the majority of the work in my view is greatly suited;

• Analytics, trading and other "data related" roles is examples of areas well suited for Pair or mob. Having constant dialog on why a trend looks like it does or why customer patterns have changed is great examples where collaboration, other views and instant feedback is beneficial. So is trading.

Mob is probably more common in IT since it originally evolved with developers and then moved to Infraenginers/devops, Data machine-learning etc.

But for me and TUI Nordic the conclusion has been that solving problems together in dialog give better results, especially over time, than what single individuals would achieve.

A special thanks to all the members in the web-teams (over the years) in TUI in the Nordics, for proving my initial thoughts wrong. And just being amazingly great at what you do, always with curiosity and a smile.

And to Charlotte, Mats Pahlberg and the TUI Sthlm office team, that transformed Web IT mob-programming to so much more by pushing and promoting this as a success story within "ways of working" in TUI in the Nordics. And making it a concept in our office.

And Woody Zuill (the mob programming founder) for the great meetings and discussions we have had and for sharing his experiences.

Stay well

//Lukas