Comment nous avons essayé le mobbing

Si vous essayez de trouver du mobbing ou du Mobbing dans un moteur de recherche, alors une partie importante des résultats portera sur les «abus psychologiques des personnes». Par conséquent, il est préférable de rechercher immédiatement la "programmation mob". Dans le top 10 des résultats de Yandex pour le moment (27/02/2019), il n'y a qu'un seul article en russe (et celui-ci est une traduction), mais il y a beaucoup d'articles en anglais. Si vous les regardez couramment, la plupart d'entre eux sont une théorie, pas une analyse d'un cas pratique. Tout le monde dit que cela aidera l'équipe à devenir plus efficace, à distribuer localement l'expertise du projet et à développer des compétences générales chez les personnes. J'ai moi-même testé le mobbing lors d'un entraînement de mêlée et, franchement, j'étais ravi! Après avoir consulté l'équipe, nous avons décidé de mener notre session de mobbing de test.

Parmi les avantages de cette approche du travail, nous avons identifié pour nous-mêmes des valeurs telles que la diffusion de l'expertise au sein de l'équipe et le développement de compétences supplémentaires pour chaque participant. Après avoir organisé une réunion consacrée au mobbing, nous nous sommes fixés trois objectifs: d'abord, essayer le mobbing en pratique. Deuxièmement, pour comprendre quels sont les inconvénients et les facteurs négatifs dans notre cas. Troisièmement, déterminez si cela apportera les valeurs ci-dessus à notre équipe.

Qu'est-ce que le mobbing

Le fondateur du mobbing comme style de travail de Woody Zuill le décrit comme suit:

des gens formidables qui travaillent ensemble sur une tâche à la fois en un seul endroit sur un ordinateur.

Autrement dit, le Mobbing est un style de travail lorsqu'une équipe travaille constamment ensemble et ensemble «bondit» sur toutes les tâches. Dans le même temps, la tâche passe par toutes les étapes nécessaires de son cycle de vie, et chaque membre de l'équipe y travaille simultanément avec tout le monde. Ainsi, l'immersion et la compréhension de la tâche par l'ensemble de l'équipe sont réalisées.

Il y a plusieurs rôles dans le mobbing:

• Conducteur: assis dans un lieu de travail commun, fait exactement ce que le navigateur lui dit.
• Navigateur: donne des instructions au conducteur. S'il ne sait pas quoi faire, il consulte la foule (le reste de l'équipe), diffuse les actions nécessaires au conducteur.
• Mob: participe au développement, indique au navigateur ce que le conducteur doit faire.
• PO (Product Owner): sait exactement ce qui doit arriver. Définit la direction souhaitée pour le mouvement de l'équipe. Il peut s'agir d'un conducteur et d'un navigateur.
• Facilitateur: surveille le respect des règles, annonce les changements, parcage les idées. Il est souhaitable qu'il y ait une personne dans ce rôle.

Mobbing se compose d'une session, qui se compose de cycles, dont chacun se compose de changements.
Session - une période de temps pendant laquelle une équipe travaille sur une tâche. Avant la session, la tâche est sélectionnée et divisée en étapes, et son objectif est déterminé - ce qui doit être obtenu en conséquence, par exemple, l'incrémentation de la fonction.

Changer - l'intervalle de temps entre changer les rôles du conducteur et du navigateur. Le changement dure, en règle générale, 15-20 minutes. Des équipes plus courtes contribuent à une vitesse plus élevée et à un plus grand engagement de l'équipe.

Règles du jeu

Pendant le quart de travail, le conducteur est assis devant l'ordinateur partagé et fait exactement ce que le navigateur lui dit. L'équipe observe et, si nécessaire, discute de ce qui doit être fait. Le navigateur structure cette discussion et diffuse au conducteur ce qu'il doit faire exactement maintenant. Le conducteur écoute uniquement les instructions du navigateur et peut lui poser des questions. Le navigateur peut diffuser la question à l'équipe. L'animateur «parcourt» les idées exprimées mais non utilisées pour une raison ou une autre.

À la fin du changement de rôle, les rôles de conducteur et de navigateur sont transférés à d'autres personnes dans un ordre prédéterminé: le navigateur actuel va à la foule, le conducteur devient le navigateur et la personne suivante devient à son tour le conducteur de la foule. Lorsque chaque membre de l'équipe a visité chacun des rôles, le «cercle se ferme», c'est-à-dire que le cycle se termine.



Après la séance de mobbing, chacun de nous a partagé ses impressions, sur la base desquelles certaines conclusions ont été tirées. En conséquence, nous avons obtenu un résultat qui a permis de comprendre comment et quand il est préférable d'utiliser le mobbing, et si cela convient à notre équipe. Je vais commencer par des impressions négatives.

Négatif

Parfois, le rôle du navigateur n'est pas entièrement clair. À un moment donné, par exemple, l'analyste pourrait jouer ce rôle et le développeur pourrait être le conducteur. Le navigateur a raconté ce que l'équipe lui disait, ne comprenant pas complètement «ce que tout cela signifie», en raison d'un manque d'expérience en développement. En conséquence, des situations se sont produites où le navigateur n'avait tout simplement pas de sens pour transmettre les instructions de la commande, car, tout d'abord, le développeur entend la commande, alors pourquoi a-t-il besoin d'un intermédiaire? Deuxièmement, le conducteur comprend comment agir dans cette situation, mais selon les règles du rôle, ses mains sont liées.

Nous avons également noté que si le navigateur doit regarder l'onglet suivant dans l'environnement de développement pour déterminer la prochaine étape, il doit alors exprimer cette idée et attendre que le pilote change d'onglet. Il l'aurait lui-même fait en exprimant la demande au chauffeur, avec tout le monde «soyez si gentil» et «merci-merci».

La difficulté était que nous avons deux développeurs travaillant à distance. Tout d'abord, cela a ajouté du temps à une opération telle que la «commutation des droits sur le curseur»: pour que l'administrateur distant puisse afficher quelque chose à l'écran, mais en même temps ne pas prendre le contrôle de la souris. Pour ce faire, il était nécessaire d'agrandir la fenêtre de contrôle de conférence, de permettre à la bonne personne de contrôler le curseur et de minimiser la fenêtre. Cela ne prend pas si longtemps, mais il distrait beaucoup, le fait sortir d'une tâche (dans laquelle il vient de commencer à plonger) et interfère généralement. Par conséquent, après chaque quart de travail, le nouveau navigateur devait demander au précédent ce qu'il voulait faire maintenant, tous les deux devaient se souvenir de cela, «synchroniser», et ensuite seulement continuer.

Une autre difficulté due à «l'éloignement» de certains employés est leur voisin. À un moment donné, un voisin du navigateur distant a décidé de percer des trous dans toute la maison, nous avons donc entendu une gamme complète de sons d'accompagnement avec amplification. Comme vous le savez, cela ne nous a pas du tout aidés.

Comme nous étions très limités dans le temps (une heure par session de mobbing), nos quarts de travail étaient très courts - 5 minutes chacun (afin que chaque participant ait le temps de visiter tel ou tel rôle au moins une fois). Elle se reflète également fortement, à mon avis, dans les progrès. Comme indiqué précédemment, tous les participants à la session n'ont été plongés dans la tâche qu'à la fin du quart de travail (1 à 2 minutes jusqu'à la fin), et après cette courte période, tout le monde a été distrait par l'interrupteur. Il est clair que vous ne ferez pas grand-chose de cette façon.

Une autre équipe aimerait avoir plus de temps pour réfléchir «en silence» et discuter des idées, mais des changements fréquents ont provoqué une tentative d'examiner plus avec les mains que ce qui était supposé en théorie.

Nous n'avons pas pris le cas le plus simple pour une expérience d'une heure: une tâche d'un autre projet qui n'était pas très familière à notre équipe. La plupart du temps, nous avons compris comment fonctionne généralement ce morceau de code que nous devons modifier. Sur un total de 7 heures de travail (1 heure pour chaque membre de l'équipe), nous n'avons vraiment pas compris de quel côté aborder cette tâche.

Le facteur a été noté que toute l'équipe voit la solution au problème d'un certain point de vue, y compris un testeur. Nous avons suggéré qu'à l'avenir (lorsque nous aurions atteint le stade approprié), cela pourrait nuire à l'objectivité des tests, car nous saurions tous «comment cela fonctionne», et inconsciemment, nous tenterions d'éviter les goulots d'étranglement. Malheureusement, ce n'est qu'une hypothèse.

Mais notre autre hypothèse a été confirmée. Même avant la session, nous avons suggéré que si des personnes de visions différentes se rencontrent en travaillant sur la même tâche, il y aura une course d'idées. C'est exactement ce qui s'est passé: certains développeurs ont suggéré d'effectuer un débogage local au moyen de tests d'intégration, d'autres - en mettant pleinement en œuvre le processus métier qui devait être modifié. Chaque partie a présenté des arguments convaincants. Nous sommes sortis de cette situation du fait que nous avons décidé d'essayer d'abord une approche, et si, à l'heure convenue, nous comprenons que cette méthode nécessite plus de travail, nous utiliserons alors une option alternative.

Les paramètres dans l'environnement de développement se sont révélés être une pierre d'achoppement: chacun des développeurs est à l'aise avec ses propres paramètres spécifiques. Dans ce cas, il n'y avait qu'un seul environnement de développement et, bien sûr, tout le monde n'aimait pas ses paramètres.

Nous avons même réussi à commettre une erreur de facilitation: peu avant la fin du quart de travail, le futur chauffeur est allé prendre le thé. En conséquence, son navigateur est également parti pour préparer du thé, et nous avons donc perdu un quart de temps.

Comme vous pouvez le voir, certains facteurs négatifs sont survenus à la suite d'erreurs organisationnelles, mais ils ont néanmoins montré comment faire mieux et pourquoi.

Positif

Les participants ont noté que ce style de travail permet aux personnes qui reçoivent normalement des tâches de l'entreprise, de les analyser et de les tester, de se plonger dans le processus de résolution directe de ces problèmes. Ils ont vu leur travail de l'autre côté: quelles étapes une tâche passe-t-elle sur le chemin de sa mise en œuvre. Il est devenu évident pour eux quelles actions les développeurs font pour comprendre comment aborder sa solution. Ainsi, tout le monde voit et comprend ce qui se passe actuellement avec la tâche.

Il est devenu évident pour certains d'entre nous pourquoi les développeurs ont souvent besoin d'une analyse plus approfondie lorsqu'ils décrivent une tâche, et pourquoi ils posent parfois des questions de clarification plutôt absurdes, à première vue.

Il s'agit sans aucun doute d'une expérience nouvelle et précieuse pour chacun de nous. De plus, une collaboration aussi inhabituelle contribue à renforcer l’équipe, c’est-à-dire qu’elle sert à une sorte de team building: pour la première fois, quelqu'un a vu le travail direct de l’autre, a appris ses pensées dans une certaine situation.

Résultats

Après avoir discuté des commentaires reçus les uns des autres au sujet de la session, nous sommes arrivés à certaines conclusions.

Selon nos résultats, il s'est avéré qu'en mobbing, vous ne devez pas travailler absolument avec toute l'équipe, ou du moins pas constamment. Dans notre réalité, si toute l'équipe travaille sur une seule tâche, alors les négociations avec les entrepreneurs ne sont pas tenues et les demandes des utilisateurs ne sont pas traitées. Vous pouvez, bien sûr, le faire jusqu'à ce que votre quart de travail arrive, mais ensuite vous devez être distrait, passer à la tâche que tout le monde résout, puis abandonner à nouveau et vous rappeler ce que vous avez arrêté avant le quart de travail.

Il faut que le navigateur soit un peu plus expérimenté que le conducteur. Sinon, cela se révèle être un jeu de téléphone cassé, lorsque le navigateur essaie de transmettre littéralement au conducteur ce qu'il a dit, sans comprendre pleinement «ce que tout cela signifie». Vous pouvez, par exemple, changer de rôle pas à tour de rôle. Si vous ne pouvez pas fournir aux couples des navigateurs plus puissants, mais que vous devez apprendre aux gens à travailler non seulement en fonction de leur spécialisation, alors, à notre avis, la programmation par paires sera plus efficace.

Nous avons eu l'impression que le mobbing fonctionnerait bien lorsque de nouveaux développeurs apparaissaient dans l'équipe, ou que quelqu'un de l'équipe voulait décidément programmer. Ensuite, lors de mobbing avec des développeurs expérimentés, les nouveaux arrivants s'immergeront rapidement dans les projets d'équipe et comprendront les principes et règles de travail généralement acceptés.

De la même manière, vous pouvez travailler sur une tâche dans laquelle une seule personne dans une équipe possède une expertise (oui, nous avons une telle personne et un tel projet) pour diffuser les connaissances parmi les autres.

Nous avions l'hypothèse que le mobbing est bon pour les équipes de tigres: des équipes qui sont formées pour résoudre une tâche urgente. Mais cela peut fonctionner si, au moins, l'équipe est dans la même pièce et avec l'environnement de développement préparé pour la majorité. Sinon, il y aura une perte de temps en raison de facteurs de communication inutiles.
Si une équipe vient de se former, et idéalement, un nouveau projet se forme avec lui, alors le mobbing peut bien fonctionner. Dans ce cas, chaque participant verra comment et pourquoi certaines décisions conceptuelles, architecturales et autres sont prises, il y aura un déséquilibre dans les connaissances sur le projet.

En fin de compte, des changements sont nécessaires plus longtemps. Au moins 15-20 minutes, au lieu de nos 5. Et vous devez faire quelque chose avec la règle qu'un conducteur n'est que les mains d'un navigateur, sans sa propre tête.

Nous avons donc essayé le mobbing en pratique dans les conditions de travail de notre équipe. Certaines règles ont interféré avec nous, quelque chose que nous avons mal compris, quelque part où nous avons fait des erreurs. Néanmoins, nous nous sommes sentis ce que c'est, si c'est possible et si nous devons travailler dans ce style. Selon les résultats de cette expérience, nous n'avons pas pleinement reçu les valeurs que nous avons identifiées comme les plus importantes. Il vaut la peine de considérer que nous avons essayé le mobbing pendant seulement une heure avec des quarts trop courts, car ces résultats peuvent ne pas être les plus fiables. Lorsque vous travaillez sur le mobbing «à plein temps», certains problèmes ne se poseront pas et certains seront surmontés après «adaptation» au processus. Probablement, nous n'avons tout simplement pas réussi à obtenir les valeurs dont nous avions besoin en si peu de temps. Pour le savoir avec certitude, cela vaut la peine d'essayer le mobbing dans d'autres situations, mais ce sera une histoire complètement différente.

PS
Vous pouvez lire et voir les documents suivants sur le sujet:
GOTO 2017 - Programmation Mob: une approche d'équipe - Woody Zuill
Woody Zuill - Une journée de programmation Mob
Blog Agilix Consulting: tuer les files d'attente et accélérer une équipe grâce au mobbing