« Désolé, mais l'Agile n'améliore pas vos produits »
Nous avons déjà publié l'article de blog de Jeff Sutherland, dans lequel il réagit à un post d'Adam Pisoni affirmant que l'Agile n'améliore pas vraiment vos produits. Voici maintenant ce fameux article d'Adam Pisoni, cofondateur et ancien directeur technique de Yammer, et fondateur de Responsive.org.
Si tu ne lis pas régulièrement les travaux de Steve Denning, je te recommande de le faire. C'est l'un des meilleurs auteurs sur l'avenir du travail. Dans un article qu'il a écrit pour Forbes, il affirme que le développement produit agile est devenu mainstream, mais il pose également la question de savoir si c'est désormais devenu une mode passagère comme tant d'autres théories de management. Sa conclusion est que l'Agile n'est pas vraiment une mode, car
« Agile et Scrum abordent directement les problématiques actuelles des entreprises que les initiatives du 20e siècle ont évitées. Avec Agile et Scrum, les clients obtiennent une voix grâce au Product Owner et les compétences sont placées au-dessus de l'autorité. »
Bien que je sois fondamentalement d'accord avec beaucoup de choses dans son article, je dois contester sa conclusion. Agile a effectivement fait un bon pas dans la bonne direction, mais cela ne va pas assez loin pour moi. Avant l'existence d'Agile, il arrivait bien trop souvent que les équipes aient besoin d'énormément de temps et de ressources pour construire quelque chose, pour découvrir au moment de la livraison que le client n'en voulait pas du tout.
Agile devait avant tout permettre de construire des produits réussis dans un monde qui évolue trop vite pour pouvoir prédire ce que les gens veulent et comment le construire au mieux pour eux.
Bien qu'Agile ait enseigné à toute une génération de développeurs logiciels l'importance de l'expérimentation et du feedback client, Agile n'a pas réussi à changer l'ancien système de management centralisé de type Command-and-Control, ce qui représente une grande partie du problème. Même avec Agile, les développeurs qui ont trop peu d'influence et trop peu de contexte mettent beaucoup trop de temps à développer des produits que les clients ne veulent en fait pas du tout. Cela a pour conséquence des clients insatisfaits, des développeurs démotivés et des managers frustrés.
Pour information, de 1995 à 2014, j'ai toujours été – à l'exception d'une courte interruption après l'éclatement de la première bulle Internet – soit développeur logiciel à temps plein, soit chef d'équipe de développement. En 1997, je dirigeais une équipe qui utilisait la méthode en cascade (prédécesseur d'Agile). Avec la méthode en cascade, on faisait tout le travail de conception et de planification en amont et on partait du principe qu'on pourrait ensuite répartir et terminer le travail.
En 2004, je travaillais pour une entreprise qui misait fortement sur l'analyse et les tests A/B et avait même des releases hebdomadaires – avec tout cela, elle était en avance sur son temps. Je me souviens quand les gens ont parlé de Scrum pour la première fois, et je me souviens que j'avais une idée claire du problème que j'essayais de résoudre : le mauvais management.
Pour être honnête, j'ai relu le Manifeste Agile et ses principes et je suis d'accord avec chaque point. Ils sont encore aussi bons et pertinents aujourd'hui qu'ils l'étaient en 2001, quand ils ont été écrits. En Agile, on devrait construire quelque chose de manière itérative et apprendre continuellement en cours de route, au lieu de suivre un grand plan. De plus, le client devrait être un partenaire proche tout au long du processus, afin qu'on puisse apprendre de lui pendant toute la phase de développement. Comme l'objectif devrait être d'absorber en permanence de nouvelles informations, on devrait aussi s'attendre à changer régulièrement de direction.
Avant Agile, le management créait un plan qui documentait précisément (prédisait) ce qui devait être construit, comment cela devait être construit et combien de temps cela prendrait – ce dernier point étant probablement la partie la plus importante. Comme nous le savons, ces plans étaient difficilement prévisibles et pouvaient rarement être respectés. Le résultat était des attentes et des délais irréalistes.
Pour couronner le tout, en raison du décalage temporel entre la finalisation du plan et la livraison du produit, il était très probable que le management change encore d'avis sur le produit sans aucune compréhension des coûts. Cela agaçait naturellement beaucoup de développeurs, dont le travail était d'exécuter le « plan ». Cela signifiait que la situation avec des délais irréalistes ne faisait qu'empirer et forçait de nombreuses équipes à minimiser les changements ultérieurs par encore plus de planification. Ironiquement, le manque de transparence dans le processus de développement donnait aux équipes de développement plus d'autonomie pour décider dans quel ordre elles effectueraient le travail, comment elles le construiraient, qui le ferait, etc. Naturellement, la conséquence de ce type d'autonomie et du manque de transparence est souvent la méfiance entre le management et l'équipe de développement. Au final, personne n'était content.
Et puis SCRUM est arrivé. Il devait augmenter la transparence dans le processus et améliorer l'efficacité du développement. Chaque semaine, les managers pouvaient décider quelles stories (ou features) ils voulaient ensuite et les développeurs pouvaient alors estimer combien de temps et de ressources ils auraient besoin pour cela. L'équipe pouvait alors déterminer le coût total de toutes les stories priorisées et découvrir combien de ce travail elle pouvait s'engager à faire pour le prochain sprint.
Scrum a drastiquement augmenté la transparence et rendu plus difficile pour les managers d'exiger plus que ce qui peut être accompli. Le besoin de mettre à jour les plans de manière itérative a également été pris en compte. Cependant, grâce à la transparence accrue de Scrum, les développeurs ont encore moins d'autonomie qu'auparavant. Les pouvoirs des développeurs ont été réduits à déterminer combien de temps quelque chose prendra probablement et à choisir la prochaine story dans une liste largement définie par le management.
Un développeur travaillant sur une story peut ne pas avoir la moindre idée des liens et de la raison pour laquelle cette story est si importante ou quelle est l'initiative derrière.
Même si Scrum a réussi à freiner les managers impulsifs, au final, il s'agissait quand même d'exercer plus de contrôle sur les développeurs et leur travail.
Le management prend toujours les décisions, priorise les features et détermine qui travaille sur quoi dans quelle équipe. Avec son focus sur l'estimation de l'effort du travail prescrit et peu de contexte, Scrum regarde vers le tournant du siècle, où Frederick Taylor donnait des instructions détaillées aux ouvriers d'usine.
Dans le taylorisme, on part du principe que les managers sont ceux qui disposent de l'expertise et du contexte pour pouvoir prescrire ce sur quoi on devrait travailler. C'est pourquoi c'était leur tâche de donner aux employés des plans détaillés, afin qu'ils aient à prendre le moins de décisions propres possible.
Assez vers la fin des Principes Agiles apparaît un principe plutôt déplacé qui est ignoré par Scrum :
Les meilleures architectures, exigences et conceptions proviennent d'équipes auto-organisées.
Théoriquement, il est possible d'utiliser Scrum pour le suivi du travail dans des équipes auto-organisées, mais ce n'est pas prévu à cet effet et cela se produit très rarement. La plupart des livres sur Scrum abordent le sujet du point de vue du management descendant et non de l'auto-organisation.
Agile a été une étape importante pour reconnaître l'importance des tests et du travail itératif basé sur les retours clients. Cependant, il est en grande partie orienté vers une efficacité accrue et le contrôle plutôt que l'empowerment ou les équipes auto-organisées. L'un des auteurs du Manifeste Agile, Andy Hunt, partage cet avis.
Bien sûr, on peut affirmer que le problème n'est pas Agile, mais des méthodes comme Scrum. Cependant, cette nuance subtile se perd, car Scrum et Agile sont devenus presque synonymes. Lorsque Agile est devenu plus connu, il a malheureusement été détourné par les modèles traditionnels de Command-and-Control, ce qui a donné naissance à des méthodes comme Scrum.
Quelle est l'alternative ? Jetez un œil aux méthodes de développement de Spotify ou aux structures de Yammer. Au lieu de surcharger des individus de travail, donnez aux équipes plus d'autonomie pour décider ce qu'elles veulent construire et comment. Ces équipes sont également composées de personnes issues de disciplines très différentes, afin de s'assurer qu'elles peuvent accomplir tout ce qui est nécessaire sans avoir à attendre la permission ou le soutien des autres.
Que tu travailles actuellement avec Scrum dans ton organisation ou non – si tu as l'impression d'avancer trop lentement et de ne pas construire ce que tes clients veulent, il existe différentes possibilités d'expérimenter de nouveaux modèles sans avoir à tout changer d'un coup.
Choisis un projet et constitue une petite équipe engagée avec des personnes qui possèdent toutes les compétences nécessaires, même si ces personnes ont des managers différents. Présente-leur le problème et donne-leur la possibilité de le résoudre comme elles le jugent approprié.
Idéalement, ce projet est assez court pour pouvoir déterminer rapidement si l'expérience fonctionne. Si tu hésites à confier cette responsabilité à l'équipe, tu as soit choisi les mauvaises personnes, soit le problème vient peut-être de toi-même. Appeler cela une « expérience » peut t'aider à vendre ton idée. Tu découvriras très probablement que de petites équipes d'experts engagées et pluridisciplinaires peuvent accomplir énormément en très peu de temps.
Le prochain défi est de trouver comment transposer cela à plus grande échelle, si ça fonctionne. Cela nécessite généralement de nouvelles solutions, ce qui mène à de nouveaux problèmes, pour lesquels on a besoin de nouvelles solutions. Ce n'est pas facile, mais ça en vaut la peine.
Vous remarquerez que ça fonctionne quand votre équipe pourra présenter plus de nouvelles idées aux clients plus rapidement qu'avant. C'est l'objectif.
L'autonomie nécessite de la confiance, et celle-ci nécessite un contexte partagé. C'est pourquoi ces nouveaux modèles dépendent d'une transparence totale pour que chacun reste informé. Chez Yammer, nous avons des équipes projet éphémères, ce qui donne aux gens plus d'opportunités de travailler concrètement et d'apprendre de personnes très différentes – mais ce n'est qu'une façon d'aborder le sujet.
Il ne suffit pas que le management soit simplement le porte-parole des clients. Les développeurs et designers doivent eux-mêmes comprendre et intérioriser les besoins et objectifs des personnes pour lesquelles ils construisent quelque chose.
Agile a été une étape importante pour s'éloigner des organisations et méthodes de l'ère industrielle. Cependant, si vous voulez créer une organisation pour le 21e siècle, vous devrez regarder au-delà d'Agile vers des modèles plus récents qui distribuent l'autorité, s'auto-organisent et invitent véritablement vos clients, partenaires et collaborateurs à devenir « propriétaires » du processus.
Ce texte provient du [blog de First Round]8https://firstround.com/review/im-sorry-but-agile-wont-fix-your-products/ "Produits Agile") et a été traduit par nos soins en allemand.
Pour les Scrum Masters, nous proposons les formations et opportunités de développement gratuites suivantes :
