Ma série d’articles sur l’Architecture et l’agilité en arrive à son 5ème chapitre. J’ai fait beaucoup de recherches, échangé avec des agilistes et des confrères Architectes. Mais avais-je vraiment pris le temps d’intégrer l’agilité dans mon mode de fonctionnement ? Pris le temps d’en discuter et d’y travailler avec mes équipes ? Et qu’a fait notre cabinet de conseil pendant ce temps-là ? Voici mon retour (d’expérience) sur ce qui s’est passé dans mon écosystème dernièrement.
Avoir dans notre cabinet une équipe dédiée à la Transformation Agile est vraiment un atout dont je n’avais pas encore mesuré toute la portée. L’évolution se fait doucement mais sûrement et en profondeur. Que ce soit par des formations, des conseils ou des exemples, elle se fait sentir à tous les niveaux du cabinet. Nous sommes en train de trouver notre voie et c’est bien là le secret !
Former les managers
En tant que consultant d’abord puis manager, je suis des formations régulièrement. Depuis plus de 15 ans ces formations portent sur mon expertise, l’Architecture, mais aussi sur le métier de consultant et de manager d’équipe.
Notre équipe de Transformation Agile propose une formation au Management 3.0. Comment refuser une telle opportunité ? Prendre 2 jours de réflexion sur ma pratique de management qui n’avait pas évolué depuis quelques années. Avoir les bonnes pratiques et de nouvelles techniques autour du management à intégrer dans mon fonctionnement et celui de mon équipe.
Je pensais bien que le changement était en marche, mais là, j’ai vraiment réalisé le retard que j’avais pris. Nous sommes donc en train de changer notre fonctionnement interne, nos modes de réunions, de travail etc. L’équipe en parlera surement plus en détail dans un prochain article.
Je ressemble à ça maintenant, j’ai bien changé, non ?
La formation pour tous, mais laquelle ?
En parallèle, la réflexion m’avait mené aussi sur la formation des consultants vers l’agilité et les changements que cela implique. Quelle formation ? Pour quel but ? Pour commencer, 2 formations fondamentales tiennent la corde. Elles correspondent aux 2 rôles principaux des projets agiles aujourd’hui : le Scrum Master et le Product Owner.
Les 2 formations sont pour partie les mêmes. Les bases de l’agilité y sont présentées. La suite diffère selon le rôle que l’on est amené à jouer. Est-ce que vous allez travailler en tant que responsable du produit ou en tant qu’animateur du projet ?
Le Product Owner se focalise sur la valeur, les finances, la stratégie, et est connecté avec les différents intervenants et clients autour du projet.
Le Scrum Master est un facilitateur de l’atteinte des résultats, un leader non autoritaire qui connecte les gens et les aide à tirer le meilleur d’eux-mêmes dans la constitution de l’équipe. Il est là pour catalyser les résultats.
Pour le métier d’Architecte, les 2 aspects semblent importants. Dans ce cas, pourquoi choisir ?
Nous avons alors pris le parti de former certains architectes en Scrum Master et d’autres en Product Owner. L’avenir nous dira si nous devons compléter par la suite la formation des uns ou des autres.
L’essentiel est de se lancer.
Nous ferons au fur et à mesure des projets et des missions, les constats et les retours d’expérience des uns et des autres sur l’utilité et la spécificité de chacune des formations (par exemple, sous le format des rétrospectives présentées dans SCRUM !)
La détection des faux positifs
Maintenant que nous sommes formés à l’agilité, que nous en connaissons les principes, le 1er changement qui nous vient à l’esprit est de détecter tous les projets qui se prétendent Agile (le terme étant très galvaudé en ce moment) et qui ne le sont pas. Et surtout de pouvoir dire en quoi ils ne sont pas agiles.
Un projet qui conserve un découpage de ses travaux en lots. Un projet sans autonomie. Autant de projets avec lesquels nous travaillons, qui se prétendent agiles, voire sont convaincus de l’être.
Nombreux sont les exemples que nous voyons dans les entreprises au quotidien.
Un des principaux défauts, que j’avais souligné dans un article précédent, est qu’il est très difficile pour un projet d’être vraiment Agile si les managers ne le sont pas et ne font pas évoluer leur posture.
Même s’il est toujours aussi difficile de travailler avec ces projets, au moins nous pouvons échanger avec eux, les aider aussi et peut être trouver des axes d’amélioration ?
Et au niveau du cabinet, le LAB !
En parallèle, notre cabinet a initié une pratique de Lab : dispositif de créativité, de co-construction et d’intelligence collective aussi bien orienté vers l’interne que vers l’externe. Les initiatives sont venues, les projets ont commencé, les premiers résultats arrivent. La dynamique est en place et le mode de fonctionnement se rode.
Il y aura des réussites, des échecs, mais surtout plein de belles histoires.
Mais le plus important dans tout ça, ce n’est pas le Lab, c’est bien le symbole. Dans notre cabinet, comment trouver une place dédiée pour le Lab où nous puissions travailler avec les bons outils ? Le seul endroit qui s’y prêtait était déjà occupé. Et pas par n’importe qui, pensez donc : le président et ses 2 DG Adjoints. Ce sont eux-mêmes qui ont proposé de laisser leur bureau pour le Lab.
Si ça, ce n’est pas un changement visible !
Fini la V1, vive le MVP !
Dans l’ancien mode de fonctionnement d’un projet, nous annoncions toujours la mise à disposition d’une V1, complète et exhaustive. Elle prenait du temps et consommait des ressources. Pour un résultat rarement satisfaisant.
Avec l’agilité, nous faisons des MVP (Minimum Viable Product). Un produit suffisamment complet du 1er coup pour qu’un client y trouve de l’intérêt (juste les bonnes fonctionnalités). Pas avec toutes les fonctionnalités bien sûr mais plus qu’une V1 bancale. Une approche qui oblige à se focaliser sur l’essentiel.
Nous essayons de démocratiser cette approche pour tous nos projets, y compris pour nos projets en interne.
Et cela fonctionne mieux. Les MVP sont mieux acceptés, consomment moins de ressource, apportent plus de retours d’expérience.
Est-ce que ça change vraiment ?
Oui ça change. Surtout la perspective avec laquelle on aborde les sujets.
La mise en pratique se fait avec un plus grand partage de toutes les informations. La transparence est primordiale.
Les échecs sont permis. On apprend à marcher en tombant. Il faut essayer. Les nouveaux modes de fonctionnement ne marchent pas du 1er coup ? Quoi de plus normal. Apprendre de nos erreurs et continuer à avancer.
La confiance était déjà de mise dans notre cabinet mais le management agile va encore plus loin.
Ne plus imposer mais fournir les informations pour que chaque niveau puisse décider de son mode de fonctionnement, de ses actions et de ses buts.
Rome ne s’est pas faite un jour, mais les changements sont visibles et je pense maintenant que personne ne pourrai / ne voudrai retourner en arrière.
Aller très loin ou aller trop loin ?
Dans la formation Management 3.0 certains aspects bouleversent complètement nos modes de fonctionnement. « Ne pas promettre de récompense », « Récompenser des comportements pas des résultats » sont des exemples de préconisations de cette formation. Ces règles visent à valoriser le collectif plutôt que l’individu / l’individualisme.
Quel changement quand on est habitué à avoir des objectifs fixés en début d’année et d’être jugé, et récompensé, sur la base de l’atteinte ou non de ces résultats.
Imaginer des commerciaux qui ne soient plus récompensés sur l’atteinte de leurs résultats mais sur leur comportement ! Impensable de nos jours dans la plupart des entreprises. Et pourtant, on sent bien la justesse des arguments de ces nouvelles techniques de récompense.
Certaines habitudes auront la vie plus dure que d’autres, et le trajet sera d’autant plus long.
Conclusion
C’est une révolte, sire ? Non, juste une belle évolution ! En faire moins (exit les V1 fastidieuses) mais mieux (les MVP).
Le principal est que cela soit le fait d’une volonté commune et que les dirigeants (un fort niveau de sponsoring est indispensable) comme les collaborateurs y adhèrent. Nous avons tous à y gagner et à grandir dans ces nouveaux modes de fonctionnement.
Nous avons les techniques, des formations sont à disposition et des vidéos pour nous guider.
A nous de jouer !
Chapitre(s) suivant(s) ?
Je ne vais plus annoncer de suite, car cela évolue / change tellement vite ! Mais ne vous inquiétez pas, vous ne serez pas déçus.
Le triptyque Big Data, Data Science, Data Lake a fait naître l’espérance de nouveaux débouchés pour l’entreprise, basés sur une meilleure exploitation de la valeur supposée des données. Ce nouvel eldorado inspiré par des technologies créées par les GAFA est souvent perçu comme une solution purement technique. Il apparaît pourtant nécessaire d’aborder les apports essentiels de l’architecture d’entreprise dans la valorisation et le succès d’un Data Lake à travers trois chapitres distincts :
L’activité urbanisation des systèmes d’information qui permet d’anticiper la place que le Data Lake occupera dans le « paysage applicatif » et dans l’organisation du système d’information.
L’activité modélisation de données et mise en place de référentiels afin de garder le contrôle de son Data Lake et empêcher la transformation du lac (Data Lake) en marais (Data Swamp).
L’activité pilotage du changement centré sur les données et les usages, pour être en capacité de transformer les futures idées innovantes issues de votre Data Lake en avantages compétitifs réels pour l’organisation.
En effet, si le Data Lake démonte techniquement les silos de données et ouvre la porte à des analyses globales et instantanées qui étaient inaccessibles jusque-là, il ne permet pas de disposer automatiquement d’une avance sur ses concurrents.
Chacun des chapitres qui suivent rappelle que le décloisonnement de la donnée n’est utile qu’à condition de faire évoluer en conséquence son système d’information et son organisation. Non par une démarche dogmatique qui imposerait un cadre, mais par une concertation autour des mutations à venir de l’organisation.
Si la résistance au changement, celle qui annihile les bonnes intentions, terrasse votre initiative de Data Lake, c’est probablement que certains des points qui suivent ont été sous-estimés.
Urbanisation : la place du big data dans la big picture
Si l’on s’en tient à une définition technique du Data Lake – un espace de stockage de données brutes à partir desquelles les Data Scientists effectuent des analyses pertinentes – la stratégie d’adoption est souvent la même. Un environnement moderne d’analyse est créé et un espace de stockage y est adjoint. Il s’ensuit une alimentation progressive en flux de données. Comme un POC qui ne dirait pas son nom. Cela ne permet aucune démarche d’urbanisation et n’embarque aucune réflexion sur les enjeux de l’industrialisation future. Pourtant, les sujets sont nombreux et porteurs d’enjeux forts.
Types d’utilisations et qualité des données
Un Data Scientist utilise toutes les données pour ses expérimentations, mêmes les erronées et les « incertaines ». Un responsable produit veut des données consolidées et visualisables quotidiennement. Un Marketing veut de la segmentation à la volée pour proposer les meilleurs produits. Les commerciaux sont sensibles au « time-to-market », de l’idée à son exploitation commerciale. Sans parler des préoccupations du RSSI, du DPO, du management, du DSI, du DAF, des partenaires…
Ces différents modes de fonctionnement évoluent dans le temps et définissent des séparations logiques dans le Data Lake. Non pas des silos, mais des contraintes d’utilisations qu’un Data Lake n’embarque pas par défaut, et qui nécessitent une certaine maturité dans l’urbanisation du Data Lake. Le Data Lake n’est pas un COTS – un produit informatique standard « vendu sur étagère ». Définir un écosystème est nécessaire pour découpler ces utilisations. Echanges de flux, orchestration des processus, supervision, autorisations d’accès, tout cela est nécessaire pour que le Data Lake évolue en phase avec le reste du SI.
Processus de collecte
En rapatriant toutes les données brutes dans le Data Lake, l’industrialisation des collectes de données ne peut pas faire l’économie d’une réflexion globale sur les qualités prioritaires attendues des échanges et de l’urbanisation qui en découle. Et toutes les entreprises n’auront pas les mêmes contraintes. Un opérateur de téléphonie peut générer un million de données par seconde de mille sources différentes, dont certaines sont soumises à des obligations légales de traçabilité et d’autres à des obligations comptables. Une petite mutuelle génèrera péniblement cinq mille données par jour, mais certaines seront des données de santé sensibles. D’autres auront leurs données dans des progiciels, dont certains en mode SaaS. D’autres encore exploiteront les données de partenaires de fiabilités variables. Des entreprises au SI de plus de trente ans passeront par des couches d’encapsulation de leur mainframe. Et toutes ces contraintes peuvent se combiner. Une logique urbanisée est vitale.
Sécurité des données
Le Data Lake a aussi pour vocation de faire circuler une part très importante des données de l’entreprise pour des usages dont le nombre, la nature et les utilisateurs finaux seront amenés à évoluer. Cela ne peut pas se faire sans une automatisation de la traçabilité, de la supervision et de la sécurisation des échanges et du stockage. C’est même bien souvent une obligation légale (RGPD, données de santé, Sarbanes-Oxley…).
La gestion des identités et des accès (IAM), l’API Management, leur intégration avec les données sensibles ou réglementées sont des sujets que l’architecture d’entreprise et le RSSI doivent orchestrer.
Quels modules dans l’écosystème data lake ?
D’autres éléments structurants de votre SI doivent être pris en compte dans l’urbanisation du Data Lake :
Le « catalogue des données », les référentiels associés et leurs cycles de vie,
L’orchestration des processus entourant la gestion des créations, évolutions ou disparitions des sources et destinations,
Le transport physique des données, la gestion de l’intégrité et de l’unicité des transactions, la reprise sur erreur…
La normalisation des données doit retrouver sa place autour d’un Data Lake qui favorise la donnée brute d’origine. La repousser en aval dans la chaîne de traitement ou faire cohabiter anciennes et nouvelles chaînes en parallèle, les choix dépendent des contraintes et attentes.
Chaque SI étant spécifique, cette liste est loin d’être exhaustive.
Se lancer dans la constitution d’un Data Lake sans faire le point sur les impacts, les contraintes et les opportunités mène généralement à une mauvaise adéquation par rapport aux enjeux stratégiques et aux besoins pressentis. Qui d’autre que l’architecte d’entreprise pour donner le recul nécessaire à la définition de la solution de bout-en-bout qui correspond à vos impératifs ?
Référentiels : connais-toi toi-même
Le principal avantage du Data Lake est aussi son principal inconvénient : il casse les silos de données en acceptant n’importe quelle donnée sans surveillance ni gouvernance. Or, il est bien hasardeux, en ces temps de RGPD, de laisser accéder n’importe qui à n’importe quelle donnée.
Autant il est facile de déverser en vrac des données non-dénaturées dans une couche persistante accessible par des personnes autorisées (le Data Lake dans sa forme épurée), autant se passer de référentiels qui permettent la mesure de la valeur des différentes sources de données fait perdre la maitrise du contenu du Data Lake et de tous ses usages possibles.
Les référentiels sont principalement des données de référence sur les données, des métadonnées. Savoir quelle donnée est disponible dans quelle source. Discriminer les données de référence, les données opérationnelles et les données d’exploitation. Connaître les fréquences de rafraîchissement, les versions disponibles, les responsables, la classification, les moyens de les visualiser.
L’utilisation qui en est faite dans le Data Lake est également un élément essentiel pour éviter la création de « silos logiques » venant remplacer les « silos physiques ». Le référentiel peut permettre de connaître le responsable des autorisations d’accès, l’endroit où elle est utilisée, son usage dans des expérimentations, des processus ou des rapports, les référents techniques, fonctionnels ou Métiers…
Si une donnée se trouve dans plusieurs sources, il faut savoir quelle source fait référence (« golden source »), les applications possédant une copie locale, celles pouvant mettre à jour la référence et les règles de propagation des modifications dans le SI, les mécanismes détectant et remédiant les inconsistances entre sources…
Il n’est pas possible de lister ici toutes les informations qui, dans un contexte ou un autre, peuvent être pertinentes. Mais c’est bien l’architecture d’entreprise qui définit le périmètre et les limites de cette gouvernance des données.
Cette gouvernance doit faire en sorte que l’utilisation des données ne reflète pas les anciens silos techniques. Elle permet aussi de faire contribuer les experts Métiers, fonctionnels et techniques sur la façon d’utiliser ces données qu’ils connaissent bien. Leur engagement et leur implication participent grandement du décloisonnement.
La technologie Data Lake pourrait permettre d’accepter n’importe quelle donnée sans surveillance ni gouvernance. Mais les organisations qui ont profité de cette possibilité de ne plus surveiller, ni mettre en place une gouvernance se sont retrouvés avec un Data Swamp dont la gestion est plus complexe, les bénéfices plus aléatoires et les risques opérationnels sans commune mesure avec ceux d’un Data Lake sous le contrôle des architectes d’entreprise.
Transformation continue et pilotage par la donnée
Commencer par aligner dans les deux sens
On se prive d’opportunités lorsque l’alignement entre le système d’information et les Métiers se fait toujours au détriment du SI. La complexité technique invisible aux demandeurs d’évolutions et la difficulté de rendre le SI adaptable aux exigences imprévues, rendent l’alignement difficile.
Dans le cas d’un Data Lake, lorsque différents acteurs Métiers accèdent au catalogue de données et aux services associés, le Métier s’aligne de lui-même sur ce que le SI lui rend disponible. En ouvrant son catalogue et en étant capable d’afficher ce qu’il est techniquement possible de fournir, le SI rationalise les exigences du Métier. Il le doit au socle urbanisé qui assure la maîtrise technique des flux et à la gouvernance pour la maîtrise fonctionnelle des données.
Certes, un travail effectué par le SI est toujours nécessaire pour s’aligner sur le besoin. Mais ce besoin sera plus naturellement cadré et les impossibilités techniques seront beaucoup plus rares.
Puis baliser la propagation de l’innovation
De même que le DevOps est le chaînon manquant entre deux mondes aux fonctionnements difficilement compatibles (le développement et l’exploitation), de même, il manque une étape importante entre la Data Science – qui extrait la valeur et valide la pertinence d’une nouvelle utilisation d’un ensemble de données – et le Métier qui attend une mise en production rapide de cette segmentation, cette visualisation ou cette publication.
Votre Data Lake va peut-être vous apporter de nombreuses idées de nouvelles utilisations de votre patrimoine de données. Il est rationnel de mettre en place des processus simples pour l’industrialisation de ces différents types d’utilisations.
Un « DevOps Data » avec des outils plus proches de la gestion de paramétrage que de la gestion d’une intégration continue. Il s’agit moins d’injecter de nouvelles versions applicatives dans le SI que de faire cohabiter des usages à différents degrés de maturation dans le même SI. A partir du Data Lake, il sera permis d’enrichir en continu des API à usages internes ou externes, ou d’automatiser la création de Data Sets pour des besoins de BI et de reporting. Ce DevOps se met en œuvre principalement autour :
D’outils d’orchestration des processus,
D’une bibliothèque extensible de connecteurs,
Du travail algorithmique des Data Scientists,
De la gestion des droits et des accès aux différents services,
D’une gestion des sources, des environnements et des déploiements, plus classiques du DevOps.
De convertisseurs en sortie pour fournir les formats utiles.
L’architecture d’entreprise associée à un Data Lake vous permet de créer du logiciel robuste, professionnel et évolutif sans vous lancer dans des appels d’offres de COTS qui reproduisent prioritairement les besoins du plus grand nombre, et non vos besoins spécifiques. Votre Data Lake devient l’élément central d’un applicatif adressant vos innovations sur-mesure.
Data lake et transformation
Cette évolution continue à l’échelle de l’entreprise fera le succès du Data Lake. Ce changement de paradigme a beau être souvent problématique, la nécessité d’une conduite du changement amenant à une modification de l’organisation est rarement perçue ; alors même que les Data Lake sont issus de GAFA et de startups dont la culture et l’organisation sont souvent à l’opposé des organisations matricielles qui s’emparent actuellement du Big Data et des Data Lake.
Ce mode de fonctionnement va bouleverser des pans entiers de votre organisation, modifier les circuits de décisions, les périmètres de responsabilités, les modes de communications internes et externes, les cycles de vie des produits et services, le contrôle des mises en production. Ces nouveautés sont anxiogènes et vont entraîner des résistances et des stratégies d’évitement.
C’est justement pour adopter plus facilement une démarche transverse affectant aussi bien l’architecture technique, les processus métiers, que l’accompagnement de la transformation de l’organisation, que l’architecture d’entreprise a été créée.
La mise en place d’un Data Lake est un saut dans l’inconnu. L’architecture d’entreprise est votre parachute.
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.
