Eh bien, avez-vous déjà eu votre stand-up quotidien, votre rétro, votre réunion des parties prenantes ou votre session de raffinement de projet aujourd’hui ? Alors vous faites probablement partie de ceux qui ont bénéficié d’une « transformation agile » dans l’entreprise. On pourrait penser que cela ne vaut plus la peine d’être mentionné de nos jours, car toutes les entreprises sont ou ont été agiles d’une manière ou d’une autre depuis des années.
Martin Gerhard Loschwitz est journaliste indépendant et travaille régulièrement sur des sujets tels que OpenStack, Kubernetes et Ceph.
Cependant, il y a un énorme hic caché dans ce « en quelque sorte » – car dans de nombreux endroits, les transformations agiles deviennent rapidement un martyre, menées sans rime ni raison, mais avec toute la violence et sans résultats significatifs. Tout ce qui reste de l’idée autrefois noble est un marathon de réunions apparemment sans fin, ce qui rend pratiquement impossible un travail efficace et axé sur les objectifs.
Les principes agiles sont bons
Pour être clair : le problème n’est en aucun cas les principes du travail agile, comme les responsables aiment à le prétendre après de nombreuses tentatives infructueuses d’introduction. Les idées de base du travail agile, telles que celles codifiées dans le Manifeste Agile, sont efficaces et très utiles selon l’état actuel de la science. Les découvertes actuelles en sociologie montrent, par exemple, qu’elles sont parfaitement adaptées pour rendre le travail d’équipe orienté vers le client.
Et ce n’est pas comme si les auteurs du Manifeste Agile tiraient leurs conclusions de nulle part. Au contraire, des approches similaires étaient déjà utilisées dans de nombreuses entreprises alors que l’informatique n’existait même pas sous sa forme actuelle. Le constructeur automobile au succès mondial Toyota en est un excellent exemple.
La réalisation est terrible
Au lieu de cela, dans la majorité absolue des cas, les entreprises elles-mêmes et leur approche sont responsables de l’échec des méthodes agiles. Vous n’avez généralement pas besoin de chercher bien loin les raisons des échecs de capital : cela commence souvent par le fait que la direction de l’entreprise décide d’introduire un certain modèle agile au-dessus de la tête de la main-d’œuvre, de sorte que leur « adhésion » fait défaut. .
Unforgotten est la vidéo Spotify sur les tribus et les chapitres et pipapo, qui a atteint une renommée douteuse, qui a été présentée dans un style pop et a propagé un certain modèle de travail avec des mots concis. Les patrons de tout le pays ont tourmenté leur peuple avec cette même vidéo, jusqu’à ce que Spotify lui-même précise que ce n’était qu’une idée. Chez Spotify, cependant, cela n’a même pas été mis en œuvre en raison de problèmes conceptuels. À ce jour, il n’existe aucune enquête fiable sur le nombre d’entreprises qui sont encore aux prises avec ce modèle, que même son propre inventeur n’a pas trouvé viable.
Pour eux-mêmes, les patrons définissent souvent des exceptions encore et encore : alors que les niveaux inférieurs de l’entreprise sont plongés dans le chaos, tout au C-Level continue de fonctionner comme avant. Cela commence par la frontière GF sur le tableau de planification et s’étend jusqu’au déni complet des idées que les groupes de travail agiles obtiennent concernant le niveau C d’une entreprise. Bon sang, ce sont les autres après tout !
Ailleurs, l’introduction des méthodes de travail agiles échoue faute de bons formateurs expérimentés pour Scrum, Kanban et les différentes formes mixtes. Dans une procédure de solution rapide, les personnes qui se sont portées volontaires sont généralement placées dans des cours appropriés, remplies de connaissances et sont ensuite censées faire avancer la transformation agile dans l’entreprise.
Même si ces personnes deviennent d’excellents entraîneurs en peu de temps, elles mènent généralement une bataille perdue d’avance. D’une part, il faut du temps pour comprendre et transmettre les bases agiles et celles de la méthode choisie. C’est d’autant plus vrai lorsqu’une partie du « convoyage » est aussi « convaincante », car les personnes concernées ne se sentent pas complètement impliquées dans la mise en place d’un concept agile. Et d’autre part, les mêmes managers qui exigent des méthodes de travail agiles s’attendent régulièrement à des résultats clairement positifs immédiatement après le début d’un pilote agile. Si ceux-ci ne sont pas visibles dans quelques semaines ou mois, une nervosité notable éclate, ce qui conduit souvent à l’abandon de toute l’approche agile. Soudain, « cascade » s’applique à nouveau avec « été rien d’autre que des dépenses ».
Ce qui est particulièrement bizarre, c’est que dans de nombreux endroits, la direction ne se rend même pas compte que les projets agiles peuvent avoir des mesures de réussite différentes de celles de l’approche en cascade – et nécessitent des conditions préalables différentes pour réussir. Quiconque juge le mal et le mal de la transformation agile avec les KPI de staff, line et waterfall n’est au pire pas en mesure de reconnaître et d’évaluer les succès obtenus a priori. Néanmoins, de tels projets sont rapidement considérés comme « peu performants », voire échoués.
C’est effrayant de courir : si vous hissez les voiles sur un voilier et recourez plutôt au petit moteur diesel – aucune personne sensée ne penserait jamais à utiliser le stock de diesel en baisse dans le réservoir comme preuve que la voile n’est pas du tout pourrait fonctionner . Or, c’est exactement ce qui se passe dans de nombreuses entreprises lors de l’évaluation des résultats des transformations agiles.
La folie des rencontres
Cependant, les effets les plus dangereux sont sans aucun doute les projets agiles qui meurent à mi-parcours sans que personne ne s’en aperçoive. Il y a plusieurs raisons à cela : les entreprises, par exemple, ne sont souvent pas assez prudentes lors de la sélection de leurs propres équipes auxquelles les méthodes de développement agiles classiques telles que Scrum ou Kanban peuvent être appliquées. L’infrastructure, par exemple, est extrêmement difficile à exploiter de manière agile. Un commutateur qui n’est pas dans le rack ne peut pas être alimenté avec une configuration, peu importe à quel point le plan de sprint l’exige. Ici, la cascade classique offre souvent des résultats encore meilleurs.
Une autre raison des transformations agiles à moitié mortes est le manque de rigueur banal lors de l’utilisation des outils de la méthode agile choisie. Les outils qui ont vraiment du sens, comme les rétros, ont tendance à devenir un club de débat général parce que personne ne fait attention au respect des délais fixés. La réunion debout dans Scrum, qui sert en fait à aligner les tâches de la journée de manière significative, devient plutôt un récapitulatif du travail effectué la veille. Et assez souvent aussi au club de débat, car personne n’applique les règles qui s’appliquent réellement. Des outils tels que les tableaux Scrum ou Kanban finissent par devenir de facto une corbeille à papier, car à un moment donné, les morceaux de papier individuels qu’ils contiennent n’ont tout simplement plus aucune pertinence pratique et il n’y a plus d’ordre discernable.
Reste une folie absurde de réunions faites de quotidiens et de rétros et de réunions d’acteurs et d’un certain nombre d’autres types de réunions qui ne laissent guère de temps pour un travail productif. Mais finalement, et c’est bien le problème, il n’est pas plus performant que le modèle précédent.
Tout ou rien
Toute personne qui se retrouve dans une ou plusieurs des situations décrites doit s’arrêter maintenant et se demander comment le problème peut être géré. Les entreprises doivent apprendre que la transformation agile prend du temps au lieu d’abattre des projets agiles hyperactifs car ils n’ont pas conduit au doublement d’efficacité souhaité au bout de quelques semaines. Ceux qui utilisent des méthodes agiles sont bien avisés de s’en tenir à leurs règles. Aussi tentant soit-il du point de vue des ingénieurs : les discussions techniques approfondies n’ont pas leur place dans le quotidien, mais dans des rendez-vous individuels prévus à cet effet. Les entreprises sont là aussi interpellées, car les coachs agiles ne peuvent être retirés des projets qu’une fois que les règles données y ont été internalisées. Jusque-là, leurs conseils sont précieux et essentiels au succès de l’entreprise.
De plus, il n’y a pas de honte à bannir Scrum, Kanban & Co. d’une entreprise si leur introduction n’a tout simplement pas de sens. Pour ce faire, il est toutefois nécessaire de surveiller les processus en cours et d’intervenir si nécessaire. Et si oui, s’il vous plaît, faites bien les choses : personne n’est aidé par d’innombrables réunions qui ne permettent pas de gagner en connaissances ou en efficacité et qui auraient tout aussi bien pu être un e-mail ou une page wiki bien conçue. Agile? Oui avec plaisir ! Mais : avec du bon sens, avec raison, et surtout avec un bon plan.
(fo)