Mob Programming

What is Mob Programming?

Mob Programming (MP) is a Group product ideation and coding technique that is all about leveraging distributed knowledge when programming and solving a problem with a single computer [Pearl 2018]. This is also known as a software development approach where all the brilliant minds work on the same thing, at the same time, in the same space, and on the same computer [Zuill 2018]. MP is a way to build a task force around a User Story (US).

Mob Programming started with Pair Programming back in 2000, coined in 2002 [Marchesi 2002] and mainly developed by Woody Zuill who experienced the technique by Hunter Industries which is by now their default way of work.

Mob programming provides maximal feedback and communication [Marchesi 2002] which is perfectly inline with the agile value “Individuals and interactions over processes and tools” [Beck 2001]. 

From its first version described by Marchesi, MP starts with a code design meeting which deals with any aspect of the code [Marchesi 2002] 

• mob code review: some random piece of code is reviewed to get some feedback on coding and design decision done in the past and refactoring decisions are made in group
• mob architecture: could be efficiently done in “Model Storming” mode [Galiber 2019]. This meeting is suggested to be done in two groups that will confront their ideas and views with everyone else in the team. It is important to avoid groups with many people to let everyone have a chance to be involved, which is perfect for a scrum team.

During this meeting, code may be changed on the fly and discussions may carry on outside of this meeting. Everyone’s participation is encouraged to avoid “passive spectatorship” or silent Kibitzers (this phenomenon is named “groupthink”) because open comments are most expected here! Participatory listening is most recommended because it helps spectators get involved and sustains their attention [Zenger 2016].

The narrator/driver role should change during the meeting to develop courage and participation. However, it appears that some preparation of the meeting is a good practice to ease discussions and let everyone participate. Moreover, it also appears that a single coach at this meeting is not a good idea because people tend to assimilate the coach with a “MP is his baby” mindset and reduce participation [Marchesi 2002].

While coding, just like in PP, the Typist should be supported by the rest of the team and just like with Ping-Pong Programming in TDD [Hoover 2005], once the Unit Tests are Green and refactored, the Typist writes a new Unit Test and hands the keyboard to someone else, the new Typist. This helps to keep people aware of what’s going on and provides some release for Typists and the code. 

An alternative to Ping-Pong-passing the keyboard to another Dev is using a timebox (5 to 15 minutes - short sessions should be privileged at start [Zuill 2018][Pearl 2018]) with the countdown clearly visible by all participants. Forcing timeboxing will help the rest of the mob to stay aware of what's going on. To limit fatigue and enable productivity, the “Pomodoro technique” may also be used [Cirillo 2017]. Avoiding keyboard preemption will also help the mob to improve their communication skills which is crucial here [Pearl 2018].

Whatever your Mob Programming configuration, to help non-Typists, line numbers should be displayed so that people may tell which specific line is involved. Since the whole team will share a keyboard and IDE, you should make sure it fits most of the Team, not to say everyone. You may watch a timelapse from Mark Pearl to see some configuration details (multiple keyboard, white board, etc.) and some other recommendations to be shared for a good start. It is also recommended to make some intermediate 20’ retrospective after a couple of sessions to improve MP and let people release. The correct mindset regarding MP is the collaborative Kaizen way: continuous improvement in a blameless attitude [Zuill 2018]. People must be critical of the code, not the people. Introvert people should also be questioned first to state their opinion and open critical thinking should be promoted [Pearl 2018]. There are several recommendations linked to PP and MP as well [Llewellyn 2014] [Pearl 2018], but the most important one is strong egos with a “my way or no way” mindset that should be avoided [Williams 2000].

It is suggested to start Mob Programming from a couple of hours per week or one hour per day to let people get familiar with mobbing, but when MP becomes the norm, it appears that the Daily Scrum Meeting to review the Sprint objectives is useless because everyone knows about the Sprint standpoint. This meeting is replaced by a quick daily retrospective for continuous improvement [Zuill 2018]. Alerts on the objectives are raised and Andon is taken into account immediately by the whole Team.

Here are some of the benefits to let people work in Mob Programming:

• Regarding interactions, it appears that working in a 3-5 people team is much more efficient in solving complex problems than with pairs and of course, solo [Laughlin 2006].
• Mobs are less subject to interruption. One or two people may be missing due to phone calls or whatever but not the whole team. This leads to a greater continuity [Pearl 2018].
• The project depends less on key-persons because MP introduces skill redundancy and enables T-Shape people [Pearl 2018]
• Decision making is more robust [Mukherjee 2016]
• Much less merge conflicts are raised since the whole team works altogether [Pearl 2018]
• Higher First Pass Yield due to higher quality standards leveraged by the many eyes  [Pearl 2018]

Moreover, there are advantages to work in MP can be found from PP [Williams 2000] [Vanhanen 2007]:

• it reduces the probability to produce bad design [Flor  1991]
• it removes flaws on the fly as proposed in the Kaizen approach [Pearl 2018]
• it is also good for knowledge sharing and training, in hands on mode for the Typist [Pearl 2018]
• it helps people to face challenging tasks 
• it improves job satisfaction and overall confidence in their work
• there is no longer delays in waiting for answers [Zuill 2018]

When it comes to productivity, it seems obvious that MP is more costly than PP or even Solo Programming (SP). PP is proven to be more profitable and faster than SP [Nosek 1998][Shull 2002]. When it comes to Mob Programming, it’s mainly about making a choice between “flow” (see WIP) and  “resource” efficiency [Pearl 2018]. Traditionally, management aims towards 100% resource utilization which is a trap and an economic disaster [Kniberg 2014][SAFe 2021-37][Reinertsen 2009] that makes MP a cost-effective solution [Pearl 2018][Zuill 2018].

However, introducing Mob Programming is not that easy because it involves management, resources and human factors. Moreover, there are some situations under which, short term profitability and a “good enough” result is the selected option regarding decision making [Kerr 2004] and resource efficiency (e.g. fixed price projects). Indeed, the balance is as hard to reach as good quality because you need to tame quality matters beforehand to set the cursor; so, as a rule of thumb, MP is usually introduced when it comes to critical parts. MP should be experienced first, notably in a dojo, a deliberate practice done in a group around an issue, combined with a TDD approach on a kata, a specific issue taken as an exercise [Bache 2010].

Impact of Mob Programming on the testing maturity

MP drastically improves the quality standard of the product thanks to the many eyes that collaborate to chase issues here and there. But good code quality requires refactoring. This infers good test coverage is necessary [Marchesi 2002], notably thanks to unit tests and test harnesses to avoid regressions while refactoring. Naturally, if coding is done in TDD mode, refactoring in MP sessions is much easier. However, to ease refactoring, producing too many test cases will slow down. Just like the production code, tests must be refactored and cleaned [Zuill 2018] and a 5S on tests on a regular basis is as necessary as on the production code and documentation; otherwise, it may ruin the delivery flow. Involving the whole Team in such an approach would enable T-Shape people, share the knowledge on the project assets. Applying MP to this activity should reinforce both courage and the need to do it continuously to avoid some technical debt on assets outside the code and eventually getting rid of what is deprecated or useless.

Coding is not the only part covered by MP; actually, group ideation starts from the US. The “3 Amigos” or “Example mapping” workshops done in Sprint Refinement provides a good start where 3 people work together against a US. Nonetheless, the Tester and the Dev may not have enough knowledge and experience on production matters because of their own culture. Therefore, it may be relevant to involve some Ops-oriented guy in the 3 Amigos which makes 4 friends. By extension, inviting different kinds of profiles is something that should eventually happen to figure out the many pitfalls a given US would infer.

Another opportunity in maturity testing is the introduction of ATDD during an MP session. Hence, from a given US

• the Acceptance Criteria (AC) will be coded first with scripts that check the AC
• the Team will focus on coding the script that automates the check
• Then the Team will start designing production code in TDD mode as described earlier.

From what was understood in terms of testing, Double Loop Learnings [Argyris 1977] take place and lead the Team toward a good product instead of a product that would be compliant with provided requirements.

‍

‍

To let pure Testers participate even more to MP, Exploratory testing may be done as soon as all AC of a US are obeyed. The Testers may also use a mind mapping tool to take some notes while pure Developers generate the product. Those notes can be generated from questions asked and partially solved during MP sessions and spot risks to test from other Mobbers’ comments. These partial responses can be suspected from other Mobbers attitudes which participate in a continuous search for transparency. Those notes will help this non-technical profile keep the attention up and ask for some complementary work that would harden the product. These notes would then lead to what James Bach names “Thread-Based Test Management” [Bach 2010][Gatien 2012].

To help other members stay aware of what's going on, someone in the mob may take some note on architecture decisions. This is named “Architecture Decision Records” (ADR) [De Simone 2020]. Those ADR facilitates notably

• onboarding new Developers
• challenging existing design‍
• assuming variability and preserving options [SAFe 2021-03]
• defining the architectural runway [SAFe 2021-38] 

Notes for TBTM or ADR matters are a way to practice participatory listening and contribute to building the product even when you are not the so-called Typist. This makes the joint effort a US Task Force which manages to do everything at the same time.

At testing time, there is yet another group product ideation technique named crowdtesting. It consists of involving a mob of users on a platform and letting them find bugs from their context [Leicht 2017]. For instance, you may invite a bunch of Testers to assess the product just as Beta Testers on mobile testing in order to check the application portability under several mobile configurations [Naith 2018]. Crowtesting could be implemented thanks to Canary Releases when SaaS products are involved and supported by tools such as https://testeum.com/ or simply with discussion forums.

Agilitest’s standpoint on Mob Programming

Agilitest can be a very good candidate for ATDD in MP. Mobbers will then update progressively the test scripts as the product interface gets more ready.

Thank to a very simple setting up of the tool and #nocode approach [Forsyth 2021], Mobbers don’t spend much time creating the MP environment and coding the test scripts. They just focus on adding new features on the product. Moreover, since Agilitest does not require strong technical skills, non programmers may join the MP effort that enables business-oriented people to take part in the MP workshop.

‍

To discover the whole set of practices, click here.

‍