Guide du dirigeant pour une transformation agile réussie : Comment aller au-delà des équipes

par Matthew Jacobs | 29 octobre 2020 | Blog

Ce que les organisations agiles ont, et que les entreprises traditionnelles n'ont pas, c'est la capacité de changer, d'inspecter et de s'adapter en permanence. Les organisations agiles sont capables de pivoter pour tirer parti des marchés imprévisibles, des demandes des clients et des conditions du monde réel.

En bref, elles ont la capacité institutionnelle de faire du changement un avantage concurrentiel. Les hiérarchies statiques et la bureaucratie ont disparu. Elles sont remplacées par un système d'exploitation adaptatif et agile qui favorise l'innovation, la rapidité et la création de valeur.  

Pas seulement au niveau de l'équipe, mais dans l'ensemble de l'entreprise. 

Votre organisation peut s'améliorer simplement en ajoutant des équipes Scrum. Elles peuvent accélérer la capacité de votre organisation à fournir rapidement de la valeur. Toutefois, si vous ne modifiez pas les processus fondamentaux de votre organisation, l'efficacité globale de vos équipes Scrum sera limitée par les structures existantes et les barrières institutionnelles. 

Ce sont les obstacles qui font échouer tant de transformations Agile.

Lors d'une transformation Agile, le système d'exploitation actuel de votre organisation et le nouveau système d'exploitation Agile vont se battre pour dominer. Ils travailleront activement l'un contre l'autre. 

Nous avons aidé avec succès de nombreuses organisations à se transformer en entreprises agiles. Il n'y a pas de raccourci, mais il existe des modèles de réussite connus. L'alignement du système d'exploitation de l'organisation sur les méthodes de travail agiles augmentera considérablement la probabilité de réussite de votre transformation agile. 

1. Participation des dirigeants vs. adhésion

De nombreuses organisations pensent qu'elles sont agiles. En effet, leurs équipes de produits ou de services le sont peut-être. Mais plus haut dans l'organigramme classique, l'ancien système d'exploitation fonctionne toujours. C'est là toute la différence entre la participation des dirigeants et la simple adhésion. 

Le problème de l'adhésion des dirigeants est qu'elle ne suffit pas à elle seule à rendre l'entreprise agile. Si les dirigeants continuent de fonctionner selon l'ancien système, ils créeront des frictions avec les équipes. Il leur sera en fait plus difficile d'atteindre les objectifs et les résultats commerciaux dont ils sont responsables. Vous donnez à l'ancien système le pouvoir de dominer et de détruire le changement dont votre organisation a besoin pour prospérer. 

Cela se manifeste notamment par une communication inefficace. L'équipe de direction transmettra des ordres au lieu d'une vision, et les dirigeants s'attendront à recevoir des rapports d'étape.

Votre équipe de direction doit se transformer en une équipe de leadership capable de soutenir les équipes agiles elles-mêmes. La meilleure façon d'y parvenir est de faire en sorte que les dirigeants eux-mêmes adoptent un état d'esprit agile.

Pour émerger en tant que leaders, ils doivent fournir la vision, la direction et les priorités nécessaires pour permettre aux équipes d'exécuter avec agilité. Les dirigeants doivent également responsabiliser les équipes en supprimant les obstacles à leur réussite et à leur productivité. 

Dans l'idéal, les cadres seront si bien formés au cadre Scrum qu'ils pourront jouer le rôle de coachs auxiliaires.

Cela permet à la direction et aux équipes d'être plus autonomes. En comprenant comment lire, interpréter et utiliser des outils tels que les carnets de produits et les tableaux de combustion, la direction est mieux à même d'aligner l'organisation. La transparence et la visibilité augmentent. La planification devient plus fiable. 

J'aurais aimé être surpris lorsqu'une équipe de direction nous a appelés au début de l'année pour nous faire part de sa frustration car ses équipes Scrum avaient non seulement cessé de s'améliorer, mais semblaient même régresser. Lorsque nous sommes allés parler aux équipes pour identifier la cause profonde des problèmes, elles ont été surprises que leur équipe de direction ait demandé de l'aide. 

L'équipe a ensuite donné des exemples de ce que certains de nos clients militaires appellent le "hallway tasking". L'équipe dirigeante intervenait fréquemment pour exiger que quelque chose d'autre soit fait immédiatement. Lorsque la Product Owner a tenté d'intervenir et de demander de l'aide pour établir des priorités, l'équipe de direction a refusé de s'engager. Ces "tâches de couloir" mobilisaient une grande partie des capacités de l'équipe. Les progrès réalisés sur des produits bénéfiques pour l'entreprise en ont souffert. 

En revanche, lorsque l'équipe identifiait de simples obstacles, elle ne disposait d'aucun canal d'escalade. Lorsque des problèmes étaient soumis au comité directeur exécutif, la réponse fréquente était "ne m'apportez pas de problèmes, apportez des solutions". Cela décourageait toute personne de présenter des problèmes de manière transparente, en particulier ceux qui nécessitaient un soutien dépassant ses compétences. 

Ces managers ont peut-être adhéré au concept Agile, mais ils n'y ont pas participé et ne l'ont pas dirigé. Quant aux obstacles non résolus, ils nuisent eux aussi à la productivité, à la créativité et au moral de l'équipe. 

Heureusement, un directeur général nouvellement nommé a commencé à promouvoir un véritable modèle de leadership au service des autres.  

Lorsque nous avons informé l'organisation sur Scrum@Scale, le nouveau directeur général a vu comment le cadre rendait opérationnel le leadership au service des autres. Les équipes Scrum ont commencé à s'accélérer une fois que Scrum@Scale et le leadership au service des autres se sont développés. Les résultats recherchés par la direction ont été rapidement atteints.

En tant qu'équipe de direction, si vous demandez à votre organisation et aux membres de votre équipe de changer et d'adopter un comportement agile, vous devez attendre la même chose de vous-même.

2. Rendre les cycles de vie de vos produits agiles

Les entreprises disposent souvent de processus spécifiques pour la gestion du cycle de vie des produits. Ces processus sont liés aux cadres d'approbation de l'organisation et alimentent le financement, les rapports, le marketing et les investissements futurs. 

Les équipes agiles ont souvent des difficultés à faire passer les projets par les étapes lorsque ce processus n'est pas mis à jour. Cela ne signifie pas que les exigences réglementaires peuvent être ou seraient ignorées. Cela ne signifie pas non plus que les autres contrôles de sécurité et de qualité seraient supprimés. 

Cela signifie que ces contrôles permettent de s'assurer qu'ils servent l'objectif prévu et qu'ils répondent au minimum requis de frais généraux pour satisfaire aux normes de sécurité et de réglementation exigées. 

Si ces processus ne sont pas modifiés, les projets qui auraient dû être abandonnés parce qu'ils ne répondent pas aux attentes des clients ont tendance à obtenir davantage de financement, simplement parce qu'ils répondent déjà aux exigences prédéterminées du processus du cycle de vie du produit. Les nouveaux produits et les pivots porteurs de valeur sont abandonnés par défaut. 

Je peux vous donner l'exemple d'une entreprise manufacturière du Fortune 100 que nous avons récemment guidée dans une transformation Agile. Dans leurs systèmes, ils avaient construit des rapports automatisés pour s'assurer que tout "fonctionnait correctement". 

Il existait un processus compliqué dans lequel des équipes extérieures au groupe de développement étaient chargées de gérer et de signaler toute erreur système au fur et à mesure qu'elle se produisait. Mais avec la mise en œuvre d'un modèle de fonctionnement agile, les équipes elles-mêmes ont assumé la responsabilité directe de l'assistance produit. 

Avant la mise en œuvre, les nouveaux développements passaient par une série de mises à disposition échelonnées, les approbations progressant lentement dans le système. 

Les équipes Scrum bien formées sont composées de membres possédant toutes les compétences nécessaires pour effectuer le travail, y compris l'assistance dans cette situation. Cela a permis à l'équipe de se concentrer sur une mise en production plus rapide et de construire des tests automatisés pour détecter rapidement les problèmes avant même qu'ils ne soient rencontrés par un client. 

Pourtant, l'organisation a conservé ces équipes de test et de reporting manuelles et distinctes qui faisaient partie de son ancien modèle de fonctionnement. Ainsi, lorsque des changements sont intervenus, les scripts de test n'ont pas pu suivre le rythme des modifications apportées par les équipes de développement. Ces tests obsolètes ont commencé à échouer. 

Alors, comme il l'avait fait depuis le début, le service de conformité est passé à l'action. Il a envoyé des rapports d'échec à différents responsables, et ces derniers ont commencé à insister pour que les problèmes qui n'existaient pas sur les applications qui avaient été remaniées ou éliminées soient corrigés le plus rapidement possible. 

Les équipes ont produit les résultats appropriés au problème et ont été correctement déployées pour le soutenir. Cependant, l'équipe de soutien a passé son temps à résoudre des problèmes liés au système de qualité qui n'avaient aucun rapport avec la tâche initiale. Si l'organisation avait reconnu la nouvelle méthode de travail et augmenté son système d'exploitation, elle aurait dissous ces équipes de test externes et placé ces compétences dans les équipes Scrum afin de favoriser l'agilité globale.

3. Utiliser un cycle de planification/budgétisation piloté par la méthode Agile

Le processus de budgétisation financière est parfois considéré comme le pouls de l'entreprise moderne. Il est facile de comprendre pourquoi. Il définit les rythmes mensuels, trimestriels et annuels d'une organisation. Ils jouent également un rôle majeur dans la planification stratégique à long terme. 

Les projets ont besoin d'un financement pour avancer et les équipes Agile qui ont besoin de budgets sont donc redevables de ce processus. Si les budgets ne sont débloqués qu'une fois par an et que le processus financier n'est pas agile, les équipes auront du mal à affecter les fonds aux projets et aux problèmes les plus prometteurs.

Chez certains de nos clients, nous avons remarqué que les projets Agile sont présentés en interne et en externe comme de grands exemples de réussite. Cependant, lorsque vous parlez aux équipes, vous entendez qu'elles sont confrontées à un combat difficile pour obtenir les ressources nécessaires par rapport aux projets traditionnels. 

En conséquence, les projets prometteurs ou les changements nécessaires sont mis en attente jusqu'au cycle de financement de l'année suivante, alors même que les projets à faible valeur ajoutée ou les projets défaillants se poursuivent et consomment de l'argent. Le coût global pour l'entreprise dans ces scénarios est tout simplement stupéfiant.

C'est pourtant l'un des principaux obstacles identifiés par les équipes avec lesquelles nous travaillons. 

Pour être agile et favoriser l'agilité au sein d'une organisation, il faut penser comme un investisseur en capital-risque :

• Utiliser les prévisions glissantes - Augmenter la fréquence des boucles de rétroaction et créer un mécanisme de reconnaissance et de planification du changement.
• Envisager la mise en place d'un budget base zéro le cas échéant - Souvent, les entreprises utilisent les budgets de l'année précédente comme point de départ pour déterminer le budget de l'année suivante. Cela conduit souvent à une mentalité de dépenses "à utiliser ou à perdre" qui engendre un énorme gaspillage. La budgétisation base zéro adopte l'approche inverse. Au lieu de partir de l'année précédente comme point de référence, vous partez de zéro et n'augmentez les allocations qu'après avoir justifié chaque dépense sur la base de projections de bénéfices.
• Allouer plus fréquemment des ressources de moindre importance - réaffecter les fonds en fonction des performances et du retour d'information. Cessez d'allouer des fonds aux initiatives les moins performantes et redoublez d'efforts sur ce qui fonctionne.  
• Financer des personnes, pas des projets - La plupart des entreprises fonctionnent selon un modèle de financement de projet : elles déterminent le coût du projet, examinent le retour sur investissement attendu et financent en conséquence pour atteindre l'objectif de recettes ou de réduction des coûts qu'elles souhaitent atteindre. Ensuite, ils mettent en place une équipe chargée de mener à bien le projet. Dans Scrum, nous préconisons un modèle de financement persistant. Il s'agit de financer des équipes de personnes (il existe plusieurs façons de procéder) et de leur confier des projets ou, idéalement, des problèmes à résoudre. Nous ne calculons pas le coût du projet séparément, mais nous donnons la priorité à l'allocation des efforts de l'équipe.

N'oubliez pas que la planification annuelle n'est au mieux qu'une supposition. Vous devez utiliser des boucles de rétroaction courtes et savoir comment utiliser les données que vous recueillez pour être agile.

4. Refondre votre processus d'acquisition

Si vos équipes évoluent rapidement et disposent de budgets dynamiques, elles identifieront fréquemment de nouveaux éléments dont elles ont besoin pour continuer à mener à bien leurs projets à forte valeur ajoutée. S'il faut six mois pour obtenir le personnel ou l'équipement nécessaires, le processus tout entier est ralenti. 

Nous voyons souvent des équipes Scrum évoluer à un rythme que le processus d'approvisionnement traditionnel de l'entreprise ne peut pas gérer. 

De nombreuses procédures de passation de marchés, si ce n'est la plupart, ont été mises en place pour atténuer le risque de dépassement des coûts d'un produit ou d'un service. Toutefois, lorsque l'on tente d'éliminer tous les risques, on en crée souvent de nouveaux en raison d'inefficacités. Si votre équipe chargée des achats et vos fournisseurs adoptent le Manifeste Agile, ils privilégieront tous deux la collaboration avec le client plutôt que les négociations contractuelles. Il a été démontré que cela augmente la vitesse de livraison. Elle peut également réduire les gaspillages coûteux résultant d'une mauvaise communication. 

Un point soulevé lors d'une récente conversation avec un partenaire qui travaille dans le secteur de la construction. Son équipe discutait avec l'un de ses fournisseurs qui venait de livrer un article à six chiffres sur un chantier. Le fournisseur a expliqué à quel point il était difficile de faire adhérer la peinture rose au type de métal utilisé. Il a fallu faire venir par avion des produits chimiques spéciaux et de la peinture pour que cela fonctionne. 

Lorsque notre partenaire a contacté le service des achats et a demandé pourquoi l'article devait être rose, le responsable des achats a répondu : "Il fallait simplement que l'article soit brillant, mais j'avais besoin de choisir une couleur spécifique dans notre système et j'ai donc choisi le rose". 

Les processus bureaucratiques de l'approvisionnement, axés sur les exigences, ont coûté des dizaines de milliers de dollars à l'entreprise en valorisant le processus contractuel au lieu d'établir un véritable accord de collaboration avec le fournisseur.    

5. Développement Pratiques agiles en matière de personnel et de ressources

Pour que les transformations agiles deviennent réalité, les équipes chargées de l'habilitation des personnes (les RH dans de nombreuses entreprises) jouent un rôle important. Pourquoi voudrais-je assumer le rôle difficile de Scrum Master si l'organisation ne le reconnaît pas comme un emploi et si les responsabilités sont en conflit avec ma description de poste ? Comment gérer les talents et la reconnaissance des personnes si le Scrum Master et le Product Owner ne sont pas mes supérieurs directs ? Comment gérer la hiérarchie des titres avec les rôles professionnels ? 

Pour qu'une transformation agile se mette en place et soit durable, l'organisation doit accepter ces changements et identifier les réponses qui s'alignent sur les résultats commerciaux souhaités. 

Par exemple, les incitations sont des outils puissants. Une fois que la méthode Agile commence à s'implanter et que vos équipes Scrum accélèrent, vous devez modifier votre structure d'incitation afin de récompenser les comportements et les modèles que votre organisation valorise désormais.

Si votre reconnaissance est uniquement basée sur les mérites individuels, pourquoi quelqu'un changerait-il d'état d'esprit et de comportement pour privilégier l'équipe ? Si la reconnaissance de l'équipe est basée sur l'achèvement d'un projet spécifique, pourquoi changeraient-ils de direction même lorsqu'il devient évident qu'ils doivent pivoter ? 

Votre organisation doit motiver et récompenser les équipes qui apportent une grande valeur ajoutée. Par conséquent, les récompenses et la rémunération des équipes doivent être alignées sur les indicateurs de performance clés que vous utilisez.  

Une équipe opérationnelle du service de comptabilité fournisseurs de l'un de nos partenaires a récemment mis en œuvre Scrum. Notre client n'a pas réaligné son programme d'incitation. La structure d'incitation de cette équipe était axée sur le maintien d'une file d'attente aussi réduite que possible. Elle a donc poursuivi cet objectif de manière agressive. Cependant, en se concentrant uniquement sur la taille de la file d'attente, l'équipe a été incitée à résoudre immédiatement les tickets faciles à traiter. Les autres restaient en attente.  

Le délai de paiement ayant considérablement diminué, les équipes ont atteint l'objectif fixé. Cependant, certains fournisseurs étaient payés rapidement tandis que d'autres fournisseurs stratégiques voyaient leurs factures mises en attente pendant des mois avant d'être payées. 

L'organisation ayant changé d'orientation, le Product Owner a fini par réorienter ses objectifs pour se concentrer sur l'objectif commercial de haut niveau que constitue le respect des délais de paiement et a recentré les priorités de l'équipe sur les conditions de chaque demande de paiement, au lieu de traiter chaque paiement de la même manière. Si vos incitations ne correspondent pas aux résultats souhaités et (ou) aux comportements requis pour les atteindre, la structure des incitations causera des frictions avec la transformation Agile.

6. Conception de l'organisation

Pour que votre transformation Agile réussisse, votre organisation doit être mise en place de manière à ce que les équipes et leurs membres bénéficient de la supervision et du soutien au développement dont ils ont besoin pour être efficaces. Des questions difficiles doivent être posées maintenant que nous sommes dans notre nouveau modèle.

Qu'est-ce qui doit faire partie d'un service partagé et qu'est-ce qui peut être externalisé ? Quelles compétences doivent être réparties entre les équipes ? Comment traiter les experts en la matière ? Que faire des
les cadres moyens ? Comment intégrer les entrepreneurs et les vendeurs ? Et bien d'autres choses encore.

Si l'organigramme n'est pas lui-même agile et que les voies de communication ne sont pas optimisées, l'organigramme se défend. Et devinez qui gagne presque toujours. 

Lorsque les organisations ne réfléchissent pas à l'avance à leur structure, elles peuvent se retrouver dans une situation où le personnel possédant des compétences similaires est sous-utilisé dans un groupe et surutilisé dans un autre.

Prenons l'exemple d'une entreprise du secteur financier avec laquelle nous avons travaillé et qui a subi une vaste réorganisation de haut en bas. Elle a créé ses équipes Scrum pour qu'elles travaillent uniquement sur les projets et les charges de travail prévus, au lieu de constituer de véritables équipes interfonctionnelles.

C'est alors que le COVID-19 a soudainement tout changé.

Ils se sont rapidement rendu compte que ces équipes n'étaient pas assez flexibles pour s'adapter facilement à la nouvelle réalité et ont dû relancer de nouvelles équipes qui étaient interfonctionnelles et pouvaient s'adapter aux changements.

La morale de l'histoire est qu'il faut constituer les équipes de manière à ce que le travail puisse leur parvenir. Vous ne voulez pas avoir à créer sans cesse de nouvelles équipes pour faire face au travail, sinon vous risquez de perdre tous les avantages des relations de travail étroites et de l'expérience pratique que l'équipe a développées. 

 Ensuite, il y a la question de la mise à l'échelle. L'un des mantras de Scrum@Scale est qu'il ne faut pas changer d'échelle si ce n'est pas nécessaire. Les couches inutiles ralentissent une organisation. 

Mais lorsque vous devez changer d'échelle, assurez-vous de le faire d'une manière unifiée. N'ajoutez pas de complexité en introduisant ce qui équivaut à un autre système d'exploitation qui déclenche un nouveau cycle de conflit à somme nulle. 

C'est l'une des raisons pour lesquelles la Cadre Scrum@Scale s'aligne si étroitement sur le cadre Scrum. 

7. Créer un espace de travail agile adapté 

L'endroit où vous travaillez peut définir le travail que vous faites. Les environnements de travail et les outils appropriés augmentent la productivité, la collaboration et la créativité. Ils permettent à l'équipe de travailler en toute transparence.

Cela vaut aussi bien pour les équipes virtuelles que pour celles qui sont localisées dans un même lieu. 

Un mauvais environnement de travail crée des distractions constantes et empêche l'équipe de produire de la valeur. Il existe de nombreuses façons d'y parvenir. Si un expert en la matière est si important qu'il ne peut pas s'asseoir avec l'équipe ou communiquer virtuellement avec elle en cas de besoin, quelle est sa valeur ? Les murs du bureau sont-ils tellement remplis d'œuvres d'art que nous ne pouvons pas rendre notre travail visible ? Si votre équipe est dispersée, dispose-t-elle des bons outils virtuels pour collaborer en temps réel sur une longue distance ? Y a-t-il des étapes inutiles qui ralentissent tout ?

Je viens de parler à une équipe qui utilisait un outil permettant à plusieurs personnes de travailler simultanément sur des diapositives. Son directeur général était stupéfait de voir à quel point ils travaillaient plus vite. À la fin de l'essai gratuit, le PDG a retiré le produit pour des raisons de coût. 

Quelle est la valeur de la rapidité et de la capacité de vos employés à travailler ensemble ? Les organisations doivent se rappeler que leur objectif est de créer de la valeur et de soutenir ce processus de création de valeur. 

Embrasser le voyage

En abordant ces questions, vous augmenterez considérablement les chances de réussite de votre transformation Agile. C'est ainsi que l'on crée des systèmes d'exploitation dynamiques qui stimulent l'innovation et la création de valeur. Mais n'oubliez jamais que la création n'est que le début de votre parcours Agile. Les principaux points de friction d'aujourd'hui ne seront plus ceux d'il y a un an. 

La transformation agile n'est pas un état final. Il n'y a pas de ligne d'arrivée clairement définie.  

Vous devrez régulièrement inspecter et adapter votre organisation. La méthode Agile vous aide à le faire.