Devops for Growth

L'intervention de Llewellyn Falco, intitulée "Understanding the Science of Mobbing", part du principe que le Mob Programming n'est pas une science - tout comme l'informatique (computer sciences en anglais, NdR). Il y a pourtant des pratiques partagées sur la manière de développer des logiciels :

• Le Solo programming est sans doute la pratique la plus admise aujourd'hui, qui implique que tout ce qui est produit entre dans le code, le bon comme le mauvais.
• Le Pair programming est la seconde manière la plus connue de développer et les meilleures idées de chacun entrent dans le code.
• Le Mob Programming est enfin la dernière pratique, et sans doute la moins connue, et comme l'explique Llewellyn : ce n'est pas obtenir le plus possible des gens mais le meilleur.

Où est donc la science ? Llewellyn fait un parallèle avec la théorie des systèmes : une équipe forme un système. Et c'est un système complexe. Il est difficile d'en isoler une partie, ou pour paraphraser Dan North : "Quel est le son de l'applaudissement d'une main ?".

Démarrer quelque chose dans un système est comme allumer un feu de camp. Dans une équipe de développeurs autonomes, même les très bonnes, lorsque quelqu'un est bloqué, il reste coincé seul. Pour qu'une idée grandisse, comme pour le feu, il faut des brindilles, et en quantité. C'est le principe du Mob : disposer d'un ensemble de personnes pour nourrir une étincelle.

Pour utiliser une image différente (qui ne vient pas de Llewellyn), c'est l'exact opposé d'un épisode de Docteur House (ou le dernier épisode de la saison 1 de Silicon Valley) : quelqu'un a une illumination, ou lance une idée, et le reste de l'équipe contribue pour la rendre meilleure.

Cet impact est similaire avec la mémoire et la mémoire de groupe. Cette dernière est plus robuste que celle d'un seul esprit, et une bande peut déclencher des mémoires multiples. Il en va de même avec la résolution de problème : l'état de votre système favorise ce que Takeuchi et Nonaka appellent la "diversité". Et c'est un état nécessaire quand les choses tournent mal.

The team currently uses Zoom to host the remote mobbing sessions. The driver shares their screen. A Slack channel is also used as a back-channel for sharing information, code, links, etc.

The ten-minute timer not only ensures everyone takes a turn driving, and stops that session of driving from being too daunting, it also keeps us honest about baby steps. The need to commit and push code at the end of ten-minutes so that the next driver can pull it down to work on forces us to work in small, bite-sized chunks in a very disciplined way. Of course, sometimes we cheat (if we are just about to finish off something when the timer goes and need a few more minutes to get it into a committable state), but mostly we do not.

One fabulous side-effect of mobbing is the fact that a team member can completely tailor their own physical environment and even change it around depending on their needs that day: the ability to sit in one’s favourite chair, have just the right level of lighting, turn the volume up and down, have fiddle toys or calming activities to hand, have access to favourite and suitable food and drinks.

Here’s Sal’s perspective on this:

“The possibility to create a sensory environment uniquely tailored to my needs that day is a wonderful luxury I have never been afforded in an office. The accompanying feeling of safety helps to compensate on the days I am feeling nervous about joining the mob or struggling to focus.

“In addition, it is supportive of a level of social interaction that feels more manageable – it is completely acceptable to turn off or hide people’s faces, although in practice I rarely do. I find the option comforting, and it is fine to leave the mob if the interaction feels too intense or prolonged. Of course, there is no pressure to be social during breaks either – I can just turn off the screen and have silent, alone time”.

Timings have flex, whilst the mob is “alive” from around 8.30 until maybe 5pm, the participants join and leave as and when they need or desire to do so. Not only does this help with social exhaustion, it creates an environment where it is OK to hop on the mob a little later so you can drop the kids at school or leave early for a meeting. Sal often goes for a run in the morning which she finds calming and helps her to focus for the day.

We believe there is a hidden benefit in this too, as each time someone joins, the mob is forced to depart from the detailed world of writing code in order to explain what they are trying to achieve from a more strategic product development perspective.

Swarming provides for collective intelligence and problem solving, real-time collaboration, fluid leadership with no explicitly defined roles. Because of this, swarming proved to be an excellent organizational pattern for resolving complex problems in a complex and tense environment where positive results had to be demonstrated almost immediately.

So what exactly is mob programming? Put simply: 3 (or more) developers, one keyboard. No, that’s not something weird that you’ve seen on the internet. It’s about working collaboratively towards delivering high quality software.

Given that most programmers get in hot sweats just thinking about the idea of working with other people, I’ll delve into more detail as to what that looks like. Imagine we have a developer, Steve. Steve works on an app where users can view recipes. One day Steve is tasked with adding a ‘favourite’ feature to the app. With this feature users are able to save recipes to a a private list called ‘my favorites’. If they want to view a saved recipe again, they can simply open the favorite list and select the recipe.

Steve wants to use mob programming to implement his feature, so he books a meeting room and asks his colleagues John and Sarah to join him in a mob. John and Sarah show up to the meeting laptops in hand, ready to take on the challenge of the favorites feature.

So at this point, Steve needs to lay down some rules (yes mobs have rules). The rules might be something like this:

1. At any given time one person is the ‘Driver’. The driver is the person with the keyboard and mouse, the driver is the only person allowed to modify the code.
2. Everyone else takes the role of the ‘Navigator’. Whilst the driver spends a lot of their time occupied with the physical task of typing, the Navigator has all the time they need to think, review, discuss, describe. And that’s exactly what the navigator should do.
3. Everybody swaps roles — often. No, this isn’t some ‘everybody gets to play’ stuff you heard in primary school. If people stay in one role for too long they can become fatigued. if they have a favourite role then when they’re not in it they can become bored.

And that’s it — you now know about mob programming. Add it to your CV.