Lorsque l'on parle d'initiatives de changement ou de programmes d'amélioration, une étude est constamment mentionnée : l'article "Leading change" de John Kotter. Son site internet, Kotter International, note que "plus de 70% des efforts de changements majeurs en entreprise échouent".
Cette année 2015 est le 20ème anniversaire de "Leading Change". Fait intéressant : lorsque Kotter a publié ses résultats, ce n'était pas nouveau. Des études antérieures en avaient montré à maintes reprises de similaires.
Il nous fallait faire mieux durant ces 20 dernières années. Au cours de la dernière décennie, nous avons vu l'agilité devenir dominante, ainsi qu'une énorme montée du lean. Ces 2 mouvements avaient pour objectif de rendre les paradigmes de management plus adaptatifs, évolutifs, pour au final être performants à changer. Les chiffres devaient juste s'améliorer.
Cela n'a pas été le cas. En fait, McKinsey & Co. a répété l'étude de Kotter en 2008 et en a tiré exactement la même conclusion. Dans le Harvard Business Review de 2013, Ron Ashkenas a synthétisé un nombre d'études sur le taux de succès des projets de changements organisationnels et a montré que celui-ci est resté stable depuis les années 70.
Nous ne voyons virtuellement aucun impact de l'agilité ou du lean sur les taux de succès des initiatives d'amélioration.
Imitateurs
Cela ne devrait pas être une surprise à la manière dont l'adoption de l'agilité ou du lean se passe typiquement. Les entreprises cherchent souvent des recettes de cuisine. C'est un thème commun des conférences, des sessions de formation et même des événements autour du coaching.
"Les personnes copient le plus visible, évident, et fréquemment les pratiques les moins importantes”.
Jeffrey Pfeffer & Robert Sutton, Hard Facts, Dangerous Half-Truths, and Total Nonsense (2006)
Lorsqu'une nouvelle approche apparaît, c'est la seule chose que nous avons : nous voyons ce que les autres font et comment ils le font. Nous n'avons pas de compréhension suffisamment approfondie pour voir au-delà de cela. Cependant, avec le temps, nous devrions pouvoir en apprendre plus sur le contexte.
Je ne dirais pas que cela est facile. En fait, il y a une célèbre histoire de managers américains de l'industrie automobile qui visitèrent les usines japonaises au début des années 80. Ils voulaient savoir pourquoi leurs concurrents japonais se portaient si bien. Avec surprise, les japonais ouvrirent leurs usines à leurs visiteurs, expliquèrent leurs process, etc...
Une surprise d'autant plus grande survint ensuite lorsque les américains appliquèrent ces mêmes pratiques dans leurs propres usines. Non seulement ils n'ont pas vu les améliorations qu'ils attendaient, mais dans certains secteurs, il ont même commencé à faire pire.
Ce qu'ils n'avaient pas compris était qu'il y avait plus que les pratiques. Il y a des principes que les personnes suivent et des valeurs qu'elles partagent. Tout cela faisant partie d'un tout plus grand : une culture organisationnelle.
L'histoire est exactement la même pour ce que nous faisons si fréquemment dans nos programmes de changement, nos initiatives d'amélioration et nos implémentations Agile et lean. Nous sommes des imitateurs. Pas étonnant que nous ne voyions pas de changement durable.
Iceberg
La métaphore que j'aime utiliser est celle d'un iceberg. Nous voyons seulement une petite portion d'un iceberg au-dessus du niveau de l'eau. Le reste demeure caché de nos yeux. Cependant, si vous enleviez seulement la partie visible du reste de l'iceberg et que vous le mettiez dans l'eau seul, il ne serait plus aussi impressionnant qu'à l'origine.
La partie visible d'un iceberg correspond aux pratiques. La partie importante de l'iceberg, celle qui est immergée, est composée des principes et des valeurs.
De chaque pratique, on peut tirer un principe sous-jacent. Prenez la visualisation par exemple. Les principes sous-jacents seraient de mieux comprendre ce qu'il se passe et d'avoir une meilleure disponibilité des informations.
Maintenant, nous pouvons faire un autre pas et deviner la valeur derrière la pratique et les principes. Dans ce cas là, la transparence.
Nous pouvons boucler entre ces aspects. Il se pourrait que la visualisation procure une meilleure disponibilité des informations et une meilleure compréhension de ce que nous faisons, et de ce fait serait moteur de la transparence. Il se pourrait également que si nous voulons de la transparence, nous avons besoin que les personnes aient plus d'informations disponibles pour pouvoir mieux comprendre ce qu'ils font, ainsi la visualisation est une pratique qui fonctionnerait pour nous.
Pour comprendre pourquoi une pratique ou une méthode fonctionne et quand elle est raisonnablement applicable, nous devrions comprendre ce qui se trouve sous le niveau de l'eau. Nous devrions penser aux principes et aux valeurs qui sont les pierres angulaires des pratiques et des méthodes.
Contexte
Il y a en fait deux icebergs. Le premier se référerait à un ensemble de pratiques ou à une méthode que nous voulons adopter. Comme proposé précédemment, nous pourrions en déduire des principes et des valeurs en commençant simplement par une compréhension méticuleuse des pratiques. Parfois, nous n'avons même pas besoin de faire cela. Par exemple, pour la méthode Kanban, Mike Burrows a fait le travail dans son article maintenant classique sur les valeurs Kanban.
Le second iceberg n'est pas moins important. Il décrit les principes et les valeurs auxquels une organisation spécifique adhère.
Il peut être délicat de le trouver. Alors que les organisations ont souvent des valeurs et des principes explicitement décrits dans leurs énoncés de vision et mission, ces derniers ne sont que revendications. En réalité, la façon dont les personnes se comportent suggère qu'un ensemble très différent de valeurs est en place. A ce niveau, le manque d'authenticité est une pathologie commune.
Nous avons, cependant, une méthode reconnue pour dériver les vrais principes et valeurs d'une organisation. Nous pouvons commencer avec les pratiques et les comportements, vu que nous ne pouvons voir que ceux-ci lorsque l'on regarde une organisation.
Peu importe si une organisation énonce explicitement la satisfaction client et la haute qualité dans sa mission. Ce qui importe est que les personnes travaillent activement dans l'atteinte de ces objectifs.
Si vous entendez un manager de projet interdire à une équipe de travailler en pair programming ou en TDD parce que "ce n'est pas efficace", vous aurez une bonne idée de l'intérêt que porte l'organisation à la qualité. Si vous voyez un responsable opérationnel dire à ses équipes de ne pas partager le véritable statut des fonctionnalités avec un client, vous comprendrez rapidement à quel point il estime la satisfaction client.
Ce que nous faisons est que nous commençons avec les comportements spécifiques. Dans le premier exemple, le manager de projet ne permet pas aux développeurs d'utiliser des pratiques spécifiques au nom de l'efficacité. Que peut-on en déduire ? Que les personnes - dans ce cas les développeurs - ne sont pas autorisées à adopter des pratiques qui sont communément associées avec la haute qualité.
(Je ne souhaite pas débattre de l'apport du TDD ou du pair programming sur l'amélioration de la qualité. Je pointe simplement le fait que ceux qui le croient ne sont pas autorisés à travailler de cette manière.)
Nous pouvons également dériver que le fait de distribuer l'autonomie ne fait pas partie de la culture organisationnelle. Ce que nous voyons est qu'une vision simpliste de l'efficacité est importante, c'est-à-dire plus de fonctionnalités plus vite. Ce qui, d'ailleurs, ne finit pas très bien.
“Traiter le gaspillage plus efficacement est moins cher, plus propre”.
Stephen Parry
Le second exemple montre que la transparence dans la communication avec le client n'est pas une priorité. Cela signifie que la construction de relations de confiance avec les clients n'est pas valorisée et que les besoins clients ne sont pas importants. Au final, la satisfaction client n'est pas une des valeurs dont l'organisation se soucie.
À quelles valeurs s'intéressent donc ces personnes ? Un responsable opérationnel qui demande à une équipe de vendre des demi-vérités et des mensonges à un client suggère que l'organisation présente un sentiment de sécurité restreinte avec des tiraillements politiques. En allant plus loin, nous pourrions spéculer que la société valorise la compétition interne car les personnes ont besoin et essaient d'être bien vues, même au prix de la satisfaction client.
Même si vous n'avez aucune information sur lesquelles baser votre analyse, observer les comportements existants vous permettra de construire un iceberg pour une organisation. Ne soyez pas surpris si ce n'est pas une image toute rose à regarder.
Je tiens par contre à vous prévenir d'une chose. N'allez pas trop loin au moment de tirer vos conclusions à partir d'une simple observation. Un idiot seul ne définit pas la culture enitère de l'entreprise. Des observations répétées vous en apprendront beaucoup sur les valeurs et les principes de l'organisation.
Discordance
Généralement, une pratique spécifique ou une méthode est finalement rejetée car elle va à l'encontre des valeurs et principes de l'organisation. En d'autres termes, une nouvelle approche va simplement trop au-delà de la culture organisationelle existante.
Laissez-moi vous donner un exemple. Une pratique que Scrum a largement popularisée est le time boxing. Nous planifions le travail complet autour d'itérations fixes. Cela aide l'équipe à se concentrer sur les détails qui sont pertinents pour la petite quantité de travail qui rentre à l'intérieur de ce temps restreint. Cela donne également un niveau correct d'isolation pour une équipe qui idéalement peut travailler sans interruption pendant la durée de l'itération.
Les principes derrière le time boxing sont la réduction du nombre d'éléments sur lesquels l'équipe travaille et l'apport d'un rythme raisonnablement constant de livraisons. Cela améliore l'efficacité et la prédictibilité.
Prenons Amazon. Ils déploient du Software en production toutes les douze secondes environ. Que se passerait-il s'ils adoptaient Scrum à la lettre, disons des itérations de deux semaines et des déploiements synchronisés en production ? Cela oblitèrerait littéralement leur capacité à répondre aux changements de la manière dont ils le font à présent. Leur aptitude à rapidement expérimenter disparaîtrait.
Cela signifie-t-il que le time boxing est mauvais ? Pas du tout. Cela signifie simplement que les valeurs et les principes qu'Amazon porte diffèrent, ou même rentrent en conflit, avec ceux qui sont derrière le time boxing.
Dans ce cas, ce qui intéresse Amazon est de raccourcir les boucles de feedback pour la construction de leurs fonctionnalités et la capacité de déployer fréquemment et indépendamment d'autres déploiements. Cela leur donne la capacité d'expérimenter rapidement. Et ils ne l'échangeraient ni pour une meilleure predictibilité, ni pour une meilleure efficacité.
C'est pourquoi comprendre une concordance, ou une discordance entre les principes et les valeurs qui alimentent une méthode et ceux par lesquels une organisation vit est si important. Sans cela, nous construirions un autre culte du cargo. Et nous savons que les cultes du cargo ne sont pas des stratégies performantes lorsque l'on vise un changement durable.
La clé ici est une compréhension minutieuse des pratiques et méthodes que nous voulons adopter. Un pattern commun que je vois est de suivre le modèle ShuHaRi : commençons par les bases, et seulement ensuite, allons vers une compréhension approfondie.
Cette approche ne fontionne pas dans notre contexte si elle considère que nous avons choisi la bonne méthode en premier lieu. Notre cas est différent car nous avons besoin de comprendre les méthodes avant de pouvoir choisir celle qui correspond le mieux à une organisation spécifique.
Une façon d'atteindre ce niveau de compréhension serait d'utiliser des sources comme des livres, des articles, des blogs, des vidéos, etc. Bien qu'elles ne remplaceront jamais l'expérience, elles peuvent vous aider à choisir plus sagement. Au lieu d'appliquer aveuglément ce qui semble être la nouvelle tendance aujourd'hui, posez des questions. Pourquoi cette pratique est-elle une partie d'une méthode ? Qu'essayons-nous d'accomplir en utilisant cette technique ? Y-a-t'il d'autres outils plus pertinents dans notre contexte avec des rendements similaires ? Traitez cela comme une expérimentation par la pensée. Elle n'est pas chère après tout.
Une autre option est de lancer une expérimentation à petite échelle, sans danger (safe-to-fail). Choisissez une équipe volontaire à modifier leur façon de travailler. Voyez comment une nouvelle méthode fonctionne. Cela vous aidera à comprendre la méthode, ainsi que sa correspondance avec le contexte organisationnel.
Profondeur
Une discussion à propos des valeurs organisationnelles n'est pas simple. Une valeur n'est pas simplement adoptée sur le champ. Nous ne pouvons pas simplement annoncer qu'à partir de maintenant, nous valorisons la diversité et qu'elle devienne vraie. Il n'y a même pas une simple réponse sur si oui ou non nous valorisons déjà la diversité. Ce n'est pas une question binaire. C'est une échelle - en fait, une échelle multidimensionnelle.
Prenez la transparence comme exemple. Dans une organisation donnée, il peut n'y avoir aucun problème de transparence au sein des équipes. Tout le monde serait heureux de partager le statut de leur travail avec le reste de leur équipe sur un tableau de tâches. Tout problème serait discuté ouvertement au sein de l'équipe.
Cela fonctionnerait-il de la même façon entre les équipes toutefois ? Les personnes seraient-elles aussi ouvertes sur leur santé devant d'autres équipes ? Par exemple, une équipe pourrait être fainéante mais ne voudrait pas l'admettre devant tout le monde. Ils ne voudraient pas que leur temps libre soit sacrifié pour secourir ce projet maudit dont tout le monde parle au bureau.
Puis nous avons la hiérarchie. Est-ce que l'équipe est équitablement transparente lorsqu'un senior manager est dans les environs ? Sont-ils prêts à dire à leur manager qu'ils font beaucoup moins bien que ce qui est attendu dans le plan directeur pour un projet ? Sont-ils disposés à partager toutes les difficultés auxquelles ils sont confrontés ? Peut-être qu'ils ont peur du retour de flammes s'ils parlent.
En parlant de management haut niveau... Les managers sont-ils ouverts et transparents avec leur équipe ? Partagent-ils honnêtement ce plan de réorganisation qui circule depuis un certain temps ? Partagent-ils que la raison de cette réorganisation est la situation financière médiocre du dernier trimestre ?
Enfin, nous avons un client. Est-ce que l'équipe sera aussi transparente devant le client qu'elle l'est entre ses membres ?
Nous avons établi que pour que la visualisation fonctionne bien, nous avions besoin de valoriser la transparence. Et si la transparence est adoptée, mais pas de manière universelle ? Cela pourrait bien marcher dans un contexte local, voire un peu plus large dans une certaine mesure, mais pas du tout dans un contexte organisationnel global ou dans les relations avec les clients.
C'est un problème simple autour duquel manoeuvrer. Vous pouvez choisir de limiter l'application de toute pratique spécifique basée sur la transparence. La visualisation peut bien fonctionner et être utile au niveau équipe, mais rencontrer de la résistance au niveau porte-feuille. Et, bien évidemment, de nombreuses équipes ne veulent pas que les clients voient ces visualisations du tout.
C'est d'ailleurs pourquoi nous voyons beaucoup d'implémentations superficielles de méthodes agiles. Cela fonctionne au niveau de l'équipe mais pas tellement plus loin que cela.
Devrions-nous introduire une pratique ou une méthode lorsque l'on est conscient que le meilleur que l'on puisse obtenir est une portée limitée ? J'ai quelques réponses à cette question.
La première réponse est de chercher une méthode qui correspond le mieux au contexte. Heureusement, nous ne vivons pas dans un monde où nous pouvons avoir n'importe quelle méthode, tant que c'est Scrum. Etant donné que nous avons fait notre devoir et que nous avons une compréhension profonde d'une variété de pratiques et de méthodes, nous avons de bonnes chances de trouver quelque chose qui convient.
Une autre réponse est d'accepter que les résultats de l'implémentation d'une méthode seront limités. Un effet intéressant des implémentations Kanban est que même lorsqu'une méthode est adoptée à un niveau superficiel, les équipes continuent à rapporter des améliorations. Ce n'est pas vraiment une surprise. L'introduction de la visualisation vous permet de moissonner les éléments les plus visibles : vous pouvez adresser la plupart des files d'attente, comprendre les causes racines des blocages, et identifier les goulots d'étranglement.
Enfin, il y a une méthode difficile. Alors que nous ne pouvons pas changer directement une culture organisationnelle, nous pouvons l'influencer. Evidemment, plus l'organisation est grande, plus le changement à l'échelle complète est difficile. Ce sujet mériterait un article en lui-même.
Compréhension
Une fois que nous avons une vue d'ensemble, nous pourrions avoir d'autres idées à propos des méthodes. Le plus souvent, nous connaissons les méthodes comme étant des collections de meilleures pratiques. L'astuce est que "meilleure pratique" est toute une affirmation.
“Il n'y a pas de meilleures pratiques, seulement de bonnes pratiques selon le contexte”.
Larry Maccherone, Impact of Agile Quantified (presentation) 2014
Il n'y a pas de solution miracle. Pour expliquer cela en utilisant les définitions de domaines de Cynefin : la plupart du temps, notre travail est dans un domaine complexe ou, au mieux, compliqué. Cela signifie que, au mieux, nous pouvons parler de bonnes pratiques. Elles pourraient fonctionner dans certains contextes mais pas dans d'autres.
Une fois que nous comprenons les fondements et les hypothèses de base des pratiques spécifiques et ce qui intéresse nos organisations, nous pourrions deviner la pertinence de ces pratiques pour nous. Non seulement nous éviterions de construire un autre culte du cargo, mais nous améliorerions également nos chances de réussite dans l'adoption d'une méthode de notre choix.
Nous contribuerions à diminuer le taux d'échec des initiatives de changement d'au moins un petit peu.
Ce qui change la donne, c'est l'attention. Au final, une utilisation attentive d'une pratique mène à l'apprentissage, alors qu'inversement, cela mène à un culte du cargo.
Challenge
Il n'y a pas de réponse simple à la question de pourquoi nous ne réussissons pas à changer - tout du moins pas sous la forme d'une recette de cuisine. En fait, nous avons plein de recettes et elles sont une des raisons clés du pourquoi nous avons continué à répéter les mêmes erreurs pendant plus de 40 ans.
Ce n'est pas seulement que nous avons plein de recettes, mais aussi comment nous les avons codifiées - et ainsi, bien sûr, commencé à certifier les personnes. Le résultat final est qu'il est plus facile pour les organisations de simplement choisir une méthode d'un menu et de s'attendre à ce que tout le monde se conforme à cette méthode - et d'espérer répéter une success story.
Il n'est pas vraiment surprenant que cela ne marche pas.
Mon challenge est de déplacer le taux de succès des programmes de changement vers le haut, au moins un petit peu. Pour cela, nous avons besoin de changer notre état d'esprit. Il n'y a pas de récompenses à être un magasin Scrum ou Kanban si nous ne délivrons pas de valeur à nos clients.
Ne sautez pas juste sur le prochain mouvement, quel qu'il soit. Informez-vous minutieusement sur cette nouvelle approche avant de la déployer en long et en large dans votre organisation. Lancez des expérimentations à petite échelle pour avoir une première expérience. Comprenez la culture d'entreprise. Faites évoluer l'approche pour qu'elle corresponde mieux à votre contexte.
Bien que cela nécessite du travail et une ouverture d'esprit, ce n'est pas difficile à comprendre. C'est de l'attention que résulte l'apprentissage. Ce n'est qu'alors seulement qu'un changement pourra être durable et réussi.
A propos de l'Auteur
Pawel Brodzinski est leader, team builder et agent du changement, mais avant tout un praticien expérimentant constamment qui aide ses équipes à mieux travailler (et apprendre dans le processus). Il est à la tête de Lunar Logic, une société de développement web de services professionnels, où il pratique ce qu'il prêche - ce qui rend le travail avec Lunar Logic une expérience exceptionnelle. Pawel a été à la tête de la première implémentation Kanban dans l'industrie Software de Pologne. Il est candidat au Brickell Key Award et membre actif de la communauté Lean Kanban. Il partage ses idées sur le management de projets software sur son blog. Pawel est un passionné pour construire de bonnes équipes, créer de superbes cultures organisationnelles et aider les personnes à grandir.