ah j’écoute aussi Système 1-2.
Le guide de poche traduit par @leodavesne
J’avais fait des sessions de relecture pour cette traduction.
Je vais regarder au 3eme
1 « J'aime »
Je viens de terminer la lecture du livre de Garry Kasparov, La vie est une partie d’échecs, où l’ancien champion du monde fait un parallèle entre le jeu d’échecs et le monde de l’entreprise. Je l’ai acheté sur recommandation d’une amie, joueuse d’échecs de très bon niveau, ce qui n’est clairement pas mon cas.
Je ne sais pas trop quoi en penser. Il passe en revue différentes notions comme la stratégie, la tactique, savoir échanger du matériel contre du temps et vice-versa, l’indispensable remise en question pour être champion, etc.
Mais toutes les notions abordées le sont de manière assez superficielles à mon goût et sans réelle connexion les unes avec les autres. On passe d’une notion à l’autre quasiment sans transition et sans un plan d’ensemble, ce qui est assez étonnant pour un maître de planification que doit être un joueur d’échecs.
En fin de lecture, j’ai surtout eu l’impression de lire une rétrospective de la vie de Garry Kasparov en tant qu’immense joueur d’échecs, illustrée par de nombreux récits de partie et d’anecdotes, sous le prétexte de conseils de vie inspirés du jeu d’échecs.
Ce n’est ni inintéressant, ni désagréable, à condition d’être quand même un amateur déjà très éclairé du jeu d’échecs vu le vocabulaire et les concepts déployés, mais je m’attendais à nettement mieux.
1 « J'aime »
Dans le cadre d’un projet de modernisation que je pilote, je me suis récemment replongé dans le livre Team Topologies, qui a eu une grande influence dans le milieu de l’IT et des organisations ces dernières années, et à juste titre me semble-t-il.
Même si Scrum Life leur a consacré quelques vidéos, ce livre pourtant n’a toujours pas son entrée dans ce topic. Essayons de réparer cette injustice surtout que je n’ai pas trouvé de résumé très satisfaisant sur le Web de ce livre qui est pourtant majeur.
Loi de Conway
Le livre démarre par une présentation de la Loi de Conway. Cette loi stipule que « tout système au sens large tend à reproduire la structure de communication de l’organisation l’ayant produite ».
Pour rendre cette assertion plus concrète, j’ai personnellement tendance à dire à mes interlocuteurs pour qui cette loi n’est pas si limpide « qu’une organisation bancale tend naturellement à produire des systèmes bancals », mais que nous pouvons tirer parti de cette tendance grâce à la manœuvre de Conway inversée en mettant en place une organisation ayant les bonnes propriétés que nous souhaitons obtenir dans nos systèmes. Car il est souvent vain de forcer une organisation à produire des systèmes avec de bonnes propriétés, si cette même organisation n’est pas alignée avec ces propriétés, le naturel revenant au galop.
Team First
Ensuite, les auteurs affirment que l’unité de production n’est pas l’individu, mais l’équipe et que par conséquent l’organisation se doit d’adopter une approche « Team First ». Que les tâches et les objectifs doivent être assignés non pas aux individus, mais à l’équipe.
Une équipe doit être relativement stable dans le temps et d’une taille limitée, jusqu’à neuf de personnes en général, ceci afin de favoriser la confiance au sein de l’équipe. Des remaniements d’équipe incessants ou des équipes trop grosses minent la confiance qui sont pourtant à la base de la fluidité dans la collaboration et de la performance globale de l’équipe.
Selon les auteurs, il est ensuite possible d’envisager des équipes d’équipes (familles d’équipes - 50 personnes, divisions - 150 à 500 personnes) en respectant néanmoins les nombres de Dunbar.
Autant j’approuve l’approche Team First, autant je suis perplexe quand à la règle des nombres de Dunbar pour ces familles et divisions d’équipe.
Charge cognitive
Le livre met l’emphase sur le concept de charge cognitive. Il convient de limiter la charge cognitive à laquelle une équipe doit faire face afin de maximiser sa performance. S’il s’agit d’une équipe de développement, cela passe par limiter le nombre de modules dont elle a la charge. S’il s’agit d’une équipe fonctionnelle, cela passe par assigner un seul domaine à l’équipe, et si le domaine est trop gros ou complexe, de n’assigner qu’un sous-domaine à l’équipe.
Mon sentiment ici, est que même si l’intention est louable et très certainement juste, j’ai rarement vu une entreprise avoir les moyens de dimensionner son staff à la hauteur de ses besoins. C’est pourquoi il me semble bien plus simple de limiter la charge cognitive en structurant au mieux la manière dont les équipes interagissent entre elles.
Cela peut passer par la maîtrise du nombre de réunions, par la réduction des emails, par l’amélioration de l’expérience développeur (DevEx) ou encore par la mise en place de plateformes proposant des services standardisés.
API d’équipe
Le livre aborde (trop) rapidement la notion d’API d’équipe. Il s’agit d’un point peu souvent mentionné dans les présentations de Team Topologies qu’on peut trouver sur le Web, alors qu’il est à mes yeux l’un des concepts pratiques les plus puissants.
Chaque équipe devrait se voir comme un fournisseur de services, et donc à ce titre, devrait exposer aux autres équipes un catalogue de services, au sens large, avec les modalités d’utilisation de chacun de ces services, et de manière générale comment cette équipe interagit avec les autres.
Par exemple, une équipe devrait préciser :
- comment (outil de communication, formalisme) elle souhaite recevoir les nouveaux besoins de la part de ses clients et d’une manière générale, comment elle souhaite travailler,
- où se trouve la documentation des produits et services dont elle a la charge,
- où se trouve son backlog et sa feuille de route
- …
Mon sentiment est si les organisations faisaient l’effort de définir les API de leurs équipes, elles fonctionneraient de manière plus efficace et avec moins de frictions et tensions.
Flow of Change
Les organisations devraient favoriser la fluidité (le Flow) dans les phases de changement. Or, elles considèrent par exemple le développement logiciel comme un processus linéaire unidirectionnel : les spécifications, la conception, la programmation, les tests, le déploiement, puis la maintenance.
Cette vision se matérialise souvent par des équipes bien distinctes à chacune de ces étapes, formant ainsi des silos fonctionnels qui obligent à une passation de connaissances (souvent incomplètes hélas) qui ralentisse le Flow et qui est souvent la source de frictions entre par exemple les équipes de développement et les opérations.
Cela a aussi comme effet néfaste que les équipes de développement n’apprennent pas autant qu’elles le devraient des incidents en production pour améliorer leur code. Tout comme elles ne subissent pas directement les conséquences de leurs mauvais choix de conception.
D’où d’ailleurs le mouvement DevOps qui a émergé vers 2009 et qui avait pour but de rapprocher les développeurs des opérations.
Les topologies et interactions fondamentales
Une fois les principaux concepts posés, les auteurs s’attachent à présenter les quatre topologies d’équipe qu’ils considèrent comme fondamentales.
Ils distinguent :
- les équipes chaîne de Valeur (Stream-Aligned Team),
- les équipes de facilitation (Enabling Team),
- les équipes de sous-systèmes complexes (Complicated Subsystem Team),
- les équipes plateforme (Platform Team)
Ces équipes peuvent interagir fondamentalement selon trois types d’interaction :
- Collaboration
- X-as-a-service
- Facilitation
Dans la mesure où ces concepts sont expliqués dans une vidéo de Scrum Life, le mieux est de s’y reporter :
Conclusion
Certains reprochent à cet ouvrage d’être bien trop long pour ce qu’il a à dire. Il y a du vrai, mais je pense aussi que la redondance et la répétition de certaines explications est délibérée de la part des auteurs qui veulent chacune des trois grandes parties plus ou moins autonome, à l’image des topologies d’équipes qu’ils prônent.
Bien que le champ naturel d’application de Team Topologies est le développement logiciel et l’IT en général, ses concepts sont à mon avis tout à fait transposables dans d’autres domaines.
Il y a notamment le modèle unFIX, qui s’inspire de Team Topologies et qui a l’ambition de le mettre à l’échelle. Mais pour avoir rapidement vu des vidéos à ce sujet, j’ai quelques doutes sur sa valeur ajoutée.
Ce livre est à mon sens plus profond qu’il n’y paraît. Il m’a fallut par exemple une deuxième relecture pour vraiment saisir l’importance des API d’équipe et mieux appréhender les implications de la charge cognitive. Il s’agit aussi d’un livre qui regorge de références et de retours d’expérience qui a elles seules valent la lecture.
Le livre Team Topologies va au-delà de simples conseils pratiques en fournissant une véritable théorie de l’organisation.
Un incontournable.
Pour ma part, j’ai trouvé les trois premiers chapitres beaucoup mieux écrits que les autres. On a l’impression que la théorie se base uniquement sur la loi de Conway et sur la charge cognitive, alors que ça s’appuie sur beaucoup plus de choses.
J’utilise pas mal Team Topologies en conjonction avec les cartes de Wardley et le DDD. D’ailleurs Susanne Kaiser a fait le même lien et l’explique bien : Susanne Kaiser on DDD, Wardley Mapping, & Team Topologies - InfoQ.
@punkstarman Je suis d’accord pour dire que la seconde moitié du livre est moins bien écrite alors qu’il aborde pourtant des concepts intéressants comme les « fracture planes » ou la « thinest viable platform ».
Aussi, ton lien est intéressant. Je suis d’accord sur le fait que même si je considère Team Topologies comme un pilier, il ne suffit cependant pas pour mener un projet de transformation. En effet, les Wardley Mapping et le DDD (qui a probablement inspiré Team Topologies vu les concepts en communs) sont de bons compléments sur la partie produit et business.
Attention avec ça… On parle de matière humaine ici. Le Conway inversé c’est une belle idée en théorie, mais ça peut générer un beau bourbier : ICM #1: Say no to the ‘Inverse Conway Maneuver’ | by Dupdob | Medium
@Samuel_Abiassi Je viens de parcourir les posts indiqués. Un peu verbeux dans la mesure où il a fallut quatre posts à son auteur pour ne pas dire grand chose pour le coup.
Pour procéder à la Manœuvre de Conway Inversée (MCI), il faut bien entendu avoir la Loi de Conway à l’esprit, à savoir que ce sont les structures de communication qui ont un réel impact sur le système résultant et pas l’organisation au sens hiérarchique en tant que telle (même si l’organisation au sens hiérarchique entraîne nécessairement une structure de communication).
La MCI nécessite de la prudence et une approche incrémentale, plutôt qu’un big bang façon « réorg » comme on en voit tant dans les entreprises.
C’est pourquoi, mettre en place des API d’équipe est une approche qui me semble à la fois puissante et nettement moins traumatisante pour les équipes, tout en respectant la MCI.