En tant que coach agile, une des questions que l'on me pose souvent est : "Nous avons mis en place l'agilité, mais pourquoi est-ce que ça n'a pas fonctionné ?".
Les personnes qui me posent cette question sont vraiment perplexes. J'ai rencontré des équipes qui se sont données beaucoup de mal pour se réorganiser, répartir différemment les responsabilités, et redéfinir les processus ; et pourtant elles étaient consternées de voir que leur productivité et leur moral étaient encore plus bas qu'avant.
Chaque organisation a des dysfonctionnements spécifiques. En tant que coach, je dois m'immerger profondément dans les équipes, et les observer de près pour comprendre comment elles fonctionnent. Mais, malgré leur caractère unique, les mêmes schémas émergent souvent. Dans presque tous les cas, ces équipes ont décidé d'adopter l'Agile parce qu'elles rencontraient des difficultés concrètes, comme une faible productivité ou qualité, et elles espéraient que l'Agile ferait miraculeusement remonter ces indicateurs. Ce que ces équipes ne réalisaient pas, c'est que l'Agile est une approche systémique pour gérer le logiciel. Elle est au service d'objectifs de hauts niveaux, tels que "satisfaire les clients en répondant à leurs besoins changeants". Les managers sont généralement exaltés par de telles ambitions, et ils sont pressés de prendre le train de l'Agile en marche. Le problème avec l'agilité, c'est que son adoption cause bien des tracas : les daily meetings, les sprints planning, les rétrospectives. Au premier coup d'oeil, la vue d'un groupe de gens tournant autour d'un tableau blanc peut laisser penser aux managers novices que la chose a fonctionné ; mais ce qu'ils ne réalisent pas est que sans soutien managérial et technique significatif, l'agilité ne survivra pas. Pire encore, que les équipes se mettront à haïr ces tracas et à espérer que les choses redeviennent comme avant.
Problèmes de Management
Une des équipes avec laquelle j'ai travaillé cette année est tombée dans le piège décrit ci-dessus. C'était une grosse équipe, divisée en 7 équipes scrum. Vous pouvez imaginer à quel point le bureau était bruyant chaque matin, avec les "scrum meetings" qui démarraient presque tous en même temps, et une réunion "scrum de scrum" juste après. Le management était ravi ; après tout, ils avaient payé fort cher pour qu'un coach mette en place l'Agile.
Les choses tournèrent mal assez tôt. J'ai assisté aux "scrum meetings" des équipes pendant des semaines et remarqué en particulier que la même équipe se trouvait systématiquement bloquée par le même problème technique pendant plusieurs jours. L'équipe ne pouvait pas avancer, donc elle se mettait à travailler sur quelque chose d'autre à la place ; avec pour résultat beaucoup de code inachevé qui ne pouvait être ni testé ni démontré.
En Agile, le scrum master est supposé ôter les obstacles. Quand on lui posait la question, le scrum master était plutôt frustré. Il disait que seules deux personnes dans l'équipe étaient capable de comprendre les détails techniques pertinents, mais qu'elles ne faisaient pas partie de son équipe scrum. Leur manager leur avait demandé de travailler sur une autre fonctionnalité.
Voici des problèmes classiques dans les équipes de développement logiciel :
- L'agilité préconise que tout le monde puisse se saisir d'une tâche quelconque du backlog. Mais, en réalité, d'obscures technologies ne sont comprises que de deux personnes. C'est difficile de motiver les autres pour qu'ils se familiarisent avec lesdites technologies, surtout quand elles sont obsolètes. Et même quand les gens sont motivés, quand ils font face au backlog, c'est difficile de résister à la tentation de se jeter sur quelque chose d'autre, pour donner plus clairement l'impression que le backlog diminue de volume.
- Le scrum master agile est censé déplacer des montagnes pour aider l'équipe à avancer sans être dérangée. En réalité, le scrum master manque de pouvoir pour faire cela. Ce pouvoir est généralement entre les mains de managers, et comme nous le savons tous, le pouvoir est addictif et il est difficile de s'en dessaisir. En pratique, je ne pousse pas les organisations à modifier les rôles des managers si cela doit induire une résistance de leur part. Si un manager remplit les pré requis pour être scrum master, il peut prendre quelques-unes des responsabilités d'un scrum master : un manager a généralement plus l'expérience de l'acquisition de ressources et de la gestion des conflits, surtout quand ils impliquent des tiers.
Mais cette équipe avait de plus gros soucis. Le responsable d'équipe a débuté de son côté une fonctionnalité séparée et privée - aucune équipe scrum n'y était affectée, et je ne pouvais pas établir son état d'avancement. En sondant un peu plus loin, j'ai découvert que l'équipe R&D et le responsable produit ne se faisaient pas confiance ; l'équipe du responsable produit avait "ordonné" à l'équipe R&D de faire certaines choses, mais l'équipe R&D avait réservé des ressources pour travailler sur un autre sujet qu'elle considérait plus important.
Je me suis assise avec l'équipe de management R&D, et j'ai tracé un diagramme cause-effet sur le tableau blanc :
(Cliquez sur l'image pour l'agrandir)
Le diagramme cause-effet est un outil puissant. Alors que les managers se plaignaient d'un manque d'effets de l'Agile, le diagramme montrait que les causes premières étaient ailleurs et plus profondes. Le diagramme faisait également ressortir des boucles, qui montraient que, si les causes premières n'étaient pas traitées, un cercle vicieux allait se poursuivre.
Problèmes Techniques
Cette équipe bénéficiait d'un soutien entier du management, mais pourtant, tout ne se passait pas bien. En particulier, l'intégration continue échouait tout le temps. L'équipe avait mis en place un grand écran qui affichait l'état de l'intégration, juste devant le bureau afin que tout le monde puisse le voir en entrant et en sortant. L'écran était vert en moyenne 1 à 2 heures par jour. Ceci retardait bien sûr fortement l'équipe. Une règle prescrivait que le code ne pouvait être commité que si l'écran était vert, mais étant donné que cela échouait si souvent, certaines personnes se contentaient juste de glisser leur code [dans le dépôt (NDLR)].
Nous aimons à penser que le développement logiciel est très différent de l'industrie classique, parce que le développement logiciel est plus "cérébral", alors que les ouvriers dans l'industrie traditionnelle se contentent de serrer leurs boulons (ce qui rappelle Les temps modernes de Charlie Chaplin). En réalité, le développement logiciel a aussi sa chaîne de production, sauf qu'elle incorpore beaucoup d'itérations, qui servent à améliorer la qualité du logiciel. Mais, tout comme une chaîne de production d'usine, si une étape ralentit, les choses vont s'empiler et la production entière ralentit.
Pour cette équipe, la chaîne de production au niveau des fonctionnalités ressemble à ceci :
(Cliquez sur l'image pour l'agrandir)
Cette ligne d'assemblage présente de nombreuses boucles de rétroaction. Plus courte est la boucle, plus le coût de correction des erreurs est faible. La boucle de rétroaction depuis "démo" vers les étapes "exigences" et "code" sont trop longues ; idéalement, la rétroaction doit partir de l'étape "développement et tests unitaires". Néanmoins, il restera toujours des anomalies, donc on s'appuie sur les tests automatisés et la recette (QA) pour fournir la rétroaction. Sauf que dans cette équipe, le processus "build-déploiement-automatisation" avait de sérieux soucis, qui plus est, aggravé par le fait que certaines personnes ignoraient la règle en déposant quand même du code, bouchant ainsi encore plus la chaîne de production.
J'ai expliqué clairement à l'équipe le concept de chaîne de production, et ils ont rapidement apporté des solutions pour l'assouplir, telles que renforcer la revue de code et garantir la règle de commit de code validé. Pour autant, sur le sujet des tests automatisés, les opinions divergeaient. Certaines personnes croyaient que ces tests étaient totalement impossibles à maintenir : le code avait été écrit pas des prestataires partis depuis longtemps, et on passait plus de temps à corriger des anomalies dans le code de test qu'à corriger des anomalies trouvées par le code de test. D'autres disaient que même si l'outil de test était de mauvaise qualité, c'était mieux que rien, et que le coût de sa réécriture dépassait les capacités de l'équipe de QA.
J'ai demandé à l'équipe de faire un rapide calcul pour évaluer les mérites des tests automatisés.
Il s'avéra que certains tests automatisés étaient plutôt bons, spécialement certains tests unitaires et de composants, mais le résultat des tests d'IHM de bout en bout était catastrophique. La conclusion était claire : il n'y avait aucun intérêt à investir autant d'effort à travailler sur quelque chose qui présentait si peu de valeur ajoutée.
J'ai aussi fait remarquer qu'écrire et maintenir des tests automatisés ne relevait pas uniquement de la responsabilité de la QA. Les tests utilisateurs de bout en bout dépendent complètement du code en production. Dans une architecture orientée service, les services disposent d'APIs bien définies et souvent négociées, si un service veut effectuer une modification de ses APIs, il notifie (ou devrait notifier) ses services dépendants, afin qu'ils puissent faire les modifications correspondantes. Le code de test des IHM est totalement dépendant du code de production : si quelque chose tel que l'identifiant ou le nom d'un composant d'IHM change dans le code de production, les tests d'IHM peuvent échouer.
Pour rendre les tests automatisés robustes et flexibles, le framework d'automatisation doit être bien conçu. Louer les services de prestataires n'est pas la solution pour s'assurer de cela, et demander aux QA d'écrire une architecture de tests automatisée n'est probablement pas bon non plus, en fonction des compétences techniques et du type de QA disponibles. Dans cette équipe, il était évident que la plupart des ingénieurs QA étaient des testeurs fonctionnels et ne possédaient pas les compétences d'architecture avancée nécessaires pour concevoir un tel framework.
Il fut donc décidé que des leaders techniques de l'équipe de développement écriraient le framework d'automatisation, et que les développeurs et les testeurs écriraient et maintiendraient ensemble les tests d'IHM automatisés. Cet accord incluait des règles telles que l'interdiction pour les développeurs de changer les identifiants ou les noms d'éléments d'IHM sans prévenir.
Vous pourriez penser que tout cela s'est produit au cours d'une unique réunion un peu animée ; en réalité il a fallu beaucoup de soutien du management pour rendre cela possible, et il a fallu près de trois mois pour écrire un framework d'automatisation qui soit rapide, stable et permettant d'écrire aisément des tests - c'est comme ça que les problèmes de la vraie vie sont résolus !
l'Agile est une approche systématique pour gérer le logiciel
Il faut revenir aux sources pour trouver l'essence de l'agilité. En 2001, 17 gourous du logiciel ont créé le manifeste agile, qui en lui-même ne prescrit pas ce qu'il faut faire :
Les individus et les interactions plutôt que les processus ou les outils
Du logiciel qui marche plutôt qu'une documentation complète
La coopération avec le client plutôt que la négociation du contrat
Répondre au changement plutôt que suivre un plan
Ils ont également produit une liste de 12 principes, peu d'entre eux prescrivent quoi faire (par exemple, transmettre de l’information via un dialogue face-à-face, et faire travailler ensemble commanditaires, développeurs et utilisateurs), mais la plupart sont plus une affaire d'état d'esprit. Et si nous analysons de près ces 12 principes, nous pouvons voir qu'ils forment une pyramide :
(Cliquez sur l'image pour l'agrandir)
Au sommet se trouve l'objectif ambitieux de "satisfaire les clients en répondant à leurs besoins changeants". Cet objectif est atteint "en livrant rapidement et régulièrement du logiciel qui marche". Livrer du logiciel qui marche, néanmoins, nécessite un soutien technique et managérial significatif. S'assurer que les changements d'exigences ne cassent pas le système est avant tout un problème technique : comment concevoir le système d'une manière flexible et comment créer des tests automatisés qui assurent que les changements ne cassent rien. Pour favoriser des compétences techniques avancées au sein des équipes, il faut que ces équipes soient motivées d'apprendre de leurs erreurs et de s'améliorer elles-mêmes.
(En passant, je choisis d'interpréter la simplicité évoquée dans le principe n°10 comme le faisait Steve Jobs, pour insister sur l'importance de la maniabilité : "Simple peut être plus difficile que complexe : il faut travailler dur pour rendre votre pensée assez propre pour faire simple").
La transition vers l'agilité n'est pas un voyage de tout repos. Si cela ne fonctionne pas, regardez de plus près. Cela dévoile peut-être des problèmes de fond dans votre équipe. Regardez le tableau de l'équipe, trouvez ce qui la ralentit, utilisez des outils du lean tels que le diagramme cause-effet et les cinq pourquoi afin d'arriver aux causes premières, réglez-les et vous récolterez les pleins bénéfices de l'agilité.
A propos de l'Auteure
Chen Ping vit à Shanghai, en Chine, et est titulaire d'un Master en sciences de l'information depuis 2005. Depuis, elle a travaillé pour Lucent et Morgan Stanley. Actuellement, elle est responsable commercial et développement chez HP. En dehors du travail, elle aime étudier la médecine chinoise. Elle tient un blog ici.