Comment une DSI est passée de 18 à 6 mois de lead time en s’organisant autour de la valeur

Ce compte-rendu fait écho au replay vidéo du comptoir sur la transformation d’organisation, disponible ici.

Le Lead Time divisé par trois grâce à une organisation des équipes repensée

L’agile a le vent en poupe et désormais les enjeux des entreprises les poussent à mettre à l’échelle le déploiement de la méthodologie, en passant d’équipes unitaires à des DSI et des BU entièrement structurées en agile.

La multiplicité de petites équipes fait le chou gras des frameworks et modèles d’agilité à l’échelle pour gérer les interactions entre ces petites équipes et donner un sens à l'entreprise agile.

Le contexte :

Dans cette entreprise, la DSI rassemble environ 500 collaborateurs, et malgré le fait qu’ils aient déployé l'agilité de manière globale, on constate un accroissement du lead time qui met en difficulté l’ensemble de l’organisation : 18 mois dans un contexte changeant, c’est trop long et trop coûteux.

Malgré un déploiement dans les règles de l’art, il y a un paradoxe que les modèles peinent à résoudre : comment conserver l’efficacité des petites équipes sans réduire à néant l'efficacité globale de l’organisation ?

Qui dit multiplicité d’équipes, dit nombreuses interactions nécessaires pour faire fonctionner l’ensemble.

Cette situation génère de multiples dépendances pour lesquelles il faut beaucoup d'énergie pour les traiter.
Cette énergie et ce temps sont directement imputés au coût de la fonctionnalité développée autant qu’ils provoquent un ralentissement du delivery du produit. Bref, de l'insatisfaction client et l’effet inverse des promesses de l’agilité.

Pour rassurer sur leur métier, les DSI lancent sans cesse de nouveaux projets. Mais cette dynamique aggrave la situation : l'encours sature, et de moins en moins de fonctionnalités voient le jour. La collaboration rapprochée des équipes, pourtant cruciale, peine à s'étendre à grande échelle.

Qu'on le veuille ou non, la structure de votre organisation façonne vos systèmes, souvent de manière invisible mais toujours de manière déterminante, conformément à la loi de Conway.

L’intention : **Défaire les imbrications

**Il est pertinent de créer une boucle vertueuse qui suit les problématiques métier, en lien avec la stratégie de l'organisation. Un domaine métier correspond à tout ou partie d'une problématique spécifique. Ces domaines servent de pierre angulaire pour aligner l'organisation humaine et l'architecture du SI en miroir. En s’appuyant sur eux, nous structurons l'organisation de manière cohérente et durable. Par exemple, les besoins de paiement en ligne ont de grandes chances de perdurer. Cette approche contribue à réduire la complexité des interactions et à clarifier les responsabilités dans chaque domaine.

La manoeuvre de Conway inversée ou comment structurer les équipes autour de vos problèmes métiers :

Étape 1: La première étape consiste à déterminer les sous-domaines métiers en s'appuyant sur l'atelier collaboratif Event Storming Big Picture d'Alberto Brandolini.
Un domaine représente l'ensemble des connaissances, concepts et règles métier d'un problème spécifique que l'on cherche à modéliser dans un logiciel. Nous nous appuyons sur les événements connexes à une problématique métier pour identifier un sous-domaine métier.

Étape 2 :Cartographier les composants techniques qui supportent les sous-domaines identifiés.
Cette étape consiste à dresser une vue d'ensemble des composants existants et à déterminer comment ces composants techniques s'alignent avec les sous-domaines métiers mis en évidence précédemment. Cela permet d’identifier clairement les dépendances et points d’intégration nécessaires.

Etape 3 : Cartographier les équipes qui interviennent sur les domaines.
Dans cette étape, nous identifions et listons les équipes opérationnelles qui interviennent sur chacun des domaines métiers définis. Cette vue permet de clarifier les responsabilités et les périmètres d’action des équipes.

Etape 4 : Etablir les liens entre les équipes et les composants techniques sur lesquels elles interviennent.

Il s’agit ici d’expliciter les interactions existantes entre les équipes et les composants techniques. Cette cartographie facilite la compréhension des dépendances organisationnelles.

À l'issue de ces quatre étapes, nous obtenons un état des lieux reflétant la situation de départ dans notre organisation. Nous venons de réaliser la première phase de notre transformation.

Une fois ces 4 étapes réalisées, l’intention est de limiter les interactions en alignant les équipes et les composants sur les domaines métier, afin que l’organisation reflète l’architecture.

Après cet état des lieux, nous appliquons un principe simple pour mener la deuxième phase de la transformation : chaque composant doit être confié à une seule équipe, garantissant ainsi qu'une équipe est seule responsable de son composant.

La troisième phase vise à s'assurer que chaque équipe soit responsable d'un seul composant et d'un seul domaine, en appliquant les lois des Team Topologies suivants :

• Loi 1 : Vous devez vous assurer qu’un domaine est géré par une seule équipe
• Loi 2 : Une équipe peut gérer 2 à 3 domaines simples
• Loi 3 : Si un domaine est jugé complexe, une équipe devra gérer alors ce seul domaine complexe

L'approche recommandée pour appliquer les lois consiste à découper les domaines en sous-domaines, afin d'ajuster la charge de travail à la taille des équipes agiles.

Le vocabulaire métier est souvent un bon indicateur de changement de contexte. Les ambiguïtés de langage, révélées lors de l'event storming big picture, permettent de les identifier facilement. Cette étape vise également à clarifier les rôles de l'équipe, en les incitant à prendre l'initiative sur les instances de développement, ce qui accélère les délais de livraison.

En conséquence, nous allons obtenir un design d'organisation qui reflète une architecture fonctionnelle. Il ne reste plus qu'à structurer l'organisation en miroir de cette architecture découplée.

**Il ne nous reste plus qu’à opérer un design d’organisation adaptée à ce découplage. **

Comme illustré par cette figure, nous visons à concevoir une organisation centrée sur des équipes productrices de fonctionnalités directement utilisées par les utilisateurs finaux. Les autres équipes jouent un rôle de support, en les déchargeant grâce à des services consommés par les fonctionnalités développées par les équipes productrices de valeur. Imaginez un pilote obligé de sortir de sa voiture pour changer ses pneus lui-même. Autant dire que la course est perdue d'avance.

Identifier les équipes productrices de valeur ainsi que celles qui les supportent.

Il existe deux catégories d'équipes à combiner pour permettre de se concentrer sur la valeur (source team Topologies).

La première catégorie sont les équipes productrices de valeur directe :

• Equipe alignée sur la valeur (Stream aligned team) : qui est en charge de produire les fonctionnalités utilisées par les utilisateurs finaux (valeur brute).

La seconde catégorie sont les équipes en support des équipes productrice de valeur directe :

• Equipe facilitatrice (enabling team) : groupe de spécialistes à factoriser qui permettent d’assurer des standards de pratiques dans des domaines transverses comme l’architecture, la sécurité, l’user experience…
• Équipes qui prennent en charge des parties complexes du produit (complicated subsystem steam) : prennent en charge une partie du système / composant qui demande des expertises spécifiques (ex : AS400).
• Platform team : service utilisable par toutes les équipes. Développe des services, outils et infrastructures qui sont consommés par les autres équipes pour leur permettre de s’alléger des contraintes technico-fonctionnelles et ainsi maximiser leur production de valeur métier.

Définir les modes d’interactions entre les équipes

Ces équipes sont mises en musique avec 3 modes d’interactions :

• Collaboration : nécessite une interdépendance forte mais elle est nécessaire pour innover. Une innovation qui se base sur la convergence de plusieurs métiers ou technologies nécessite des collaborations entre équipes. Ensuite le modèle devrait évoluer vers une standardisation des interactions pour passer à l’exploitation du produit.
• X as a service : découplage et standardisation pour permettre un passage à l’échelle.
• Facilitating : équipe qui vient en“coup de main”. Elle ne fait pas à la place des autres équipes mais permet de les rendre autonomes sur divers sujets.

En appliquant les typologies d’équipes et les modes d’interaction, nous obtenons un design d’organisation centrée sur la valeur basé sur notre cartographie découplée :

Une bonne organisation est une organisation qui bouge au fur et à mesure que le produit évolue.

Votre modèle d’organisation DOIT évoluer pour permettre au produit de tirer le meilleur de chacune de ses étapes de maturité, depuis l'innovation jusqu'à son industrialisation et son passage à l’échelle.

Enseignements

1. Réduction des interactions complexes : En limitant les imbrications entre composants, les échanges entre équipes sont simplifiés, réduisant les frictions et les pertes de temps.
2. Structuration par domaine métier de l’organisation : Une architecture découplée permet d’aligner l’organisation humaine sur les domaines métiers.
3. Orientation sur la valeur livrée : Les équipes sont organisées autour de la valeur qu’elles produisent, ce qui augmente la valeur livrée aux utilisateurs.

Résultats

• Lead Time divisé par trois : Le délai de livraison des fonctionnalités est passé de 18 à 6 mois après six mois d’accompagnement.

• Simplification de l’organisation : Une cartographie en trois dimensions permet de rendre visible les couplages dans l'organisation. Une structuration autour des domaines métiers réduit les coûts de coordination entre équipes.
  
• Amélioration de la Collaboration : Le design collaboratif de l'organisation a renforcé l'adhésion des équipes.

S’il ne fallait retenir que l’essentiel pour réussir sa manoeuvre de Conway inversée :

• Diminuer les interactions entre équipes en limitant les interactions entre composants
• Faire émerger une architecture cible et structurer une organisation par domaine métier
• Aligner et Structurer l'organisation autour de la valeur
• Tous les modèles sont faux mais certains sont utiles. Il est important de les faire évoluer selon le contexte.
• Organisation et système techniques sont les deux faces d’une même pièce

Sources

Domain Driven Design, by Eric Evans

Team topologies : Matthew Skelton and Manuel Pais