L'Agile au long cours ? Vainquez le côté obscur du gradient de changement faible.

Ou comment passer sereinement la 100e itération. Oui, oui, nous allons évoquer les caractéristiques d’un projet ayant vécu plus de cent (100) itérations, sur cinq ans de vie. Débuté en mode Cycle en V traditionnel en 2006, cette application métier pour un grand acteur télévisuel a vu 12 mois après son lancement ses cycles de livraison passer de 6 mois à 3 mois, puis rapidement à 2 semaines. Au-delà d’une simple durée de cycle, c’est un vrai changement organisationnel qui a été opéré grâce à la confiance d’un client qui souhaitait aussi expérimenter cette nouvelle méthode, promettant visibilité et réactivité.

Aujourd'hui, ce projet est l'œuvre collective d'une petite vingtaine de coéquipiers répartis sur ces six ans en équipes de trois à sept personnes. Outil de gestion web et batch fort de ses deux cents et quelques mille lignes de code en six langages, cinq frameworks JavaScript et quatre-vingts contrôleurs, il continue de grandir et répondre aux nouveaux besoins fonctionnels d'un métier en permanente évolution.

Le cap de la centième itération nous a semblé être un bon prétexte pour faire un petit bilan des risques d’un projet agile sur le long terme. Nous ne parlerons pas des bénéfices, nos clients en parlant mieux que nous.

Des risques dans leur plus insidieuse expression

Vous vous souvenez probablement de ces vacances chez vos grands-parents qui commençaient toujours de la même façon : "Oh mais qu'il a grandi !". Et soudain, vous vous rendez compte que vous vous êtes baissé pour faire la bise à votre grand-mère. Effectivement, vous avez grandi, mais le gradient au quotidien est si faible que cela ne vous a pas frappé. Le même syndrome peut toucher votre projet. On peut insidieusement passer de "Ah, attention, on a laissé passer dans le panier une story sans test de recette" à "Ah, cool, on a de nouveau dans le panier une story avec test de recette". Méfiez-vous du quotidien et de son gradient de changement faible.

Nous avons ainsi appris à être particulièrement attentif au phénomène d'inertie méthodologique illustré ci-dessus. En Agile, on privilégiera les individus et leurs interactions plutôt que les processus et les outils, créant ainsi une méthode propre à chaque équipe, reflétant la meilleure organisation trouvée à un moment donné. On pourrait ainsi croire qu’une bonne organisation trouvée un jour est une bonne organisation pour toujours. Mais nous ne travaillons pas en vase clos et nos équipes rencontrent des forces extérieures en permanence, des plus évidentes comme la pression de la livraison aux plus subtiles comme les interruptions d’un coéquipier. Ainsi, une organisation n’aura pas tendance à persévérer dans son état d’excellence, mais sera dégradée par les aléas du système dans lequel elle évolue.

De la même manière, un projet logiciel va voir s'accumuler la dette technique. Elle représente grosso modo la quantité de malfaçon introduite au cours du développement. Du code source bien testé, bien conçu, mutualisé, est un terrain de jeu très agréable pour une équipe ; cependant, après cents itérations, le temps et les circonstances ont fait leur office et la qualité du code se révèle très inégale. L’entropie d’un système a une tendance naturelle et irréversible à l’augmentation et l’effort à fournir pour réordonner est toujours plus important que l’effort fourni pour désordonner. Prenons garde alors à ne pas tomber en faillite technique, quand plus rien ne pourra le sauver à part un investissement démesuré.

A l'inverse, autant le code aura tendance à se dégrader en vivant, autant la documentation, elle, se déconnectera de toute réalité au fur à mesure qu'elle commencera à rouiller dans un coin. Le point crucial et critique de la documentation est qu'elle est à la croisée des deux mondes : le métier et la technique. Elle est le lien entre le besoin exprimé et la fonctionnalité réalisée : description des cas d'utilisation et des choix d'implémentation. A défaut, nous nous reposons sur l'Historien du projet, qui est là depuis suffisamment longtemps pour connaitre ces détails, ou transmettre les connaissances acquises auprès de ses aïeux, cette fameuse tradition orale transmise de génération en génération... Dans les cas extrêmes, nous devrons nous mettre à une discipline risquée et couteuse : l'archéologie fonctionnelle, sorte de rétro-ingénierie sur code open-source, activité très efficace, mais loin d'être efficiente.

Des actions de mitigation poussées dans leurs derniers retranchements

Paradoxalement, les méthodes agiles louent le gradient de changement faible. Ne pronons-nous pas la livraison de valeur en continu plutôt que les tunnels de développement ? Ou encore la conception émergente plutôt que le Big Design Up Front ? Ainsi, l'Agile tire parti du côté lumineux du gradient de changement faible et vient avec ses rituels et son adaptabilité, l'équipe avec son professionnalisme et ses bonnes pratiques.

Afin d'enrayer l'inertie méthodologique, on se reposera principalement sur la rétrospective d'itération. Moment d'introspection et de prise de recul, il permet à l'équipe de sortir périodiquement du quotidien afin d'échanger autour de son mode de fonctionnement. La rétrospective a la vertu d'adresser tous les aspects du travail en équipe. Elles ont été par exemple le déclencheur d'une dizaine de revue de notre kanban sur les douze derniers mois (colonnes, limites d'encours, definitions of done...) pour tenter de résoudre des douleurs touchant aussi bien la qualité de la documentation que la prédictibilité de nos développements. Une fois les rétros ritualisées, l'équipe est capable à chaque itération d'évaluer les effets des actions initiées, capitaliser, trouver d'autres axes de progression... Bref, instaurer une véritable démarche d'amélioration continue. Tant que les rétros ne sont pas elle-mêmes embarquées par l'inertie.

Pour éviter le problème de la faillite technique, de nombreuses pratiques entrent en jeu : TDD, qui assurera entre autre un harnais de tests confortable pour les futurs développements, ou encore la revue de code systématique par un pair, qui donnera autant d'importance à la qualité d'implémentation qu'à la validité fonctionnelle. Ces pratiques évitent l'accumulation de plus de dettes mais n'en éradiquent pas nécessairement. Pour cela, nous pouvons compter sur la Boy Scout Rule de ce cher Uncle Bob Martin, discipline consistant à toujours laisser un endroit plus propre que l'état dans lequel on l'a trouvé. D'une variable renommée à un refactoring pour mieux séparer les responsabilités de deux classes, prenez garde à la portée du chantier engagé pour ne pas mettre en péril la livraison de la fonctionnalité elle-même.

Pour terminer par la documentation, sa tendance à la dispersion est un frein sérieux à sa transmission. Bien évidemment, une grande partie de la documentation est issue des phases de cadrage préliminaire qui établissent le fonctionnement global du sous-système spécifié. Mais le diable est dans les détails, et ces détails se retrouvent souvent et malheureusement dans des échanges par courriel ou téléphone, sans que l'on ait la rigueur de les répercuter finalement dans la doc. Sur cet aspect, peu de pratiques expérimentées ont trouvé grâce à nos yeux. Mais sur la question même de l'archéologie fonctionnelle, nous retiendrons le pouvoir de la messagerie instantanée. Sur un périmètre existant mal ou non documenté, demandez des précisions par Gtalk (ou autre) à l'Historien et copiez/coller les réponses dans votre outil de capitalisation. Poser une question par e-mail demande un effort rédactionnel plus important qui peut freiner l'interlocuteur, et une conversation de vive-voix s'envolera comme toute parole. Peut-être n'obtiendrez-vous pas un premier jet bien structuré, mais au moins vous aurez les informations et les mots-clés seront présents et remontés par le moteur de recherche de votre wiki.

La rotation d'équipe, levier dangereux mais puissant

Ces actions au fil de l'eau sont absolument essentielles à la pérennité de votre produit logiciel mais sur une longue période, ils atteindront leurs limites. Le côté obscur prendra discrètement le dessus, et nous avons constaté que l'entrée d'un nouveau protagoniste renverse rapidement la tendance. Les bienfaits de la rotation d'équipe compensent largement les risques liés à son gradient de changement élevé.

Ils ne savaient pas que c'était impossible, alors ils l'ont fait, Mark Twain.

"Ils", ce sont les nouveaux coéquipiers sur un projet. Leur regard neuf sur nos pratiques établies est d'une grande richesse et nous aidera à mitiger les risques identifiés ci-dessus.

Tous les postes sont concernés :

• un nouveau Tech Lead prendra à bras le corps les axes de désendettement et trouvera de nouveaux plans d'action pour les adresser ;
• un nouveau Dev fera parler l'Historien et retranscrira ces informations dans l'outil de capitalisation ;
• un nouvel AMOA remettra en question la relation avec le client, qui avait tendance à devenir trop consensuelle ;
• et de manière générale, tout oeil nouveau apportera son lot de questions et remarques qui feront avancer l'équipe.

Mais la rotation fait peur. La rotation est synonyme de perte de connaissances. La rotation entraîne des changements plus forts que les rétrospectives. Faire rentrer un nouveau développeur a toujours bouleversé notre vélocité, voire complètement revu notre manière de chiffrer. Cela a bien évidemment un impact sur vos engagements et la visibilité que vous offrez à votre client, mais c'est une période transitoire qui peut être grandement limitée dans le temps et l'ampleur.

Pour ce faire, il faut qu'elle soit préparée et outillée. Il est impensable, même avec la meilleure documentation du monde, de penser à faire une rotation efficace d'un même poste sans chevauchement du futur sortant et du nouvel entrant. Remarquez d'ailleurs que la rotation ne se prépare pas que pour le jour J, mais également au quotidien. Assurer notamment le Collective Code Ownership est une des conditions sine qua non pour sécuriser le départ d'un coéquipier, et ceci se traduit dans notre équipe par du binômage opportuniste et de la revue croisée systématique.

La rotation est si bénéfique que nous envisageons d'en expérimenter la ritualisation sur ce projet : tous les six mois, une ou deux nouvelles têtes entrent sur le projet. Il est ainsi facile de les préparer au mieux, comme trouver en temps et en heure le bon remplaçant et assurer la collision des agendas des personnes concernées. Ce rythme nous permettra également d'industrialiser la montée en compétences, aidant du même coup l'adaptation de l'équipe à un départ fortuit (dont on n'est jamais à l'abri).

Après l'Agile à large échelle et l'Agile offshore, l'Agile au long cours apporte son lot d'expériences et d'enseignements. La rotation d'équipe en est un exemple très puissant, permettant de vaincre sur le long terme le côté obscur du gradient de changement faible du quotidien.