95% des entreprises indiquent compter dans leur rang au moins une équipe agile. En d’autres termes, aujourd’hui tout le monde veut être agile. C’est devenu une norme, à la fois pour l’entreprise qui doit pouvoir réagir vite et avec la bonne réponse aux conditions changeantes du marché, mais aussi pour les individus qui doivent réussir à mieux collaborer et travailler collectivement à un but commun. Si bien qu’il est même devenu compliqué d’être recruté ou de recruter sans afficher un plan de transformation agile pour l’un et une certification pour l’autre.
Pour autant, dans la plupart des situations que je rencontre, les entreprises se concentrent beaucoup plus sur le “FAIRE” agile que sur le “ÊTRE” agile, beaucoup plus sur les processus et les outils que sur l’essence même de l’agilité qui se situe dans l’état d’esprit et dans les interactions.
Nous avons parfois tendance à oublier que l’agilité est un état d’esprit et un moyen, ou plus globalement un ensemble de moyens, de pratiques qui servent un objectif. Un moyen de s’en rendre compte est d’observer les indicateurs des entreprises concernant l’agilité. Ce qui est mesuré et suivi par les entreprises est l’utilisation et l’adoption de pratiques plutôt que la performance qu’elles sont supposées apporter.
Voyez plutôt :
Je fais des daily meetings donc je suis agile
J’utilise Jira donc je suis agile
Je fais des rétrospectives donc je suis agile
J’organise des PI Planning pour aligner les dépendances entre mes équipes donc je suis agile
Je dis que je fais de l’agilité à l’échelle donc je suis agile.
L’agilité : au service de la performance avant tout
Mais au fait, si je suis agile, quel but cela sert-il ?
Ce but qui est si souvent inexistant devrait pourtant être la préoccupation première de l’entreprise ou de l’équipe.
Essayons d’utiliser les 3 cercles de Simon Sinek pour détailler dans quel but devenir agile :
le WHY c’est la performance de l’entreprise ou de l’équipe
le HOW ça peut être l’adoption de l’état d’esprit agile (qui peut être complété par d’autres choses, comme le renforcement des compétences ou l’innovation par exemple)
le WHAT ça peut être la mise en oeuvre de pratiques concrètes comme certaines méthodes agiles : Scrum, Kanban, XP… ou d’autres techniques
L’agilité n’est pas une fin en soi. Être agile, intrinsèquement, ne suffit pas. Viser une meilleure performance est nécessaire. En fonction du contexte, la performance se décline sur des axes différents comme par exemple : plus de ventes, plus de notoriété, plus de nouvelles fonctionnalités, dépasser un concurrent, moins de turnover, mais aussi plus de partage de connaissances, plus d’apprentissages, plus de nouvelles expérimentations…
Je vais être clair ici, pour moi la performance, qu’elle soit individuelle ou collective, n’est pas un gros mot. C’est même ce qui doit nous animer au quotidien. Être plus performant dans son métier ou dans son rôle, c’est tout simplement être meilleur, apprendre sans cesse, progresser. C’est une nécessité pour moi.
Mesurez des KPI sur le but, pas sur le moyen
Mes clients me demandent souvent comment nous allons mesurer l’impact de leur transformation agile, afin de prouver que cette transformation est utile. J’aime qu’on me pose cette question car, même si il n’est pas simple d’y répondre, elle dénote une bonne compréhension des enjeux autour de la transformation.
Comme je le disais, mesurer l’impact d’une transformation n’est pas simple à réaliser. Car si je peux mesurer aisément si une équipe respecte ses rituels, met à jour son Jira, délivre ce qu’elle a prévu (via le Burn-Down Chart par exemple), ce faisant je mesure le WHAT : le moyen. Je ne mesure pas l’impact. Je ne répond pas à la question.
Donc je travaille plutôt à mettre en place des indicateurs de performance qui permettent de mesurer un résultat sur le WHY : augmentation du panier moyen, du taux de repeat, du nombre d’utilisateurs actifs, du taux de disponibilité, etc… Evidemment, il n’y a pas de lien direct (ou 1 pour 1) entre le moyen (l’agilité) et le résultat (la performance), car d’autres facteurs viennent impacter le résultat (l’évolution du marché, le marketing…). Mais je préfère expliquer à mon client que la transformation agile permet de soutenir le développement de ses ventes que de lui dire que 93% de ses équipes font un daily meeting.
Comment mesurer le ROI d’une initiative agile ?
I WANT MY ROI !
Si vous êtes dans une démarche « ROIste » pur, il sera peut-être compliqué pour vous de voir l’intérêt de l’agilité.
Car l’agilité intervient dans un système global et il n’est pas possible de découper le système de sorte qu’on puisse mesurer l’impact d’un seul moyen mis en œuvre. C’est d’ailleurs un des principes fondamentaux de la pensée systémique : un système complexe ne peut pas être découpé en petits systèmes plus simples. C’est un tout.
Dès lors, le retour sur investissement se mesure dans la capacité à améliorer l’axe de performance principal de l’entreprise ou de l’équipe. S’il était difficile au départ de faire grossir sa base utilisateur, la transformation mise en œuvre aidera probablement à délivrer plus vite des fonctionnalités à plus forte valeur ajoutée. Et donc à sortir en premier LA nouvelle fonctionnalité qui va faire le buzz. C’est à ce moment que l’investissement sera rentable.
Visez la performance plutôt que l’adoption des pratiques agiles
Je suis personnellement convaincu que l’agilité est un bon moyen pour améliorer la performance d’une entreprise ou d’une équipe. Et j’expérimente mes convictions depuis une dizaine d’années maintenant. Les transformations qui réussissent sont celles qui se concentrent sur la mesure de la performance, et non pas sur le nombre de cérémonies effectuées dans le mois. Et puis, il existe de nombreux autres moyens d’améliorer sa performance, des moyens qui se découvrent par l’expérimentation et l’apprentissage.
Rupture douce 05 : les individus et les interactions d’abord !!
Rupture douce 05 : les individus et les interactions d'abord !!
Les individus et les interactions d’abord !!
Les Individus et les interactions d’abord !! Le nouveau Tome de Rupture Douce est disponible !!! 40 textes, 30+ auteurs, de nombreuses illustrations pour remettre les pendules à l’heure en matière d’agilité et de transformations agiles.
Auto-édition sur lulu.com, 15€ HT (coût de fabrication 10€ + 5€ qui seront reversés aux resto du coeur. Pour mémoire 536€ = repas pour une famille de 4 pour tout l’hiver.
Quel plaisir pour moi d’avoir fait partie de cette aventure collective, capable d’accoucher d’un livre en quelques semaines. J’ai immédiatement plongé dans le projet avec quelques pages qui proposent ma vision d’une agilité agnostique des frameworks, mais centrée sur l’humain, le (bon) sens et la recherche de simplicité. Et ça aussi, ça fonctionne « à l’échelle ».
Séverin Legras
4ème de couverture
Durant toutes ces années, l’agilité a connu de beaux succès, et encore trop d’échecs. Dans tant d’endroits, les transformations agiles sont encore asservies par une descente de processus agiles (Scrum, Kanban, Safe, etc) sur les individus. Heureusement, nous pouvons savourer des initiatives comme Agnostic Agile ou bien Heart of Agile, cultivées par des anciens de l’agilité, ceux qui ont donné naissance au Manifeste Agile en 2001.
Ce tome 05 s’inscrit dans cette mouvance : ici, les contributeurs entendent rappeler que notre manifeste précisait dès sa première valeur « les individus et les interactions plus que les processus et les outils ». Vues les confusions constatées, autant simplifier en « les individus et les interactions d’abord !! ».
Dans vos mains, vous tenez une nouvelle collection d’histoires épatantes, pour remettre les pendules à l’heure. Retours d’expériences authentiques, approches pragmatiques : vous disposerez d’un beau matériel pour espérer que les 10 prochaines années soient encore meilleures.
Claranet | Oxalide et Rhapsodies Conseil vous invitent à découvrir un retour d’expérience de transformation vers une Organisation plus Agile.
Co-construit en intelligence collective, ce modèle aligné sur la stratégie de développement prévue par Oxalide (groupe Claranet) visait à faire face à des enjeux de croissance, d’organisation, de scalabilité dans un marché ou le time-to-market est le nerf de la guerre.
La conception d’un modèle de transformation en mode agile différenciant, intégrant leur cible, leur rythme et une trajectoire adaptée, était majeure pour atteindre les résultats souhaités.
Une Organisation Produit conçue avec les équipes et les consultants de Rhapsodies Conseil qui ont eu plaisir à mener cette mission.
La mise en place de la pensée agile, c’est comme un Paris-Brest : on peut choisir le savoir-faire de l’artisan, ou bien l’industrialiser et le vendre en surgelé. Pour ma part, je préfère la première version… J’aurais pu choisir la métaphore du kouign amann, mais je ne veux pas visualiser le blasphème de sa congélation…
Dans cet esprit, je partage avec vous ici quinze idées de clarification qui me paraissent fondamentales pour vraiment obtenir ce que l’agilité promet, quinze idées qui ont tendance à disparaître quand on industrialise trop l’activité de conseil en transformation.
La majorité de ces idées relèvent du bon sens… quand on vit dans un contexte déjà agile, mais il ne faut pas oublier les autres organisations qui doivent vivre avec leurs cultures et leurs réflexes inconscients. L’héritage inconscient (la force des habitudes) en matière de méthodes de décision et de management devient un élément prépondérant, et ces cultures interprètent à leur façon le nouveau paradigme. Le problème apparaît quand leur interprétation s’enkyste : elles finissent se convaincre qu’elles se sont transformée et devenue agile dans leur ADN, alors qu’elles n’ont fait que surfer sur l’idée, à la limite du détournement de sens… et il faut reconnaître que beaucoup d’organisations s’arrêtent au milieu du gué de leur transformation !
Une vision trop rapide des équipes agiles peut donner l’impression des symptômes de la réunionite. Certains croient que Scrum exige de 5 à 10 h de réunion par semaine à tous les développeurs. Au risque de vous perturber, il n’y a au contraire plus aucune réunion ; plus aucune réunion mais beaucoup d’ateliers. Dès qu’on se met ensemble, ce n’est pas pour parler, mais pour produire quelque chose. Et pour rendre les choses factuelles :
Stand up : 15 min par jour
Sprint planning + demo + retro : 5h par 3 semaines…et ce sont ces rituels/ateliers qui empêchent les développeurs de s’enfermer dans la myopie du quotidien. Si vous voulez de l’information sur l’avancement de l’équipe, allez voir directement son « radiateur d’information » : aucune réunion n’est nécessaire pour ça.
L’agile qui se limite au développement applicatif oublie tout le reste de la chaîne… Il faut s’intéresser à l’ensemble du cycle de vie du produit et de la façon dont il répond au problème des clients. Si on laisse les développeurs dans un bocal hermétique, en s’assurant que l’agilité ne perturbe pas le reste de l’organisation, on construit une vérité schizophrène… On ne peut pas être agile sur un seul segment de la chaîne de valeur.
En agile, le rôle fondamental de chacun envers tous les membres de l’équipe de développement est de dédramatiser les « fails » : un échec, c’est bien si on tombe très vite avant de se faire trop mal. Et si on en apprend quelque chose. Sinon, on fera mieux la prochaine fois, mais on en parle ensemble pour que chacun en retire quelque chose.
La logique de timebox s’inspire effectivement – entre autres – du fonctionnement des sections spéciales US en particulier, mais cela ne justifie en rien un rythme insoutenable. Après une mission, ces dernières ne retournent pas dans un régiment classique. Un sprinter de 100 m ne passe pas les 24h de ses journées à courir de façon maximale. Il y a des temps de relaxation, des temps de récupération active, des compétitions sans enjeu, et des compétitions essentielles. De même, le management autour de Scrum doit s’assurer que ces alternances sont réelles. Il y le temps de la production de code opérationnel, il y a le temps du team building et le temps de l’amélioration en compétence (clin d’œil à nos amis du Craftmanship !).
De la même façon, il n’y a pas de notion d’urgence dans la réalisation d’un sprint (ou d’une mission) : seul l’impact compte ; le sprint est un mot qu’il aurait mieux valu traduire par « timebox » et qui oblige à se poser régulièrement, quel que soit l’état d’avancement, pour relever ensemble la tête du guidon.
Il n’y a pas de « war room » pour les sections spéciales ; la « war room » est l’organe de pilotage pour les officiers supérieurs qui dirigent des campagnes militaires et pas des missions individuelles. De la même façon, les « radiateurs d’information » et les stand up ne sont absolument pas des « war rooms », mais des points de coordination et des opportunités de travailler au quotidien le team building. Dans les sections spéciales, on parle de briefing et de « l’intention du commandement sur l’effet majeur ». On parle de l’essentiel pour la mission en cours. La stratégie, c’est pour le sprint planning et la démo.
La logique agile n’est surtout pas « customer first » ou « customer only » : au contraire, il s’agit maintenant de répondre de façon équilibrée à toutes les parties prenantes, et pas uniquement l’utilisateur final le plus évident (rem : le management interne est une partie prenante). Si les arbitrages ne se faisaient que dans l’intérêt exclusif d’un client, on laisserait ce dernier arbitrer. Si la demande à prendre en compte venait uniquement des utilisateurs finaux, une équipe de « business analysts » suffirait et il n’y aurait pas besoin de Product Owner.
La sociabilité « obligatoire » de l’agile est plutôt le retour à ce qu’il était normal d’avoir avant la spécialisation des ouvriers du modèle Fayol/Ford. Dans un monde « normal », où l’on ne peut pas supposer que chacun est essentiellement indépendant de tous les autres, il faut savoir parler, motiver, influencer, recadrer, écouter, être écouté… On ne peut plus se cacher derrière des processus aussi pléthoriques que mal maîtrisés pour se déresponsabiliser.
Les paradigmes classiques RH et hiérarchiques deviennent effectivement obsolètes tel quel : il ne peut plus y avoir de pilotage de gestion de carrière, ni de détection des « High Pot ». On va plutôt créer et nourrir un système d’interrelations entre personnes qui permet l’émergence de l’intelligence collective, et que l’innovation ne s’arrête jamais. On va chercher des talents pour aiguillonner les réflexions, plutôt que de trouver des profils trop compatibles. On devient beaucoup plus exigeant sur la motivation à apprendre collectivement que sur la production immédiate de valeur. Une personne n’est pas incompétente par son incompétence technique uniquement, mais surtout parce qu’elle n’est pas intrinsèquement motivée pour apprendre et transmettre son savoir
Les réflexes comportementaux qui viennent du paradigme bureaucratie/spécialisation sont effectivement un sujet : il faut souvent les accompagner pour qu’ils apprennent à se responsabiliser sur ce qu’ils sont et comment ils sont influencés. En particulier, chacun doit être responsable de sa propre protection, de son propre bien être, du respect de ses valeurs. Plusieurs méthodes, qui incluent des étapes de coaching personnel et de groupe, sont raisonnablement efficace.
On reproche – entre autres – à l’ancien système d’induire une hiérarchie de valeur : le plus noble étant dans la contact proche du client et l’écriture de son besoin, et le moins noble, au fond de la soute étant le développement logiciel, la maintenance et la production. Des développeurs juniors s’enfuient vers les MOA avant de devenir de bons codeurs ; de bons chefs de projets deviennent des experts du contentieux contractuel avant de savoir gérer des dynamiques de groupe. En agile, comme on aime bien les réponses extrêmes et réalistes, on automatise tout ce qui est de faible valeur. On ne donne aux Hommes que ce qui nécessite vraiment des neurones. Ecrire des tests est une activité critique : on met plusieurs cerveaux autour de la table. Passer des tests ? Un click… et des automatismes qui savent très bien faire ça sans nous.
Oui, on a besoin de beaucoup moins de types d’acteurs… les experts isolés n’ont plus leur place. Des profils disparaissent. Ou ils deviennent coachs/mentors sur plusieurs équipes, ou ils font évoluer leurs compétences en « T-shape » pour être utile dans une équipe. Chacun a une place dès qu’il apporte de la valeur à quelqu’un, et chaque équipe est solide quand chacun individuellement s’enrichit du travail que fait l’équipe et enrichit réciproquement l’équipe par son travail.
J’ai lu quelque part que ce qu’on appelle les « user stories » étaient une énorme manipulation des managers. Il s’agirait d’une escroquerie pour faire coexister des développeurs très bons (qui ont besoin d’une vision globale) avec des incompétents complets (qui ont besoin de faire perdre du temps aux autres en demandant au jour le jour ce qu’il faut faire) … en autorisant ces derniers à se positionner presque ouvertement en passagers clandestins qui usent de leur furtivité en se noyant dans le dans le groupe.
Et bien non encore… Le découpage en « user stories » n’est pas une méthode de management… mais un atelier de design technique. On y utilise l’intelligence collective et des points de vue complémentaires pour réfléchir ensemble sur les solutions techniques possibles. Donner une vision globale au développeur n’est pas jeter des perles à des pourceaux : c’est juste fondamental !
Les technologies utilisables sont tellement évolutives que vous – clients, MOA, Chefs de projet et mêmes développeurs des autres équipes – n’êtes pas les mieux à mêmes de connaître ce qui est le plus pertinent. On reprochait il y a quelques dizaines d’années aux informaticiens d’imposer leurs mots et leurs concepts aux non-informaticiens. Ils ont bien compris le message : ils vous écoutent maintenant. Parlez-leurs de vos vrais besoins ; ne leur parlez pas d’informatique : ils ont l’impression que vous leur parlez d’événements préhistoriques, voir d’uchronies. Non… défragmenter un disque dur ne va pas accélérer votre cloud… Et non encore : ce n’est pas une bonne pratique de faire une multitude de forks de votre code.
La démo en fin de sprint est TOUT SAUF une recette : c’est une occcasion/prétexte de faire du liant entre le client et l’équipe de développement. L’agile va de pair avec le DevOps et donc le Continuous Delivery. Le développeur est anxieux de la démo ? Il vaudrait mieux qu’il soit anxieux — au jour le jour – du risque de laisser prospérer de la dette technique… L’automatisation des tests de non-régression, le monitoring et la qualimétrie lui donnent instantanément, à chaque ligne de code, la portée de ce qu’il fait, et il peut donc agir au moment où son stress est légitime et utile.
La vie en « open space » oblige effectivement un autre savoir-vivre, celui du collectif, de l’équipe, de l’esprit de corps… Le coaching et le team building sont très importants pour éviter les effets de groupe qui peuvent s’emballer… L’esprit de corps, ce n’est pas non plus idéaliste : une équipe de mercenaires peut être très efficace, mais il faut savoir la gérer. C’est probablement un type de compétence que les managers n’ont pas toujours.
Une dernière clarification, qui est plutôt un recadrage…Il faut quand même être très clair : l’agile n’est absolument pas un monde idéal, une utopie fouriériste qui deviendrait possible au XXIème siècle. De la même façon que le cycle en V n’était pas un délire déshumanisé de Saint-Simoniens. Les « passagers clandestins » se font exclure sans autre forme de procès. La motivation peut compenser des compétences trop faibles. Le caractère de chacun est un sujet en soi : toute personne doit se sentir responsable de son intégration et de son utilité, et agir en fonction. Les conflits existent et doivent devenir des opportunités constructives : c’est aussi la responsabilité de chacun d’oser provoquer le conflit utile.
Un programme très riche pour la 9ème édition de l’Agile Tour Rennes 2017 qui s’est tenue les 13 et 14 octobre dernier et a réuni plus de 40 conférenciers sur des thématiques clés de l’Agilité.
Retour sur cet événement avec Hervé, Nicolas et Séverin qui, en plus des conférences qu’ils ont animées, en ont profité pour arpenter les couloirs de l’INSA et dénicher des nouveautés sur l’Agilité.
Comment s’est passé l’agile tour de Rennes ?
Nicolas : N’étant présent qu’une seule journée (le Vendredi), tout est passé très très vite ! J’en garde un super souvenir avec un accueil très chaleureux et une équipe d’organisation disponible et passionnée. Nous avons poursuivi les discussions le soir au restaurant et ce fut un beau moment de partage. Les sujets couverts par cette édition étaient larges et convenaient aussi bien aux novices qu’aux experts.
Séverin : Super bien. L’organisation était au top, on sent qu’ils ont de nombreuses années d’entraînement. Le programme était super intéressant, dommage que je n’ai pas pu rester le samedi car Christian Den Hartigh et Alistair Cockburn ont l’air d’avoir eu beaucoup de succès vu les tweets qui sont passés. Hâte de voir leurs conférences en vidéo.
Hervé : Pour compléter ce que dit Séverin, je confirme: les keynotes d’Alistair et Christian étaient très riches d’idées à tester. La deuxième journée était plus familiale: beaucoup d’enfants ont participé à des ateliers qui leurs étaient dédiés (et tout ça sans trahir ni simplifier l’agilité 🙂
Quelle a été pour vous la découverte de l’événement ?
NL : Le dîner du Vendredi était riche en échanges et j’ai fait la connaissance d’un speaker qui m’a surpris par sa créativité. Il tenait une conférence le Samedi matin sur l’agilité vue par les animaux : original et surtout rafraîchissant comme intervention.
SL : J’ai adoré voir un consultant qui me suit depuis longtemps dans ma carrière et qui a fait preuve d’une grande maîtrise pour sa toute première conférence. Mais chut, je ne donnerai pas son nom.
Une conférence coup de cœur à laquelle vous avez assisté ?
NL : La conférence d’Alexandre Gérard (“Libérer l’entreprise de son patron… pour plus de performance”) très maîtrisée dans le discours. C’était (déjà) la troisième fois que je voyais Alexandre Gérard se produire et force est de constater qu’il a fortement gagné en impact dans son niveau de discours et surtout sa gestion des silences.
SL : Forcément, je vais parler de la conférence “Changer le monde une conversation à la fois” de Gery Derbier. Gery que j’ai connu il y a quelques années et qui m’avait fait découvrir à l’époque Solution Focus. Très sympa de le revoir ici.
HT : J’ai adoré la conférence d’Alistair. Pour lui, c’était une grande première: parler une heure en français ! Ses travaux actuels essaient de reformuler le manifeste agile de façon beaucoup plus compacte, et de proposer une approche différente de l’apprentissage de l’état d’esprit “agile” : kokoro (plutôt que Shu Ha Ri)… Je vous laisse chercher ces deux expressions sur votre moteur de recherche préféré.
Une anecdote à partager ?
NL : A l’occasion de cet Agile Tour de Rennes j’ai effectué ma première conférence en tant que speaker (en fin de matinée le Vendredi). J’étais très stressé si bien que je n’ai absolument rien retenu de la première intervention (de Gery Derbier) qui avait l’air très intéressante. Je m’efforçais d’écouter par intermittence … avant de décrocher quelques secondes plus tard. J’étais sans cesse ramené à mon introduction que je bachotais.
Au final, j’ai l’impression d’avoir passé la conférence à copier le comportement de mon voisin, notamment pendant les animations. J’étais là sans l’être !
SL : Comme j’ai fait mes études à Laval (avec quelques soirées à Rennes à l’époque), j’ai gardé quelques connaissances dans la région. 2 amis d’école d’ingénieur se sont arrangés pour venir me voir, et j’ai aussi croisé un ancien collègue de promo que je n’avais pas vu depuis 15 ans dans les couloirs.
Je suis intervenu le 10 octobre dans une grande banque française à l’occasion de leur « Agile Day » annuel. On m’a demandé d’intervenir sur l’impact de la transformation agile sur le management.
Mon constat est que la transition managériale dans les grands programmes de transformation agile n’est pas efficace. Ce constat commence à être partagé et mes réflexions m’ont amené à identifier une approche différente de celle traditionnellement mise en œuvre.
Pour développer les Hommes, travaillez sur l’environnement en premier
Quand vous souhaitez amener une entreprise vers un leadership plus agile, il ne suffit pas de décréter qu’elles doivent devenir agiles. Il est nécessaire de rénover le système, qui dans la quasi-totalité des cas, n’est pas compatible en l’état.
Supprimer les silos entre les métiers, les équipes de développement et les équipes de production (approche que j’appelle BIZDEVOPS) est une première étape d’une transformation agile. Modifier les mécanismes contre-productifs, comme les systèmes d’objectifs orthogonaux entre DEV et PROD par exemple, devrait être l’étape suivante. On peut même imaginer une gouvernance d’entreprise basée sur une information transparente, fraîche et honnête, générant des prises de décisions décentralisées et efficaces.
Pour travailler sur le système, vous pouvez démarrer par :
identifier clairement et communiquer beaucoup sur la vision de l’entreprise : son but, sa raison d’être. Finalement, le rôle du dirigeant pourrait se résumer à cela : répéter encore et encore la raison d’être de l’entreprise. C’est d’ailleurs une constante dans les organisations « libérées » qui surperforment dans leurs domaines d’activité.
décentraliser les prises de décisions en donnant plus d’autonomie. Cela signifie en corollaire de garantir un accès transparent à l’information, de développer les compétences, de bâtir des interactions basées sur la confiance mutuelle et de donner le droit à l’erreur dans une approche « fail fast, learn fast ».
Former n’est pas assez
Une fois la prise de conscience et les modifications réalisées au niveau de l’organisation, accompagnez vos managers dans le changement nécessaire de posture. Car en modifiant l’organisation et les interactions entre les différentes parties prenantes, l’impact sur le manager est plus important qu’il ne pourrait y paraître. J’ai déjà rencontré des chefs de projets qui venaient se plaindre de l’agilité parce que leurs équipes parlaient désormais directement avec le Product Owner pour la priorisation des sujets, alors que c’était leur prérogative quelques mois plus tôt.
D’une approche où le manager est traditionnellement un sachant promu pour sa compétence technique (et pas forcément sa compétence en leadership !), nous évoluons vers une approche où le manager s’oriente plutôt vers une posture d’hôte (Host Leadership) ou de coach, avec comme objectif de faire émerger de nouveaux leaders dans son équipe.
Plutôt que d’envoyer les managers en formation pour leur apprendre des recettes qu’ils ne pourront/sauront pas appliquer dans la plupart des cas, préférez un accompagnement sur le terrain. La formation peut être envisagée comme un apport complémentaire si nécessaire et dans un second temps. Le coaching des équipes et des individus amène des résultats bien plus probants car les acquis sont ancrés dans le concret, et surtout, l’apport régulier du coach sécurise la montée en compétences opérationnelle. L’expérience du coach va aussi aider à gérer des situations délicates qui ne manqueront pas d’arriver, et également à identifier les ajustements nécessaires aux modifications réalisées sur le système, dans une approche d’amélioration continue.
