Recettes pour accélérer la transformation agile à l’échelle

Compte rendu réalisé par Nicolas Kalmanovitz

Qui cuisine ?

Ce petit déjeuner a été présenté le 27/04/2017 par Nicolas Kalmanovitz, coach agile et manager OCTO ainsi que Thomas Diavet, directeur R&D de MEETIC. Se sont joints à eux pour une table ronde : Irène Doan, coach agile à LECTRA et Alban Dalle, le leader de la tribu d’agilité à l’échelle d’OCTO. Dominique Lequepeys, coach agile et manager OCTO a assuré la facilitation graphique.

La cuisine comme origine

D’après certains chercheurs, c'est quand l'homme a cuit sa nourriture, passant de 9h à 3h de digestion, qu’il a pu prendre le temps de réfléchir à autre chose qu’à la nourriture. Il a pu ainsi développer son imagination et sa capacité à raconter des histoires. Pour Yuval Harari dans « Sapiens » c’est justement cette capacité à raconter des histoires qui permit à l’hominidé de collaborer à une très grande échelle, se différenciant ainsi du reste du règne animal.

Le petit déjeuner servi, nous avons, à notre tour, pris le temps d’une matinée pour partager nos histoires et ainsi accélérer notre capacité à tous collaborer à grande échelle.

I. Quand le changement n'est plus une option

Il y a urgence

Il y a urgence dit-on, urgence à changer, urgence à embrasser la transformation digitale, à résoudre l’incertitude et répondre plus vite aux attentes du marché. Mais nos organisations sont devenues lentes, complexes et résistantes au changement. Les interactions ne fonctionnent pas on ne comprend plus le “qui fait quoi”, Il y a “perte de sens” et quand les équipes ne comprennent plus le “pourquoi?”, elles se désengagent. Il y a aussi comme une perte de “bon sens” , dans nos “pourquoi du comment?”, le pourquoi faut il un formulaire RJ.4212 pour mettre en production.

Dans ces conditions, comment relever le défi de retrouver la croissance, d’assurer la transformation digitale, d’apprivoiser l’incertitude, de réinventer l’expérience utilisateur ou d’éviter l’uberisation ? Sans les bonnes conditions de collaboration, on échoue à s’organiser en grand nombre et c’est le drame, le cauchemar en cuisine.

Il est alors temps de réapprendre à cuisiner et de prendre le temps d’apprendre à aller plus vite. C’est souvent une des raisons principales de transformation agile.

De plus en plus nombreuses sont les entreprises séduites par la promesse d’une meilleure capacité d’adaptation, de livraisons plus fréquentes, de solutions plus simples et couronnées de succès, le tout produit par des équipes ré-engagées et responsables.

Mais réaliser l’Agilité à l’échelle de l’entreprise est un défi en soi.

L’agilité à l’échelle

L’agilité à l’échelle, c’est quand l’agilité couvre la stratégie et la tactique avec la gestion de programme comme courroi de transmission; c’est être agile à l’échelle de l’équipe, à l’échelle multi équipes et à l’échelle du portfolio et du budget avec l’utilisateur au cœur des préoccupations.

Il y a des frameworks (SAFe, LESS, Nexus, ...) pour porter l’agilité à l’échelle de l’entreprise et ils sont tous séduisants mais ce sont des recettes complexes et quand on les applique à une entreprise, le choc peut être violent, Le framework peut être incompatible avec le contexte.

Les anti-patterns

Il faut dire que les organisations ont une façon peu agile d’aller vers l’agile.

Elles reproduisent leurs comportements réflexes : • Le plan de transformation est impulsé en TOP-DOWN ce qui freine l’adoption • Des organisations cibles sont conçus en petit comité sans prise en compte des spécificités des différents contextes internes • Et dans le meilleur des cas, des formations théoriques sont prévues pour accompagner le changement ce qui ne manque pas de cristalliser la résistance.

La recette de l’agilité à l’échelle humaine

Entre Coachs agile OCTO nous avons partagé nos expériences de transformations réussies et 3 points communs sont ressortis :

• Les moments de bascule, les bons en avant ont toujours été déclenchés par des ateliers collaboratifs entre les différents métiers et les livrables issus de ces ateliers (forum ouvert, brainstorming, atelier vision…) • Les stratégies de transformations qui fonctionnent sont celles qui se basent sur l’expérimentation rapide et continue (moins de plan et d’organisation cible mais plus d’expériences et d’apprentissages rapides) • On apprend mieux en faisant et c’est en expérimentant de nouvelles pratiques que l’on peut changer de mindset et de culture

C’est ainsi qu’en prenant le temps de privilégier les personnes et leurs interactions on peut porter l’agilité à l’échelle HUMAINE.

Plus les personnes interagissent au sein d’ateliers collaboratifs où elles expérimentent de nouvelles pratiques, plus rapide et durable est la transformation.

Ce sont ces principes que nous allons illustrer autour de 3 dimensions : L’équipe, la synchronisation multi-équipes et les stratégies de transformation

II. Le bootstrap d’équipe

Le constat d’échec

Plus de 70% des projets échouent alors qu’environ 80% des risques d’échec surviennent avant le moindre développement car ils sont issus de la qualité de la communication et de l’alignement entre les différents contributeurs. En matière d’organisation, il ne faut jamais oublier la Loi de CONWAY : « Les organisations conçoivent des produits qui sont des copies de la structure de communication de leur organisation. » Si la communication n’est pas le point fort de votre organisation, il y a de bonnes chances pour que vos produits soient insatisfaisants.

Le produit c’est l’équipe

Chez OCTO, nous considérons que « Le produit c’est l’équipe » et c’est pourquoi nous privilégions des équipes pluridisciplinaires et co-localisées. L’équipe idéale doit, en effet, profiter de conditions de communication idéale (co-localisation), à l’image de ce classique des features de teams des conférences agiles.

Une brigade qui ne se comprend pas à demi-mot ne réalise pas de grands menus. Mais il ne suffit pas de réunir les acteurs. Il ne suffit pas de réunir les ingrédients pour réussir une recette. Une équipe agile doit être alignée sur une vision, prête à développer un produit intégré à son SI, gérant ses risques et son planning, engagée et responsable, collaborative et auto-organisée.

Le cadrage 360°

Pour obtenir ce résultat, nous suivons la recette du cadrage 360°. Une série d’ateliers prenant 2 à 7 jours selon la maturité et la complexité de vos projets, de vos organisations. Le cadrage 360° va lever le voile sur tous les aspects organisationnels, techniques et fonctionnels en privilégiant la co-conception avec tous les contributeurs via des ateliers collaboratifs (plutôt que des réunions en petits comités).

Je vous propose de faire un Focus sur le 1 er atelier du cadrage 360°: le bootstrap d’équipe. C’est celui qui est trop souvent négligé alors même qu’il constitue la base, la pierre angulaire sur laquelle construire l’équipe.

Les objectifs du bootstrap

Les objectifs du bootstrap sont les suivants : • Développer l’esprit d’équipe pour être plus qu’une somme d’individus • Se rencontrer personnellement pour sortir des relations forcées et des réflexes de l’entreprise • Créer une dynamique positive et orientée solution pour être capable de surmonter ensemble les obstacles qui ne manqueront pas d'apparaître • S’aligner sur le travailler ensemble, prendre le temps de réfléchir aux interactions et de décider collectivement • Adopter l’agilité par choix et non par obligation en adoptant une définition commune de ce que l’on entend par là.

L’agenda

Ici, un exemple d’agenda type joué avec une équipe réelle.

L’accueil

Il consiste à prendre le temps de se saluer et de discuter de manière informelle en dégustant un croissant, un cookie…

L’introduction

C’est le moment de poser le cadre de l’atelier et se fixer un objectif commun. Le cadre est constitué de l’agenda, des règles et des objectifs. L’agenda permet à tout le monde de se projeter dans la journée et d’être rassuré par le fait que des temps de pauses sont prévus.

Les règles

Les règles de l’atelier vont assurer la qualité de la journée. Elles peuvent être préparées et présentées ou on peut les faire émerger par la discussion avec les participants. Dans les deux cas, il est utile de les dessiner et de les afficher à un endroit que tout le monde peut voir. En général, les équipes s’accordent sur les règles suivantes : • La bienveillance : on ne se critique pas, on ne parle pas des absents de manière négative, on est là pour progresser ensemble • L’écoute : on ne se coupe pas la parole • Le Focus : on ferme les PC et les téléphones car les emails peuvent attendre, aujourd’hui nous sommes ensemble (exception accordée à ceux qui doivent gérer les incidents de production). • Le timing : on respecte le timing, on revient à l’heure des pauses

Les objectifs

Le ou les objectifs de la journée posent l’autre partie du cadre. Pour chaque atelier du 360° il est important de vouloir obtenir un livrable. C’est l’objectif pragmatique qui permet de garder l’équipe concentrée et ce qui permet de lui faire vivre l’expérience du travailler ensemble. Dans le bootstrap, on se fixe 2 objectifs : • Livrer un nom d’équipe (ou de projet) • Redécouvrir les concepts clés de l’agilité.

Livrer un nom d’équipe est à la fois «tangible » et en même temps dénué de pression. L’enjeux étant à priori faible, l’équipe pourra plus facilement s’aligner et décider ensemble. Choisir ensemble sera juste assez compliqué pour que l’équipe puisse apprendre de ses mauvais réflexes et développer les bonnes pratiques qui lui seront utiles pour traiter des sujets plus sensibles et ce, dès les ateliers de cadrage suivants (rôles et responsabilité, roadmap etc.).

Une fois le cadre posé, il est temps de se présenter et de créer des liens. C’est l’objectif de l’ice breaker.

L’icebreaker

L’exemple utilisé concerne une équipe dont les membres se connaissent peu. L’animateur a choisi d’utiliser « le réseau social en papier ». Il consiste à demander à chaque personne d’écrire sur un demi A4 leur nom, leur poste et leurs hobbies. Chaque personne se présente en fixant sa fiche sur un grand tableau. Au fur et à mesure que les personnes identifient des hobbies qu’elles ont en commun, elles relient leur fiche par un trait de couleur. A la fin de l’exercice, de multiple traits s’enchevêtrent et relient l’ensemble des fiches à la manière d’une toile d’araignée. Les participants se reconnaissent liés par des liens autre que ceux du travail et se sont rencontrés comme lors d’un déjeuner ou d’une soirée au bar.

Débarrassés des à-priori du contexte ils sont prêts pour la collaboration.

La simulation

Il est alors temps de passer aux serious game ou aux fun games. Il s’agit d’apprendre par la pratique les concepts et principes clés de l’agilité. On peut utiliser le jeu des cocottes, le jeu des balles, etc. L’important est d’amener l’équipe à expérimenter le travailler ensemble sans enjeux tout en expérimentant les pratiques agiles et notamment le fait d’organiser le travail par itération et de prendre le temps de réfléchir à comment s’améliorer ensemble. L’équipe va alors CHOISIR de privilégier les interactions, de développer l’écoute, de prendre le temps de se donner du feedback et d’expérimenter pas à pas des modifications de leur workflow.

En utilisant la simulation et la métaphore, l’équipe va se poser la question du comment s’améliorer collectivement et prendre l’habitude de chercher à comprendre les contraintes des différents métiers.

Au fur et à mesure des jeux, l’équipe va construire un mur des concepts et des pratiques agiles qu’elle choisit d’adopter ou d’expérimenter. Ainsi, il sera plus facile lors des ateliers suivants d’aborder la question des rôles et des processus et il sera évident pour l’équipe dès sa première itération de mettre en pratique les enseignements de ce premier atelier.

Le nom d’équipe

La dernière partie de l’atelier consiste en la production du livrable : le nom de l’équipe. Pour ce faire, l’équipe va pratiquer : Le brainstorming, la co-conception itérative et incrémentale, la priorisation et faire l’expérience du consensus, de la prise de décision collective.

Ce sont autant de pratiques et de qualités qui seront utiles à l’équipe tout au long de la réalisation de sa mission, de son projet.

Le premier livrable

Ce premier livrable est clef. Choisir un nom est un acte fondateur. C’est un premier signe de culture et d’identité commune et le témoignage d’une prise d’autonomie. Biensûr, le résultat peut surprendre. Lors d’un bootstrap, une équipe pluridisciplinaire a choisi comme nom : « LES PETITS PONEYS »… Le jour ou il faut expliquer à la direction que l’équipe en charge du projet le plus stratégique de l’année se nomme... “les petits poneys” et que c’est ainsi que le projet sera désigné dans les communications internes... Quand le premier livrable en production n’est pas un “hello world” mais un “hello poneys”... Cela peut piquer un peu. Mais c’est très bien ! C’est une très bonne façon de tester la capacité du système à accepter le changement et à permettre l’autonomie. C’est également un très bon choix de la part de l’équipe et un très bon signe pour la suite du projet.

Lorsqu’un ensemble d’individus peu ou pas habitué à collaborer se met d’accord pour choisir ensemble un nom décalé et plein d’humour, c’est que nous avons obtenu une équipe, capable d’assumer son originalité et d’affronter les inévitables problèmes qu’elle rencontrera sur son chemin.

Et puis, les “petits poneys”disposent ainsi d’un très fort potentiel en mascottes et artefacts divers et variés; autant de possibilités pour renforcer son identité tribale.

L’ingrédient secret

L’ingrédient secret du bootstrap est le même que pour chaque atelier du cadrage 360° : Il s’agit de co-construire un livrable de manière collaborative, itérative et incrémentale. Cela permet d’expérimenter les pratiques agiles et de réinventer consciemment les conditions du travailler ensemble. A la sortie du bootstrap, l’équipe travaille différemment, communique mieux et ce, avant même d’entrer dans la phase de cadrage proprement dite. Ce n’est plus un ensemble de contributeurs mais bien une équipe qui peut relever les défis et réussir à livrer un incrément au produit ,une solution au besoin utilisateur.

Vous l’avez compris, l’agilité à l’échelle d’une équipe c’est fondamentale, reste à savoir comment rester agile avec de nombreuses équipes

III. Le release planning day @meetic, rituel collectif et acculturation agile

Nous allons vous parler d’une partie de la cuisine agile @meetic et en particulier du Release Planning Day : un rituel trimestriel de roadmapping inspiré du PI Planning de SAFe (Scaled Agile Framework de Dean Lefingwell)

Nous vous présenterons comment il fonctionne en pratique, comment nous l’avons implémenté et en quoi il s’est avéré être un puissant levier d’acculturation agile et un accélérateur de la transformation de l’entreprise.

Le Release Planning Day en pratique

Meetic grandissant, la construction des roadmaps et la gestion des dépendances entre équipes étaient devenues cauchemardesques : 6 semaines chaque trimestre. Le R.P.D. est apparu en réponse à ce problème.

Il s’agit d’un rituel d’entreprise, qui réunit les équipes qui y participent pendant 1 à 2 jours :

• Pour assurer la cohérence entre la stratégie d’entreprise et les roadmaps des équipes • Pour gérer de manière collaborative les dépendances entre équipes

L’objectif est d’aboutir à des Release plans partagés, plus réalistes, avec un @meilleur niveau de confiance des équipes. Chaque équipe repart donc avec un livrable, son Release Plan du trimestre ainsi que d’une vision d’ensemble de l’activité.

Les différentes étapes de l’agenda

1. Présentation de la Stratégie

La direction prend la parole devant tout le monde pour présenter les résultats du trimestre précédent ainsi que la stratégie et les priorités du nouveau trimestre.

Cela permet de mettre en perspective les objectifs annuels. Cela remet bien en tête de tous les priorités avant de passer à l’étape suivante.

Nos astuces : faire court, limiter le nombre de priorités, ajouter une présentation par les archi dev & ops des chantiers techniques prévus afin que chacun sache dans quel contexte technique va se dérouler le développement.

2. Release Planning par équipes

Ensuite, les équipes se séparent et les Epics (ou projets) sont présentés par le Product Owner de chaque équipe.

Au fur et à mesure, l’équipe estime en taille de tee shirt chaque épique et identifie les dépendances avec les autres équipes (les livrables nécessaires pour commencer ou finir une épique).

La taille S correspond à une faible charge de travail. Le M correspond à une charge normale de travail. Le L est soit long soit compliqué. Le XL est à la fois long et compliqué ce qui induit qu’il doit être re-découpé.

Une fois les Epics estimées, l’équipe effectue une première tentative de Release Plan : une planification sur 3 mois du développement des différents Epics réparties sur des itérations de 2 semaines.

Ensuite, l’équipe identifie et partage les risques en utilisant une matrice ROAM (Resolved, Owned, Accepted, Managed) assurant ainsi que les risques qui ne sont pas résolus ou acceptés en séance ont au minimum un owner et au mieux une action corrective.

Les risques pris en compte, l’équipe peut ajuster sont release plan.

Ceci fait ,l’équipe procède à un premier vote de confiance. Il s’agit d’une note sur 5 que chacun donne individuellement pour signifier la confiance qu’il a dans la capacité de l’équipe à respecter son planning.

Si la note globale est inférieure à 2,5, l’équipe procède à des ajustements du release plan.

Les équipes sortent de cette étape avec 4 choses : Leur Release Plan, leurs dépendances, leur tableau de risques et le premier vote de confiance.

Nos astuces : Limiter le nombre de tickets/Epics en amont; ne pas croire ceux qui pensent être prêts et que le RPD est une formalité; matérialiser les épics qui s’étalent sur plus d’une itération pour occuper l’espace; indiquer les dates correspondantes aux itérations du trimestre – tout le monde les mêmes.

3. Bourse des dépendances

La troisième étape est celle de la bourse des dépendances.

Les Tech leads, les Pos, les key people et tous ceux qui le souhaitent se rassemblent dans une même pièce. Les release plans sont affichés les uns à côté des autres et les tickets de dépendances sont posés sur le board des équipes concernées.

Démarre alors une période de discussions, négociations et ajustements… jusqu’à ce que toutes les dépendances soient réglées.

Une dépendance peut être acceptée, re-planifiée, sortie du scope ou déléguée. Les cas litigieux sont arbitrés avec le management. Toutes les équipes ne sont pas égales sur ce marché. Les features teams très indépendantes reçoivent généralement peu de demandes tandis que les équipes composants sont très sollicitées ce qui peut perturber leur propre release plan.

Nos astuces : Bien expliquer à chaque équipe les modalités de gestion des dépendances, faciliter le rituel mais surtout faire simple. Certains utilisent des matrices complexes, des fils etc. après quelques expérimentations, nous avons opté pour des tickets roses précisant l’équipe demandeuse, l’équipe demandée, le nom du projet et l’itération de livraison idéale. Chaque équipe a son board de dépendances sur lequel les demandeurs viennent poser leur ticket. Les tickets sont négociés et, dans le meilleur des cas, ajoutés au release plan.

4. Finalisation des Release Plans

Une fois les dépendances résolues, les release plans sont ajustés et si nécessaire, la confiance revotée.

Ensuite, les PO et les managers techs préparent une communication précisant ce qui est sorti du scope et ce qui est pris pour le trimestre à venir.

Nos astuces : Prévoir une joli format commun, pas trop verbeux avec, si possible un point de vue client sur ce qui va être livré.

5. Partage des résultats et vote de confiance

Enfin, chaque équipe présente le résultat à l’ensemble des participants. Une fois que chacun a une vision d’ensemble, un dernier vote de confiance peut être effectué.

Pour finir, un ROTI (note sur 5 du « Retour On Time Invested) et des applaudissements permettent de clore cet évènement.

Chaque équipe repart avec son Release Plan pour le suivre pendant le trimestre et alerter les équipes en cas de problème sur leurs tickets en dépendance.

Comment nous l'avons implémenté

Think big, start small, scale fast

L’exercice est globalement assez simple. Il s’agit d’un atelier de « release plan » collectif. Pour autant et à cette échelle, l’implémenter n’est pas une mince affaire. Contrairement à ce qu’on pourrait imaginer pour un rituel qui concerne potentiellement toute l’entreprise, nous avons fait le choix d’un déploiement progressif. Nous avons d’abord testé le principe avec 2 équipes, puis 5 équipes et augmenté chaque trimestre jusqu’à arriver aujourd’hui à une vingtaine d’équipes et environ 160 participants.

Nous avons donc géré ce changement en mode « test & learn » ce qui nous a permis de bien apprendre à l’organiser, à l’animer et à faciliter le travail des équipes. Nous avons porté une attention particulière à comment s’assurer que la mayonnaise prennent bien avant même d’envisager d’en faire un évènement d’entreprise.

S’appuyer sur les champions agiles

Ce qui nous a beaucoup aidé, c’est de nous appuyer sur les champions agiles dans les équipes. Ils ont accepté de jouer le jeu dès le début : • En cherchant à bien s’approprier le rituel eux-mêmes • En transmettant leur compréhension à leur équipe, à leur niveau • En participant à l’animation de l’événement

Et sur les managers

Les managers ont également joué un rôle crucial en prenant le relais, en montrant l’importance de ce nouveau rituel et en l’inscrivant dans le “sens de l’histoire” de la transformation de l’entreprise.

A la fois le Directeur Produit et le DSI ont commencé à intégrer le RPD dans la nouvelle histoire.

Demander du feedback

Un autre point important dans la réussite, c’est qu’après chaque RPD, 2 choses ont été organisées par les PMO : un sondage ouvert à tous les participants et une rétrospective avec une sélection de volontaires.

Cela nous a permis de favoriser l’autonomie et d’envoyer un message fort : ce rituel est pour vous, mené par les équipes et pour elles-mêmes.

Cela nous a également permis de responsabiliser tout le système : si vous n’êtes pas satisfait, il est de votre responsabilité de prendre part à l’amélioration du processus.

Et communiquez!

Enfin, la communication par les PMO, en amont et en aval de chaque session, a eu un rôle déterminant dans le succès du déploiement progressif.

Communiquer chaque trimestre sur la préparation et les résultats du RPD et sur l’élargissement du nombre de participants a généré la conviction qu’il n’y aurait pas de retour en arrière.

Les autres équipes ont rapidement commencé à demander de monter dans le train !

Un levier d'acculturation agile

Vous vous souvenez de notre petit problème de digestion préhistorique? Grâce à la cuisson, les hominidés ont donc pu prendre le temps de se raconter des histoires et d’apprendre à collaborer à grande échelle. Si j’étais un anthropologue venu de loin, que dirai-je du RPD ?

Une autre interprétation de l’histoire

D’une certains manière, il s’agit d’un rituel collectif saisonnier, dont la structure atavique remonte à la préhistoire et a pour objectif de conjurer la peur de l’incertitude, la peur du futur, tout en renforçant les liens entre les tribus.

Le rituel commence avec la présentation de la stratégie qui correspond à un partage de sens et à une réinterprétation de l’histoire à laquelle s’ajoute le récit des péripéties à venir : Le printemps des audites, l’été des campagnes d’acquisition etc.

Vient ensuite le rituel initiatique propre à chaque tribu qui produisent un artefact : le release plan. Ce dernier est un chemin métaphorique vers la prochaine saison. Sa construction s’accompagne d’un rituel de conjuration du sort : l’établissement de la matrice des risques.

Enfin chaque représentant des tribus se retrouvent pour une ANAGNORISIS collective avec la découverte des dépendances, des liens de parenté qui les unissent tous et renforcent de fait la cohésion du peuple tout entier tendu vers un objectif commun.

A la fin, il y a la célébration et la confirmation de la foi en un avenir commun écrit collectivement.

L’analyse est sans doute un peu capilotractée mais, pour autant, le RPD est bien un phénomène de culture.

Gérer la résistance au changement

Pour « scaler », mettre à l’échelle, il faut répondre à plusieurs problématiques : -La résistance du reste de l’entreprise (par ex : la Critique du silo). -L'inertie et les réflexes du système (par ex : le retour au processus de roadmap classique) -La coexistence de deux cultures (waterfall / agile) qui n’ont pas le même temps, les mêmes valeurs, rites, pratiques et vocabulaires; deux cultures qui ne se comprennent pas - Il faut fournir la marche qui va permettre à l’agilité de s’élever à une échelle supérieure.

Agile & Waterfall ensemble ?

En créant un espace de coordination commun, avec un langage commun, le RPD nous a permis de manager la coexistence de deux approches, Waterfall et agile tout en nous assurant que nous continuions dans le sens de la bonne transformation tout au long de notre transition.

La mise à l’échelle facilitée

A mesure que nous avons multiplié le nombre d’équipes agiles, le système s’est montré moins résistant et les équipes ont pu aisément se brancher les unes aux autres par le biais de ce rituel agile. Dans le même temps, ces équipes ont pu être protégées des réflexes de l’entreprise puisque l’on avait retiré le processus anti-agile de roadmap remplacé par le RPD.

Parce qu’il est plus facile de connecter des personnes que des processus, le RPD est devenu la colonne vertébrale de la mise à l’échelle.

Apprendre par la pratique ?

Le RPD a permis à toutes les équipes non agile de découvrir et d’apprendre par la pratique les méthodes, pratiques et principes agiles: l’itération, l’estimation en taille de tee shirt plutôt qu’en jour/homme, le découpage, la co-construction du planning, la valeur du facilitateur etc. Cet apprentissage s’est fait en douceur, en team-buildant, debout, en se parlant. Ainsi le RPD a permis de démystifier la transformation. Il ne s’agit plus d’être ou non agile mais simplement d’être intelligent ensemble.

Le rituel a permis à tous de toucher la magie, de faire l’expérience de l’agilité et de constater que c’est bien le collectif qui peut transformer le chaos en complexité gérée.

Un même rythme pour tous

Si nous avions demandé à l’ensemble de l’entreprise d’adopter des itérations de deux semaines, nous n’aurions pas été bien reçus. Au lieu de cela, nous avons utilisé une facilitation visuelle (le release plan) qui découpe le trimestre en plusieurs périodes de deux semaines. Cela permet à tout à chacun de s’y retrouver dans le planning et d’échanger sur les dépendances entre équipes. C’est devenu rapidement une norme partagée, un élément de culture qui a facilité la suite de la transformation agile des équipes.

Lorsqu’on ait déjà habitué à gérer son planning par périodes de deux semaines, le concept d’itération est facile à concevoir, à tester et à adopter.

Un outil de leanification””

Du point de vue du transformateur, le RPD facilite la “leanification” de l’ensemble de la chaîne. Il permet de réfléchir le workflow par rapport à la capacité réelle des équipes “contraintes”, les équipes rares et multi-clients qui concentrent la plupart des dépendances. Parce que l’on sait réellement ce que peuvent et ce que vont faire ces équipes, on peut initier un flux tiré et obtenir, au final, un planning général bien plus réaliste. Dans le même temps, le RPD permet d’initier des pratiques dev-ops sans effort. Les devs ont des dépendances ops… comme les dépendances se règlent en directe, on trouve plus facilement des solutions ensemble (“je ne peux faire ce projet mais, si je vous donne les droits et un peu de temps de support, vous pouvez peut être le faire tout seul...”)

Agir sur les processus

Avec le cycle de rétrospective sur le RPD, nous avons pu ancrer le principe selon lequel les process et l’organisation de l’entreprise peuvent et doivent évoluer par le travail de tous les acteurs. OPS, Produit, Dev, PMO travaillent donc ensemble à l’amélioration des processus et de l’organisation de manière régulière.

Lors d’une des premières rétrospectives, il en est ressorti un besoin de travailler l’alignement et le partage des priorités en amont du RPD. Cela a donné lieu à la mise en place d’un nouveau rituel pour partager les top priorités de chaque demandeur IT et Produit ce qui a également contribué à la fin du rapport client fournisseur. Une itération plus tard est apparu un besoin de lissage de la charge de cadrage en amont du RPD et de synchronisation des release plan tout au long du trimestre.

Cela a donné lieu à la mise en place d’un company kanban qui tire progressivement l’échelle portfolio de l’agilité à l’échelle.

Vers une nouvelle culture

Après quelques RPD, la culture de meetic a changé et ce rituel est devenu un composant de cette nouvelle culture. Il est le poul qui rythme l’entreprise. C’est un élément de l’identité de l’entreprise et non un changement subit. Le RPD a créé de la fierté collective. C’est une élément de la culture dont les meetic parle avec passion auprès des autres sociétés du groupe, auprès des candidats en entretien de recrutement et en conférence régulièrement.

C’est la fierté de pouvoir démontrer tous ensemble et régulièrement la qualité de leur collaboration et la force de leur collectif.

A vos fourneaux

Nous ne pouvons que vous souhaiter d’avoir la même chance et n’oubliez pas : 1. Il faut faire simple et avancer pas à pas 2. L’important c’est d’expérimenter 3. Ne focalisez pas sur le processus mais privilégier les interactions car c’est là que réside la condition de l’intelligence collective : quand tout à coup le tout devient plus grand que la somme de ses composants, quand l’agilité se déploie à l’échelle.

I. Table ronde : Stratégie de transformation et ingrédients secrets

Thomas, Irène et Alban ont accepté de répondre à nos questions et de nous confier leurs recettes pour réussir une transformation agile à l’échelle. Vous trouverez ci-dessous, quelques-uns de leurs enseignements.

De la stratégie du pilote à l’expérimentation continue

Pour promouvoir le changement dans un environnement à forte inertie, il faut s’en donner les moyens et marquer la rupture. Commencer avec une ou deux équipes pilotes peut permettre de passer une marche, de lancer la dynamique de changement sans pour autant prendre le risque de tout casser par une approche “Big Bang”. Une fois démontrés les premiers succès, il est plus facile d’accélérer la transformation et de déployer les nouveaux modèles à grande échelle. Pour autant, il faut faire attention à s’adapter à chaque contexte. Un modèle d’organisation d’équipe ne peut servir toute l’entreprise dans la variété de ses contextes.

Par ailleurs, la pérennité du changement n’est pas assuré tant que la culture n’a pas changé. La mise à l’échelle de l’agilité n’est pas tant une transformation vers une organisation cible qu’une transition continue. C’est le développement d’une culture de l’expérimentation continue qui permet l’émergence d’une organisation apprenante à même de se réinventer continuellement afin de s’adapter aux nouveaux enjeux comme aux nouvelles technologies.

Le pas le plus important à franchir est donc celui qui consiste à supprimer les longues réunions ou on liste les bonnes et mauvaises raisons pour ne pas implémenter un changement et de les remplacer par une décision rapide d’expérimentation sur une petite échelle.

En testant, on se trompe plus vite, on apprend plus vite et on arrive plus rapidement à la bonne solution, au bon changement.

L’équilibre Top down - Bottom Up

L’approche bottom-up atteint rapidement ses limites sans le soutien de la hiérarchie. Les réflexes de l’entreprise, les résistances du système ne peuvent être réellement dépassés sans le soutien des équipes dirigeantes.

Les transformations qui réussissent s’appuient toutes sur un très fort sponsorship de la direction.

Pour autant, les plans de transformation Top-down ne réussissent pas sans la participation volontaire des équipes. La plupart des entreprises ont déjà eu leurs lots de transformations sans succès. Il faut privilégier l’approche Lean qui considère que celui qui fait est celui qui est le mieux placé pour savoir comment ont peut améliorer le système.

Pour échapper à la transformation par l’incantation (il faut que vous changiez), les salariés doivent être considérés comme des acteurs responsables auxquels il convient de faire confiance et pour lesquels des moyens doivent être mobilisés.

C’est donc en recherchant l’équilibre top down-bottom up que l’on peut espérer réussir la transformation.

Donner l'exemple et développer le droit à l’erreur

Un fort sponsorship peut être insuffisant s’il ne s’accompagne pas du droit à l’erreur et d’une transformation à l’échelle des équipes dirigeantes. Le droit à l’erreur est la condition sinéquanone d’une culture de l’expérimentation continue. L’absence de ce “droit” est aussi le principale frein de l’adoption de l’agilité dans les entreprises. C’est en démontrant le droit à l’erreur et en faisant la promotion de l’autonomie des équipes dès les premières initiatives que les équipes dirigeantes peuvent contribuer au développement d’une organisation agile qui apprend rapidement. Il est d’ailleurs important que les “codir.” soient eux mêmes formés à l’agilité dont ils font la promotion. Non seulement les équipes accepteront plus facilement de changer si leur direction change aussi mais la transformation courra moins de risque de revenir en arrière au moindre problème.

Il ne faut pas sous estimer les conséquences du fossé culturel qui peut se creuser si seules les équipes opérationnelles adoptent l’agilité tandis que le management reste le même.

Lorsque les équipes de direction font l’expérience de l’agilité et assurent la promotion du droit à l’erreur et de l’autonomie des équipes, la transition agile est sur la bonne voie.

L’accompagnement des managers

La transformation agile est donc aussi celle des postures managériales. Les équipes de direction ne sont pas les seules en cause. C’est au contraire l’ensemble des figures de “management” dans l’entreprise qui constitue la clef de la transformation agile à l’échelle. Ce sont pourtant les managers qui, le plus souvent, subissent la transformation. Leurs rôles et leurs prérogatives sont remis en questions par le développement de l’autonomie des équipes et de la transparence des informations ce qui ne manque pas d’alimenter leur résistance au changement. Paradoxalement, ces équipes “agiles” ont plus que jamais besoin de porteurs de vision, de servant leaders et de managers-coach.

La mise à l’échelle de l’agilité suppose donc un fort accompagnement des managers. Pour réussir, cet accompagnement peut s’articuler sur 3 axes :

1. La formation aux nouvelles postures managériales (management 3.0, ...) pour repartir sur de nouvelles bases et constituer des premières communautés de managers. 2. Le coaching personnalisé des managers sur leur terrain pour les aider à s’approprier leurs nouveaux rôles dans la réalité de leur contexte. 3. La mise en place de groupes de codéveloppement pour cranter le changement et alimenter la dynamique collective.

Le couple Coach Interne - Coach Externe

Avec l’agilité apparaît un nouveau rôle dans l’entreprise : Le coach agile. Il est à la fois l’artisan incontournable de toute transformation, l’évangéliste qui incarne le changement, le garant de la méthode et celui qui s’assure que les équipes apprennent à apprendre rapidement.

Mais ce rôle doit il être porté par des internes ou par des externes ?

D’après nos intervenants, le coach interne et le coach externe sont les deux facettes d’une même pièce essentielle à la mise à l’échelle de l’agilité.

Le coach externe a pour lui : • L’indépendance qui lui permet d’aller droit au but et de parler vrai quelque soit l’interlocuteur • L’absence de préjugés sur l’entreprise qu’il regarde comme un système, • La légitimité du consultant • L’expérience des transformations • Le coût de la prestation qui oblige à y réfléchir à deux fois avant de saboter ses ateliers :)

Le coach interne bénéficie des forces suivantes : • La connaissance de l’organisation lui permet d’aborder le changement en prenant soin d’un écosystème qu’il comprend • La connaissance personnelle des acteurs de l’entreprise lui permet de bien choisir ses alliés et sponsors • La maîtrise de l’historique et des enjeux de l’entreprise facilite la priorisation des actions qu’il veut mener.

Pour bien commencer une transformation et la mise à l’échelle de l’agilité, le coach externe est un plus. C’est lui qui pourra créer l’effet miroir qui favorise la prise de conscience. Son indépendance lui permettra d’être plus disruptif et de jouer les catalyseurs pour mettre en évidence les points de douleurs et assurer la mise en oeuvre de la dynamique de changement.

Son expérience en gestion du changement lui permettra de garder le cap quelque soit les obstacles rencontrés.

Une fois le changement démarré, pour ne pas revenir en arrière et assurer la mise à l’échelle, il est important d’incarner la transformation de l’intérieur. Le coach interne est la personne idéale pour celà. Il est cet employé exemplaire qui doit faire ce qu’il dit et dire ce qu’il fait. Il est le changement fait homme ou femme dont l’inclusion dans le système constitue pour les autres un gage d’engagement et de respect des particularités de chacun.

Au fur et à mesure de la prise de maturité agile de l’organisation, les coachs internes vont prendre en charge le changement. Le coach interne pourra revenir pour assurer la supervision des coachs, les challenger et aider l’organisation à prendre du recul face à une nouvelle problématique.

Souvent les organisations pensent que le besoin d’un coach agile n’est que temporaire, qu’il ne vaut que le temps de la transformation. Ensuite, elles font l’expérience du coach agile et ne veulent plus s’en passer. 2 chez Meetic, 4 chez Lectra, les coachs internes incarnent les nouvelles conditions du travailler ensemble.

Il y a des champions agiles et des coachs potentiels dans toutes les organisations, à vous de les reconnaître et de leur faire de la place pour qu’ils s’épanouissent.

S’inscrire dans l’espace

Faire de la place, inscrire le changement dans l’espace c’est le dernier ingrédient secret que nous partagerons aujourd’hui et l’un des plus importants pour nos intervenants.

Chez meetic, par exemple, l’un des actes fondateurs de la transformation fut le sacrifice de deux salles de réunion. Les deux premières équipes agiles (les pilotes) ont tout de suite disposées d’une “obeya”, une salle près de leur open space pour : • mettre en place le management visuel (Kanban, release plan, graphiques, vision etc.) • mener leurs rituels et leurs ateliers collaboratifs • afficher les créas • assurer des points adhocs • assurer les One on One • se reposer, déjeuner, jouer aux cartes ou aux jeux vidéos etc.

Bien que les salles de réunion soient une denrée rare et précieuse, ce “sacrifice” permet aux équipes d’assurer la qualité de leur communication tout en renforçant leur sentiment d’appartenance.

Au moment de l’accélération de la mise à l’échelle, meetic a également dédié une salle ouverte pour le kanban de programme et les points de synchronisation. Cet espace était également le lieu de prédilection de préparation des ateliers pour les coachs agiles. De même, Lectra dispose de son Obeya pour faciliter la synchronisation transverse.

En s’inscrivant dans l’espace, le changement prend corps et confirme son inéluctabilité.

Avec l’agilité vient le management visuel et les post-it colorés. Si on compare meetic aujourd’hui et meetic il y a 3 ans, le changement qui saute aux yeux est sur les murs et déborde largement des obeyas. Les boards kanban, les tickets de couleurs, les facilitations graphiques décorent l’espace ainsi que le résultat impressionnant de plusieurs “post-it wars”. Un visiteur non initié s’est exclamé un jour : “C’est génial ! On se croirait dans une école maternelle pour les adultes” et c’est, je crois, le plus beau compliment que l’on puisse faire à ce décor. L’entreprise est devenu un lieu d’apprentissage à l’échelle humaine.

Les équipes se sont appropriées l’espace qu’elles rendent vivant par leurs interactions et où toute information est disponible pour tous, à tout moment.

V. Conclusion

Si vous vous demandez encore par où commencer et quelle organisation choisir pour développer l’agilité à l’échelle dans votre entreprise, n’hésitez plus, lancez votre première expérimentation collaborative et faites parler les post-it et les interactions.

Plus les personnes interagiront au sein d’ateliers collaboratifs où elles expérimenteront de nouvelles pratiques, plus rapide et pertinente sera votre transformation.