Amélioration continue : Comment rester dynamique à mesure que l’équipe s’agrandit ?

Différentes études^<a href="#note1">1</a>^ soutiennent qu’une équipe performante est une équipe qui est capable de remettre fréquemment en question ses modes de fonctionnement afin d’apprendre et s’améliorer en continu. Pour y arriver, elle :

• favorise l'émergence de nouvelles idées
• a moyen de valider ou d’invalider efficacement la pertinence de ces nouvelles idées
• est en mesure d’aligner ses membres derrière les idées retenues comme étant pertinentes

Or, plus une équipe grandit (aussi bien en nombre de membres qu’en temps passé à travailler ensemble) plus elle est sujette à la calcification (voire à l’arthrose) : il devient de plus en plus difficile pour elle de se remettre en question et changer. Rien de plus naturel. En effet, prendre une décision à 3 ou 4 membres est bien plus simple qu’à 6 ou 7. De même, il est plus aisé de changer une architecture ou une organisation sur un projet vieux de 6 mois que sur un projet vieux de 3 ou 4 ans. Pour autant, les gains (de productivité, de fiabilité, de motivation) issus de la remise en question restent aussi intéressants pour une jeune équipe “réduite” que pour une équipe consolidée plus “conséquente”. Pour lutter contre la calcification, il est judicieux pour de telles équipes de migrer d’un mode de prise de décision "a priori" vers un mode de prise de décision "a posteriori" basé sur l’expérimentation.

Testez et [Adoptez ou Rejetez]

Dans une équipe, lorsqu'une idée de changement qui ne fait pas l’unanimité est proposée, on observe souvent la formation de 3 groupes : les enthousiastes, les indécis et les sceptiques.

Lorsque vous proposez un changement à votre équipe, identifiez donc le positionnement de chacun vis-à-vis de celui-ci (ce positionnement pourra bien sûr varier d'une idée à l'autre pour chacun des membres). À partir de là, l'erreur à ne pas commettre serait d'essayer de convaincre l'ensemble de vos coéquipiers que le changement que vous proposez vaut la peine d'être opéré avant même d'en faire l'expérience : vous vous y casseriez sûrement les dents. Il est plus intéressant de vous lancer au plus tôt à tenter de nouvelles choses avec le groupe de vos coéquipiers enthousiastes dans le cadre d'une expérimentation.

Imaginons par exemple que vous ayez l’intuition qu’introduire le NoEstimates au sein de votre projet représenterait une amélioration. Vous pourriez tout à fait essayer de mettre tout le monde d’accord sur cette supposition avant de vous lancer à sa mise en pratique. Il est fort probable que cette tentative de consensus a priori donne lieu à des débats passionnés, relativement “hors-sol”, et qui, en plus d’être énergivores et chronophages, pourraient tout aussi bien s’avérer infructueux : au bout du compte, chacun resterait campé sur ses positions et rien de concret ne serait engagé. Au lieu de ça, vous pourriez tout aussi bien décider, avec l’aide de vos quelques coéquipiers enthousiastes, de faire le suivi des développements en NoEstimates (une User story = un point) sur quelques sprints en parallèle du système en points de complexité déjà en place. Dans le même temps, vous pourriez vous engager auprès du reste de l’équipe (et notamment auprès de vos coéquipiers sceptiques) à présenter les résultats de votre expérimentation à toute l’équipe et à décider en cette occasion (a posteriori donc), tous ensemble, des suites à donner à celle-ci : continuer à estimer vos User stories en point de complexité ou alors passer effectivement au NoEstimates.

Autre exemple: imaginons que vous soyez tenté de mettre en place l’architecture hexagonale. Ici aussi, vous pourriez lancer l’idée et essayer d’obtenir l’adhésion de tous les développeurs autour de celle-ci avant de mettre la main à la pâte. Ce faisant, il y a un risque non-négligeable que cette discussion ait des difficultés à aboutir en l’absence d’exemples concrets d’implémentation in-situ et s’enlise. Au lieu de cela, vous pourriez très bien mettre en place l’architecture hexagonale sur un périmètre réduit (une petite feature par exemple) en time-boxant votre effort sur quelques jours et vous engager auprès du reste de l’équipe à discuter a posteriori des résultats en revue collective, décidant seulement alors de conserver le code produit et adopter cette nouvelle architecture ou bien, au contraire, de la rejeter.

Les expérimentations, telles que décrites ci-dessus, sont des espaces de “liberté encadrée”. Dans ces espaces précisément délimités, il est possible, sans accord explicite de l’ensemble de ses coéquipiers, de s'affranchir des règles explicites ou implicites en vigueur dans l’équipe pour tenter de nouvelles choses et ce, sans l'impacter (pas directement du moins). L’impact vis-à-vis de l’équipe sera en effet limité à l’investissement en temps que vous consacrerez à l'expérimentation. Pour rendre possible de tels espaces de liberté, il est nécessaire de leur poser un cadre et de le communiquer. Celui-ci définira à minima:

• Les hypothèses qu’on cherche à valider/invalider
  • Est-ce que le NoEstimates permet, à moindre coût, d’obtenir une prédictibilité au moins équivalente à celle de l’estimation en Story Points ?
  • Est-ce que l’architecture hexagonale nous apporte plus de découplage ? Plus de testabilité ? Plus de modularité ? Est-elle plus compliquée à mettre en place ? Demande-t-elle un temps de développement plus important ?
• Son périmètre "spatio"-temporel
  • On produira les indicateurs de suivi de sprint en NoEstimates en parallèle du système existant pendant une durée de X sprints.
  • L’effort de mise en place de l’architecture hexagonale sera limité à X jours et sera cantonné au seul code de la feature Y.
• La façon dont on décidera collectivement si l'expérimentation est un succès ou bien un échec
  • On montrera et comparera la prédictibilité des deux systèmes de suivi de sprint en présence de toute l’équipe et décidera alors du système à conserver.
  • On montrera le code produit en architecture hexagonale ainsi que nos retours d’expérience lors d’une revue collective et on décidera alors, tous ensemble, de merger ou non ce code et d'intégrer ou non cette architecture à nos standards.
• La façon dont sera géré l’éventuel échec de cette expérimentation afin qu’il n’impacte pas l’équipe
  • On conservera le système en place d’estimation en Story points_._
  • On ne mergera pas le code produit en architecture hexagonale sur master et ré-écrirons cette feature en suivant nos standards actuels en cas de rejet de cette architecture par l’équipe.

La raison pour laquelle je préconise de passer par ce genre d’expérimentation, (discussions et prise de décision a posteriori, plutôt qu’a priori) est simple : il est fort probable que certaines (voire la plupart) de vos expérimentations ne soient pas concluantes. Dépenser le temps et l'énergie nécessaires pour faire monter toute l'équipe à bord d’un essai infructueux serait alors une perte sèche. Pire encore, vous pourriez abandonner votre idée en cours de route et ne peut-être jamais savoir si elle en valait le coup restant ainsi ignorant (et frustré). En expérimentant de nouvelles choses en petits groupes, l’apprentissage est garanti : en cas d’échec, vous avez la certitude que le changement proposé n'était pas judicieux et ce, à moindres frais. Fail early, learn fast!

Si, de plus, vous communiquez régulièrement votre avancement avec vos coéquipiers “sceptiques”, ces derniers viendront enrichir l'expérimentation de leurs réserves. Ainsi, à l’issue de l’expérimentation, l’équipe aura tous les éléments pour mener une discussion constructive basée sur un artefact concret. Concernant l'expérimentation sur l’architecture hexagonale, un de vos collègues sceptiques pourrait par exemple vous dire “J’ai peur que si on se lance là-dedans, on ait ensuite deux architectures différentes qui cohabitent dans l’application”. Concernant celle sur le NoEstimates vous pourriez entendre : “mais si on n’estime plus en Story Points, est-ce que ça veut dire que l’atelier de Grooming saute ?”. Parfait ! Vous avez là deux nouveaux éléments à observer pendant vos expérimentations : le risque de fragmentation de l'architecture et l'intérêt (ou non) de conserver un grooming sans estimer. C’est précisément là que les choses deviennent intéressantes et que la complémentarité entre enthousiastes et sceptiques opère. Si l’adoption de l’architecture hexagonale ou du NoEstimates sont en effet des idées pertinentes, elles survivront à ces réserves supplémentaires et n’en seront que plus robustes. Au contraire, si elles en meurent, cela n'en sera que tant mieux : dans votre contexte précis, à cet instant t, ces idées n’étaient de toute évidence pas pertinentes. Enthousiastes et sceptiques, chacun à leur manière, œuvrent ainsi au bien de l'équipe. Les enthousiastes créent le mouvement et les sceptiques le canalisent, en limitent la dispersion et garantissent la stabilité des pratiques de l’équipe : l'équilibre entre les deux est primordial. Ensemble, ils contribuent à l’amélioration continue.

while(true) { val result = trySomething() if (result.isPositive()) { keepDoingIt() } else { dropThatThing() } }

Modes de prise de décision

Il arrive que les résultats d’une expérimentation fassent l’objet d’un consensus tacite et immédiat. En ces rares occasions, l’ensemble de l’équipe a conscience que l’expérimentation s’est soldée par un franc succès ou bien par un lamentable échec. Adopter ou rejeter la proposition de changement qui la motive est alors une évidence. La plupart du temps cependant, il faudra trancher et prendre une décision. Dans une équipe, il existe de nombreuses façons de prendre une décision^<a href="#note2">2</a>^. En effet, celle-ci adoptera différents modes de prise de décision en fonction du périmètre et des conséquences potentielles d'une décision. Il est cependant assez rare que ce modus operandi soit explicite. Plus l’équipe est consciente et alignée sur le procédé de prise de décision et plus il sera aisé et rapide pour elle de se mettre d’accord. Dans l’optique de rendre ces derniers explicites, on peut par exemple définir les classes de décisions qui peuvent être prises individuellement vis-à-vis de celles qui, au contraire, doivent être prises en incluant tout ou partie de l’équipe. On pourra décider si une décision collective sera prise par consentement (tout le monde est en faveur), par consensus (personne n’est contre), avec un Decider, par un vote à la majorité ou bien de toute autre façon. Certains types de décisions peuvent être prises individuellement mais faire obligatoirement l’objet d’une consultation préalable de l’équipe. D’autres peuvent être la prérogatives de certains ou encore faire l’objet d’un droit de véto. Chacun de ces modes de prises de décisions peut se révéler pertinent en fonction du contexte et évoluer dans le temps. Rendre explicite la façon dont sont prises telles ou telles décisions dans l’équipe maximise sa capacité à s’adapter et performer. Il en va de même vis-à-vis des expérimentations. Le fonctionnement par expérimentations favorise la prise d’initiatives personnelles ou en petits groupes. Toutefois, l'idée n'est pas de multiplier les pratiques et d'affaiblir les standards de l'équipe mais bien d'en favoriser l'émergence et surtout l’évolution. Aussi est-il judicieux de passer par un mode de décision à minima consultatif quant à l’adoption ou le rejet des changements proposés.

Patience et Réalisme

Si le fonctionnement par expérimentations évite que l’équipe ne s’enlise dans le status quo, facilite sa remise en question et lui permet de changer, il ne rend pas pour autant le changement nécessairement rapide ou même aisé.

Dans le livre Mastery, George Leonard invite le lecteur à voir le changement comme le déplacement d'un solide dans un fluide : plus le solide est volumineux et le fluide visqueux et plus son déplacement sera lent. Ainsi, mécaniquement et inexorablement, plus le changement proposé est important et l'équipe qui y fera face inerte, plus votre patience devra être grande. C'est possiblement très frustrant mais hélas, vous et vos camarades d'expérimentation n'y pourrez rien. Accueillez et acceptez cette lenteur aussi tôt que possible afin de préserver votre motivation. Pour l’équipe, il est bien plus intéressant que vous proposiez régulièrement de petites expérimentations ciblées plutôt que de grandes remises en cause tous azimuts (façon Big Bang) au risque d'épuiser votre motivation et de claquer la porte en vous en allant.

Cela invite à la considération suivante : si vous comptez soumettre de nombreuses idées de changement à l’équipe, il vous faudra distribuer l'effort dans la durée de façon soutenable en priorisant et en ménageant vos attentes.

Prioriser

Je vous propose un exercice : faites la liste des points qui vous aimeriez améliorer dans votre équipe et des changements que vous aimeriez soumettre pour y remédier. Attribuez une note de 1 à 10 au potentiel qu'aurait chaque changement de faire du bien à l'équipe selon vous. Attribuez ensuite une note de 1 à 10 quant à l'énergie requise pour mettre en place ces changements. Enfin, classez ces changements par ordre décroissant de ratio “amélioration potentielle perçue / énergie requise perçue”.

Attention au biais de confirmation : il est possible que vous tendiez naturellement à surévaluer le potentiel et à sous-évaluer l'énergie requise de tel ou tel changement pour influer sur sa priorité. Ce n’est pas très grave, l’important c’est surtout de se poser les bonnes questions en connaissance de cause.

Les 2-3 premiers items de la liste sont les choses sur lesquelles vous devriez concentrer votre énergie. Concernant ces items, quelles sont alors les expérimentations que vous pourriez mener (périmètre, mode de partage et de prise de décision, contingence en cas de rejet) ? Lesquels de vos coéquipiers seraient partant pour mener cette expérimentation avec vous ?

Ménager vos attentes

Pour conserver sa motivation il est également nécessaire de ne pas viser trop haut trop vite. Je vous invite donc à reprendre la liste issue du paragraphe précédent. Vos deux ou trois items prioritaires sont-ils facilement actionnables ? En cas de doute, il est intéressant de les décomposer en sous items. Pour ce faire, essayez de visualiser le gap qui existe entre la situation actuelle et la situation qui serait pour vous idéale. Par exemple : imaginons que votre item numéro 1 soit “Améliorer la qualité de code”. Essayez de visualiser la distance entre la qualité du code actuellement produit par l'équipe et celle d’un code qui, pour vous, ne serait pas une contrainte.

Vous avez ce gap en tête ? Bien, essayez maintenant d’imaginer parcourir les dix premiers pourcents de cette distance. Quels sont alors les signes concrets qui montrent que vous avez parcouru ces 10% ? Avoir posé des tests unitaires ? Que l’équipe propose spontanément des revues de code ? Avoir refactoré telle ou telle partie du code ? Ceci devrait être votre objectif : dix. petits. pourcents. Obtenir une amélioration de 10% est beaucoup plus précieux pour l’équipe que d’échouer dans la tentative d’en obtenir 50. Tâchez de vous remémorer ceci alors que vous traverserez des moments de doute et de frustration pendant lesquels vous aurez l'impression de pédaler dans la semoule car les choses ne vont pas assez vite ni assez loin à votre goût.

Take-aways

• Favoriser la dynamique de changement et d’amélioration continue en passant par des expérimentations. N'essayez pas de convaincre tout le monde avant de passer à l'action. Identifiez plutôt un périmètre vous permettant de passer vos idées au crash test en faisant des essais concrets en groupes réduits de personnes motivées. Partagez ensuite vos résultats d'expérimentation au reste de l’équipe et décidez ensemble des suites à donner à celle-ci.
• Mettez-vous d’accord sur la façon de vous mettre d’accord. Quels sont vos modes de prise de décision ?
• Prioriser vos expérimentations par ordre de potentielle amélioration vs. potentielle difficulté
• Fixez-vous des objectifs à 10% d’amélioration à la fois, pas plus.

Cet article vous a plu ? Votre équipe adresse la problématique de l’amélioration continue différemment ? Vous avez un conseil ou un retour d'expérience à partager sur le sujet ? N'hésitez pas à contribuer en laissant un commentaire ci-dessous !

[1]

• Dans 5 dysfunctions of a Team, Patrick Lencioni soulève la question “Does your team come to decisions quickly and avoid getting bogged down by consensus?”
• Dans Fearleass Organization, Emy Edmonson associe la performance d’une équipe avec sa capacité à apprendre
• Dans les Core Protocols, Jim et Michele McCarthy soulignent l’importance de “soumettre une idée plus pertinente que celle qui domine à ce moment” afin “qu’elle soit acceptée ou refusée” et “explicitement chercher à l’améliorer”

[2] cf. la notion de Decision Stack dans Brave New Work de Aaron Dignan