Kenny Baas-Schwegler - Autonomy, is that what we really want? (EN)

[00:00:06] Désolé, euh, bienvenue à tous. J'ai eu quelques difficultés techniques, donc mon ordinateur était vraiment autonome et se fichait de ce que je voulais faire. J'ai donc emprunté un autre ordinateur portable, alors merci pour cela. Euh, je n'ai pas certaines de mes notes, donc je pourrais sauter quelques points, juste pour que vous sachiez. Et commençons. Alors, bienvenue. Euh, avant qu'il n'y ait de ragots, vous voyez le nom de ma chère amie Evelyn sur cette diapositive. Elle n'est pas là, je prends le relais d'Alberto, euh, donc c'est pour ça que je fais ça seul. Euh, elle passe de joyeuses vacances, et tout va bien entre nous, juste pour que vous sachiez. Alors, bienvenue. Je vais parler un peu d'autonomie, et est-ce vraiment ce que nous voulons ? Ce sera la seule citation des Spice Girls dans toute cette présentation. Alors ne vous inquiétez pas si vous n'êtes pas fan des Spice Girls, mais ce sera la seule. Euh, et j'aime toujours commencer par une histoire différente en dehors de l'informatique, et c'est avec mon déménagement il y a deux ans. Maintenant, j'ai acheté une maison avec ma femme, euh, qui ressemble un peu à celle-ci. Ce n'est pas particulièrement celle-là, ma femme était un peu inquiète que vous me fassiez de l'OSINT. Donc, euh, c'est pour ça que c'est une autre maison, alors, euh. Euh, mais vous auriez pensé, oh, acheter une maison, vous en êtes propriétaire maintenant, vous êtes autonome, n'est-ce pas ? Vous pouvez en faire ce que vous voulez. Eh bien, malheureusement, ici vous voyez la voiture dans l'allée, n'est-ce pas, qui est un abri de voiture, donc ma maison a un abri de voiture. Maintenant, dans le document légal que j'ai signé, il est dit que vous ne pouvez pas le retirer.
[00:01:48] Mais la terre est à moi. Oui, mais vous ne pouvez pas l'enlever parce que d'autres maisons dans mon quartier n'ont pas d'abri de voiture. Il y a donc quelques places de stationnement publiques, et si j'utilisais ces places de stationnement publiques, il n'y aurait pas assez de places de stationnement publiques, n'est-ce pas ? Donc j'ai besoin d'un peu d'alignement avec le reste de mon quartier. N'est-ce pas ? C'est donc un contrat explicite que je ne suis pas autonome dans ma propre maison. Deuxièmement, vous voyez ces beaux chats, ce sont les miens. Euh, ils ont aussi des besoins, n'est-ce pas ? Alors, euh, j'ai en fait percé un trou dans ma maison pour qu'ils puissent sortir, commencer à chasser, euh, dans le quartier. Donc encore une fois, euh, c'est un contrat plus implicite que, eh bien, j'ai besoin de quelque chose avec mes chats. Je suis aussi dans ce groupe WhatsApp, malheureusement, je préférerais être sur Signal, mais avec le quartier. Et il y a aussi beaucoup de ces discussions de limites sur l'autonomie que vous avez, n'est-ce pas ? Puis-je faire une fête à la maison jusqu'à quatre heures du matin ? Je pourrais vous dire, euh, non, euh, à une heure, vous verrez probablement beaucoup de groupes WhatsApp circuler, n'est-ce pas ? Donc, oui, avoir une maison n'est pas vraiment autonome. Et c'est à peu près la même chose que nous allons discuter aujourd'hui, euh, au sein des entreprises informatiques, n'est-ce pas ? Nous avons des équipes, et toute la chose de nos jours avec ce livre est que, eh bien, nous devons donner de l'autonomie aux équipes. Et je crois vraiment à cela, nous devrions leur donner de l'autonomie, nous devrions leur donner plus d'autonomie, surtout dans beaucoup d'organisations où ce n'est pas le cas, nous devrions leur donner. Mais il y a une chose ici, euh, Combien allons-nous en donner ? Et que signifie l'autonomie ? Alors regardons d'abord ce que signifie l'autonomie, n'est-ce pas ? L'autonomie, telle que décrite par M. Pink, est le désir de diriger sa propre vie.
[00:03:32] C'est c'est c'est à peu près le truc à moi, moi, n'est-ce pas ? Sans la capacité de contrôler quoi, quand et comment nous travaillons et comment et qui travaille avec ne sera jamais complètement motivé pour accomplir la tâche. C'est sa définition de l'autonomie. Et il y a plus dans le livre que l'autonomie, dont la plupart des gens ne parlent pas et dont nous parlerons. Mais c'est une définition de l'autonomie, n'est-ce pas ? Et pour moi, c'est déjà un peu, hmm, il s'agit de moi qui dirige ma propre vie. Je ne pouvais pas faire ça avec mon quartier. Je ne peux pas diriger ma propre vie. J'ai certaines règles et limites pour les restreindre. Maintenant, il y a une autre conférence, vous pouvez approfondir un peu, mon ami Romeo est ici, euh, si vous voulez en savoir plus sur la psychologie et le fait que nous ne pouvons jamais être autonomes en tant qu'être humain, veuillez nous rejoindre après cette conférence. Euh et cela durera probablement une semaine, juste pour que vous le sachiez. Donc je ne parlerai pas de la de cette définition d'Eric Burn sur l'autonomie. Euh, mais je vais plus probablement me pencher sur cette définition, Merriam Webster, n'est-ce pas, où nous disons que nous dirigeons notre propre vie. La qualité de l'état d'autogouvernance, en particulier le droit d'autogouvernance conféré à l'autonomie. Maintenant, qui ici pense que c'est l'autonomie, que c'est la bonne définition de l'autonomie pour vous, pour les équipes ?
[00:04:53] Quelques-uns, intéressant, oui. Donc, et c'est le problème quand nous, Evelyn et moi, allons dans beaucoup de ces organisations. Qu'est-ce que l'autonomie ? Et je suis entièrement d'accord avec ce que disent Jape et Mark ici, ils détestent le mot autonomie car il sonne comme une individualisation. Je ne déteste pas le concept, je déteste le mot. N'est-ce pas ? Parce que ça peut donner l'impression que je peux faire ce que je veux aujourd'hui. Ce qui n'est pas le cas. Je viens de te le dire. Eh bien, si vous êtes avec une seule équipe, eh bien, peut-être. N'est-ce pas ? L'autonomie peut donc être vraiment compulsive, elle peut être un moyen d'atteindre une fin. Nous voulons l'autonomie parce que nous ne l'avons pas. Et oui, nous devrions écouter cela et oui, nous devrions examiner le concept. Mais que signifie réellement être autonome ? N'est-ce pas ? Si c'est juste avoir l'autonomie pour l'autonomie, ça ne fonctionnera pas, malheureusement.
[00:05:47] Ça ne veut pas dire que je peux faire ce que je veux aujourd'hui. N'est-ce pas ? Vous aurez certaines règles quant à l'autonomie que vous aurez.
[00:05:58] Et c'est tout, c'est quand vous voulez discuter de l'autonomie. Il s'agit de votre histoire. Quoi dans votre contexte, désolé, je suis consultant, ça dépend. Combien d'autonomie est bonne pour vous ? Et aujourd'hui, dans cette discussion, je vais parler de cette carte de polarité qui vous aidera à définir les limites de l'autonomie à plusieurs niveaux de votre organisation. Parce que pour moi, l'autonomie signifie la partie individuelle, tandis que l'alignement, qui est généralement le contraire, dans ce cas, c'est vrai. L'opposé de la polarité, ce qui signifie le tout. Et vous avez besoin des deux côtés. N'est-ce pas ? Donc, habituellement, quand j'entends que nous voulons l'autonomie, cela signifie généralement que les gens sont surtout du côté de l'ensemble à ce moment-là. Ils se concentrent ici. Maintenant, ce qu'il y a avec la polarité ici, c'est que les polarités ne sont pas des choses que l'on peut résoudre. Ce sont des problèmes continus, n'est-ce pas ? Alors ce soir je sors dîner, c'est un problème, où vais-je ? Bien ici, et nous l'avons résolu. Mais la polarité, c'est combien d'autonomie devons-nous leur donner et devons-nous leur donner beaucoup d'autonomie, c'est plus une polarité, c'est une chose continue. Tout comme inspirer et expirer est une chose continue. Je ne peux pas te demander, que veux-tu ? Inspirer ?
[00:07:15] Expirer ? Oui, nous en avons tous les deux besoin. C'est pareil avec l'autonomie et l'alignement, vous avez tous les deux besoin d'eux, mais combien et où en sommes-nous sur cette carte ? Et comme vous pouvez le voir, des deux côtés il y a ce qu'ils appellent des effets positifs. Ainsi, pour une part, cela signifie l'unicité, un individu ou une équipe peut être très unique dans ce qu'ils font.
[00:07:37] Mais aussi l'ensemble est la connectivité, qui est l'alignement, les deux côtés positifs. Nous allons approfondir cette carte de polarité plus tard. Mais les deux extrémités de cette polarité ont aussi des inconvénients. Si vous restez unique trop longtemps, comme ce que je vais discuter plus tard, des architectes de tours d'ivoire ici ? J'en suis un. Très unique, très isolé, n'est-ce pas ? Nous ne voulons pas ça non plus. Ou si vous restez trop longtemps dans l'alignement, vous allez tous être les mêmes. La plupart des entreprises et des cultures bureaucratiques se transforment en uniformité et ensuite elles se demandent, oh, où va l'innovation ?
[00:08:14] Oui. Et ce sont généralement les entreprises qui passent en mode "nous avons besoin d'autonomie", oui ? Nous allons donc en discuter quelques-uns ici. Et nous le faisons à plusieurs niveaux. Maintenant, ce n'est pas une discussion technique, mais je vais d'abord approfondir un peu le niveau du code. Oui, je ne vais pas vous montrer beaucoup de code ou je vais vous montrer du code, ce n'est pas entièrement vrai, désolé. Mais je n'entrerai pas dans les détails du code. Je vais parler un peu des tests. Oui ? Et nous allons voir comment la polarité et l'autonomie fonctionnent à ce niveau. Ensuite, je vais me plonger dans le niveau de l'équipe. Donc l'équipe dans son ensemble a aussi des parties, n'est-ce pas, l'individu et toute l'équipe. Ensuite, j'irai plus entre les équipes.
[00:08:56] Et je terminerai aujourd'hui avec l'autonomie au niveau organisationnel.
[00:09:01] Donc ce sera euh tous mes exemples et pour chacun des exemples j'utiliserai la carte de polarité pour vous montrer comment nous avons cartographié cette autonomie et comment nous avons créé des limites ensemble pour cette autonomie.
[00:09:17] Alors commençons par l'autonomie dans le code. Euh, je suis un développeur Java, désolé pour ça déjà. Euh, j'étais un développeur Java en fait, de nos jours c'est Ruby.
[00:09:28] Euh, mais quand j'ai commencé ma carrière, j'ai commencé à faire de la programmation Java. J'ai commencé à rejoindre une équipe, ils écrivaient du logiciel et heureusement ils avaient une bonne pratique de faire des tests. Tests unitaires. Euh, j'espère que tout le monde est d'accord avec les tests unitaires.
[00:09:45] Super, super. C'est déjà bien. Alors, euh, mais quand je suis arrivé là-dedans, nous avions ces cours. Et c'est la seule diapositive sur le code ici, n'est-ce pas ? Donc c'est une classe Java et vous voyez une classe appelée la classe calculate. Et puis ce qui était la pratique courante quand j'ai rejoint cette équipe, c'est que nous avions un test de calcul. Et pour chacune des classes dans le truc Java, nous avions un test pour accompagner. Qui a déjà utilisé cette stratégie auparavant, cette stratégie de test pour chaque classe. Oui. Et c'est une bonne pratique, il n'y a rien de mal à cela. Mais parfois, vous pouvez aussi faire plus de ce qu'ils appellent des tests sociables. N'est-ce pas ? C'est l'autre extrémité du spectre.
[00:10:30] J'espère que vous sentez déjà la polarité arriver ici. Donc le test solitaire, qui est celui que je viens de décrire, c'est que certains testeurs unitaires préfèrent isoler l'unité testée, tandis que certains, souvent, l'unité testée repose sur d'autres unités pour remplir son comportement. Et les deux stratégies sont bonnes.
[00:10:49] Et c'est encore la polarité qui se produit, n'est-ce pas ? L'autonomie et le code signifient que le test solitaire, certains que nous allons isoler cette unité testée, mais cela a des inconvénients. Et sur le côté gauche, nous avons le test sociable.
[00:11:03] Et chaque fois que nous découvrons quelque chose de nouveau, nous devrions décider quoi faire.
[00:11:09] Parce qu'ils ont tous les deux des inconvénients.
[00:11:12] Maintenant, certaines des personnes ici ont déjà entendu parler un peu de la conception de domaine. Et je l'ai mis ici parce que pour moi, Je regarde toujours ce que nous voulons.
[00:11:23] Maintenant, le DDD a ce concept de contexte délimité et il a un modèle pour un but spécifique. Pour moi, tester le code signifie : mon modèle fait-il ce qu'il est censé faire ? Et peu importe si j'utilise le test sociable ou le test solitaire. Tant que j'ai testé ce que le modèle devrait faire.
[00:11:47] Et je peux décider différemment n'importe où. Vous voyez, ce contexte délimité est un reflet de notre langage que les architectes d'affaires, les développeurs, le code, mais aussi les tests parlent. Et cela est souvent oublié dans de nombreuses discussions sur le DDD car il s'agit du code et de l'architecture, mais les tests en font également partie.
[00:12:08] Et ce à quoi cela ressemble, c'est que j'ai certains de ces tests en haut à gauche, j'ai certains de ces tests. J'ai testé un objet à l'intérieur de mon modèle de domaine, et cela pourrait être mon test sociable. Je peux tout tester et si cela réussit, c'est ce que nous appelons les tests d'acceptation, qui peuvent être faits en tests unitaires, alors ça me va. Mais parfois, quand je creuse plus profondément, vous pouvez le voir ici, si je vais plus loin à l'intérieur de cet objet et qu'il a beaucoup de complexité. Je pourrais utiliser un test plus euh euh solide, j'ai oublié le nom, désolé. Maintenant, je pourrais je pourrais aller plus profond parce que la complexité est plus grande, donc ma boucle de rétroaction sera plus difficile.
[00:12:46] Mais chaque fois que j'aborde un nouveau problème, je décide, est-ce que j'opte pour le test sociable ou le test solitaire ?
[00:12:53] Et à quoi cela ressemble-t-il sur la carte ?
[00:12:56] C'est si vous regardez le test solitaire, qui est, nous devrions tester en isolation, nous avons un retour rapide sur l'échec. Mais les changements ou les changements en cascade se produiront sur le test solitaire, qui a déjà eu cela avec cette approche individuelle où ils ont changé un test et puis whoop, il fallait changer tous les autres tests. Oui, c'est un inconvénient. Mais ensuite, ce que nous pouvons faire, c'est plus aller vers des tests plus sociables, n'est-ce pas, ce qui est plus cohérent. Moins de moqueries, donc moins d'effets en cascade, mais une défaillance d'un bug. Peut arriver dans d'autres classes, n'est-ce pas ? Donc vous allez plus en profondeur, vous avez une boucle de rétroaction plus rapide.
[00:13:38] Et c'est ce que je veux présenter, cette carte vous aidera à savoir quel test vous aidera, quel test vous aidera le plus dans cette situation. Tout cela parce que c'est l'objectif que vous voyez en haut, ce que je veux, c'est me sentir en sécurité pour modifier le code. Ce que je ne veux pas, ce sont les changements en cascade sur mes tests unitaires. Oui ?
[00:14:01] Dans la prochaine section de code, ou au niveau suivant, je vous montrerai, d'accord, mais comment décidons-nous quand utiliser l'un ou l'autre, n'est-ce pas ? Mais j'espère juste que vous comprenez que chaque fois est une situation différente et que nous ne choisissons pas une seule stratégie. Nous essayons de les mélanger tous les deux et de rester en équilibre ici.
[00:14:22] D'accord, donc c'était l'autonomie dans le code. Alors passons un peu à l'autonomie dans les équipes et les individus et l'interaction sur les processus et les outils.
[00:14:32] Alors,
[00:14:34] Une chose. Nous sommes des êtres sociaux, nous aimons, en substance, une hiérarchie.
[00:14:43] N'est-ce pas ? Nous voulons tous rester en sécurité, nous voulons tous nous sentir membres d'un groupe.
[00:14:49] Ce qui, si vous m'entendez dire ça, hmm, autonomie mais aussi faire partie d'un groupe. Cela semble un peu paradoxal.
[00:14:58] Ce qui est peut-être le cas.
[00:15:01] Mais parfois nous prenons des décisions sur une polarité, n'est-ce pas ? Parfois nous disons, nous avons ceci
[00:15:10] leader technique, n'est-ce pas ? Nous voulons que quelqu'un prenne nos décisions pour nous parce que nous avons maintenant besoin d'un peu de leadership. Alors qui aime parfois, qui aime quand d'autres personnes prennent des décisions pour vous ?
[00:15:22] Allons. N'avez-vous jamais été en vacances où quelqu'un a juste pris les décisions sur où aller, où manger ? Oui, c'est sympa.
[00:15:32] J'étais à une conférence il y a deux semaines et Steve, euh, a fait un travail majeur pour nous trouver un restaurant. J'aime ça, je n'ai pas eu besoin de prendre la décision, donc c'est un plaisir coupable, parfois nous voulons être dirigés, n'est-ce pas ? Nous ne devrions pas l'oublier. Mais le fait est que si nous maintenons cette décision, c'est là que nous avons le problème. Donc quand vous parlez d'équipes ayant des leaders techniques ou quelqu'un qui fait l'architecture logicielle, ce qui est génial, n'est-ce pas, parce que vous pouvez vraiment prospérer avec cette expertise. Mais nous devons continuer à examiner et à revoir cette décision. Parce que c'est une polarité, vous donnez de l'autonomie à une personne pour longtemps, n'est-ce pas, en tant qu'équipe, parce que cette personne prendra des décisions. Mais s'il vous plaît, mettez en place quelque chose pour revoir cela. Parce que cette polarité marquera davantage vers, oh, maintenant seule cette personne prendra les décisions. Et ce qui s'est passé, c'est que l'autonomie dans ce cas se transformera en dictature. Parce que cette personne a dit, oui, mais vous vouliez que je prenne la décision.
[00:16:37] Il m'arrive parfois d'intervenir en tant que consultant, en tant qu'architecte logiciel, et ils me demandent, pouvons-nous avoir de l'aide pour l'architecture logicielle ? Et puis ce que je fais, c'est que je vais jouer le rôle du dictateur bienveillant. Alors je dis, d'accord, vous avez besoin de quelqu'un qui prend des décisions en architecture logicielle pour vous aider parce que vous ne savez pas comment faire. Mais aussi en même temps, j'ai mis en place des retours pour voir quand ils peuvent commencer à prendre les décisions eux-mêmes.
[00:17:10] Et c'est très important. Parce qu'à ce moment-là, si vous ne réexaminez pas cette décision au sein de votre équipe,
[00:17:19] les gens commenceront à le reprocher à quelqu'un.
[00:17:23] Oui ? Qui s'est déjà retrouvé dans cette situation où quelqu'un a pris les rênes et à un moment donné a commencé à tout gâcher ? Changer la limite et commencer à penser, d'accord.
[00:17:35] Oui. Et puis nous essayons d'y faire quelque chose et cette personne dit, mais tu voulais que je fasse ça, n'est-ce pas ? C'est là que vous traitez la polarité, n'est-ce pas ? C'est bien que quelqu'un prenne le leadership, mais vous devez continuer à réaffirmer ces limites. Et ce qui arrive finalement, et c'est ce que je vois, euh, encore une fois comme un très bon exemple. Un ami à moi est allé à une conférence sur le low-code. Et ils rencontrent à nouveau les mêmes problèmes. Et leur problème était qu'une équipe d'application grandit, la livraison ralentit car plusieurs développeurs se disputent pour modifier le même code. Il me semble que vous avez affaire à une polarité ici. Mais au lieu de gérer la polarité, ils font juste du branching. Je. Et je me dis, pourquoi ? Parce que vous avez affaire maintenant à cette polarité alignement contre autonomie à ce moment-là.
[00:18:27] N'est-ce pas ? Et c'est ce que je veux que vous commenciez à reconnaître, est-ce que ce problème est un problème de polarité ? Parce qu'un problème de polarité n'est pas soluble. Cela ne cesse de revenir vous mordre constamment.
[00:18:43] Mais si c'est une décision ponctuelle, alors c'est bon, vous pouvez juste prendre la décision et passer à autre chose. Mais dans ce cas, cette compétition pour changer le même code est une polarité car elle revient sans cesse à vous. Et vous ne le résoudrez pas avec le branching. Désolé, vous ne le ferez pas.
[00:19:00] Vous pourriez occasionnellement avoir besoin de branching. Mais voyons comment cela fonctionne. Parce que ce qui se passe quand vous commencez à faire du branching, c'est que les gens commencent à s'isoler. Et ils commencent à travailler en isolation pendant peut-être une journée, ce qui est, eh bien, peut-être acceptable. Mais s'ils le font pendant une semaine, ils commencent à s'écarter de cet alignement.
[00:19:21] Même deux semaines, ce sera un retour mais tardif. Si cela n'apparaît pas dans la ligne principale ou la ligne de tronc, ce n'est pas aligné ou intégré. Et vous avez affaire à une personne autonome travaillant sur une branche qui n'est pas alignée avec vous.
[00:18:52] parce que ça ne cesse de vous revenir. Et vous ne le résoudrez pas avec le branching. Désolé, vous ne le ferez pas.
[00:18:58] Il se peut que vous ayez occasionnellement besoin de branching. Mais voyons comment cela fonctionne, car ce qui se passe lorsque vous commencez à faire du branching, c'est que les gens commencent à s'isoler.
[00:19:09] Et ils commencent à travailler isolément pendant peut-être une journée, ce qui est, bon, peut-être acceptable, mais s'ils le font pendant une semaine, ils commencent à s'écarter de cet alignement.
[00:19:21] Même deux semaines, ce sera un retour d'information mais tardif. Si cela n'apparaît pas dans la ligne principale ou la ligne de tronc, ce n'est pas aligné ou intégré. Et vous avez affaire à une personne autonome travaillant sur une branche qui n'est pas alignée avec vous.
[00:19:39] Et ce qui se passe alors, et c'est ce que je vois toujours, c'est : oui, mais j'ai déjà passé une, deux semaines à coder sur ma branche. Pourquoi changer maintenant ? J'ai déjà perdu tellement de temps à coder. N'est-ce pas ? Alors il y a une pull request et une revue, et ensuite ils se disent, d'accord, allons juste scotcher ça ensemble et passer à autre chose. Ça ne se répare jamais. N'est-ce pas ? Alors ce qui s'est passé ici, c'est que sur une branche vous avez la liberté, vous avez la créativité, la créativité individuelle, j'applaudis cela, mais une branche a une perte de modèles mentaux cohérents. Et c'est ce que vous ne voulez pas, n'est-ce pas ? Nous ne voulons pas de bugs. Cela arrive quand vous restez trop longtemps sur une branche. Donc, de l'autre côté, nous avons le mode basé sur la branche principale. Nous nous soucions de l'ensemble. Nous avons partagé un modèle mental. Nous avons un effort d'équipe. Mais une chose, si vous commencez tous à coder, bon, peut-être pas en mode basé sur le tronc, mais plutôt aligné, vous obtenez une conformité excessive. Nous ne voulons pas ça. Ce que je vois habituellement, c'est toute la discussion actuelle sur Twitter : non, ne codez plus seul, commencez la programmation en équipe ou en ensemble. N'est-ce pas ? Ce qui est génial, ce qui est parfait. Mais juste pour information, la programmation en ensemble est un côté de la polarité. Donc, dans cette carte de polarité, comme vous pouvez le voir, j'ai mis quelques post-it sur les côtés extérieurs. Et ce sont les parties importantes de la carte de polarité, car si je remplis le centre avec beaucoup d'équipes, vous obtenez généralement la même chose. Mais le côté gauche et le côté droit sont les signaux et les observations. Alors je demanderai à une équipe qui est sur une branche, d'accord, quels sont les signaux ou observations que vous restez trop longtemps sur une branche ?
[00:21:21] Eh bien, nous sommes en concurrence pour changer le même code. N'est-ce pas ? C'était ça le problème. D'accord, nous nous battons pour changer le même code. Si cela arrive, que pouvons-nous faire pour rester alignés ? Eh bien, certainement pas plus de branching. Ce que nous pouvons faire, c'est en fait de la programmation en équipe.
[00:21:39] Donc, et à un moment donné, vous aurez quels sont les signaux d'observations allant au fond de l'aligné que nous faisons trop de programmation en ensemble. Et j'entends les gens dire, eh bien, nous n'avons pas beaucoup de nouvelles idées, n'est-ce pas ? Nous n'avons pas eu de nouvelle idée depuis 10 minutes. Nous avançons juste. Ah. Peut-être que nous pouvons diviser le travail et recommencer à travailler seuls. Peut-être sur une branche pour un jour maximum. C'est bien, mais pas plus longtemps. N'est-ce pas ? C'est donc une polarité que vous devez continuer à gérer. Et ces signaux et observations sont les limites que vous devez continuer à discuter avec votre équipe.
[00:22:16] Quand tombons-nous dans cet isolement ? Que pouvons-nous repérer ? Et soyez d'accord sur ces points car ceux-ci vous mèneront de l'autre côté et maintiendront la polarité en équilibre. Et savoir ce que l'autonomie signifie exactement pour vous ?
[00:22:32] Et surtout, encore une fois, je vous l'ai déjà dit, utiliser ce modèle de contexte délimité pour trouver des objectifs dans l'équipe. Daniel Pink l'a déjà décrit. Ce n'était pas seulement l'autonomie, c'était aussi la maîtrise, c'était aussi le but. Le contexte borné, ou le modèle de contexte borné vous donnera ce but. Oui?
[00:22:55] C'est donc au sein d'une équipe. Donc une équipe a peut-être à un moment donné son propre objectif. Ils restent alignés par eux-mêmes, en utilisant cette carte de polarité. Mais maintenant, ils ont aussi d'autres équipes avec qui traiter. Et ce que je vois habituellement de nos jours, et c'est quelque chose que je vois depuis deux à trois ans, c'est que cette histoire d'autonomie est devenue plus un battage médiatique. C'est que je travaille avec une équipe et qu'ils ont besoin de l'autre équipe pour faire quelque chose. Ils doivent peut-être changer de propriétaire. Peut-être qu'ils disent, eh bien, au lieu que ce soit eux qui prennent la responsabilité ou nous qui prenions la responsabilité de ce changement, ce sont eux qui doivent le faire. Et puis je lui demande, d'accord, mais quel est le problème ? Et ils disent, oui, cette autre équipe est autonome et elle gère son propre backlog. D'accord? Et si nous leur parlons, oui, nous devons voir s'ils vont s'en occuper. Qui s'est retrouvé dans cette situation où l'autre équipe est juste, oui, pas dans notre priorité ? Désolé, parce que nous sommes autonomes.
[00:23:51] Ouais. Et c'est ce que je vois, surtout en tant que personne DDD qui anime beaucoup de ces sessions. Le but et l'autonomie du modèle de contexte borné sont plutôt agréables, mais cela a un côté compulsif car il faut rester aligné. Et puis ce livre est apparu.
[00:24:13] Et il y a beaucoup de choses géniales là-dedans et il y a aussi des choses dont DDD a déjà parlé. Et c'est comment ces modèles interagissent les uns avec les autres dans la conception de domaine, nous appelons cela les modèles stratégiques. Maintenant, les modèles stratégiques ne sont pas plus importants que les modèles tactiques, d'ailleurs, ils sont tous aussi importants selon votre contexte, mais la topologie d'équipe en décrit quelques-uns avec leurs propres mots et j'aime vraiment ça.
[00:24:40] Parce que si vous pouvez voir les systèmes ici, vous avez l'équipe alignée sur le flux, qui sont les équipes qui créent de la valeur pour votre entreprise, n'est-ce pas ? Et elles conçoivent généralement leur propre contexte délimité.
[00:24:53] Et vous les voulez généralement plus ou moins autonomes, n'est-ce pas ? Ensuite, bien sûr, vous avez votre équipe de sous-système compliquée, vous avez votre équipe de plateforme, vous avez votre équipe d'activation, mais attardons-nous un peu sur cette équipe alignée sur le flux. Parce que dans cette équipe alignée sur le flux, nous devons faire attention, n'est-ce pas ? Parce que nous ne voulons pas leur donner trop de charge. Et ils parlent de ce concept de charge cognitive. Qu'est-ce que cela signifie ? Oui? Donc, s'ils sont toujours autonomes et qu'ils ont une charge cognitive trop élevée, où peuvent-ils la décharger alors ? Où peuvent-ils décharger leur fardeau ? Nulle part, parce que tout le monde est autonome.
[00:25:29] Ça ne marche pas.
[00:25:31] Et il y a ce mème qui circule avec les équipes qui doivent être autonomes, où elles disent, eh bien, nous construisons maintenant ce tout nouveau produit, faisons en sorte dès le premier jour que les équipes soient autonomes.
[00:25:47] Eh bien, DDD a décrit ce modèle de partenariat, euh, la topologie d'équipe l'appelle le style de collaboration.
[00:25:55] Et cela diminue l'autonomie.
[00:25:59] Mais ce que ça fait très bien, c'est qu'au début d'un nouveau produit et que vous construisez avec deux équipes un nouveau produit, je ne peux pas concevoir une API entre les équipes dès le début. Parce que c'est vraiment difficile. Alors, qu'est-ce que tu fais ? Tu les laisses collaborer pour les premières sprints. Laissez-les avoir moins d'autonomie, et avec le temps ils créeront leurs APIs si bien conçues et si vous en prenez soin, ils concevront leurs APIs et évolueront ensuite vers plus d'autonomie.
[00:26:32] Donc encore une fois, cette compulsivité selon laquelle tout le monde devrait être autonome. Eh bien, voici un modèle de partenariat ou le modèle de collaboration de la topologie d'équipe qui dit le contraire. Ce qui est aussi génial. N'est-ce pas ? Il y a plus que seulement les équipes autonomes. Parfois, vous voulez qu'ils travaillent ensemble, surtout, surtout lorsque vous construisez ou mettez en place une équipe de plateforme. Ce que je vois si souvent, c'est que l'équipe de plateforme est juste celle qui en sait le plus, elle s'isole et ne parle pas aux équipes qui utilisent sa plateforme. Ça devrait être l'inverse. Il devrait y avoir un partenariat et ils devraient le construire ensemble. N'est-ce pas ?
[00:27:13] Et puis cette dernière chose, désolé, j'ai un peu sauté. Et puis cette dernière chose, c'est cette équipe habilitante.
[00:27:20] Et maintenant, je vais parler de mon sujet préféré, qui est l'architecture logicielle. Alors, qui a déjà eu affaire à cette personne de la tour d'ivoire comme moi ? Qui a été un architecte de tour d'ivoire ? Ne soyez pas timide. Oui, c'est une chose courante parce que cette équipe d'habilitation est excellente et nous avons certainement encore besoin d'architectes logiciels, mais il y a un problème là. Et c'est que les équipes habilitantes doivent activement éviter de devenir des tours d'ivoire du savoir, dictant les choix techniques à d'autres équipes pour qu'elles nous suivent, et comment elles font cela, c'est en ayant un but.
[00:27:53] Une date de fin. Je suis en train de construire une pratique d'architecture logicielle, mais la première chose que je fais, c'est : comment s'assurer que les équipes sont capables de faire de l'architecture logicielle ? C'est ma date de fin.
[00:28:07] Oui? Parce que sinon vous allez obtenir cette chose, les architectes de la tour d'ivoire resteront dans leur tour d'ivoire ou la plateforme restera dans sa tour d'ivoire, ils construisent des composants que personne n'utilise. Alors établissez ce partenariat.
[00:28:24] Oui ? Parce qu'une chose dans cette carte de polarité, c'est que lorsque vous restez trop longtemps d'un côté d'une polarité, vous obtenez les inconvénients des deux, comme vous pouvez le voir ici. N'est-ce pas ? Donc si je reste dans cette partie d'isolement, qui est de ce côté, n'est-ce pas ? J'ai la liberté, j'ai la créativité d'équipe, ce qui est bien, n'est-ce pas ? Vous pouvez mettre en place une équipe habilitante. Et cette équipe habilitante peut innover, peut vraiment mettre en place une plateforme ou une pratique d'architecture logicielle. Mais s'ils y restent trop longtemps, à un moment donné, ils perdent leur égalité, ils s'isolent, ils deviennent égoïstes, n'est-ce pas ? Ils deviennent, non, c'est comme ça que vous devriez faire de l'architecture logicielle.
[00:29:08] Eh bien, ça dépend. Ça dépend de ce dont les équipes ont besoin. Comment habilitez-vous les équipes ? Et ce qui se passe alors, à un moment donné, cela se transforme en conformité excessive parce que les architectes de la tour d'ivoire diront : c'est comme cela que vous devez le faire. Conformez-vous à mes normes. Nous les avons construites.
[00:29:27] Oui? Donc, rester trop longtemps d'un côté de cette polarité vous apportera les deux côtés négatifs.
[00:29:36] Et cartographiez-le à nouveau là-bas. Si vous constituez une équipe d'activation, mettez en place la polarité ensemble et voyez quand nous basculons vers les inconvénients de l'isolement ? Donc, si je n'ai pas eu de vos nouvelles en un mois, chère équipe d'architecture logicielle, vous vous êtes isolés et ce n'est pas une bonne chose. N'est-ce pas ? Alors nous, qu'est-ce que nous faisons ? Nous nous retrouvons.
[00:30:06] Et je dois toujours afficher cette diapositive.
[00:30:10] Parce que je déteste ça, parce que ce qu'est cela pour moi, c'est une conformité excessive. N'est-ce pas ? C'est une chose isolante.
[00:30:20] Juste pour que vous sachiez, tout ici est axé sur cette seule partie, qui est la structure, mais nous devons former des limites en équipe ensemble, dépendant du contexte. Et ce n'est pas ce que cela essaie de faire.
[00:30:34] Alors, nous avons parlé de l'autonomie dans le code, de l'autonomie au sein d'une équipe, de l'autonomie entre les équipes. Et la dernière question est toujours : d'accord, mais qu'en est-il des organisations ? Si les équipes deviennent plus autonomes, que faisons-nous, en tant que managers, architectes, leaders ?
[00:30:56] Pour moi, le truc c'est qu'ils doivent établir des visions avec l'équipe.
[00:31:02] Ils doivent fixer des limites en utilisant ces cartes de polarité, n'est-ce pas ? Ils ont généralement toute l'organisation là.
[00:31:11] Et puis à un moment donné, quand ils disent, d'accord, nous avons implémenté, nous avons aidé les équipes à créer une vision, nous les avons alignées sur l'organisation. Qui prend les décisions maintenant ?
[00:31:22] C'est ce que je vois arriver souvent avec beaucoup d'équipes, qui a déjà eu cette situation, qui prend les décisions maintenant à un moment donné dans l'organisation ? Oui, parce que les lignes sont un peu plus floues car elles deviennent, au lieu de limites explicites, des limites implicites. Et je gère beaucoup ça.
[00:31:41] Et une chose qui arrive alors, c'est que les gens deviennent frustrés et se tournent à nouveau vers la dictature. Pour moi, c'est encore une partie d'une polarité appelée pouvoir et ils oublient l'autre côté. Donc, le leadership n'est pas la dictature, ce n'est pas le management. Le leadership nous demande d'équilibrer ce pouvoir et cet amour, cette situation de bateau et d'aller vers les équipes. Et établissez ces limites avec ces cartes de polarité. C'est un aspect. Je ne dis pas que vous ne devriez faire que des cartes de polarité, il y a plus que cela, mais les cartes de polarité aident vraiment à établir cette limite entre l'autonomie et l'alignement. Et puis à un moment donné, nous disons que nous leur avons donné de l'autonomie, pourquoi n'en font-ils rien ? Et c'est la deuxième situation, n'est-ce pas ? En tant que leader, vous voulez vraiment commencer à vérifier et à comprendre ce que les équipes font et gèrent. Et ma femme a une formation en anthropologie, et j'ai beaucoup appris d'elle sur ce qu'ils font dans leur domaine de scientifiques sociaux, où ils repèrent des modèles, repèrent des modèles dans ce que l'équipe gère. Obtenez des informations quantitatives mais aussi qualitatives de vos équipes.
[00:32:57] Et puis quand il y a de l'autonomie partout, avons-nous encore besoin de managers et d'architectes ? Désolé, ça dépend. Dépend de votre organisation, sur la, sur la taille de votre organisation. Je ne pense pas que nous puissions nous en débarrasser, mais nous devrions aussi essayer d'y aller, essayer de rendre les équipes aussi autonomes que possible, mais aussi leur apprendre avec des cartes de polarité à rester alignées, à les habiliter. Fixez des dates, assurez-vous de revoir et de continuer à le valider et faites cela avec cette carte de polarité. Donc,
[00:33:32] Pour une organisation à l'échelle de l'entreprise, il s'agit vraiment de savoir si nous prenons des décisions centralisées ou décentralisées. Et encore,
[00:33:43] Nous continuons de modifier cet équilibre ici. Où la prise de décision décentralisée autonomise l'individu, c'est spontané et euh mais l'inconvénient, bien sûr, c'est que, comme vous pouvez le voir, le groupe ne peut pas se coordonner. C'est la peur de rater quelque chose et de se sentir exclu. Qui a déjà eu ça, d'ailleurs, si vous avez une prise de décision décentralisée ? Oh, ils prennent maintenant une décision sur laquelle je suis l'expert. Et tu es dans une autre équipe ? Oh, tu dois t'en occuper.
[00:34:12] Et puis nous avons celui centralisé, n'est-ce pas ? Donner du pouvoir au groupe, le groupe peut se coordonner, le groupe agit de manière décisive et tout le monde se sent inclus, mais le problème est que nous allons avoir des files d'attente.
[00:34:22] Et certaines personnes que je connais parlent maintenant de la façon dont les architectes logiciels ont les conseils. Conseil, ça s'appelle. Je, je ne suis pas sûr. Andrew en parle beaucoup. Et c'est ça, n'est-ce pas ? Le problème est de savoir comment gérer les files d'attente. Si vous êtes un architecte logiciel et que vous devez tout dicter, vous devenez une file d'attente.
[00:34:46] Mais si vous laissez les équipes prendre les décisions elles-mêmes, elles ne peuvent pas se coordonner.
[00:34:53] Et si vous voulez le faire efficacement, essayez de le mapper sur celui-ci et essayez de voir quels sont les signaux.
[00:34:59] Pour effectuer efficacement ce processus de conseil pour la décision d'architecture logicielle, voyez pour votre contexte, où vous vous situez sur cette carte. Parce que pour moi, au final, nous ne voulons pas d'autonomie, nous voulons vraiment de l'action. Ce qui signifie que nous voulons des systèmes logiciels autonomes, mais nous voulons avoir des équipes qui peuvent décider par elles-mêmes, mais qui connaissent leur impact dans l'organisation. Et ce que nous ne voulons pas, c'est l'indécision, au final.
[00:35:30] Et la dernière chose dont je vais parler, ce sont ces modèles d'autonomie et d'isolement, ils sont fractals dans une organisation. Et pour ceux d'entre vous qui ne savent pas ce qu'est un fractal, cela signifie que c'est à chaque niveau dont je viens de parler dans votre organisation.
[00:35:42] Vous pouvez probablement retrouver le même motif encore une fois. N'est-ce pas ? Vous pouvez parier que vous pouvez trouver ça à chaque niveau. Qu'est-ce que je veux dire par là ? À titre d'exemple, j'ai vu de l'autonomie, ou j'ai vu des gens davantage sur la polarité de l'action, agir, donc c'est aussi de l'autonomie dirigée.
[00:36:04] Et je vois un propriétaire d'entreprise dire à un développeur de logiciels : pourrais-tu déplacer ce bouton un peu vers la droite ? N'est-ce pas ? Maintenant, cinq ans plus tard, à tous les niveaux de cette organisation, ce même modèle est toujours présent. Le système n'oublie pas.
[00:36:23] Donc, si je travaille maintenant avec la même équipe, j'essaie de faire quelque chose comme l'event storming. N'est-ce pas ? Conception collaborative et plus de planification. Le premier retour que j'ai est que cela prend trop de temps. Pourquoi ne peux-tu pas simplement déplacer ce bouton un peu vers la droite ?
[00:36:40] Donc, si vous voyez un modèle dans une partie de l'organisation, essayez de repérer si vous pouvez le voir à tous les niveaux. Parce que ça se répète. Et juste pour que vous sachiez, le plus haut niveau, qui est généralement le niveau de la direction, ils décident généralement de ce que le reste de l'organisation fait, n'est-ce pas ? Donc, si l'organisation en dessous essaie de devenir autonome, mais que la direction ne le veut pas, ce sera une chose très difficile à faire.
[00:37:08] Alors s'il vous plaît, voyez si vous pouvez repérer ça. Donc, l'autonomie, est-ce vraiment ce que nous voulons vraiment ? Oh oui, désolé, il y a la deuxième citation de Spice Girl. Définissez et négociez les limites en permanence et essayez vraiment de commencer par gérer cette polarité, rendez ces signaux et observations explicites avec vos équipes, avec votre organisation, euh et cela vous aidera à négocier le degré d'autonomie dont une équipe a besoin ou qu'elle requiert à un moment donné. C'est contextuel.
[00:37:42] Merci beaucoup.

Transcription (Traduit)