Réussir une "Conway inversée" - Compte-rendu du talk de Romain Vailleux à La Duck Conf 2021
L’entreprise est un système complexe constitué d’humains et de systèmes technologiques en perpétuelle interaction. Ce système “socio-technique” est le sujet favori de Romain.
Melvin Conway a observé que les structures de communication des humains influencent directement le design des systèmes techniques d’une organisation.
En clair : l’organigramme de l’entreprise et les relations interpersonnelles entre acteurs ont plus d’influence que les designers et les architectes !
Le principe d’une “Conway inversée” est simple : pour transformer à moindre coût votre entreprise, intéressez-vous d’abord aux équipes et à leur mode d’interaction. Le reste suivra...
En s’inspirant du best-seller Team Topologies: Organizing Business and Technology Teams for Fast Flow par Matthew Skelton and Manuel Pais, Romain donne quelques conseils pour passer à la pratique, réorganiser vos équipes pour mieux répondre aux enjeux stratégiques de votre entreprise et concevoir à cette occasion des organisations apprenantes où il fait bon vivre.
L’entreprise : un système socio-technique complexe
Romain Vailleux, consultant chez OCTO depuis 2015 est régulièrement contacté par des dirigeants d’entreprise qui se lamentent sur les limites de leurs systèmes d’information : “Mon CRM ne fait pas l'omnicanal, notre application mobile est en retard, mon chantier API part en sucette….”
L’entreprise est un système complexe constitué d’humains et de systèmes technologiques en perpétuelle interaction. Ce système “socio-technique” est double :
- Côté Socio : l’humain, le sensible, les équipes et leurs interactions
- Côté Technique : les machines, la logique et la rigueur des processus et du capital
Ces deux dimensions interagissent au sein d’un seul et même système complexe, oscillant autour d'un point d'équilibre rarement optimal.
Ce système résiste vaillamment à toute tentative de transformation...
Est-ce que vous voyez le problème?
Comment créer des changements d’équilibre durables dans les systèmes socio-techniques que sont nos organisations ? Et cela en économisant le temps et l’énergie dépensés...
La loi de Conway
Melvin Conway aussi s'intéresse, depuis les années 1960, aux systèmes “socio-techniques”.
La loi qui porte son nom (Loi de Conway) s’énonce ainsi : « les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. »
Cette loi est citée abondamment par les consultants OCTO qui repèrent ces patterns dans les entreprises et constatent invariablement que “la structure de l’entreprise influe sur l’architecture” et non l’inverse.
Manœuvre de Conway inversée
Cette manœuvre audacieuse consiste à utiliser la loi de Conway pour parvenir indirectement à nos fins : pour transformer à moindre coût votre entreprise, modifiez ses structures de communication pour influencer l’émergence des designs d’architecture optimaux.
La vraie question à se poser est alors : quelle est l’organisation idoine pour atteindre une cible d’architecture donnée ?
En pratique : Team first!
Le livre Team Topologies: Organizing Business and Technology Teams for Fast Flow (Matthew Skelton, Manuel Pais) nous offre un nouvel outil de modélisation utile pour étudier, débattre et clarifier la structure de communication entre les équipes.
Pour concevoir des équipes optimales, deux facteurs sont essentiels :
- Limiter la charge cognitive (métier, technique, infra) de l’équipe pour éviter l’overflow et conserver une capacité d’apprentissage.
- Choisir une taille de l’équipe facilitant les interactions.
Répartir 150 personnes dans plusieurs équipes n’est pas évident. Les travaux de Dunbar et d’autres nombres significatifs s’avèrent bien utiles :
- 150 : le nombre de personnes avec qui vous pouvez maintenir une relation/vous rappeler simultanément ;
- 50 : le nombre de personnes avec qui vous pouvez entretenir une relation de confiance mutuelle ;
- 15 : le nombre de personnes avec qui vous pouvez entretenir une relation de confiance élevée ;
- 5 ( +/- 2) : le nombre d’objets simultanés que vous pouvez retenir instantanément (à rapprocher de la charge cognitive). Il s’agit également du nombre de personnes maximum avec qui vous pouvez entretenir une relation de collaboration étroite.
Privilégiez les petites équipes et une faible charge cognitive
Trouver l’optimum entre taille d’équipe et efficacité, c’est positionner le curseur entre :
- Synchronisation dans l’équipe versus Synchronisation inter-équipe
- Avoir toutes les compétences dans l’équipe versus Créer des dépendance envers d’autres équipes
- Coupler fortement les briques logicielles versus Tendre vers une architecture découplée
Les auteurs de Team Topologies: Organizing Business and Technology Teams for Fast Flow distinguent quatre types d’équipes :
- Stream-aligned team : flow et réactivité, dédié à l’atteinte des objectifs de l’entreprise.
- Trois autres types d'équipe qui n’ont pour objectif que de lever les obstacles sur la route des stream aligned teams, et de minimiser la charge cognitive :
- Enabling team : diffuser des bonnes pratiques et augmenter le niveau de savoir-faire des équipes (consulting/coaching/mentoring/formation...)
- Complicated-subsystem team : regrouper des compétences de pointe pour abstraire de la complexité essentielle dans un produit mis à disposition du reste de l’organisation.
- Platform team : simplifier l’usage de socles communs qui accélèrent la mise en oeuvre des produits
_Les 4 types d’équipe du modèle
_Team Topologies: Organizing Business and Technology Teams for Fast Flow
Enfin trois types d’interactions possibles entre équipes sont proposées dans ce modèle :
- Collaboration : lors d’inter-dépendances fortes deux équipes décident d’intensifier leurs relations de façon à adapter finement l’intégration de leurs produits logiciels. Le mode d’intégration est donc conçu plutôt ad hoc avec un objectif d’efficacité et de spécialisation.
- X-as-a-Service : mode d’interaction favorisant le découplage et la standardisation. Un équipe met à disposition son produit via des interfaces standardisées. L’équipe productrice du service adopte une culture “produit”.
- Facilitating : relation temporaire entre 2 équipes avec pour objectif la transmission de compétences de façon durable de l’une vers l’autre.
_Les 3 modes d’interaction du modèle
_Team Topologies: Organizing Business and Technology Teams for Fast Flow
L’organisation cible se conçoit et s’assemble ensuite comme un Lego® en ajoutant successivement les équipes et les modes d’interaction adaptés.
Exemple d’organisation avec les 4 types d’équipe et les 3 modes d’interaction
En pratique : assemblage d’un cas concret
Nouvelle organisation cible
L’organisation se conçoit et s’assemble pas à pas en prenant en compte les enjeux et les contraintes de l’entreprise :
| #### Enjeux & contraintes | #### Equipe | #### Mode d’interaction |
| Résoudre les dépendances fortes : “Le PIM et le CMS doivent être très fréquemment synchronisés et fonctionnent en miroir.” | Complicated Subsystem team “Products” | Collaboration |
| Prendre en compte la stratégie d’entreprise : “Notre cœur de métier est d’offrir une expérience client reflétant la qualité et l’innovation de nos produits.” | Stream aligned teams “Front Web” et “Front Mobile” | Collaboration avec Products |
| Supporter les chantiers de transformation : “L’omnicanal passe par la mise à disposition des informations CRM et des services OMS pour l’ensemble des canaux.” | Complicated Subsystem team “CRM” et “OMS” | X as a service avec “Products” |
| Regrouper les compétences rares avec une mission de transmission des compétences : “Nous avons opté pour la solution Xforce sur plusieurs briques. Mais les experts sur le marché sont rares.” | Enabling team “XForce” | Facilitation |
| Prendre en compte l’état de maturité du marché applicatif : “Les moyens de paiement se multiplient. Les évolutions de la brique de paiement doivent bénéficier à tous les canaux de vente. Elle doit pouvoir être décommissionnée/remplacée facilement si nous changeons de partenaire.” | Complicated Subsystem team “Service Paiement” | X as a service avec “Products” |
| Partager les bonnes pratiques<br><br>“Par ailleurs, nous avons remarqué que certaines bonnes pratiques au niveau de l’implémentation du service de paiement nous permettaient de gagner 34 pts de conversion.” | Complicated Subsystem team “Service Paiement” | Collaboration avec Products “Front Web” et “Front Mobile” |
Votre modèle doit évoluer
Le modèle n’est pas figé : il va être initialisé puis être ajusté en fonction de nombreux paramètres évolutifs :
- Le mode d’intégration des applications
- La stratégie d’entreprise
- La maturité des marchés applicatifs
- La maturité des équipes
- L’architecture existante
- La loi / le risque (eg. séparation des responsabilités)
Takeway
Bonus : La boite à outil de l’architecte d’orga
