Westrum Organizational Culture et Machine Learning - Partie 1 : Impacts de la culture sur le delivery

Cet article fait partie de la série “Accélérer le Delivery de projets de Machine Learning”, traitant de l’application du framework Accelerate dans un contexte incluant du Machine Learning. Si vous n’êtes pas familier avec le framework Accelerate, ou si vous souhaitez avoir plus de détails sur le contexte de cet article, nous vous invitons à commencer par lire l’article introduisant cette série. Vous y trouverez également le lien vers le reste des articles pour aller plus loin.

Cet article aborde la capacité "Westrum Organizational Culture" d'Accelerate appliqué au Delivery de projets de Machine Learning et est lui-même divisé en deux parties :

• Partie 1 : Impacts de la culture sur le delivery
• Partie 2 : Changer la culture

Qu’appelle-t-on “culture” et comment la visualise-t-on ?

La capacité “Westrum organizational culture” d’Accelerate [1] fait référence à la “théorie des trois cultures” que le sociologue Ron Westrum expose dans son article A typology of organisational cultures [2]. Selon les auteurs d’Accelerate, avoir une culture de type “générative” au sens de Westrum, c'est-à-dire une culture axée sur les résultats, améliore la performance d’une entreprise, du point de vue du delivery de son système d’information, mais aussi de façon générale. Les personnes évoluant dans une organisation à la culture “générative” sont également en plus satisfaites au travail.

Dans cet article, nous explorons ce modèle de Westrum afin de mieux comprendre les changements culturels qui se produisent lorsqu'une organisation commence à mettre en œuvre du Machine Learning.

La théorie des trois cultures

Dans A typology of organisational cultures, Ron Westrum met en lumière l'influence de la culture d'une organisation sur sa performance. S’intéressant plus particulièrement à la performance dans la sécurité médicale, il a mis en évidence les relations suivantes :

figcaption {color: grey; text-align: center; font-style: italic}

Ce qui fait la culture et comment elle se manifeste selon Ron Westrum

• Les priorités du leader de l’organisation sont transmises au reste de l’organisation à travers ses actions ainsi qu’au travers de ses feedbacks aux membres de l’organisation (récompenses et punitions) ;
• Les membres de l’organisation réagissent à ce signal en adaptant leurs comportements : ces comportements constituent la culture de l’organisation ;
• La culture à son tour influence la façon dont l’information circule dans l’organisation ;
• La circulation de l’information régit la façon dont les personnes coopèrent, communiquent, innovent et résolvent leurs problèmes. C’est ce dernier point qui a un impact sur la performance.

Ron Westrum distingue trois types de cultures d’organisation, découlant de différentes priorités des leaders :

• La culture pathologique surgit dans une organisation où la priorité du leader est sa gloire personnelle. Dans ce type de culture, l’information est une arme et confère un pouvoir à celui qui la détient. Elle va donc être divulguée au moment et aux personnes qu’il faut pour obtenir une faveur ou neutraliser un concurrent dans un contexte de forte compétition entre leaders.
• La culture bureaucratique découle d’une priorité accordée à la gloire du service. La circulation de l'information est très normée et doit passer par les bons échelons avant d’arriver à destination. Il n’est pas question de court-circuiter quelqu’un dans ce processus, au risque de se faire recadrer. L’information arrive, mais souvent tard.
• La culture générative éclot dans une organisation où le leader priorise la mission de l’organisation. Dans ces organisations, les personnes se mobilisent pour faire parvenir l’information à la personne qui est en capacité de mieux l’exploiter, en temps et en heure.

Types de culture et leur relation avec l'information

Westrum présente quelques caractéristiques de ces trois cultures :

Source : A typology of organisational cultures [2]

Dans quelle culture sommes-nous ?

Westrum a produit son modèle à partir d'observations méthodiques. Or au cours d'un projet de développement de type Machine Learning, nous ne disposons souvent ni de son savoir-faire ni du temps nécessaire pour une étude approfondie de la culture. Comment caractériser la culture qui nous environne ?

Écouter et observer

La table extraite de l’article de Westrum résume les caractéristiques saillantes d'une culture en relation avec les problématiques courantes d'une organisation :

• le degré et la forme de coopération entre individus ou entre équipes ;
• ce qui arrive aux porteurs de mauvaises nouvelles ;
• la façon dont on envisage les risques et les responsabilités ;
• la façon dont la communication entre équipes (ou "silos") est accueillie ;
• le traitement des échecs ;
• la disposition de l'entreprise face à la nouveauté.

Comme un projet de Machine Learning ne manquera pas d'occasions de rencontrer ces problématiques, il nous suffit d'écouter et d'observer - en faisant la part des biais et des interprétations, et en multipliant les sources d'informations - pour situer la culture de l'entreprise.

Porter son attention sur les conflits

Les conflits sont particulièrement intéressants à ce titre. Aucun projet un tant soit peu ambitieux ne peut se dérouler sans conflit de ressources et/ou d'idées. Le temps et les budgets sont limités, et toutes les idées contribuant à la conception d'une solution, à son optimisation, ainsi que les méthodes pour la réaliser, ne peuvent coexister dans la solution qui sera mise en œuvre : il faut choisir. Dans une culture générative, la résolution des conflits fait partie du travail de l'équipe, et de l'entreprise, évitant qu’un conflit de solutions ne se transforme en bataille interpersonnelle. Dans une culture bureaucratique, les conflits sont mal vus, mal compris et pour cette raison, évités autant que possible. Dans une culture pathologique, les conflits d'idées se transforment mécaniquement en batailles de pouvoir, et alimentent de façon quasi-permanente  le triangle dramatique (victime, persécuteur, sauveur) au sein des relations interpersonnelles.

Etudier les processus et l'organisation

La culture de l'entreprise façonne ses processus et son organisation. Ces processus à leur tour se reflètent dans les projets et les produits. Comme l'a souligné Conway : "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure". Une culture générative se reflétera dans la présence d'équipes autonomes et résilientes, au sein  desquelles les compétences se répartissent de manière redondante. Dans une culture bureaucratique, la spécialisation ainsi que la coordination par le haut sont la norme. Un projet ou même une initiative transverses ne réussissent qu'au prix d'efforts considérables et d'une ténacité hors du commun. Dans une culture pathologique, les objectifs des projets sont subordonnés aux objectifs des "fiefs" dans lesquels ils prennent naissance. Dans une telle culture un responsable préfèrera toujours pouvoir assigner la responsabilité d'une réussite ou d'un échec, quitte à tuer dans l'œuf les initiatives qui favoriseraient les chances de réussite, mais qui ne peuvent être clairement attribuées à un responsable.

Comment la culture influence les pratiques

Une fois que l’on sait dans quelle culture on évolue, que peut-on en tirer ? Comme l’a souligné Peter Drucker, “Culture eats strategy for breakfast”. Une stratégie fondée sur un remaniement des processus, dans une organisation où ceux-ci ne seraient pas compatibles avec la culture, est vouée à l'échec. En l'occurrence, dans un projet de delivery en Machine Learning, certaines étapes sont indispensables : la récupération des données, l’expérimentation et la mise en production. De même, certaines de nos pratiques de développement, comme l’utilisation d’un board visuel sont essentielles pour travailler efficacement. Comment réagira chaque culture face à ces pratiques ? Quelles difficultés pouvons-nous anticiper en évoluant dans chacune de ces cultures en tant que Data Scientists ?

Utiliser les radiateurs d'information

Les méthodes agiles, dont la popularité s'est accrue ces 10 dernières années, mettent en avant la communication et le pragmatisme. Ainsi elles préconisent que les supports d'information de coordination et d'avancement du projet, tels que le kanban (qui permet de visualiser les tâches à venir, en cours et réalisées de l'équipe) ou le burn down chart (qui montre la courbe et la projection du reste à réaliser sur une date pour un objectif donné) soient disposés sur les murs. De cette manière, quiconque a besoin de ces informations peut en prendre connaissance sans avoir à ouvrir un outil ou questionner un membre de l'équipe. Cette doctrine de l'information "poussée" plutôt qu'extraite, constitue un des piliers du management visuel. Cette disposition à afficher la donnée et à la représenter sous différentes formes fait d'ailleurs partie de l'ADN du métier des Data Scientist dans la mesure où dans ce métier presque tout le travail est guidé par la donnée, et où la visualisation joue évidemment un rôle clé dans ce pilotage.

Au sein d'une culture générative, qui met en valeur les performances fondées sur la coopération, les radiateurs d'information forment un standard quasi-implicite. Là où travaillent des équipes cohérentes et auto-organisées, vous trouverez de l'information sur les murs, c'est-à-dire que vous accéderez efficacement à une information partagée, pertinente, et à jour. Les projets de Machine Learning, qui s'appuient (comme les projets en agile) sur des boucles de retours d'information courtes, utilisent très souvent et à bon escient les radiateurs d'information. Il est important de noter que ces outils de visualisation peuvent également exister dans l'espace "virtuel" constitué par les outils numériques. Il n'est pas nécessaire de travailler dans le même espace physique pour disposer d'un "affichage". Un graphique constitué à partir d'une feuille de calcul ou d'une base de donnée de gestion de ticket, à condition d'être accessible sans privilège particulier, constitue un outil de diffusion valide, bien que son efficacité ne soit pas tout à fait celle d'un tableau de bord mural, puisque l'information n'est plus affichée en permanence dans l'espace, mais doit être "tirée" par l'utilisateur sur sa station de travail.

Au sein d'une culture bureaucratique, la présence de radiateurs d'information ne va pas de soi, en premier lieu parce que la collaboration et l'autonomie des équipes ne sont pas mises en avant dans les entreprises de ce type. Lorsque des outils numériques de coordination et d'avancement sont utilisés, c'est avec restriction d'accès (selon le rôle) de manière à limiter la diffusion. Ces limites tiennent à la nature hiérarchique des relations dans les entreprises dont la culture est bureaucratique. D'une part, il existe plusieurs niveaux de management entre l'équipe opérationnelle et le management stratégique de l'entreprise, d'autre part chaque manager, à son niveau, veut disposer d'un contrôle sur l'information, espérant ainsi rester maître des "messages" qu’elle transmet. On voit alors des rapports d'avancement et d'état des lieux dont le contenu est en quelque sorte pondéré à chaque étage de la hiérarchie afin d'éviter d'être mal vu ou d'empêcher des réactions ou répercussions trop brutales. D'autre part, le contrôle des projets étant centralisé plutôt que laissé aux équipes, la collection des données d'avancement des projets incite les managers à faire des comparaisons quantitatives dénuées de sens (un exemple particulièrement absurde étant les comparaisons basées sur la vélocité relative de chaque équipe), créant un environnement de règles et de contraintes arbitraires (par exemple, transmission d'objectifs de vélocité aux équipes). Dans ce contexte, les radiateurs d'information sont utilisés comme des outils de contrôle et de surveillance.

Dans une culture pathologique, les radiateurs d'informations seront considérés comme non seulement inutiles mais "dangereux", puisque la transparence et la sincérité sont des attitudes non supportées, au sens où ceux qui prennent à cœur ces postures diminuent les chances de succès de leur projet. Dans un contexte de projets interdépendants par exemple, la transparence totale sur leur avancement empêcherait la stratégie habituelle de gestion des risques projets dans laquelle chaque responsable cherche à être le dernier à annoncer un retard. Qui plus est, une culture pathologique place souvent les silos en compétitions les uns avec les autres. Partager des informations touchant à vos résultats dans un tel contexte, c'est rendre votre projet vulnérable aux possibles attaques "politiques", aux campagnes de dénigrement, ou plus simplement vous exposer au blâme.

Récupérer des données

Dans une culture générative, une seule question se pose : est-ce que mettre ces données à disposition des Data Scientists permettra à l’organisation de remplir ses objectifs ? Pour récupérer des données, il faut donc une bonne raison, ce qui est plutôt sain. Cependant, une dérive commune dans ce type de culture est de négliger des aspects réglementaires ou de sécurité dans un souci d’efficacité. Dans certaines organisations, la direction peut être tentée de fermer les yeux sur le non-respect des réglementations relatives à la donnée, telle la RGPD. Dans cette configuration, nous proposons à nos clients des solutions simples pour respecter la législation tout en bloquant le moins possible la récupération des données. Cette approche est généralement bien acceptée dans des organisations génératives, qui voient l’intérêt pour l’organisation de se prémunir contre des problèmes futurs.

Dans une organisation bureaucratique, récupérer les données prend du temps. La demande d'extraction de données de production à des fins d'entraînement d'algorithmes est inhabituelle, et souvent incompatible avec les règles de sécurité et de RGPD. On est ici dans l’excès inverse des cultures génératives : il faut remplir des formulaires, attendre que la demande monte les niveaux hiérarchiques pour ensuite les redescendre. On est renvoyé de la DSI vers le Chief Data Officer en passant par la direction juridique pour enfin finir à la Direction de la Sécurité. Ce processus peut paralyser une équipe de Data Scientists pendant des mois et coûter cher en temps, en argent, en énergie et en motivation des équipes. Il peut même avoir un effet inverse :  bloquée, l’équipe de Data Science finit parfois par court-circuiter le processus officiel et par récupérer ces données officieusement, rendant tous ces processus inutiles.

Dans une organisation pathologique, cette demande n’aboutit pas, à moins de compter sur les bons sponsors. En effet, la donnée c’est de l’information et l’information c’est du pouvoir : on ne la cède pas sans contrepartie. Il n’y a pas de secret : pour avoir accès aux données, avoir le leader de son côté est un prérequis, au risque de paralyser le projet, qui ne verra probablement jamais le jour. Par ailleurs, le risque du non-respect des réglementations sur les données dans ces organisations est très fort, vu le pouvoir qu’elles peuvent conférer. Les arguments avancés dans une organisation générative afin de pousser à leur respect n’auront donc pas d’effet ici. Ce non-respect se fait cependant aux risques et périls de ceux qui s’y aventurent : il peut être utilisé pour faire tomber des “boucs émissaires”.

Expérimenter

Dans une culture générative, l’expérimentation est acceptée et même encouragée par l’organisation si elle est nécessaire pour faciliter l’implémentation d’une proposition de valeur pour ses clients. Cependant, un point de tension est possible : le temps d’expérimentation. La culture générative voudra une expérimentation courte, permettant de déployer une solution en production au plus vite. Cette approche est en règle générale plutôt salutaire, car elle empêche les équipes d’entrer dans un tunnel et leur permet d’obtenir des retours rapides de leur solution. Cependant, les projets de Machine Learning ont une composante R&D plus forte que les projets informatiques classiques et demandent parfois des phases de recherche bien plus longues. Le défi dans une organisation générative est de ne pas sacrifier ce temps de recherche, permettant la création de valeur pour l’utilisateur à long terme. Dans nos projets, nous essayons de distinguer les cas où une recherche longue est nécessaire des cas où il s’agit uniquement de valider rapidement quelques hypothèses, afin de time-boxer de façon pertinente chaque type d’expérimentation.

Dans une culture bureaucratique, expérimenter est possible, à condition de faire partie des équipes de recherche. Il sera cependant compliqué de justifier des expérimentations quand on est censé livrer des fonctionnalités. Il faudra transmettre la demande à l’équipe de recherche et attendre qu’ils traitent cette demande en fonction de leurs propres priorités. À l’inverse, la participation des membres de l’équipe de recherche au projet de développement n’est pas non plus envisageable. Chaque équipe respecte ainsi le pré carré de l’autre. D’ailleurs, ces équipes ne communiquent que rarement entre elles. À l’opposé des organisations génératives, les organisations bureaucratiques sont en général très efficaces sur des cycles de recherche longs, moins sur des expérimentations de type spike.

Dans une culture pathologique, l’expérimentation est à double tranchant. Si cela ne marche pas, on trouve un bouc émissaire et on enterre le projet, sans chercher à apprendre de ses erreurs. On va donc tout faire pour montrer que ça marche, même si ça ne marche pas, car on met sa tête en jeu. Une organisation pathologique encourage la falsification des résultats, et va tout faire pour sauvegarder ses apparences. Citons l’exemple d’une start-up dont on taira le nom qui communiquait en interne à ses employés et en externe aux éventuels investisseurs des résultats falsifiés à propos d’une expérimentation. Les personnes qui étaient au courant en interne ont soit tu l’information, soit ont été poussées vers la sortie.

Déployer une expérimentation en production

Seulement 13% des projets de Machine Learning vont en production, et la culture y est pour quelque chose.

Les organisations génératives sont les plus aptes à mener un tel projet jusqu'à la mise en production. Aller en production est une condition sine qua non pour apporter de la valeur aux utilisateurs et in fine atteindre ses objectifs. On se mobilise donc pour que cela se fasse au plus vite et de façon fluide. Les difficultés de cette étape seront ici uniquement techniques et méthodologiques, et non pas culturelles.

Dans une organisation bureaucratique, l’affaire est bien plus compliquée. Dans ces structures, l’articulation entre le “R” et le “D” de R&D est parfois très laborieuse. Il faut d’abord que le sommet de la hiérarchie soit convaincu, à coup de présentations Powerpoint, que l’algorithme “marche” avant de le mettre en production, même pour un test sur une audience restreinte. Souvent, le modèle doit avoir une performance supérieure à un seuil, déterminé de façon un peu arbitraire par des personnes éloignées de l’opérationnel, pour avoir le droit de se retrouver en production.

Une fois la performance démontrée, il faut que le métier veuille bien adopter ce nouvel outil. Certaines organisations, notamment dans le secteur banque et assurance, investissent dans la recherche parce qu’elles savent que c’est l’avenir. Pourtant, elles sont réticentes à adopter le fruit de leur recherche quand leurs vieilles méthodes “marchent”. Elles continuent à gagner de l’argent, donc à quoi bon changer ? Dans ces organisations, la recherche peut mettre des années à arriver en développement... si elle a la chance d’y arriver. Parfois, comme c’était le cas chez un client ayant expérimenté une solution très prometteuse pendant plus d’un an, les algorithmes n’arrivent pas en production car les équipes sont paralysées, parce qu’elles “ne savent pas faire” : ce projet n’entre pas dans leurs process. On rejoint ici le constat de Ron Westrum : dans une organisation bureaucratique, “novelty = problems”.

Si on réussit tout de même à passer cet obstacle, il faut alors s’intégrer à un SI normé. On le voit chez certains de nos clients, chez qui l'accès à des ressources s'appuie sur un processus très rigide. Il faut faire une demande à la DSI, qui ne donne accès qu’à certaines ressources qu’elle a au préalable validées comme étant acceptées pour utilisation interne. Faire des demandes trop exotiques, comme l’accès à des GPUs dans une DSI qui n’en a pas l’habitude, peut poser problème et ralentir d’autant plus le processus. De plus, il arrive souvent que l’équipe chargée du déploiement ne soit pas la même qui développe, et que la communication entre les deux ne se fasse pas directement, mais à travers la hiérarchie. Ceci rend la démarche DevOps compliquée et augmente la probabilité d’échec dans le déploiement, ainsi que les allers-retours entre opérations et développeurs.

Dans une organisation pathologique, aller en production ne va pas de soi. Dans ce type de culture, les erreurs sont fatales. On essaie donc de prendre le moins de risques possible, et aller se confronter à la réalité de la production est un très gros risque. En effet, lorsque le Data Scientist mesure la performance de son modèle sur ses données de test, il travaille dans un environnement maîtrisé, où il connaît le format des données et où la distribution n’évolue pas. Les performances sont donc également maîtrisées. En livrant en production, il s’expose fatalement à la détérioration de la performance de son modèle, comme illustré dans l’article Why machine learning models crash and burn in production. Il peut donc être plus intéressant pour une équipe de Data Science dans une organisation pathologique de multiplier les proof of concepts (POC) hors production, d'afficher des performances contrôlées mais hors-sol, puis de se défausser sur une autre équipe pour la mise en production - si ça ne marche pas, on se renverra la balle. Cela fait illusion, et peut permettre avec un peu de chance à des start-ups de lever des fonds en faisant miroiter des résultats impressionnants, surtout s’ils ont été falsifiés.

À la lumière de tous ces exemples, cela semble limpide : un projet de Machine Learning Delivery est fortement impacté par la culture dans laquelle il évolue. Il aura plus de facilités à s’épanouir dans certains environnements culturels que dans d’autres. Forts de ce constat, que faire ? Dans notre prochain article, nous reprendrons la question de la culture et de son influence sur le succès des projets de Machine Learning en l'abordant sous l'angle des stratégies possibles pour tenter de changer cette culture.

[1] Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: the science of lean software and DevOps: building and scaling high performing technology organizations. IT Revolution.
[2] Westrum, R. (2004). A typology of organisational cultures. BMJ Quality & Safety, 13(suppl 2), ii22-ii27.