Cet article introduit le modèle de l’iceberg, un outil qui permet de voir la réalité sous quatre différentes perspectives : les événements, les patterns, les structures et les modèles mentaux. Son utilité est de rendre visible ce qui, la plupart du temps, est caché sous les événements que nous observons.

Source : https://www.systemsinnovation.network/posts/iceberg-canvas

Événements

La partie visible de l’Iceberg représente les événements observables. L’analogie est que ce que nous observons ne représente qu’une petite partie de ce qui se passe réellement.

Prenons l’exemple vécu d’une équipe agile de développement logiciel à l’intérieur d’un cadre SAFe.

Voici des faits observables sur l’équipe :

• Son sprint a débuté il y a trois jours.
• Son carnet de sprint contient quarante bogues et sept récits.
• Trente-neuf de ces bogues sont entrés lors de la deuxième journée de l’itération.

À la lumière de ces observations, quelles conclusions pourrions-nous en tirer? Probablement pas grand-chose de pertinent, car il manque tout le contexte! Justement, rendre visible le contexte duquel découle ce que nous observons est au cœur du modèle de l’Iceberg.

Par exemple, des bogues, ça n’arrive pas par hasard, mais à cause d’un ensemble de facteurs présents dans le contexte interne et externe d’une équipe. Le modèle de l’Iceberg appelle cela des structures.

Une structure est composée d’éléments et de relations. Par éléments, pensez à des systèmes informatiques, des équipes de travail, des comités de gouvernance, des tables de sécurité, etc. Une organisation peut comporter des centaines d’éléments différents. Par-dessus ça, ces éléments sont interconnectés. Les équipes interagissent avec les systèmes pour répondre aux visions des comités de gouvernance de produit et les deux doivent tenir compte de chaque table de sécurité, et ainsi de suite.

Donc une structure, ça peut être très petit ou très gros. Une structure peut en contenir plusieurs plus petites. Des structures peuvent être interconnectées par des canaux non officiels.

Une structure, c’est donc un réseau de relations entre des éléments qui créent des comportements. L’essence d’une structure n’est pas dans l’ensemble des éléments qui la composent, mais dans les relations entre ces éléments.

Si vous voulez un exemple plus simple, prenez le cadre Scrum. Il organise la manière dont les gens d’une équipe interagissent à travers ses valeurs, ses cérémonies, ses rôles ainsi que ses artéfacts. Ce faisant, Scrum crée une nouvelle structure, en transformant les relations entre les éléments de l’équipe (les individus). Ce sont les mêmes personnes, mais organisées avec des relations différentes, ce qui leur permet d’obtenir des résultats différents. Scrum est un cadre pour créer des structures dont les éléments sont des personnes.

Si vous pensez que c’est abstrait, c’est que ça l’est. Pourtant, les structures sont partout et ce sont elles qui donnent forme au monde.

C’est difficile de voir des structures, parce que nous n’avons pas l’habitude de réfléchir en structures. Nous sommes plutôt conditionnés à voir les événements et à réagir.

Après tout, il y a urgence! Il y a quarante bogues dans le sprint, il faut les régler. Maintenant! L’enjeu est important!

Cependant, cela ne fait que régler temporairement le problème parce que ce qui génère ces bogues reste en place. D’autres finiront par atterrir dans le carnet de l’équipe. Pour augmenter son impact, l’équipe doit agir sur les structures à la source de ses bogues.

Il est donc temps de descendre sous la surface de l’Iceberg et d’aller regarder les patterns.

Patterns

Pour agir sur les structures, encore faut-il pouvoir les identifier. La bonne nouvelle est que les structures ont tendance à générer des événements similaires et selon des tendances qui se répètent à travers le temps. Dans le modèle, cela s’appelle des patterns. Autrement dit, trouver des patterns dans les événements que nous observons nous donne des indices pour identifier les structures qui les causent. Cela se résume en une question :

Quelles sont les tendances qui se manifestent à travers le temps?

Évidemment, cela implique de recueillir des données sur ces événements afin de pouvoir les analyser.

Ce faisant, en analysant les huit derniers mois, l’équipe observe que ceci :

• Une grande quantité de bogues arrivent dans l’équipe toutes les six semaines.
• Ces bogues arrivent toujours dans la première semaine du sprint.
• Outre ces pics, l’équipe ne reçoit pas de bogue.
• Ces tendances sont observables depuis environ six mois. Avant, l’équipe ne recevait aucun bogue.

En ayant connaissance de ces patterns, l’équipe peut agir de façon prédictive. Sachant que les bogues arrivent aux six semaines, elle pourrait ajuster sa planification de sprint en conséquence ou demander de l’aide à d’autres équipes, mais cela ne réglerait pas le problème.

Structures

Sachant que les structures sont omniprésentes, par où commencer? Une fois des patterns identifiés, la prochaine étape est de poser deux questions supplémentaires :

• Qu’est-ce qui a une influence sur les patterns? 
• Quelles sont les relations entre les éléments? Comment sont-ils reliés?

Rendez-les visibles !

Par exemple, l’équipe pourrait se demander : qu’est-ce qui influence le nombre de bogues?

Ce diagramme se lit comme suit :

• Le nombre de bogues diminue si la qualité du code augmente (-).
• La qualité du code augmente si la qualité des tests augmente.

Jusque là, rien d’exceptionnel.

Cependant, un élément intéressant est mis en lumière en regardant ce qui influence la qualité des tests :

En effet, l’équipe doit utiliser des maquettes pour faire ses tests.

Nous pouvons nous demander pourquoi : pourquoi ces maquettes sont-elles nécessaires aux tests de l’équipe?

L’équipe travaille dans un contexte d’agilité à l’échelle. Dans ce cadre, une autre équipe s’occupe de faire les tests d’intégration. 

Par conséquence, la seule façon pour l’équipe de tester ses fonctionnalités, c’est d’utiliser des objets factices (mock) pour imiter les vrais systèmes.

L’équipe d’intégration s’occupe également de plusieurs équipes. Ce faisant, cela prend environ six semaines pour intégrer le code d’un seul sprint.

Si vous avez déjà fait du développement d’applications, vous savez à quel point cette façon de faire n’est pas optimale! Et pourtant, il s’agit d’un cas vécu.

Prenons un moment pour contempler l’iceberg qui se construit à travers les réflexions de l’équipe.

L’équipe reçoit beaucoup de bogue aux six semaines, parce qu’il y a un délai de six semaines pour que le code soit testé dans l’ensemble de la solution. Cette perspective permet de concevoir une intervention avec impact réel sur le problème.

Nous pouvons également augmenter cet impact en agissant sur ce qui est à l’origine de ces systèmes. La base de l’Iceberg : les modèles mentaux.

Modèles mentaux

Les modèles mentaux représentent la base de l’Iceberg. Ce sont les hypothèses, les croyances et les valeurs qui ont façonné les structures qui sont en place aujourd’hui.

L’équipe est face à une question fondamentale. Pourquoi une seule équipe fait-elle les tests intégrés pour six autres? Pourquoi ne pas tout simplement donner à tout le monde la capacité de faire ses propres tests?

Pour y arriver, l’équipe a dû parler avec les autres équipes, les coordinateurs et coordinatrices, les directeurs et les directrices, ainsi qu’à toutes les parties prenantes capables de répondre à ces deux questions :

• Quelles hypothèses, croyances et/ou valeurs ont donné forme aux systèmes en place?
• Quelles croyances maintiennent les systèmes en place?

Voici le résultat de leur enquête.

À la base de l’Iceberg, la perception que l’initiative était en retard sur une estimation initiale, faite il y a plusieurs années et jamais mise à jour depuis. Ce faisant, une trop grande part du budget avait déjà été utilisé et il fallait donc réduire les coûts.

Paradoxalement, c’est plutôt l’effet inverse qui se produisait. Les dépenses explosaient, parce que les équipes étaient grandement retardées dans leur cycle de développement, notamment parce qu’elles devaient attendre six semaines pour avoir de la rétroaction sur leur travail!

Restreindre les coûts pour conserver le budget diminuait ainsi la capacité à livrer de la valeur, ce qui garantissait que les budgets seraient dépassés.

Cet exemple démontre que ce sont les modèles mentaux qui donnent forme au monde qui nous entoure.

Synthèse

Le modèle de l’Iceberg est un levier. Plus nous agissons à sa base, plus la transformation sera profonde et durable. 

Vous pouvez intervenir au niveau des événements. Il se passe quelque chose et vous réagissez. Vous n’allez probablement régler le problème que temporairement.

Si vous observez les événements à travers le temps, vous pourrez percevoir des patterns qui se répètent. Cela vous permettra de différencier les événements isolés de ceux qui sont causés par des structures.

Au niveau des structures, vous aurez réellement la capacité de régler le problème parce que vous agirez sur sa cause. Et si vous arrivez à agir sur les mentalités, les principes, les idées clés derrière ces structures, vous aurez un impact encore plus grand. Cependant, plus l’on vise à agir à la racine de l’Iceberg, plus grande est la résistance au changement. 

Dans un prochain article, nous explorons d’autres outils à utiliser en association avec le modèle de l’Iceberg, afin de diminuer cette résistance au changement.

How to See “Structure”