La manœuvre inversée de Conway c'est partir de l'architecture pour construire ses équipes. Au lieu d'avoir une équipe d'experts fronts d'occupant des produits A, B, C, D, une équipe spécialisée Black gérant les produits A, B, C, D et une équipe de DBA, tu te dis que l'équipe A gère le front, le back et l'accès BDD du produit A, etc
La manœuvre inversée de Conway c'est partir de l'architecture pour construire ses équipes. Au lieu d'avoir une équipe d'experts fronts d'occupant des produits A, B, C, D, une équipe spécialisée Black gérant les produits A, B, C, D et une équipe de DBA, tu te dis que l'équipe A gère le front, le back et l'accès BDD du produit A, etc
Très bonne vidéo, ça montre l’écart qu’il peut y avoir entre ce que prescrit SAFe et Team Topologies, les deux sont faits pour marcher à l’échelle mais c’est pas du tout le même philosophie derrière
@@ScrumLife Bonjour JP, Globalement il reprend les patterns évoqués dans le 1er livre en évoquant le contexte Remote. Beaucoup de bon sens dans les améliorations proposées mais pas de nouveaux modes d'interactions en particulier. C'est pas un complement indispensable mais ça met le focus sur la nécessité de bien réfléchir à comment on créer les canaux de discussion, pour quoi, pour qui, les limtes (dunbar) et insiste sur la clarté et les règles d'utilisation et de sollicitations des canaux (en évoquant les teams api et les modes d'interactions)
J'ai aussi aimé ce livre car il présente des applications concrètes du modèle dans un contexte de télétravail pour que les interactions asynchrones soient optimisées.
Bah merci du coup, mais c'est pour mettre où ? Dans l'oreille j'espère ! Nous on repart avec ton pouce et toi, avec quoi repars-tu de cette vidéo ? Des astuces ? Des idées ? 3 mois après, quelque chose à changé ? -- Constantin
Bonjour, très intéressant pour aider à situer et préciser le fonctionnement des équipes Enabling ou Complicated sub system qui par leur position transverse dans une structure importante (DSI de plus de 500 personnes) doivent partager leurs activités avec plusieurs trains SAFe et des équipes cycle en V. Très intéressé une vidéo sur les manœuvres de Conway inversées !
Petite précision sur la définition des Enabling Teams à 7:33 Le livre distingue bien les Enabling Teams des Communautés de pratique. "Enabling teams ans CoP can co-exist because they have slightly different purpose and dynamics". "An enabling team is a small, long-lived group of specialists focus on building awareness ans capabilities for a single team (or a small number of teams) at any point in time. A CoP usually seeks to have more widespread effects, diffusing knowledge across many teams"
Merci @eirianlegoux pour ta précision et ta citation tirée du livre ! 🤓 Effectivement, la distinction entre les Enabling Teams et les Communautés de Pratique (CoP) est essentielle pour bien comprendre leurs rôles respectifs dans l'organisation agile. Les Enabling Teams agissent comme des catalyseurs, concentrant leurs efforts sur un petit nombre d'équipes pour les aider à surmonter des obstacles spécifiques et développer leurs compétences. C'est un peu comme un commando agile en intervention ! 💪 De l'autre côté, les CoP jouent un rôle plus transversal en diffusant les meilleures pratiques et les connaissances à travers l'ensemble de l'organisation. Leur effet est plus vaste et global. 🌍 Merci encore pour ton apport enrichissant à la discussion ! Si tu as d'autres questions ou réflexions, n'hésite pas à partager. Qu'est-ce que tu penses des effets à long terme de ces deux approches sur la culture d'entreprise ? À bientôt, Robin 🚀 #ScrumLife
Hello Scrum Life, donc une organisation qui fonctionne avec des teams dédiées à un ou plusieurs modules techniques est conforme à Team Topologies ? On sait toujours qui contacter quand le problème est sur tel ou tel module même les non techniques. Et wow le concept des Complicated Subsystem Team, c'est exactement le cas de l'une des nôtres 🤯.
Ah ah ! Joyeux anniversaire avec de l'avance, alors 😁 Pas de vidéo Unfix planifiée mais on l'a bien dans notre viseur ! Est-ce que tu as apprécié cette vidéo ? Qu'en retires-tu ? -- JP
Hello, merci pour la vidéo ! Dans la partie "communication" apparait un schéma avec le nombre de chemins de communication entre plusieurs personnes, avez-vous un lien d'article sur ce sujet ? merci par avance pour votre aide
Safe 5.1 incopore les team Topologies aligné avec les trains et les chaînes de valeurs ..il donne les team l autonomie au niveau de leurs pratiques ( scrum xp kanban etc.) La syncro entre équipe ( principe 7 cadence et syncro ) permet de bouger et d adapter rapidement un train dans la même direction ( but de la buisness agility dont la conséquence est un ttm réduit entre autres ) du coup je suis perdu ? Nexus pourrait être également intéressant à regarder. Bien amicalement
Nous en parlons dans notre dernière vidéo ou nous abordons aussi les nouveautés de SAFe 6.0. Dis nous si cela a pu apporter quelques clarification. Robin
X-as-a service n’est pas vraiment un SaaS comme vous l’aviez décrit. Ce sont les interactions entre l’équipe plateforme et la stream-aligned team. Cette équipe (Plateforme) est responsable de ses services de bout en bout à la stream-aligned team par exemple. Ca peut-être une plateforme cloud, un service de conteneurisation, du CICD (incluant l’automatisation) etc.
@@ScrumLife que j'ai une nouvelle lecture a mettre a ma liste... j'ai travaillé dans une strcuture SAFE avec beaucoup beaucoup de personnes et plusieurs trains simultanés donc je suis preneur d'une "alternative" qui en plus permettent de garder un esprit "service, tourné vers le client, garder de l'autonomie". Bref sujet qu'il faut que je creuse.
Salut Ludo, la question est laquelle ? Les différences ? Les avantages ? Notre avis ? Sachant que le modèle Spotify n'existe pas, n'hésite pas à préciser :) -- Constantin
Je suis désolée, mais je n'ai pas trop compris. Comment peut en mettre en place le team topologies ? Est ce qu'il faut avoir les 4 types d'équipe en parallèle ? Est ce qu'on peut se mettre selon le contexte, le sujet dans une une seule topologie à la fois ?? On parle de 4 topologie et 3 modes d'interactions. Faut il choisir un élément de chaque type ? Je ne comprends pas la mise en place 😢 Merci de votre aide
Salut ! L'idée est de choisir une typologie par équipe, ainsi qu'un mode d'interaction -- potentiellement des modes d'interactions différents selon les équipes. -- JP
Merci beaucoup JP. Je suis à la recherche d'une organisation à mon équipe. Je suis la scrum master/lead devs de 8 personnes déjà. On va passer à 15 personnes dans quelques mois. Je fais de la veille sur l'agilité à l'échelle que j'ai découvert grâce à ta chaîne. Je te remercie. Mais là, c'est compliqué comme ça de choisir un framework plutôt que l'autre 😅 L'équipe va bosser sur le logiciel phare et certains personnes sur les anciens produits selon la roadmap. Une piste JP stp pour une meilleure organisation ? Quel framework ? Combien de scrum master ? Est ce que 1 pour 15 c'est ok ou faut il 2 ? ... Pas mal de questions à l'instant sans réponse. Merci d'avance. Bouchra
Salut @UniversB3 ! Pas de souci, les Team Topologies peuvent sembler complexes au début. Prenons une grande respiration ensemble et démêlons tout ça. 🌬️ Pour ta première question, il n'est pas nécessaire d'avoir les 4 types d'équipes (Stream-aligned, Enabling, Complicated-Subsystem, et Platform) en parallèle dès le départ. L'idée est d'identifier les besoins spécifiques de ton organisation et de structurer les équipes en conséquence. Oui, tu peux ajuster et évoluer avec une seule topologie au départ et ajouter les autres types d'équipes au fur et à mesure que le besoin se fait sentir. Concernant les 3 modes d'interaction (Collaboration, X-as-a-Service, et Facilitating), tu ne choisis pas un élément de chaque type par défaut. Encore une fois, cela dépend de la nature de tes projets et de tes objectifs. Le but est de fluidifier les interactions et réduire les frictions, donc choisis les modes qui correspondent le mieux à ton contexte. Pour une mise en place réussie, je te conseille de commencer par une analyse de ce que demande ton environnement actuel. Ensuite, essais de mettre en place une équipe Stream-aligned comme base et vois comment tu peux l'étoffer avec d'autres types d'équipes et modes d'interaction. Si tu as des exemples concrets ou des détails spécifiques sur ton contexte, n'hésite pas à les partager ici, je serai ravi de t'aider davantage et peut-être même de faire une vidéo dédiée sur le sujet ! 🚀 À très bientôt et bon courage dans ta démarche agile ! Robin
C'est vrai ! Tu as totalement raison. Pour la vidéo elle-même, elle est déjà longue donc pas évident d'insuffler d'autres éléments. Je pense que jeudi, au Live, on pourra rentrer plus dans la partie retour d'expérience. Tu seras là ? D'ailleurs, as-tu toi-même une expérience de Team Topologies ? Si oui il faudra venir nous la partager au Live ! -- JP
Voici la traduction des équipes donnée dans un article chez Atlassian : Équipe alignée sur les flux Équipe de plateforme Équipe de sous-systèmes compliqués Équipe habilitante C'est bien mieux en anglais :)
J'adore quand vous parlez Scrum, mais pourquoi ce bashing de SAFe ? Team topologies est cité en exemple dans SAFe 5 dans la partie Teams, donc pourquoi les opposer. Vous n'avez pas vraiment compris et implémenté SAFe pour avoir ce genre de parti pris. Team topologies ne fait que mettre un nom sur ce qu'on fait naturellement depuis 10-15 ans par bon sens. Par expérience, quand les équipes autonomes s'additionnent, à un moment il faut un cadre pour piloter la stratégie globale dans le budget, et c'est plus compliqué sans cadre global qui aligne tout le monde sur les objectifs, une vision commune. Les teams autonomes c'est bien en phase de croissance, mais très vite il faut cadrer pour éviter la dispersion et le gaspillage à l'echelle. C'est pas du C&C, la vision et les objectifs sont top down, l'innovation est bottom-up... quand c'est bien compris et bien implémenté, c'est par expérience la meilleure pratique. Ca fait beaucoup trop d'erreurs grossières en 2 vidéos pour moi là, faut vous ressaisir et retourner aux fondamentaux :) C'est aussi le cas sur la vidéo PO-PM. Pour rappel, en SAFe, c'est les PO qui restent en lien avec les customers, le PM(gt) coordonne, aligne les PO sur la stratégie décidée collectivement, communique, mais l'execution reste entre les mains des PO.
Bonjour ! Nous abordons avec nuances ce sujet dans notre dernière vidéo... et c'est un SPC qui parle :) N'hésite pas à y faire un tour pour cerner mieux nos propos. Robin
