Cinq pièges lors de la mise à l'échelle de l'agilité
Les grandes entreprises recherchent particulièrement des moyens rapides et simples pour effectuer la transition du développement classique vers le développement agile. Plus une transition doit se faire rapidement, plus les pièges qui passent inaperçus sont dangereux. Le développement agile repose davantage sur la durabilité que sur le simple fait de terminer vite. C'est pourquoi le management porte une grande responsabilité dans le succès de la transition agile. Une transition qui ne tient pas compte de ces pièges deviendra très probablement un cargo cult. Vue de l'extérieur, la transition semble réussie, mais à l'intérieur, les avantages de la transition ne se matérialisent pas.
Voici cinq pièges courants sur le chemin vers une organisation agile :
1. Agilité fondamentale
Passer aux processus agiles est facile. On dérégule un peu et on envoie quelques personnes en formation. Ensuite, les gens peuvent « faire du Scrum » – ou choisir une autre approche agile. Mais dans l'ensemble, on a peut-être atteint 1% – 99% du chemin reste encore à parcourir. Le voyage est encore long. Au cœur de l'agilité se trouve le processus Inspect+Adapt. Pour qu'il fonctionne, il faut un état d'esprit particulier. Chacun doit remettre en question sans complaisance ce qui se passe – et apporter des changements quand ça va dans la mauvaise direction. Pour ancrer Inspect+Adapt de manière pertinente dans l'organisation, il faut deux choses : D'abord, la façon de travailler existante doit être assainie. Les éléments de la culture d'entreprise qui découragent les développeurs de prendre la responsabilité de leurs processus doivent être éliminés. Pour cela, de nombreux processus Command+Control doivent être abandonnés et le management des développeurs fondamentalement repensé. Le changement n'arrivera que si on le permet ! Ensuite, une façon de travailler saine doit être créée. On a besoin d'un système de management qui encourage les développeurs à assumer la responsabilité de leurs propres actions, décisions, changements, échecs et succès. Pour cela, des structures et des processus doivent être créés qui valorisent honnêtement la contribution individuelle de chacun – que le management soit satisfait de la direction prise ou non. Les gens ne donneront leur contribution que si on les laisse faire !
Tant que les fondations de l'agilité ne sont pas posées, il n'y aura pas d'agilité. Les équipes sans agilité fondamentale ne tireront aucun bénéfice de la mise à l'échelle agile – et n'y contribueront pas non plus.
2. Outils du métier
Introduire les cérémonies de Scrum ne prend qu'une journée, formation et prise de décision comprises. Cela pose les bases du « travail agile ». La planification à court terme, les mises à jour régulières du plan, le feedback produit et l'amélioration incrémentale du processus sont essentiels. Ainsi, les développeurs peuvent découvrir au fil du temps leur façon optimale de travailler. Il faut simplement prévoir beaucoup de temps pour l'optimisation si les pratiques d'ingénierie ne sont pas encore établies. Les développeurs doivent être familiarisés avec des concepts comme le contrôle de version, l'intégration continue, l'automatisation des tests, le design émergent, TDD, BDD, le pairing, les conventions de code – et bien d'autres choses qu'XP a à offrir. Ils doivent décider consciemment quelles pratiques leur sont utiles dans leur contexte actuel. Tant que les développeurs ne connaissent pas ces pratiques, il est tout à fait possible qu'ils soient « rituellement agiles » sans pour autant pratiquer l'agilité. Une équipe sans les bons outils peut même ralentir la mise en œuvre d'un développement à grande échelle.
3. Esprit d'équipe
L'esprit d'équipe, souvent moqué comme ésotérique, est immensément important pour l'amélioration systémique lors de la mise à l'échelle agile. Beaucoup de managers pensent que les objectifs personnels (jusqu'au Stack Ranking) sont utiles pour obtenir des collaborateurs hautement performants. Cependant, la mise à l'échelle agile sert avant tout à construire un système complexe et adaptatif dans lequel de nombreuses personnes apportent leur contribution. La nécessité de contribuer au bien commun est bien plus importante que la contribution à ses propres objectifs. Ici, « esprit d'équipe » signifie que les individus doivent fondamentalement subordonner leurs propres intérêts pour servir la mission de l'entreprise. L'esprit d'équipe ne consiste pas tant à « faire des choses amusantes avec les autres » (par exemple des événements d'équipe comme le rafting, le karting ou le paintball). Il s'agit avant tout de prendre plaisir à faire des choses qui aident à avancer ensemble. Pour cela, les développeurs ont besoin de deux choses : Premièrement, ils doivent savoir comment ils peuvent contribuer. Comme cela dépend fortement de chaque cas particulier, la contribution naît principalement de l'auto-organisation et de la motivation intrinsèque. Deuxièmement, ils doivent savoir que l'entraide est valorisée. Tout ce qui crée un désavantage personnel lorsqu'on aide les autres à atteindre un objectif commun doit être éliminé. Un exemple classique d'« esprit d'équipe » est le football : nous avons souvent vu que le match n'est pas gagné par le meilleur joueur. Le gagnant est la meilleure équipe. C'est pareil en développement : les as qui cherchent à se surpasser mutuellement ne gagnent pas. On gagne en unissant ses forces, en combinant les idées et en avançant ensemble.
Des groupes de développeurs sans esprit d'équipe gaspillent leur énergie en « occupation ». Un groupe à l'échelle qui n'est pas une équipe n'utilise qu'une fraction de son potentiel pour atteindre l'objectif commun !
4. Transparence
De nombreuses organisations échouent par manque de connaissance du système global. Elles ne peuvent pas optimiser à l'échelle globale. Les obstacles classiques à la transparence existent à tous les niveaux : du développeur qui ne sait pas comment le travail d'un collègue l'influence, jusqu'au manager qui ne peut pas dire quelle est la Priorité Absolue numéro 1. Ce manque de transparence engendre de nombreux problèmes. Cela commence par le développeur qui torpille inconsciemment le travail de ses collègues et va jusqu'à des équipes entières qui travaillent sur les mauvaises choses. Rien de tout cela n'est souhaitable et plus cela se produit fréquemment, plus il devient critique et important d'augmenter la transparence. Certaines organisations gaspillent presque toute leur capacité à gérer des problèmes causés par le manque de transparence. Dans de telles situations, « s'épuiser à la tâche » est probablement une description plus appropriée que « mise à l'échelle ». Il existe de nombreux leviers pour augmenter la transparence au point où la mise à l'échelle devient pertinente. En voici quelques-uns :
- Mettre en place un Kanban – visible par tous !
- Un backlog central dans lequel toutes les équipes peuvent puiser
- Collective Code Ownership comme base pour la « communication par le code »
- Utiliser des Andons : surveillance du build et « Stop the Line » basés sur des tests automatisés
- Planning commun et reviews communes, où seul le produit intégré est présenté
La transparence est inversement proportionnelle aux frais généraux et aux problèmes. Autrement dit : dans le cadre de la mise à l'échelle agile, la transparence est proportionnelle au ROI. Les équipes agiles qui manquent de transparence n'apportent pas de contribution significative aux objectifs de l'entreprise.
5. Focus
Dans de nombreuses organisations, l'un des principaux problèmes est une focalisation erronée sur le taux d'occupation : on gère le travail et on apporte des tâches aux collaborateurs. L'hypothèse de base ici est qu'on crée de la valeur en gardant tout le monde au maximum « occupé ». Dans une organisation agile, c'est exactement l'inverse : nous amenons les personnes vers le travail qui vaut la peine d'être fait. Nous savons qu'il n'y a pas de corrélation positive entre la création de valeur et le taux d'occupation. Nous nous concentrons sur la livraison d'un produit utilisable – sur le fait de terminer les choses. Un problème classique dans de nombreuses organisations est que la tentative d'occuper les collaborateurs met beaucoup de choses « en cours » : cela nécessite du changement de contexte et de la coordination. Pourtant, même dans les scénarios les plus triviaux, la perte de focus qui en résulte conduit à un ROI massivement réduit et à des délais de livraison significativement plus longs : nous passons trop de temps à comprendre pourquoi rien n'est terminé – et pas assez à terminer quelque chose. L'idée principale derrière la focalisation est : il coûte nettement moins cher de faire d'abord la mauvaise chose puis la bonne – que de faire deux choses en même temps. Aussi trivial que cela puisse paraître, c'est difficile à mettre en œuvre : l'ensemble de l'organisation a besoin d'une liste d'objectifs clairement ordonnée, et chaque objectif doit être priorisé de manière univoque. Il n'y a qu'une seule et unique priorité 1. Ensuite, le « travail en cours » doit être strictement limité. La focalisation exige que les managers repensent fondamentalement leur attitude : il faut accepter que le « temps mort » coûte moins cher que la surcharge. On ne peut pas non plus tout avoir en même temps. Les équipes non focalisées sont certes « bien occupées », mais hautement inefficaces. Moins elles sont focalisées, plus elles mettent de temps à créer de la valeur.
Les pièges lors de la mise à l'échelle de l'agilité
« La mise à l'échelle agile » qui ne se préoccupe pas des pièges mentionnés ci-dessus deviendra très probablement un cargo cult. Vue de l'extérieur, la transition semble réussie, mais de l'intérieur, les avantages de la transition ne se concrétisent pas. Pour des transitions agiles réussies, une approche courante consiste à faire appel à des experts expérimentés qui ont déjà « combattu sur le terrain » et connaissent déjà les pièges.
Pour éviter les pièges dans un environnement à grande échelle, nous recommandons :
Soutien de la direction pour la transition. Pour combler les lacunes, beaucoup de choses doivent être bouleversées dans l'organisation. Cela nécessite un soutien sans réserve de la direction.
Constituer une équipe de transition agile (ATT) composée à la fois de managers et de développeurs. L'ATT dispose d'un backlog de changement clair sur lequel tout le monde travaille ensemble.
Coaching exécutif pour les personnes clés de la transition. Cela inclut aussi bien les managers hiérarchiques que les Product Owners et les Scrum Masters. Le coach externe doit avoir de l'expérience en mise à l'échelle agile !
Coaching technique aide les équipes à acquérir plus rapidement les bons outils : cela se traduit très vite par un produit de meilleure qualité !
Engager un consultant pour diriger la transition. Cette personne doit savoir exactement ce qu'elle fait et travailler sans compromis. Elle doit avoir le pouvoir d'imposer des changements même impopulaires.
Formation pour tous concernant l'agilité. Dans un environnement de formation sécurisé, l'impact de la transition est beaucoup plus facile à transmettre.
