Vous êtes six à former une équipe Scrum dans votre entreprise afin de réaliser un projet critique et vous livrez des incréments toutes les semaines. C’est votre dixième sprint, et aujourd’hui c’est mercredi. Vous devez livrer une nouvelle version majeure avant le week-end. Vous sentez la pression montée, car il reste encore un lot important d’items à terminer. À la fin de la journée, chacun est rassuré, même si un effort supplémentaire a été nécessaire. Vous êtes persuadés que, demain, vous finirez le reste.
Le lendemain matin, une mauvaise nouvelle tombe : Jean et Jacques sont malades; ils ne pourront pas travailler. Leur présence et leurs compétences sont pourtant essentielles pour pouvoir achever les dernières tâches et rendre possible la livraison. L’objectif du sprint ne sera donc pas atteint, et le client n’en sera pas particulièrement ravi.
Avez-vous déjà vécu un scénario similaire? L’absence de vos collègues met-elle en péril vos projets? Si oui, dans quelle mesure? Le succès repose-t-il sur les épaules de chacun? Prenez-vous le bus? Pourquoi?
Bus Factor
Le Bus Factor (aussi Truck Factor ou tout autre véhicule de votre choix) est un terme évoqué dans le monde du développement logiciel, mais dont, selon moi, on devrait discuter plus souvent. Que l’on soit plus ou moins Agile, il nous concerne tous.
Pensez au contexte dans lequel vous travaillez actuellement. Quelles sont les conséquences des imprévus sur votre environnement, votre projet, vos processus lorsqu’ils surviennent et incapacitent vos collègues ou vous-même. Imaginez que votre équipe voyage en bus et qu’un accident de circulation survient. Résultat : plusieurs membres de l’équipe sont incapables de poursuivre leurs activités, et ce, pour les jours, semaines, voire mois à venir. Le Bus Factor, c’est le nombre de personnes en deçà duquel votre projet ne peut se poursuivre de manière viable.
À combien ce facteur s’élève-t-il pour vous? 1, 5, 10…? Plus il est bas, plus c’est mauvais signe. Ce qui est encore plus inquiétant lorsqu’il s’agit d’équipes de petite taille!
Les champions d’équipe
Jacques, c’est l’administrateur de la base de données avec les pleins pouvoirs et Jean, c’est le seul infographiste de l’équipe. Ils sont tous deux spécialistes dans leur domaine, et l’équipe dépend d’eux pour mener à bien le projet, et ce, quotidiennement. Dans l’équipe, on les apprécie, et actuellement les autres membres ne sont pas en mesure de se doter des mêmes compétences et d’accomplir leurs activités. Quel est le Bus Factor de l’équipe?
Deux? Raté! Un. Exact! L’absence d’un d’entre eux suffit à figer l’avancée de l’équipe. Deux serait une réponse valide si ces deux personnes pouvaient mutuellement se remplacer.
Qui sont vos piliers, vos champions? Il est possible de les identifier grâce à leurs compétences, à leur niveau d’expertise, aux permissions uniques qu’ils ont dans l’équipe. L’objectif n’est pas de se passer d’eux, mais de ne pas dépendre d’eux; donc, d’augmenter le facteur.
Réduire le risque et ses impacts
Entretenir la pluricompétence
Il est utopique de vouloir que chacun puisse réaliser n’importe quelle tâche jugée nécessaire pour le projet. Sans pour autant que votre équipe soit composée de généralistes, le fait de promouvoir la pluricompétence, de diffuser le savoir et de partager différentes « casquettes » entre les membres de l’équipe, ça aide grandement à réduire l’impact du Bus Factor, et ce, indépendamment du niveau d’expertise.
Et voici d’excellents moyens pour éveiller la curiosité et envisager de nouveaux parcours : développer des compétences secondaires en partageant son savoir par des supports tels que les wikis, organiser des séances de programmation en binôme ou de Mob Programming en jouant tour à tour le rôle de conducteur et de navigateur.
Envisager de la formation
Dans la même optique, si des compétences requises ne sont pas présentes dans l’équipe ou s’il est difficile de les partager à un rythme soutenu, la formation est un bon investissement à long terme. Pouvant accentuer le facteur à court terme, la formation peut aussi être donnée à tout membre de l’équipe qui est disponible, moins sollicité.
Favoriser l’auto-organisation
L’équipe est la mieux placée pour déterminer ce qu’elle doit réaliser et comment elle doit le faire pour atteindre les résultats souhaités. Il est improductif de forcer sa participation à une multitude de longues réunions. Avec leur durée courte et limitée, les mêlées quotidiennes permettent à l’équipe d’obtenir du feedback sur sa synergie et son avancée et aussi d’établir des plans d’action efficaces à court terme quel que soit le contexte.
Ne faites pas l’impasse sur ce partage! De l’information précieuse est bien trop souvent connue d’une seule et même personne, ce qui peut compromettre la journée de travail d’un ou de plusieurs collaborateurs! Rendez visible l’information; ne bridez pas la communication.
Sécuriser l’équipe
Ce point n’est pas si évident. L’efficacité d’une équipe relève aussi de la disponibilité de ses membres et de leur attribution à un seul projet. Cependant, est-ce le cas? Que faites-vous pour préserver votre équipe des sollicitations et distractions extérieures qui viennent perturber insidieusement le projet?
Il est non seulement impossible d’immuniser les membres de votre équipe contre le rhume, la fatigue, les accidents, etc., mais il y a aussi des obstacles qui les incapacitent directement sur le lieu de travail. En voici quelques exemples : la réunionite, les soucis matériels, les formalités administratives, les politiques d’accès… Faites la liste et rodez leur processus de résolution. Malheureusement, quant aux problèmes de circulation, vous ne pourrez rien faire.
Enfin, la flexibilité de l’horaire et de l’organisation à titre individuel peut être une bonne piste de solution pour contrecarrer le facteur. L’absence n’implique pas impérativement l’incapacité et encore moins la non-productivité. Si un de vos collègues est forcé de rester chez lui, les canaux de communication ne se sont pas coupés. C’est peut-être l’occasion d’envisager une participation à distance, d’un commun accord. Travailler de chez soi permet de prévenir certaines sollicitations externes et donc d’être plus efficace.
Recruter
La recherche et l’accueil de nouveaux membres dans l’équipe devraient être envisagés uniquement si aucune des solutions précédentes n’est réalisable ou bénéfique, car cette solution a un coût important et ajoute de la complexité. Aussi, elle ne fait qu’élever superficiellement le facteur de 1 pour une compétence critique.
Qu’en pensent vraiment les autres? Que se passe-t-il si le nouveau membre n’apprécie pas son poste et quitte l’équipe avant la fin du projet? Mesurez la portée de cette décision sur les moyen et long termes.
Alors, en lisant ce billet, quels voyants se sont allumés sur votre tableau de bord? Comment prévoyez-vous réagir? Votre ceinture est-elle bien bouclée?
Bonne route!
4 Commentaires
Excellent blog!!! Toujours pertinent même si notre projet est Agile, traditionnel, TI ou non!!!
[…] autre avantage du mob programming est qu’il permet d’augmenter le bus factor de l’équipe à son maximum. Il s’agit du nombre de personne au deçà duquel votre projet […]
“Le Bus Factor, c’est le nombre de personnes en deçà duquel votre projet ne peut se poursuivre de manière viable.”
nombre de personnes “????” il manque un adjectif, un bout de phrase mais il manque qqchose. prenez la phrase seule, elle ne veut rien dire ou alors “plus il y a de personnes dans un projet, moins il est viable”, c’est ce qu’elle signifie telle qu’elle en francais ! et il n’y a pas de subordination avec la précédente donc on peut au mieux tenter de deviner ce que vous voulez dire
À combien ce facteur s’élève-t-il pour vous? 1, 5, 10…? Plus il est bas, plus c’est mauvais signe. Ce qui est encore plus inquiétant lorsqu’il s’agit d’équipes de petite taille!”
non c’est inquiétant sur une grosse équipe justement. sur une petite équipe, on peut comprendre/tolérer que les sachants soit répartis, sur une grosse équipe, c’est encore plus grave, car ca impacte plus de monde et on ne peut pas sortir l’excuse du “on avait pas assez de bras”. C’est grave d’avoir un faible bus factor sur un projet critique ou une grosse équipe. mais par contre, une petite équipe a plus de chance de rencontrer naturellement ce bus factor bas, c’est ca les faits. pas l’inverse
l’article est bien, le sujet est important (bravo!), mais vous avez décrit le bus factor à l’envers à force voulu trop en faire 😉
Michael Bowler est super clair dans son livre Truck Factor
Il semble y avoir un malentendu. Formulé différemment: le “Bus Factor” correspond au nombre minimum de membres de l’équipe qui doivent soudainement disparaître d’un projet pour que celui-ci soit bloqué faute de personnel compétent ou possédant les connaissances nécessaires.