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.
« Il nous faut innover ! Relancer la créativité », tel est le cheval de bataille des entreprises pour « rester compétitives ». Mais force est de constater que les entreprises historiques peinent à bâtir du neuf, à créer ces synergies en interne dont elles rêvent tant : des équipes transverses, cross-fonctionnelles, auto-organisées qui se mettent à monter des projets innovants sans que personne ne leur ait demandé quoi que ce soit.
Or l’innovation ne vient pas des processus*, mais de la capacité des salarié.e.s à penser en dehors du cadre et, plus difficile encore, à exécuter cette même idée dans un environnement hostile à l’inconnu… Mais alors, comment infuser du neuf ?
De manière opérationnelle, faire du neuf signifie notamment favoriser deux phases : l’inspiration et la création. Voici quelques exemples concrets.
#1. Inspiration : organiser des « Learning Expeditions » ou expéditions d’apprentissage
Quel est le pire ennemi des organisations contemporaines dans ce monde « ouvert », « agile », « disruptif » et tout le tralala ?
Le cloisonnement ! Et pour cause, comment créer du neuf si l’on a comme seul modèle d’inspiration le vieux et le poussiéreux que l’on veut changer ?
Or, vous avez peut-être remarqué que personne ne sait réellement ce qui se passe en dehors de leurs murs, chacun fantasme et raconte à la machine à café ce qu’il a entendu du fonctionnement des uns et des autres : « le petit frère du cousin de ma belle-mère travaille chez Google et il paraît que là-bas on innove en faisant la sieste ! ». Ben voyons.
Alors pour explorer de nouveaux possibles et (enfin) innover, les expéditions d’apprentissages sont indispensables ! Prendre du dehors pour inspirer dedans.
Dans les faits, il s’agit d’aller visiter une entreprise libérée* pour s’apercevoir que laisser des salariés s’auto-organiser ne mène pas au chaos ; ou encore d’assister à une conférence chez The Family pour prendre conscience qu’il ne faut pas plus de 48h pour créer un Produit Minimum Viable, l’innovation de rupture de demain !
48h pour monter sa startup https://www.youtube.com/watch?v=ieq4Ugzr8Uw&t=4s
Bref, vous l’aurez compris ces expéditions ont vocation à casser les préjugés de chacun sur ce qui est possible ou non. Et sortir de sa zone de confort.
Astuce : chez Rhapsodies Conseil nous avons construit un calendrier d’inspiration. Par exemple, dans le cadre de notre transformation d’organisation les membres du comité exécutif reçoivent des contenus inspirants sur les entreprises organiques : un jour un contenu qui parle des prises de décisions dans les entreprises libérées ou d’une autre manière d’engager les nouvelles générations.
#contenu inspirant pour changer les pratiques actuelles
*Entreprise dans laquelle chacun est susceptible de prendre toutes les décisions qu’il pense être bonne pour l’entreprise sans en avoir à référer à un supérieur hiérarchique.
#2. Création : organiser un product day
Lorsque j’ai débuté dans le monde professionnel dans une grande entreprise, j’ai eu le sentiment que pour créer quoi que ce soit tout était plus compliqué que dans la « vie réelle ». Par exemple pour ajouter deux fonctionnalités à l’application de ce mastodonte dont je tairai le nom, les étapes étaient les suivantes :
Remplir un dossier avec les spécifications, les risques, etc. ; durée : 2 mois
Envoyer son dossier au comité de pilotage qui se réunit 4 fois par an ; durée : 4 mois
Le projet est rétorqué parce qu’il manquait les notes de bas de page, durée : bien trop longue
Vous l’aurez compris, dans ces conditions ni les entreprises, ni les individus ne s’y retrouvent. Alors voilà comment nous nous y sommes pris pour créer le programme « devenir intrapreneur : de 0 à 1 » sous la forme d’un produit minimum viable lors de notre dernier product day :
Jour 1 :
Interviews pour recenser les attentes des entreprises et des individus #CarteEmpathie
Première curation de contenus (vidéos, article, etc.) sur le thème : « développer un état d’esprit de hacker »
Jour 2 :
Envoi des contenus sous forme d’un mailing à quelques cobayes + recueil des avis + amélioration du premier mailing
Seconde curation de contenus sur le thème : « création de valeur en cycle court » (c’est quoi un produit minimum viable, les étapes pour y arriver, etc.)
Jour 3 :
Envoi d’un second mailing sur la « création en cycle court » + recueil des avis + amélioration du second mailing
Curation de contenu sur le thème : « vendre son projet en interne » (pitcher un projet, fédérer des individus autour d’un projet, etc)
Envoi du troisième mailing sur le thème : « vendre son projet en interne » + recueil des avis + amélioration du troisième mailing
Jour 4 :
Présentation du programme de 40 jours : « devenir intrapreneur » dans son entreprise Il nous a donc fallu 4 jours pour fabriquer un produit minimum viable, c’est-à-dire un produit qui répond aux premiers besoins que l’on avait détecté pendant la phase d’interviews. Un investissement de temps et de moyen faible pour un impact maximum.
Pour aller plus loin !
Favoriser la créativité des individus et du collectif fait émerger des comportements et des pratiques durables liés à une culture d’entreprise où la prise d’initiative et de risque devient la norme. Car comme je l’évoquais en introduction, l’innovation et la créativité sont intrinsèquement liées à la capacité de l’organisation à bâtir un environnement et un état d’esprit favorables à ces prises risques. Et pour cela, la transparence et la confiance ne sont plus seulement des valeurs, mais au cœur de l’organisation et du pilotage de l’entreprise.
*sinon les grandes entreprises seraient championnes du monde de l’innovation ! 😉
En cas de départ de l’entreprise, 75%* des salariés ne quittent pas leur emploi mais leur manager, c’est donc bien que le management joue un rôle clé dans la rétention des talents.
Cet article illustre 3 exemples de management qu’il vaut mieux éviter à l’avenir :
Ne pas donner l’exemple
Ma manager m’engueule sur de l’organisationnel, sur de la gestion de projet, mais c’est énervant car elle ne se plie pas aux mêmes règles que nous.
Claire
La semaine dernière mon manager m’a dit : « Tu as 25 ans, c’est à toi de te former seule sur Google Analytics, Google Adwords, Photoshop, on ne va pas engager des dépenses pour le Groupe alors qu’il y a plein de formations en ligne. » Alors que dans le même temps il fait des notes de frais à tout bout de champ, même pour ses cafés.
Carole
De manière générale, chacun est disposé à prendre de manière constructive les remarques qui lui sont faites. Mais lorsque le manager ne s’applique pas la même discipline, il cultive alors un sentiment de défiance et nourrit le désengagement du salarié. « Lead by example » est désormais la devise du management du 21e siècle ! C’est d’autant plus vrai à l’ère du numérique qui, bien au-delà de l’aspect technologique, place la coopération horizontale comme la nouvelle norme d’organisation.
Ne pas expliquer pourquoi
Tu es trop jeune pour comprendre.
Vincent
Je n’ai pas le temps de t’expliquer pourquoi, fais-le c’est tout
Maxime
Si le rapport d’autorité a fonctionné (relativement) bien pour nos parents et nos grands-parents, ce temps semble révolu. Donner du sens aux individus n’est plus une éventualité, mais un des devoirs de l’organisation dont le manager est porte-parole. Sa casquette pivote quelque peu et nécessite qu’il explique le « pourquoi » pour susciter l’adhésion et l’engagement des membres de son équipe pour laisser le « quoi » et le « comment » à l’appréciation des individus désormais engagés.
Ne pas laisser de place à la prise d’initiative
Quand j’ai proposé une idée de projet qui aurait eu un impact concret pour nos clients, mon manager m’a tout de suite dit : ça ne marchera jamais, passe à autre chose. J’aurais aimé qu’il me laisse au moins essayer. — J’ai compris que ce n’était pas avec ce manager que j’avais envie d’évoluer. —
Pauline
Une petite phrase suffit à tuer le poussin dans le l’œuf et enterrer six pieds sous terre l’engagement de vos collaborateurs. Les individus qui prennent des initiatives sont pourtant la poule aux œufs d’or des organisations du 21e siècle. Il n’y a qu’à voir les cultures d’entreprise déployées par les BlaBlaCar, Facebook, Leboncoin et consorts pour s’en convaincre. Par exemple, la devise chez Facebook est « Move fast and break things », une incitation à prendre des risques largement relayée et encadrée par les « coachs/managers ». Oui, parce que la prise d’initiative s’organise ! On travaille des MVP « Minimum Valuable Products » pour valider des concepts avant de passer à plus grande échelle ; en cycle court pour limiter l’investissement ; piloté à l’aide d’OKR (Objectives and Key Results) pour s’assurer que le projet est aligné avec la stratégie de l’entreprise.
En résumé
Les entreprises ont tout intérêt à piloter et encourager leurs salariés dans la prise d’initiative si elles veulent continuer à briller (exister !). Il est urgent de penser un cadre dans lequel les individus puissent s’engager, sorte de laboratoire des innovations de demain !
* : source – Infographie Officevibe, “Les piliers de l’engagement des collaborateurs”, 2016
Je vous partage ici deux outils de coaching très simples et relativement puissants découverts en mai dernier lors de la conférence « Heart of Agile » qui visent à accompagner la transformation agile des organisations.
Ces outils, qui se basent sur une méthode de questionnement et un principe de fonctionnement itératif, se révèlent être particulièrement efficaces pour analyser les problématiques de transformation d’organisation débouchant ainsi sur des actions concrètes d’amélioration.
Comme on se laisse facilement convaincre par les principes de l’approche, mais qu’elle peut se révéler assez difficile à transposer dans certains cas : il m’a semblé intéressant de vous partager ici des exemples d’applications.
Solution Focus, back to basics
D’habitude, on a tendance à raisonner en termes de problèmes à analyser et de brainstorming classique, Solution Focus constitue une approche alternative où on se concentre sur la solution plutôt que sur les problèmes.
Mais avant toute chose, « la Solution Focus », qu’est-ce que c’est ?
« Solution focus » autrement appelé – Thérapie brève orientée solutions fut créée au « brief family therapy center » de Milwaukee par Steve de Shazer dans les années 80.
La thérapie brève orientée solutions permet en effet de ne pas focaliser sur le problème mais à l’inverse de considérer la solution comme déjà là ; le problème comme étant déjà résolu.
Cette forme de thérapie systémique & stratégique dont la « projection dans un futur réalisable » est très impactante peut se fait grâce à des outils que nous allons mettre ici en lumière.
« Quel est ce besoin que nous avons d’aller toujours chercher ce qui ne va pas, au lieu de s’intéresser à ce qui fonctionne » ?
Steve de Shazer a cherché, au contraire, à « faire toujours plus de la même chose », mais cette fois, toujours plus de ce qui marche.
C’est ainsi qu’est née l’orientation solutions, une des approches les plus innovantes – et les plus simples – de ces dernières décennies.
Au préalable, après avoir « vérifié » que le client et/ou l’équipe souhaite(nt) véritablement résoudre une problématique grâce à l’embarquement, avancer vers un objectif orienté solution.
Explorons les outils
1er outil : la « question miracle » : Pendant la nuit un miracle s’est produit et votre problème a été résolu
L’idée est de construire un questionnement permettant d’amener une, voire plusieurs personnes à décrire de manière détaillée un futur désirable. C’est à travers cette description qu’on cherche à ce que la ou les personnes trouve(nt) ce qui peut contribuer à aller vers ce futur désirable.
Le travail de questionnement vers l’objectif peut se faire de 2 façons.
On se projette vers le futur, vers cette butée contextuelle qu’est la date de réalisation de l’objectif. Comme si on y était, on considère que l’objectif est atteint et on positionne le client dans cette perspective. Le questionnement du coach se conjugue au présent.
Exemple :
Votre problème est résolu, qu’est-ce qui a changé ? A quoi le voyez-vous ? Comment les autres le voient-ils ? Ce mode de questionnement permet de faire vivre et de faire ressentir la situation au présent et d’ancrer le client dans sa réalité, (ressources, solutions non conscientes, sens…)
Ou alors, de manière structurée par étapes successives et chronologiques, dans un mouvement de A (le présent) vers B (le futur). Le questionnement du coach se conjugue au futur.
Quand vous aurez atteint votre objectif, à quoi le verrez-vous ? Comment les autres le verront- ils ? Possibilité pour le client d’imaginer ce futur en le regardant comme un écran projeté devant lui.
Prenons un exemple concret appliqué à un cas de transformation (Continuous delivery)
Le Client : On n’arrive pas à passer en continous delivery…
Le Coach : Et si vous y arriviez, à quoi le verriez-vous ?
Le Client : On déploierait souvent, les mep se dérouleraient sans soucis, on arriverait à anticiper les dépendances entre nos équipes.
Le Coach : Et comment réagirais-tu ?
2ème outil : l’échelle : « sur une gradation de 1 à 10 », quelle note donnerais-tu ?
Prenons un exemple concret appliqué à un cas de transformation (Niveau d’agilité de l’organisation)
Ici, on applique le principe agile d’itérations courtes pour s’attaquer à un sujet complexe :
Le coach : Est-ce que tu pourrais donner une note de 1 à 10 sur le niveau d’agilité de ton organisation ?
Le client : disons 3
Le coach : qu’est-ce qui fait que tu es déjà à 3.
Cette question a pour but d’identifier les ressources sur lesquelles nous pouvons nous appuyer avant de passer à la prochaine étape.
Nous passons alors à l’étape des petits pas.
Etape permettant de passer d’une logique de sens à une logique d’actions ; Le coach va accompagner l’équipe sur des « petits pas » car il faut qu’il y ait un apprentissage nouveau et que cela se fasse naturellement. On va être dans une logique de cercle vertueux, la logique dit des objectifs atteignables, permettant d’arriver jusqu’à la note de 4 ! (Auto-organisation, …).
Le coach : tu me dis que ta note est de 3, qu’est-ce que tu verrais de différent si cette note était de 4.
En répondant à cette question, on identifie des propriétés que nous pourrions observer dans la situation si nous avions fait ce +1.
Une fois ces étapes effectuées, on va itérer sur quelques semaines ou mois jusqu’à ce que l’on considère avoir obtenu un niveau de qualité acceptable : 7 ? 8 ? 10 ?
A vous de choisir en fonction des objectifs visés !
Et pour finir, ces quelques mots inspirants d’Alistair Cockburn, (THE master of Agile) qui en appliquant lui-même sa propre méthode nous invite au petit pas suivant :
« La confiance et l’appropriation sont les deux leviers principaux pour atteindre un management inspirant et j’insiste sur l’importance de penser l’intégration des nouveaux collaborateurs, notamment les plus jeunes, comme votre meilleur atout pour faire émerger une culture différente, agile.
Toutes les grandes entreprises ont lancé leur vaste chantier d’agilité à l’échelle. Mais dans quel but ? Devenir une entreprise agile ? Ont-elles au moins compris ce que cela voulait dire ? Ou assistons-nous tout simplement à une ruée vers la dernière mode ?
Parce que toutes les grandes entreprises ne parlent que de ça
Le passage à l’agilité à l’échelle est la grande tendance du moment dans les entreprises. Les expérimentations de mise en œuvre de l’agilité dans les équipes ont fleuri ces dernières années avec plus ou moins de succès. Qu’importe, les dirigeants veulent que leur entreprise soit « agile ». Une solution s’impose, l’agilité à l’échelle, soutenue à grand renfort d’investissement marketing par des « frameworks » qui pullulent.
Autant le dire tout de suite, je ne rentrerai pas dans la guerre des frameworks, à essayer d’identifier lequel est meilleur que l’autre. De mon point de vue, tout framework est bon dès lors qu’il est utilisé comme un framework (un cadre, une boite à outils) et pas comme une méthode.
Le flou est savamment orchestré par les organisations qui commercialisent ces framework et certains consultants qui y voient leur intérêt.
Mais qu’elles n’ont pas compris les valeurs de l’agilité
Devenir une entreprise agile, c’est avant tout repenser le mode de fonctionnement pour qu’il soit recentré vers les clients, internes et externes. Externes pour produire un maximum de valeur à l’attention des clients qui font gagner de l’argent à l’entreprise. Internes pour faire en sorte que les collaborateurs de l’entreprise soient dans les meilleurs dispositions pour délivrer cette valeur. C’est aussi mettre en place un système propice aux changements, un environnement bienveillant, une culture de l’expérimentation et de la tolérance à l’échec.
Combien de grandes entreprises ont ces valeurs dans leur ADN ? Croyez-vous que la mise en œuvre à l’échelle d’une entreprise d’un cadre préconçu quel qu’il soit va réussir à changer cela ?
Parce que c’est vu comme une manière d’améliorer l’existant alors qu’il faut révolutionner les usages
Mettre du Kanban dans le pilotage de la stratégie ne fait pas de votre entreprise une entreprise agile.
Réaliser des « PI Planning » tous les 6 sprints non plus.
Ce qui fait une entreprise agile, ce sont des petites équipes autonomes, responsabilisées sur leur part de chaine de valeur, accompagnées par des leaders bienveillants.
Travailler sur la synchronisation des équipes n’est pas inutile, mais la systémique nous apprend qu’il est nécessaire de regarder plus loin, et particulièrement sur la culture managériale et la posture des managers.
Et que ceux qui sont à l’initiative de ces changements doivent d’abord se les appliquer à eux-mêmes.
L’agilité à l’échelle est une approche qui vise souvent (dans les intentions) à rendre l’entreprise plus agile, mais qui est menée de manière bottum-up. En effet, on va s’attaquer d’abord aux équipes de développement ou de production sans changer l’environnement autour. De mon point de vue, cela a peu de chances d’aboutir réellement.
L’entreprise agile, avec une approche top-down, est plus intéressante à creuser car elle demande un engagement des dirigeants à changer eux-mêmes et à renoncer à certains pouvoirs ou privilèges. Les exemples d’entreprises libérées, organiques, holacratiques deviennent chaque jour plus nombreux.
Parce que nous devons nous inspirer mais pas copier
« Pendant la ruée vers l’or, ce ne sont pas les chercheurs d’or qui se sont le plus enrichis, mais les vendeurs de pioches… ».
Les pioches ont changé mais les résultats sont les mêmes. Plusieurs entreprises sont revenues de ces transformations à la hussarde réalisées en « appliquant des modèles », avec pour impact une image négative de l’agilité.
Quelques bonnes pratiques que vous pouvez suivre
Plutôt que de déployer des framework d’Agilité à l’échelle, si vous voulez transformer votre entreprise en Entreprise Agile, il est intéressant de disposer des ingrédients suivants :
Assurez-vous de disposer d’un sponsorship fort et d’une implication réelle des dirigeants (avec des changements visibles).
Faites-en sorte d’exprimer clairement les enjeux liés à la transformation.
Faites travailler les collaborateurs pour faire émerger des valeurs communes partagées par tous.
Communiquez, communiquez, communiquez : régulièrement et surtout de manière transparente (arrêtez de penser que les employés ne sont pas prêts à comprendre une situation donnée)
Ce type de transformation appelant un changement de mindset, mettez en œuvre un dispositif d’accompagnement adapté à toutes les populations : équipes de développement, de production, managers et top managers, architectes, parties prenantes métier…
Et n’oubliez pas de vous faire accompagner par d’autres passés par le même chemin : des consultants bien sûr mais aussi d’autres chefs d’entreprise ou managers.
Dans un monde de plus en plus complexe, la capacité des organisations à intégrer rapidement les changements et à s’adapter en permanence devient un critère prépondérant de développement, voire de survie.
Pour gagner en souplesse et arrêter les processus lourds et complexes, accélérer l’innovation, rester compétitives, certaines entreprises comme Spotify, Michelin ou encore Favi ont sauté le pas de l’Entreprise Agile.
Cette transformation implique de repenser la culture d’entreprise pour favoriser la prise d’initiative et de réinventer l’organisation du travail autour du client avec des équipes auto-organisées et cross-fonctionnelles.
Découvrez un très bon exemple (mais pas un modèle) de ce type d’organisation : l’organisation Spotify.
Cet exemple de transformation a réussi parce qu’il était adapté à l’organisation Spotify et tenait compte de sa culture, ses valeurs et de ses pratiques.
