Je remet juste mes commentaires de la vidéo ici parce que je pense que malheureusement personne d’autre que l’équipe ne les lira.
C’est fouilli et désordonné mais je pense qu’on peut aller plus loin dans la conversation:
Bon, alors, pour faire écho à Benjamin, l’organisation n’est pas la structure de l’organisation n’est pas la communication à l’intérieur de l’organisation (comme le plan n’est pas l’architecture n’est pas la maison). Ce que ça veux dire, c’est qu’effectivement, des relations interpersonnelles existent, et faire bouger et réorganiser des personnes, ce n’est pas abstrait. On parle de vrais personnes, dont on va changer le quotidien. D’autre part, la Loi de Conway se cache pas tant dans une organisation que dans les moyens et modes opératoires de communication. Des équipes qui communiquent de manière asynchrone par mail auront tendance à créer des services découplés (à bon ou mauvais escient) alors que des équipes communiquant en face à face à l’oral auront tendance à produire des systèmes plus intégrés. Autre point que j’évoquais sur la vidéo principale, la Loi de Conway se ressent aussi dans l’archi du code en elle même: Selon la forme de la documentation (et donc le mode opératoire de communication) vers l’équipe de dev, l’architecture du code sera clairement impactée. N’attendez pas une architecture faisant remonter les cas d’usages si ces derniers ne sont pas clairement documenté à priori du développement. C’est mécanique.
Pour l’origine de la manoeuvre inversée:
The term was created by Jonhy Leroy and Matt Simons (ThoughtWorks) Dec 2010. Here is its only mention in this good article:
In what could be termed an “inverse Conway maneuver,” you may want to begin by breaking down silos that constrain the team’s ability to collaborate effectively.
J’irais même plus loin. L’important, ce n’est pas tant les gens ici, mais comment et pourquoi ils communiquent entre eux. Si ces points ne sont pas adressés, peu importe les cases dans lesquels ils ou elles seront mis, la communication continuera de se faire, en bien ou en mal.
Qui peut lancer le truc ? Bonne question, mais de ce point là, je reviens sur ma marotte: c’est avant tout la verticalité de l’organisation qui met des freins. Vous dites qu’un collaborateur a sa petite échelle peut pas lancer ce genre de projet, mais si il n’y a pas de hiérarchie au dessus et donc que de facto le lead est créé de manière collégiale par les équipes qui le souhaite, je vois pas où ça peut bloquer exactement. Mais encore une fois, ça demande que les équipes soit auto-gérés, et c’est déjà un énooooorme prérequis.