Teamicide offshore
Certains d’entre vous connaissent probablement le phénomène du teamicide, décrit par Tom de Marco et Timothy Lister dans le fameux (et indispensable) Peopleware. Le teamicide, c’est un ensemble de pratiques managériales dont la conséquence directe et inéluctable est la destruction définitive de tout esprit d’équipe au sein des personnels concernés. Souvent pratiqué par inadvertance, le teamicide est particulièrement fréquent dans les projets informatiques, avec des résultats souvent désastreux pour ces projets – et une expérience navrante pour ceux qui y participent et chez qui les symptômes oscillent généralement entre dépression nerveuse et indifférence cynique.
Rappelons rapidement les principales techniques de teamicide décrites dans Peopleware :
- Le management défensif – résultat direct d’une défiance irréfléchie envers l’équipe, et qui se manifeste sous diverses formes plus ou moins spectaculaires, mais toujours avec le même objectif : réduire autant que possible les degrés de liberté des membres de l’équipe.
- La bureaucratie, qui, dans le développement logiciel, prend souvent la forme d’une méthodologie formelle impliquant un grand nombre de documents d’étape dont l’intérêt douteux n’en entame pas moins le caractère sacré. Dans les organisations les plus avancées dans le domaine, on observe souvent une cellule spéciale qui agit en tant que police de la Méthode et vérifie scrupuleusement qu’aucune équipe n’a enfreint les tables de la Loi. Cette approche permet de cumuler bureaucratie et management défensif.
- La séparation physique des individus, dont on comprend sans peine qu’elle réduit mécaniquement les relations interpersonnelles entre eux.
- La fragmentation du temps – demander aux gens de travailler à temps partiel sur plusieurs projets simultanément est l’une de ces recettes magiques qui, outre qu’elle réduit fortement l’efficacité des individus, interdit à coup sûr l’émergence du moindre esprit d’équipe (quelle équipe, au fait ?).
- La réduction de la qualité, qui est une technique plus subtile mais non moins efficace et populaire de teamicide. Il n’est tout bonnement pas imaginable qu’une équipe émerge formée d’individus honteux de leur travail …
- Les délais arbitraires et intenables, qu’un nombre encore impressionnant de cadres s’acharnent à considérer comme un moyen astucieux de conserver une équipe sous pression. Mettre d’emblée une équipe en situation d’échec, en lui fixant des objectifs qu’elle n’a aucune chance d’atteindre, est pourtant le plus sûr moyen de voir s’évaporer toute trace de motivation, tant collective qu’individuelle …
Fort de ces quelques indices, on comprend aisément que le développement offshore est un terrain spontanément très propice au teamicide. Tellement propice au demeurant que la plupart des organisations offshore baissent d’emblée les bras et ne cherchent même pas à construire des équipes – elles se contentent d’agréger des jours-homme au meilleur coût dans l’espoir souvent déçu que cette masse d’effort pourra être canalisée vers un résultat tangible. Elles utilisent pour cela des techniques de management qui pour la plupart finissent par achopper, précisément parce qu’elles sont de nature teamicidaires et que l’on n’échappe jamais vraiment à l’impératif de constituer d’authentiques équipes pour réussir un projet.
Depuis plus de trois ans maintenant, Xebia mène des projets agiles distribués, grâce à des équipes transcontinentales dont une partie des membres est localisée à Gurgaon, dans la banlieue de Delhi. Rappelons que la construction d’équipes de petite taille et fortement autonomes est une condition sine qua non de succès dans un projet agile, fût-il mené en offshore. Tout l’enjeu de l’approche ADDM (Agile Distributed Delivery Model) est donc précisément de parvenir à constituer de véritables équipes dont les membres sont distants de 6000 km les uns des autres et issus de substrats culturels radicalement différents.
Cet impératif nous a permis de découvrir, parfois dans la douleur, tout un jeu de techniques teamicidaires inédites. Attention : l’usage d’une ou plusieurs de ces techniques constitue le meilleur moyen d’échouer rapidement dans un projet agile distribué. En voici les 10 principales, :
- Impliquer l’équipe offshore après quelques sprints, une fois que l’équipe locale a bien compris les enjeux du projet, réalisé les principaux choix techniques et élaboré une road-map
- Une fois l’équipe offshore intégrée, continuer de prendre localement les principales décisions en matières d’architecture et de conception. Communiquer fréquemment sur l’incapacité de l’équipe offshore à bien comprendre ces choix, et sur les erreurs qui en découlent.
- Attribuer à l’équipe offshore tous les problèmes du projet, fussent-ils dus à des exigences floues, à de la dette technique ou encore à des choix technologiques erronés. Vous serez surpris de constater à quel point il est aisé, aux yeux de vos commanditaires, de faire porter le chapeau à l’équipe distante.
- Rester condescendant lors des rétrospectives, sans jamais donner de feedback honnête à l’équipe offshore. Lui assurer systématiquement que son travail est excellent, quelle qu’en soit la réalité.
- Ne jamais colocaliser toute l’équipe et maintenir l’équipe offshore à distance du Product Owner, des utilisateurs, et plus généralement de toutes les parties prenantes du projet. Invoquer le coût du voyage permet très aisément de convaincre le management du bien fondé de cette mesure.
- Si malgré tout une période de colocalisation est organisée, s’assurer que les développeurs offshore ne programment jamais en binôme avec leurs pairs locaux. Si possible, placer les premiers dans un bureau distinct.
- Confier à l’équipe offshore les tâches dont personne d’autre ne veut, et réserver les user stories les plus stimulantes pour l’équipe locale.
- Remanier le code durant le weekend, ou en l’absence de l’équipe offshore (l’après-midi, si ce sont des Indiens), en se gardant de l’informer sur ce refactoring.
- Ré-écrire le code produit par l’équipe offshore, sans communiquer avec elle sur les raisons de cette mesure. En complément, faire en sorte que le management soit informé du retard pris par le projet en raison de cette ré-écriture.
- Ne jamais permettre à l’équipe offshore de corriger les problèmes qu’elle a elle-même introduits.
Bref, xebia sont les meilleurs … article douteux, problèmes vaguement exposés et non argumenté, auto-satisfecit et auto-proclamations …
Franchement, c’est article est mauvais et vous m’avez habitué à mieux : continuez dans la veine technique, retours d’expérience (ce qui met Xebia en avant positivement), framework, architecture, … mais pitié, arrêtez ces articles qui essayent de parler de « management » (c’est un terme anglais).
J’espère que cette remarque ferme mais amicale vous aidera.
Absolument pas d’accord avec le commentaire précédent… c’est un retour d’expérience mettant en avant surtout l’échec pour en sortir des enseignements « Cet impératif nous a permis de découvrir, parfois dans la douleur, tout un jeu de techniques teamicidaires inédites »
Pour avoir mener un projet offshore en étant basé à Bangalore, je peux dire que je me retrouve totalement dans l’article.
Notamment sur l’importance de donner le maximum de moyen aux développeurs de se sentir inclus le processus de développement (et pas seulement de simples exécutants sur une TMA codant une ligne par jour).
Qu’ils soient indiens ou vietnamiens ne leur donne pas moins de volonté de s’impliquer et c’est, comme partout dans le monde, la meilleure façon pour une équipe de développement d’être motivée et d’être force de proposition.
Mais bref tout ça n’est pas nouveau…
Par contre, oui, l’article manque de profondeur ; donnez un exemple concret de ce que vous avez pu vivre comme mauvaise expérience.
Selon moi, pour tout dire, concernant l’offshore, le principal ennemi c’est la peur… la peur de tous les acteurs qui participent à un tel projet, qu’ils soient commanditaires ou prestataires.
Oui en plus c’est trop directif « Ne jamais permettre » …
En lisant l’article, j’en retiens que le code produit par l’équipe offshore est endetté et qu’ils ne sont pas capable de résoudre leurs problèmes.
Quelle est la valeur ajoutée d’avoir une équipe offshore s’il faut passer son temps à refaire 2 fois le travail ?
Je pense, un peu comme lekant, qu’il ne faut pas prendre cet article comme réflexion sur le « Teamicide offshore » en général, mais comme un retour d’expérience personnel, une sorte d’introspection menée sur l’un de leurs projets.
Effectivement lekant, la peur « mutuelle » entre les différents acteurs du projet est un obstacle de taille, je rajoute à cela (de part mon expérience personnelle dans le sujet) les préjugés « culturelles » (indiens ou européen, parisien ou de province..) c’est des sujets qu’ils faut absolument traiter entre l’équipe au début du projet, et maintenir la mentalité du « une équipe » tout au long..
La plupart des autres points mentionnés dans cet article restent valables qu’il s’agisse d’un projet agile ou non (impliquer l’équipe, modification du code et refractoring en mode ‘discret’, privilégier des membres de l’équipe sur d’autre)
Cela étant dit, je me demande ce que nos amis de l’autre coté en pensent?
Superbe article.
Il y manque cependant une des caractéristiques des méthodes « Teamicides »:
- Faire faire un travail difficile à un subalterne et s’en approprier le mérite
dans son dos une fois le labeur achevé.
Merci pour cette récréation bien sympathique.
Un « Teamicidé »
En réponse au commentaire de Sylvain M. :
Vous dîtes :
« Oui en plus c’est trop directif « Ne jamais permettre » … » => on donne la la recette pour tuer une équipe offshore… Le ton directif est là car pour tuer une équipe offshore, il n’y a pas mieux que d’appliquer les points présentés dans cet article (expérience vécue de mon côté)
« En lisant l’article, j’en retiens que le code produit par l’équipe offshore est endetté et qu’ils ne sont pas capable de résoudre leurs problèmes. » => Non… Encore une fois, c’est ce qu’il faut communiquer afin de tuer l’équipe offshore, pas ce qui est réellement.
« Quelle est la valeur ajoutée d’avoir une équipe offshore s’il faut passer son temps à refaire 2 fois le travail ? » => justement aucune, mais encore une fois, il s’agit d’une recette pour tuer l’équipe offshore..
Je crois, monsieur M., que vous avez compris l’article à l’envers.
En réponse au premier commentaire de « am » : pourquoi penser d’emblée que, parceque Xebia exposent et font partager un retour d’expérience, Xebia sont les « meilleurs » ? Si vous aviez pu y mettre le ton, il aurait été à coup sûr ironique. En quoi le fait qu’ils exposent « ce qu’il ne faut pas faire » impliquerait le fait qu’ils savent « ce qu’il faut faire » ? Tout le monde sait constater et exposer les failles sans forcément savoir comment la combler… Je vous imagine d’ailleurs, comme tout le monde, dans votre canapé devant votre télé en train de râler contre une décision politique qui n’est manifestement pas la bonne… Avez vous la vraie solution pour autant ? J’ai comme un doute…
L’article est bon. Il m’a fait à la fois fait rire et peur… Rire parceque j’ai connu ce genre de situation et peur… parceque j’ai connu ce genre de situation.
Merci Xebia.
« Ne jamais permettre à l’équipe offshore de corriger les problèmes qu’elle a elle-même introduits. »
Et pourquoi pas ? si c’est fait très peu de fois, je suis sûr que ça peut stimuler une équipe. Dans mon équipe il nous arrive de faire des revues de code, on sélectionne une partie de code et on débat sur les qualités/défauts du code et des améliorations envisageables.
« L’article est bon »
Dans le fond et dans la forme? Vous avez remarqué que tous les arguments sont toujours dans le sens positif à l’équipe locale ? Si c’est accès sur comment tuer l’équipe offshore uniquement autant pour moi je ne l’avais pas pris comme tel
Monsieur M., ne voyez aucune attaque personnelle ni même une quelconque critique, mais je ne vois pas bien à quel moment, en lisant cet article, vous avez pu penser ne serait-ce qu’une seconde que cet article prônait la pratique du teamicide offshore… Teamicide, néologisme tiré de mots tels que fratricide, génocide etc… et étant un mot péjoratif, je ne comprendrais pas qu’un auteur d’article sur son blog utilise des mots péjoratifs pour décrire quelque chose qu’il recommande…
Des phrases comme
« Cet impératif nous a permis de découvrir, parfois dans la douleur, tout un jeu de techniques teamicidaires inédites. Attention : l’usage d’une ou plusieurs de ces techniques constitue le meilleur moyen d’échouer rapidement dans un projet agile distribué. »
Contenant des expressions comme « dans la douleur » ou encore « le meilleur moyen d’échouer » auraient dû vous mettre la puce à l’oreille quant à l’orientation du texte.
Enfin, pour vous répondre, l’article est bon aussi bien dans le fond que dans la forme. Dans la forme car clair et amusant : on sent un ton ironique, limite cynique et désabusé du début à la fin dont je suis, pour ma part, très friand. Dans le fond enfin car il ne fait que résumer, hélas, le quotidien et le fonctionnement de bon nombre de sociétés et de projets informatiques.
Peut-être connaissez-vous déjà le site http://www.la-rache.com/
Je ne connais pas votre parcours, je ne connais pas le nombre de projets informatiques auquel vous avez déjà participé, mais avec un peu de recul et d’expérience, on se rend compte que les auteurs de ce genre de choses ne sont hélas pas allé chercher leurs délires dans leur imagination, mais bien dans la vraie vie, dans de vraies sociétés, sur de vrais projets avec des vrais gens (je ne suis pas dans le métier depuis 20 ans, mais ma modeste expérience me permet déjà de me rendre compte de cela).
Bonne soirée à vous !
A quel moment je dis que l’article « prônait la pratique du teamicide offshore » ?
Je dis juste que les exemples qui sont fournis par Xebia mettent en avant que c’est toujours l’équipe offshore qui fait mal son boulot et pas l’équipe locale.
Vous semblez avoir bien compris le texte mais pas compris mes arguments, c’est une lacune ou de la mauvaise fois ?
@Sylvain
S’il est d’usage de dire que la meilleure défense c’est l’attaque, il ne faut, à mon (humble) avis, pas en abuser. Merci donc de modérer vos propos.
Sans vouloir réellement répondre, permettez-moi juste de vous signaler que nous travaillons conjointement avec des équipes offshore Xebia …
Erwan (Xebia)
Sylvain, on va dire que d’une façon générale, tous les deux, on ne se comprend pas. Cela vous convient ? Mais relisez quand même le texte puis relisez vos commentaires…
A bientôt et bonne continuation. Moi je m’arrête là.
Merci encore à Xebia pour l’article
J’ajouterais ma petite recette perso, qui à fait ses preuves :
séparer les rôles des développeurs dans des sous-équipes spécialisées, de façon à ce que chacun ait un rôle bien défini et que le projet soit aussi peu collectif que possible. Assez rapidement, le jeu va consister à renvoyer les problèmes sur le dos des autres et à organiser un « Fight Club »-like. Pour pimenter, gérer le tout à base de l’indispensable ExcelWare.
Plusieurs réactions :
- celui qui prend sur lui sans fin et finira un jour chez le psy,
- celui qui baisse les bras et se détache de tout,
- celui qui essaie de rester motivé et crame littéralement sur pied,
- celui qui rue dans les brancards, ce qui n’a d’ailleurs aucun effet
Plutôt pertinent mais cette situation n’est pas propre à l’off§shore… malheureusement