est la pratique organisationnelle la plus intéressante que j'ai apprise depuis un moment. Aujourd'hui, je partage ce qu'est FAST Agile et j'examine s'il vaut la peine de l'expérimenter. TL ; DR ? Assez convaincant, mais toujours expérimental. FAST agile Qu'est-ce que FAST Agile ? est une variante logicielle agile. FAST se concentre sur l'auto-organisation au sein de très grandes équipes. Ces grandes équipes sont appelées Collectifs. Ils peuvent être de quelques personnes à 150 personnes [1]. FAST Agile Deux fois par semaine, le Collectif se réunit. Lors de la réunion: . Les membres de l'équipe montrent et racontent les progrès qu'ils ont réalisés . Ils donnent un contexte sur les meilleurs projets. Ils introduisent de nouvelles priorités à mesure que le travail se termine ou que les priorités changent. Et généralement, ils montrent les priorités de manière visuelle, sur un mur ou un équivalent virtuel. Le chef de produit réitère la vision et définit la direction et se sélectionnent en équipes plus petites pour effectuer le travail prioritaire. Les personnes au sein du collectif s'auto-organisent La partie la plus intéressante de FAST agile est ces équipes auto-organisées, alors décrivons-les un peu plus en détail. À chaque réunion, des personnes se portent volontaires pour diriger des équipes et des personnes se portent volontaires pour participer à ces équipes. Quand quelqu'un se porte volontaire pour diriger une équipe, il s'avance et dit : « Je vais travailler sur [l'un des meilleurs projets] ». Les gens rejoignent alors les équipes qui ont été créées et travaillent dans ce domaine. La taille minimale de l'équipe est de deux, vous avez donc besoin que les gens « votent avec leurs pieds » pour former l'équipe. Les équipes formées font doivent être autour des priorités que le produit a définies. Par exemple, une équipe peut se former pour améliorer le pipeline de déploiement ou améliorer la surveillance de certains services défaillants. pas En dehors de l'heure par semaine en réunion, les gens passent la plupart de leur temps dans leurs équipes auto-sélectionnées et auto-organisées. Théoriquement, vous pourriez changer d'équipe deux fois par semaine. Mais en pratique, les gens finissent par trouver avec qui ils aiment travailler, et les équipes ont tendance à . s'installer après le premier mois environ Ils restent suffisamment fluides pour que les personnes puissent se déplacer à mesure que les besoins de l'entreprise évoluent ou que des personnes possédant une expertise sont nécessaires dans différents domaines. Le déplacement d'équipes est un changement attendu nécessitant peu d'efforts. Donc, ce que cela signifie, c'est que pendant les réunions du Collectif, il y a un schéma de personnes qui recréent leurs équipes, mais la composition a tendance à ne pas changer autant que vous pourriez l'imaginer. Il y a beaucoup d'autres détails comme la façon dont les bugs et les appels sont gérés. Je couvrirai certains de ces sujets plus tard. Mais le noyau de base de FAST agile, ce sont ces équipes auto-sélectionnées, travaillant au sein d'un collectif plus large, sur des projets. Les réunions collectives sont structurées et axées sur le contexte des besoins de l'entreprise et la communication des progrès par rapport à ces priorités. Résumé des différences FAST est très différent de la façon dont la plupart des organisations logicielles agiles fonctionnent aujourd'hui. Voici les différences telles que je les vois : (SCRUM, Kanban ou « Lightweight Agile ») Pratique courante RAPIDE Agile Densité de réunion Moyen à élevé Varie d'une entreprise à l'autre, mais généralement des standups quotidiens, des démos, des toilettages, des estimations, des rétros, etc.). Faible Deux réunions d'une demi-heure par semaine. D'autres au choix. Capacité à évoluer L'unité d'échelle est l'équipe. La croissance, la division et la création d'équipes (et de leurs domaines de responsabilité) est un objectif majeur de la gestion. À mesure que les priorités de l'entreprise changent, les réorganisations doivent refléter le changement de priorités. L'unité d'échelle est le Collectif. En pratique, le nombre de pistes de travail évoluera de manière similaire à la pratique courante. Cependant, ajouter des personnes et déplacer les flux de travail est plus fluide et auto-organisé. Moins de défis avec des équipes « trop petites » ou « trop grandes ». Moins de soucis concernant la viabilité des équipes et l'adéquation des équipes aux domaines de responsabilité. Non testé dans de très grandes entreprises, mais semble théoriquement solide. Propriété du code et alignement de l'expertise La propriété stricte du code, qui aide à diviser le monde en ce que les individus peuvent maîtriser. Bon alignement des incitatifs parce que les gens travaillent dans leur région. Les défis consistent à s'assurer que chaque équipe peut maintenir et exploiter sa base de code. Le déménagement des responsabilités a tendance à être douloureux. Changer les priorités de l'entreprise entraîne souvent des réorganisations. Les pratiques peuvent être décentralisées et fragmentées, même si cela peut poser des problèmes. Par exemple, vous pouvez laisser les équipes choisir leurs propres langages de programmation, choisir différentes méthodes de travail et différents styles de codage. Propriété partagée du code. Nécessite de bonnes normes, une équipe qualifiée ou de bonnes pratiques d'examen. Changer les priorités est moins difficile. Les réorganisations sont presque inexistantes, à moins que vous ne changiez les limites collectives. (Pensez au temps de gestion consacré aux réorganisations !) Les pratiques doivent être plus standardisées, sinon vous aurez des problèmes. La normalisation des pratiques est une bonne chose, donc les incitations sont au bon endroit, mais le mode d'échec est probablement pire. Motifs architecturaux L'architecture idéale est celle des microservices. Les grands monolithes doivent être bien factorisés. En dehors des environnements de microservice généralement désordonnés. Je m'attendrais à ce que FAST soit plus agnostique en matière d'architecture. Doit fonctionner avec des bases de code monolithiques ou des environnements de microservices. Et avec un mélange. Devrait rendre le passage aux environnements de microservices plus progressif. Modèles de déploiement La propriété stricte du code a tendance à exiger une conception à l'échelle de l'organisation de quelle équipe possède quoi. La mise en œuvre de ces changements est toujours un big bang. Nécessite de grandes réorganisations perturbatrices. Peut être fait progressivement. Vous pouvez commencer avec une équipe ou deux, et y ajouter progressivement des équipes supplémentaires si cela fonctionne. Les réorganisations doivent être peu fréquentes. Cela arrivera toujours au niveau collectif, mais cela devrait être moins fréquent. Mécanismes d'alignement Utilisez généralement les OKR, les réunions entre toutes les mains et la communication écrite pour aligner les gens. Les réunions collectives sont une réunion All Hands intégrée deux fois par semaine, où vous renforcez les objectifs et définissez le contexte pour l'équipe. Si la direction traite cette réunion au sérieux, semble avoir un effet de levier très élevé. La rétention des employés Les pratiques peuvent aller de et des environnements descendants à contrôle élevé, à des équipes hautement performantes qui , et qui apportent continuellement de la valeur à leur entreprise. Ainsi, la rétention variera considérablement d'une entreprise à l'autre. l'usine de fonctionnalités comprennent leur contexte commercial et leurs clients Je m'attends à ce que les pratiques puissent varier, comme les pratiques agiles courantes. Cependant, FAST se prête à la rétention des employés car il est aligné sur . Les employés peuvent choisir avec qui ils travaillent, sur quoi ils travaillent et obtenir le renforcement de l'importance de leur travail. Je m'attendrais à ce que cela se traduise par une meilleure satisfaction globale. Un défi pourrait être la politique. Les groupes autonomes gèrent parfois mal les conflits, ce qui peut se retourner contre eux. la motivation intrinsèque Comme vous pouvez le voir, FAST est une approche très différente de ce que font la plupart des entreprises aujourd'hui. Quels sont donc les compromis ? Selon moi, voici les compromis de FAST Agile : FAST peut offrir une meilleure évolutivité organisationnelle FAST peut être expérimenté progressivement FAST devrait entraîner moins de réorganisations FAST permet de répondre plus facilement aux priorités changeantes FAST pourrait être meilleur pour la motivation intrinsèque et la rétention Mais… De nombreux environnements sont incompatibles avec FAST Vous devrez peut-être gérer l'autogestion FAST demande beaucoup de travail Les matériaux FAST sont pleins de jargon Nous allons discuter de chacun d'eux à tour de rôle. FAST peut offrir une meilleure évolutivité organisationnelle Lorsque vous mettez à l'échelle des organisations, vous le faites généralement en les faisant évoluer « horizontalement ». Vous développez l'organisation une équipe à la fois. Chacune de ces équipes possède une part du produit, et vous avez souvent une organisation de plate-forme qui rend les équipes de produit plus efficaces. La complexité de l'organisation explose à mesure que le nombre de personnes augmente. Si vous avez dix personnes en ingénierie, elles peuvent toutes communiquer entre elles. Une centaine d'ingénieurs ne peuvent pas tous se parler. Et la base de code ne rentrera dans la tête d'aucun individu. Vous segmentez donc cette complexité en équipes, et chaque équipe a un domaine sur lequel elle peut se concentrer. FAST est intéressant car il s'agit d'une tentative de mise à l'échelle « verticale » des organisations. Au lieu d'ajouter plus d'équipes, FAST tente de créer , appelées Collectifs. Les collectifs possèdent toujours le code, mais pas les équipes auto-organisées au sein de ce collectif. Et vous devez toujours segmenter la communication. Mais les équipes sont plus dynamiques et évoluent continuellement. Au lieu de remodeler les équipes par le biais de réorganisations, c'est une partie continue et attendue de votre façon de fonctionner. des équipes plus grandes La taille de l'équipe est un sujet familier pour de nombreux chefs d'ingénierie. Quelle doit être la taille des équipes ? Approfondissons un peu ce sujet, car cela nous aide à comprendre comment FAST prétend mieux évoluer. Quelle doit être la taille des équipes ? Lorsque vous passez du temps avec les vice-présidents de l'ingénierie, le sujet de la taille de l'équipe d'ingénierie sera parfois abordé. Vous entendrez des arguments pour les petites équipes et des arguments pour les grandes équipes. Les deux parties ont des mérites. Avantages des petites équipes Moins de frais généraux de coordination et de communication au sein de l'équipe. Peut se déplacer rapidement en conséquence. Moins de flux de travail, donc plus facile de se concentrer et de produire des résultats. Plus facile à gérer. Avantages des grandes équipes Organisation plus plate. Une organisation d'ingénierie avec 150 ingénieurs aura 3-4 directeurs avec des équipes de dix personnes. Il aura 6 à 8 administrateurs et 1 à 2 vice-présidents avec des équipes de cinq personnes. D'où vient la confusion dans une organisation ? Probablement le leadership, afin que les grandes équipes puissent réduire la confusion. Plus de résilience. Quelqu'un peut prendre des vacances et l'équipe peut continuer très bien. Donc les petites équipes sont formidables au sein de leur équipe, mais moins idéales car elles sont si nombreuses que cela augmente la complexité organisationnelle. Les grandes équipes sont meilleures pour la complexité organisationnelle globale, mais moins idéales pour les performances au sein de chaque équipe. L'approche adoptée par de nombreux dirigeants consiste à constituer de grandes équipes qui se concentrent sur moins de flux de travail. Cela réduit la complexité de l'équipe interne et réduit également la complexité organisationnelle. Vous pouvez considérer FAST comme une approche qui tente d'atteindre une simplicité organisationnelle encore plus grande grâce à des équipes ridiculement grandes. Et il a également essayé d'obtenir les avantages d'avoir de petites équipes auto-assemblées. Faire évoluer les organisations est un travail difficile Une grande partie de mon activité de conseil consiste à aider les organisations à faire face à l'échelle. Il existe plusieurs phases de défis de mise à l'échelle auxquels les organisations sont confrontées. La première barrière est généralement à la marque ingénieur 15-25. C'est le moment où votre amibe est devenue trop grosse et doit se séparer. Vous voyez ces types de problèmes : Les canaux de communication deviennent inefficaces. L'ingénierie commence à avoir des problèmes de livraison et/ou de qualité. Les managers ou les dirigeants se sentent dépassés. Ajouter plus de personnes aggravera les choses, pas mieux. Et une deuxième barrière se situe à une soixantaine d'ingénieurs. À ce stade, vous commencez à voir beaucoup plus de problèmes : de coordination Les projets inter-équipes réussissent rarement. Le travail sur les produits submerge les équipes de la plate-forme, ou vice versa. Incapacité à mener à bien de grandes initiatives. J'ai vu des personnes brillantes échouer encore et encore à naviguer dans ces changements progressifs de la complexité organisationnelle. Mon intuition est que ces augmentations de complexité dans l'ordre des étapes correspondent au moment où vous ajoutez une couche de gestion supplémentaire. Faire grandir des organisations d'ingénierie est une vraie compétence. Cela nécessite une compréhension approfondie du fonctionnement des organisations et des personnes. Vous apprenez des choses comme : pour amener des groupes de personnes à travailler ensemble. Des modèles de coordination par rapport aux équipes conçues de manière fonctionnelle. Équipes alignées sur le flux Comment faire des réorganisations, où vous déplacez les gens et codez au fur et à mesure que les priorités de l'entreprise changent. Comment diviser les produits en domaines de responsabilités techniques chevauchant l'investissement dans les produits. Mise en place de canaux de communication autour des équipes. Mise en place de programmes d'astreinte et de fiabilité pour soutenir efficacement votre produit. Mise en place d'organisations de plateformes et d'initiatives d'expérience développeur pour lutter contre la complexité. Etc. Même si vous avez des personnes possédant cette expertise, cela demande beaucoup d'efforts de la part de votre équipe de direction pour faire face à la mise à l'échelle. Donc, si FAST peut mieux évoluer, vous libérerez une grande partie du potentiel de votre équipe de direction pour vous concentrer sur autre chose. Et, comme vos changements d'ordre des étapes se produisent beaucoup moins fréquemment, vous pourriez potentiellement rendre votre organisation beaucoup plus facile à gérer. Une expérience de pensée autour de FAST agile Alors, imaginez que vous augmenter la taille de l'équipe. Au lieu d'équipes composées de cinq ou dix personnes, et si vous pouviez avoir des équipes efficaces de vingt personnes ? Ou des équipes de soixante personnes ? puissiez À première vue, c'est une proposition ridicule. Des équipes aussi grandes ne sont pas efficaces. Même les équipes de douze personnes sont exagérées. Je vois parfois les curriculum vitae de personnes qui ont eu vingt ou trente personnes sous leur responsabilité. Ma réaction immédiate est de penser qu'ils travaillaient dans une entreprise épouvantable. Avoir autant de subalternes directs est une « odeur organisationnelle ». Le principe central de FAST agile est que si vous ajoutez l'auto-organisation et des équipes auto-sélectionnées au sein de ce collectif plus large, vous pouvez faire évoluer vos équipes plus . Chaque équipe (FAST les appelle les Collectifs) peut être beaucoup plus grande. Et puis les équipes avec lesquelles les gens travaillent au quotidien sont auto-assemblées au sein de ces Collectifs. horizontalement Si les grands collectifs étaient efficaces, ils réduiraient considérablement la complexité organisationnelle. Le démarrage typique d'un logiciel pourrait durer des années avant de devoir se diviser en domaines de responsabilité. La base de code n'aurait pas besoin d'être rigoureusement segmentée en zones appartenant à chaque équipe. Cela libérerait un temps de gestion important que les managers pourraient utiliser pour se concentrer sur le produit et les équipes. C'est donc la chose centrale que nous devons tester : l'auto-assemblage et l'auto-organisation offrent-ils un mode de fonctionnement aussi efficace que des équipes plus petites et conçues ? Si c'est le cas, cela offrira un moyen de faire évoluer les organisations qui est potentiellement d'un ordre de grandeur meilleur pour faire évoluer les organisations. Pourquoi autant ? Comparons une organisation qui grandit avec des équipes de taille six personnes à une organisation qui grandit avec des « équipes/collectifs » de taille soixante personnes. Il y a beaucoup d'hypothèses intégrées dans cet argument, et vous pourrez peut-être y percer quelques trous. Mais même si vous le faites, FAST permet essentiellement à une plus grande unité organisationnelle de posséder une partie du produit et de la base de code. FAST est nouveau, il n'y a donc pas une tonne de preuves à l'heure actuelle pour savoir si les équipes FAST fonctionnent aussi efficacement que les équipes agiles conventionnelles. Mais je soupçonne que la réponse à cette question est oui. J'ai plusieurs raisons de le croire. Tout d'abord, l'expérience préliminaire de Jim Shore a été assez positive, et c'est quelqu'un en qui j'ai confiance. Une deuxième raison pour laquelle je suis optimiste sur FAST est que j'ai eu une certaine expérience avec de grands groupes de personnes qui s'auto-organisent. Et j'ai été surpris de voir à quel point cela fonctionnait. Dans les petites entreprises, bien sûr, vous voyez beaucoup d'auto-organisation. Mais à mesure que les entreprises grandissent, vous normalisez les choses et supprimez l'auto-organisation, sauf au sein des équipes. Cependant, l'une des expériences les plus intéressantes auxquelles j'ai participé était un événement d'auto-organisation à grande échelle à New Relic. Nous avons repensé toutes nos équipes et demandé à chacun des cinquante équipes logicielles de sélectionner l'équipe dont il souhaitait faire partie. Nous avions des contraintes sur les compétences nécessaires pour chaque équipe, et avions défini ce que chacun devait posséder. Cela a fini par être bien plus réussi que quiconque ne l'avait prévu, même nous, les organisateurs. Donc, bien que le jury soit sur ce point, mon intuition est que cette pratique a beaucoup de potentiel dans les bons contextes. FAST peut être expérimenté progressivement Ce n'est pas mentionné dans les documents FAST, mais une chose qui m'a sauté aux yeux comme étant intéressante à propos de FAST est que vous pouvez l'expérimenter progressivement. Vous pouvez implémenter FAST Agile sur une équipe à titre expérimental, puis utiliser une approche blob dans laquelle vous avalez des équipes supplémentaires au fil du temps. Si ça se passe bien, continuez à avaler des équipes supplémentaires. Si ce n'est pas le cas, annulez l'expérience. FAST devrait entraîner moins de réorganisations Le changement se produit dans les organisations. Les priorités changent, les gens partent, les domaines du produit connaissent une croissance inattendue. Les décisions techniques précédentes vous mordent et vous devez faire un travail supplémentaire. De nouvelles opportunités se présentent qui nécessitent des investissements. Toutes ces choses ont un impact sur la structure de votre organisation. Vous avez un ensemble d'équipes, chacune ayant ses propres domaines de propriété. Au fur et à mesure que ce changement se produit, vous refactorisez votre organisation au fil du temps pour donner le meilleur de vous-même. Ces refactorings sont des « reorgs » et, dans les organisations en croissance, ils peuvent se produire fréquemment ! Les réorganisations devraient être beaucoup moins fréquentes avec FAST. L'unité de réorganisation est si grande que vous ne devriez pas avoir à le faire aussi souvent. Un inconvénient potentiel de cela est que vous n'avez pas d'équipes avec des domaines de responsabilité définis. Vous pourriez donc avoir une diffusion des responsabilités et avoir un code commun mal entretenu. (Nous en reparlerons un peu plus tard) FAST permet de répondre plus facilement aux priorités changeantes Lorsque les priorités changent dans des équipes structurées de manière conventionnelle, vous avez des équipes mises en place pour faire le travail. Si cette structure d'équipe ne prend pas en charge les nouvelles priorités, vous devez refactoriser votre organisation. Pour FAST, les changements de priorité sont plus fluides et continus. Tant que les responsabilités sont au sein du Collectif, les équipes s'organisent autour du travail, et c'est comme un autre jour. La structure des réunions collectives rend également les changements de priorités moins dramatiques. Vous avez essentiellement un All Hands intégré deux fois par semaine. Lors des réunions collectives, vous pouvez continuellement communiquer le contexte et éduquer votre équipe sur vos clients et votre marché. Cela devrait aider à mieux aligner votre équipe. Lorsque je compare cette approche à quelque chose comme les OKR trimestriels, cela semble plus fluide et comme si cela ferait un meilleur travail d'alignement des gens. Cela nécessite un effort engagé de la part du chef de produit pour partager en permanence le contexte et les priorités. Mais certaines des meilleures équipes dont j'ai fait partie avaient un chef de produit agissant de cette manière, donc je pense que c'est du temps bien dépensé. FAST pourrait être meilleur pour la motivation intrinsèque et la rétention De nombreuses équipes peuvent avoir l'impression que leur processus est conçu comme un outil de contrôle des personnes. Et cela peut donner l'impression de travailler sur une chaîne de montage. FAST considère l'auto-organisation comme un élément fondamental de sa conception. C'est tellement fondamental que ça ne marchera pas sans l'auto-organisation. Cela nécessite une boîte à outils complètement différente pour la gestion, et c'est la plupart du temps (mais pas complètement) incompatible avec les approches hiérarchiques descendantes. Daniel Pink a décrit : trois aspects célèbres de la motivation intrinsèque - Un désir d'être autonome, ce qui augmente l'engagement par rapport à la conformité. Autonomie - L'envie de devenir plus qualifié. Maîtrise – Le désir de faire quelque chose qui a du sens et qui est important. Les entreprises qui se concentrent uniquement sur les profits sans valoriser le but se retrouveront avec un service client médiocre et des employés mécontents. But Avec FAST, vous êtes en mesure de diriger vous-même votre travail, ce qui vous aide à vous sentir autonome. Vous êtes en mesure de choisir de vous concentrer sur un travail qui améliore vos compétences, en acquérant un sentiment de maîtrise. Et vous vous souvenez constamment de la façon dont votre travail est lié à ce qui est important pour l'entreprise, ce qui vous aide à vous sentir utile. Donc, bien que ce ne soit pas garanti, je vois un potentiel pour les organisations mettant en œuvre FAST pour voir des taux de rétention élevés. L'auto-organisation fournit également des signaux pratiques qui peuvent permettre à une communauté de personnes de mieux travailler ensemble. Le type de personne « jerk manager » reçoit un signal que son comportement n'est pas le bienvenu. Comment? Ils s'avancent pour diriger une équipe, et disent le travail qu'ils veulent faire. Si personne ne se joint à leur équipe, le travail ne se produit pas et l'équipe ne se forme pas (les équipes ont un minimum de deux ou trois personnes, ou elles ne se produisent pas). L'auto-organisation permet également aux gens de faire face à des aspects pénibles du travail qui peuvent ne pas attirer l'attention dans d'autres entreprises. Par exemple, si la suite de tests est terrible, quelqu'un peut se proposer pour diriger une équipe qui résout ce problème. Il est parfaitement raisonnable de faire un travail qui n'est pas explicitement une priorité commerciale. Mais c'est ouvert, et d'autres doivent s'y joindre pour que cela se produise. Cela peut vous éviter d'avoir l'impression d'être dans une . fabrique de fonctionnalités Enfin, vous pouvez choisir les personnes avec lesquelles vous travaillez au quotidien. Quand j'ai vu des équipes s'auto-organiser dans le passé, c'était un avantage inattendu : les gens choisissaient de travailler avec des gens avec qui ils voulaient travailler. Et ces équipes étaient beaucoup plus fortes que ce à quoi je m'attendais. La chose contre laquelle tout cela serait équilibré est toute nouvelle douleur que les gens éprouveraient avec FAST. Un défi pourrait être la dynamique de pouvoir informelle ou la politique potentielle. De nombreux environnements sont incompatibles avec FAST Parce que FAST est si nouveau, il est plus risqué à mettre en œuvre. FAST n'aura pas de sens dans toutes les situations. Et il y a plus d'inconnues. Il est préférable de considérer cela comme une approche expérimentale. Quels environnements sont les plus propices à l'essai de FAST ? Et où devriez-vous éviter FAST ? Plus votre entreprise possède de qualités dans cette liste, plus elle est adaptée à FAST : Intérêt pour l'innovation et l'expérimentation en gestion. Environnements à haute confiance et à faible peur. Ou du moins un désir d'éviter le commandement et le contrôle dans le leadership. Un bon guide ou facilitateur du processus. Quelqu'un qui peut diriger une réunion collective efficace, mettre en place le processus, l'évaluer et le gérer activement. Quelqu'un qui comprend la dynamique organisationnelle et comment les humains en groupe travaillent ensemble. (Vous pourriez m'engager pour cela). Un taux moyen à élevé de changement des priorités. FAST est moins utile si les priorités ne changent pas. Une équipe collaborative, autonome, performante et en apprentissage continu. Une équipe dirigeante capable de définir ses priorités. Vous avez un chef de produit qui peut parler des priorités et du contexte d'affaires à chaque réunion du Collectif. Et ils peuvent communiquer efficacement. Moins ces traits sont vrais, plus vous serez confronté à des vents contraires avec FAST. Je ne pense pas que vous ayez besoin d'être dans un environnement parfait pour cela. À certains égards, je pense que vouloir être ces choses est plus important que d'être réellement ces choses. Alors peut-être que le facteur de succès le plus important est que le leadership est d'accord pour lui faire de la place. Vous devrez peut-être gérer l'autogestion Les systèmes auto-organisés peuvent fonctionner efficacement. Mais ils ne sont pas gratuits. Ils ressemblent plus à la gestion d'une communauté. Vous devrez créer des contraintes et des moyens pour encourager le bon comportement. Et vous devrez surveiller attentivement et gérer pour vous assurer que les choses ne dérapent pas. Toute organisation peut avoir de mauvais acteurs ou des personnes qui ne sont pas alignées sur les intérêts de cette communauté. Je me souviens avoir parlé une fois avec un ingénieur qui m'a dit (je ne plaisante pas) qu'il ne pensait pas avoir l'obligation de produire de la valeur pour son employeur. Certains ingénieurs pourraient vouloir se concentrer sur des choses qui développent leurs compétences ou font d'eux des employés plus précieux, plutôt que sur des choses qui sont bonnes pour l'entreprise qui les emploie. Avec FAST, vous vous engagez à gérer une de personnes. communauté Dans les situations conventionnelles, la hiérarchie précise qui en est responsable. Dans FAST, je soupçonne qu'il serait facile d'essayer d'éviter les conflits et de "laisser les membres le résoudre". Il pourrait en résulter une domination des réseaux de pouvoir informels dans une sorte de . Si vous utilisez FAST, c'est quelque chose contre quoi je me prémunirai. tyrannie de l'absence de structure L'autre extrême serait de ne pas laisser le groupe résoudre les problèmes et de laisser la direction s'en occuper complètement. Cela pourrait être nocif. également FAST nécessitera donc une bonne animation, une observation attentive et une intervention occasionnelle. FAST demande beaucoup de travail La principale raison pour laquelle vous ne voudrez peut-être pas expérimenter FAST est qu'il y a beaucoup de travail caché avec FAST. Cela nécessite beaucoup de changements dans votre organisation, vers un mode de fonctionnement peu familier. Vous pouvez comparer FAST au travail dans un nouveau langage de programmation informatique. Le nouveau langage semble prometteur car il comporte tellement de nouvelles fonctionnalités ergonomiques qu'il semble bien meilleur que tout ce que vous avez vu auparavant. Mais, vous n'avez pas de frameworks et de bibliothèques écrits dans ce nouveau langage. Vous devrez donc en construire une grande partie vous-même. Donc, le plus grand inconvénient de FAST est que ce n'est pas une pratique bien établie. Vous devrez inventer beaucoup de choses pour faire face aux incompatibilités entre le fonctionnement de FAST et les pratiques conventionnelles. Voici quelques exemples: Comment fonctionne la gestion des performances ? Dans les équipes conventionnelles, vous avez un manager qui supervise le travail et coache les individus. Vous avez des évaluations de performance et si quelqu'un ne convient pas, le responsable peut intervenir. Bien qu'il y ait des problèmes avec les évaluations de performance, la plupart des gens comprennent comment ils fonctionnent et ils servent un objectif dans l'organisation. Dans les équipes FAST, il n'y a pas vraiment de moyen évident de faire des évaluations de performance. Le responsable de la personne sait-il même ce qu'elle fait ou comment elle travaille ? Vous ne pouvez même pas évaluer les « équipes », car elles sont transitoires. C'est donc toute la notion de gestion de la performance qu'il faut réinventer. Bien que cela puisse être une bonne idée de toute façon, c'est quelque chose qui nécessitera de la réflexion et de l'invention. Quel est le rôle des responsables de l'ingénierie dans FAST ? Il existe de nombreuses façons de structurer un rôle de responsable de l'ingénierie. Je recommande généralement d'avoir le , car cela les amène à travailler côte à côte avec leur équipe, sans les mettre dans une zone où le différentiel de puissance pose problème. Il existe de nombreuses façons valables de définir le rôle de directeur de l'ingénierie, mais c'est celle vers laquelle j'ai tendance à graviter. responsable de l'ingénierie responsable de la gestion de projet Dans FAST, le rôle du responsable de l'ingénierie est moins clair. Vous n'avez pas d'équipes de longue durée, il est donc plus difficile pour le directeur de l'ingénierie de travailler côte à côte avec ses subordonnés directs. Vous pourriez avoir des responsables de l'ingénierie à la tête des équipes auto-assemblées. Ou vous pourriez les faire être de purs gestionnaires de personnes. Ou vous pourriez les avoir comme joueurs-entraîneurs. Tous ces éléments ont des compromis et quelques inconvénients assez importants. FAST semble diminuer le besoin d'autant de gestion technique. Vous avez toujours besoin de personnes pour embaucher, gérer la performance et superviser le processus. Mais peut-être pas autant que dans une organisation classique ? J'ai vu de nombreuses organisations souffrir parce qu'elles ne valorisent pas la gestion en tant que discipline. Mais je suppose que les organisations FAST ont besoin de moins de gestion. Je suis vraiment curieux de voir si cela fonctionne, et je veux entendre des organisations qui expérimentent FAST. Que faites-vous de la gestion ? Comment assurerez-vous la qualité du code sans zones de propriété ? La propriété du code fournit des incitations naturelles pour maintenir la qualité du code à un niveau élevé. C'est dans votre propre intérêt, parce que votre futur moi doit travailler dans votre code actuel. Dans une situation de propriété de code partagé, vous devez aller plus loin pour garantir la qualité du code. Ma recommandation serait l'appariement ou le mobbing comme pratique obligatoire. Vous aurez également besoin de normes plus strictes pour les modèles de code. Vous aurez besoin de peluches de code. Et vous aurez besoin d'une sorte de prise de décision architecturale. Vous ne voulez pas avoir vingt modèles pour la façon dont votre code frontal gère l'état. Ce sont des problèmes que vous rencontrerez dans la plupart des organisations de logiciels, mais ils seront beaucoup plus pressants dans une organisation utilisant FAST. Une chose dans laquelle de nombreuses organisations sous-investissent est la formation et la communication autour de modèles de conception de logiciels efficaces. Et des conversations pour s'assurer que tout le monde est d'accord sur les approches à utiliser et quand. Ceux-ci sont probablement encore plus importants dans une organisation FAST. La propriété partagée du code est une pratique qui a des précédents. Cela vaudrait la peine de passer du temps à chercher comment réussir si vous continuez avec FAST. Que se passe-t-il avec les collectifs multiples et le franchissement des frontières collectives ? Le travail qui traverse les frontières collectives est essentiellement indéfini dans FAST. Et les grandes initiatives nécessitant des degrés élevés de coordination sont également sous-spécifiées par FAST. Il faudrait donc inventer des solutions à ces situations. Toute organisation suffisamment grande pour avoir plusieurs collectifs utilisant FAST se heurtera à des projets inter-collectifs. Les modèles pour résoudre ces problèmes seront similaires ou analogues à la façon dont vous les résolvez à plus petite échelle. Mais c'est un territoire largement inexploré, pour autant que je sache. Vous devrez donc utiliser des pour résoudre ces problèmes lorsqu'ils surviennent. Ce sera un acte d'invention. modèles de coordination Comment FAST traite-t-il les astreintes ? L'astreinte n'est pas spécifiquement mentionnée dans le . Vous devrez donc inventer un plan pour y faire face. guide FAST Dans les équipes conventionnelles, le conseil standard pour les astreintes est que chaque équipe soit responsable de ses propres opérations. Et d'avoir tout le monde dans l'équipe sur appel. Cela implique que vous devriez avoir des équipes d'au moins quatre personnes afin que le fardeau ne soit pas trop lourd. L'idée est que le fait d'avoir des équipes sur appel pour leur produit de travail les incite à intégrer la fiabilité. Cela les aide à s'assurer qu'ils ont un horaire de garde décent. Avec FAST, vous pouvez créer une rotation sur appel qui a des niveaux (suivez ce runbook et escaladez si cela ne résout pas le problème). Et vous devrez explicitement conserver une carte de qui est capable de prendre en charge quoi. Cela ne correspondra pas à vos équipes. Ce n'est pas très difficile à faire, mais c'est moins courant que les pratiques de garde conventionnelles et nécessitera l'attention de la direction. Qu'en est-il de la correction des bugs et des escalades de support ? FAST a un rôle facultatif appelé « Feature Steward ». Ils sont en quelque sorte un expert pour une fonctionnalité particulière et sont le point de contact autour de cette fonctionnalité pour les parties prenantes. Ils ne sont pas tenus de travailler en permanence sur cette fonctionnalité, mais doivent en avoir une compréhension continue. Comme sur appel, vous aurez besoin d'un mappage des fonctionnalités aux personnes ayant une expertise sur ces fonctionnalités. Cela sera important à la fois pour les bogues et les escalades de support. Et vous pourriez aussi bien le combiner avec une astreinte. Vous aurez besoin d'un moyen de trier les problèmes vers les bonnes personnes. Vous devrez également vous assurer que vous disposez d'un mécanisme pour combler les lacunes dans les connaissances lorsque l'expertise est limitée à une ou deux personnes. Une chose que vous devrez décider est votre politique de correction des bogues. Voulez-vous qu'ils soient toujours corrigés, ce qui ralentit le travail d'autres fonctionnalités ? Les bogues sont-ils corrigés par la personne qui les a introduits, ou voulez-vous un autre schéma ? Et comment allez-vous déterminer qui est responsable du triage des bogues ? Probablement une sorte de ? rotation Les escalades de support nécessiteront également des efforts. Le point de contact est le Feature Steward pour une zone. Mais que se passe-t-il si le Feature Steward est en vacances ? Vous voulez probablement plus d'une personne bien informée sur chaque domaine. Et si la question de support finit par nécessiter du travail ? Faites-vous simplement le travail ou l'intégrez-vous aux priorités centrales ? Aucun de ces problèmes n'est difficile à résoudre, mais il s'agit d'un travail de gestion. Et tout ce que vous ferez aura des compromis entre concentration et réactivité. Qu'en est-il des incidents de fiabilité et des rétrospectives d'incidents ? FAST ne définit pas la manière dont les incidents sont traités. Vos habitudes d'astreinte détermineront en grande partie la manière dont les incidents sont traités et impliqueront probablement quiconque sait comment résoudre la situation qui sera amené à la résoudre. FAST ne décrit pas comment gérer les rétrospectives d'incidents. Je recommanderais de faire quelque chose comme ce qui suit : planifier une rétrospective de l'incident avant la prochaine réunion du Collectif. L'un des objectifs de la rétrospective serait d'identifier quelques travaux qui pourraient être effectués pour réduire la probabilité ou la gravité de ce qui a causé l'incident. Une autre serait d'apprendre tout ce que vous pouvez de l'incident. Lors de la réunion du Collectif immédiatement après l'incident, je partagerais ce que nous avons appris, et je ferais aussi une priorité automatique pour le prochain cycle de faire une partie du travail identifié dans la rétrospective. Chez New Relic, nous n'utilisions pas FAST, mais nous avions une politique similaire. Nous l'avons appelé "Ne pas répéter les incidents" (DRI). C'était l'une des meilleures choses que nous ayons jamais faites pour la fiabilité. La règle était que le travail de DRI était automatiquement plus important que les autres priorités. Ainsi, un incident entraînait toujours soit une réduction de la portée, soit une échéance repoussée. Comment les designers travaillent-ils dans FAST ? Un défi pour de nombreux concepteurs est de se concentrer sur le travail avec l'équipe d'ingénierie ou de travailler en amont de l'équipe d'ingénierie. Ou faites-les fonctionner dans les deux sens. Vous entendrez des arguments solides pour les deux façons de travailler. FAST ne précise pas comment cela devrait fonctionner, vous devrez donc décider par vous-même. Les designers s'inscrivent-ils pour que les équipes travaillent dessus ? Ou s'agit-il d'une organisation de services, qui travaille à l'avance et agit en tant que lorsque les gens ont besoin de quelque chose de leur part ? Vous devrez décider. Je demanderais probablement aux concepteurs de s'inscrire et de faire partie des équipes, mais encore une fois, c'est un exemple du type de décisions que vous devrez prendre lors de l'adoption de FAST. consultant Comment fonctionnent les chefs de produit dans FAST ? Le rôle du produit dans FAST est principalement de hiérarchiser et de communiquer les priorités. Il y a beaucoup de choses qui ne sont pas vraiment décrites dans le manuel FAST concernant le travail en dehors de cela. L'hypothèse du manuel FAST semble être que les chefs de produit inspirent et communiquent, puis que les ingénieurs travaillent sur les fonctionnalités. Dans la mesure du possible, je demanderais aux ingénieurs de parler avec les clients et de leur faire acquérir une expertise dans le domaine de produits dans lequel ils travaillent. Idéalement, ils feraient le travail, en feraient la démonstration aux clients et obtiendraient des commentaires de leur part. . Faire en sorte que les chefs de produit facilitent cela et améliorer la capacité des ingénieurs à le faire efficacement pourrait constituer une partie précieuse de leur travail. Il y a beaucoup de flexibilité dans ce modèle. Vous pouvez faire le transfert typique du produit à l'ingénierie, ou vous pouvez leur faire découvrir et résoudre les problèmes de l'espace ensemble, avec les clients. Donc, comme vous pouvez le voir, il y a de nombreuses lacunes dans FAST. Vous aurez besoin de résoudre le reste. Les matériaux FAST sont pleins de jargon Vous pouvez trouver le site Web et le manuel de FAST déroutants. Vous devrez naviguer dans beaucoup de jargon et de terminologie ennuyeuse pour obtenir l'or de FAST Agile. A titre d'exemple, voici la terrible définition de FAST Agile qui tente de définir la pratique dans : la version 2.12 du FAST Guide "Qu'est-ce que la technologie de mise à l'échelle des fluides ? La technologie Fluid Scaling combine la technologie Open Space et l'allocation ouverte pour créer une méthode légère, simple à comprendre et simple à maîtriser pour organiser les personnes autour du travail - qui évolue. FAST est l'acronyme de Fluid Scaling Technology. La technologie de mise à l'échelle des fluides pour Agile est FAST Agile. Donc. Mauvais. Et c'est très représentatif. Vous verrez de nombreuses références aux collectifs, aux cycles de valeur, à la technologie ouverte, à la transformation turquoise, à la théorie Y, etc. Tout cela est présenté sans explication, et même si cela était expliqué, cela ne serait pas utile. Ils s'adressent à un public de niche de théoriciens agiles et se concentrent sur l'attribution plutôt que sur l'utilité. Conclusion Alors, où en sommes-nous? FAST agile vaut-il la peine d'être expérimenté ? Je crois que la réponse à cette question est oui, mais avec prudence et dans les bons contextes. Vous pouvez jouer avec au sein d'équipes individuelles. Et si vous avez le soutien de la direction, expérimentez-le progressivement au sein de grandes organisations. S'il vous plaît partagez avec moi si vous l'expérimentez. Et si vous avez besoin d'aide pour le déployer dans votre organisation, contactez-moi. Je vais soit vous aider directement, soit vous mettre en contact avec d'autres qui peuvent vous aider. Merci Les premières versions de ce post étaient… vraiment mauvaises. J'aimerais remercier et pour leur critique. Ils ont tous deux souligné des problèmes majeurs avec le poste qui m'ont fait reculer et repenser mon approche. Et ils ont fait d'excellents points que j'ai incorporés dans leurs propres sections du message. Finalement, j'ai réécrit la majeure partie du message et j'étais beaucoup plus satisfait du résultat. Merci! Seth a une qui vaut la peine d'être consultée, et Davy (comme moi) . Seth Falcon Davy Stevenson newsletter sur le leadership en ingénierie conseille et coache les startups m'a présenté FAST Agile. Il a d' sur ses expériences avec elle. Et nous nous sommes rencontrés à quelques reprises et avons discuté des implications et de la mise en œuvre de FAST. Jim est l'auteur de . Jim Shore excellentes discussions The Art of Agile Development Image de parKanenori Pixabay Notes de bas de page Je crois que 150 personnes est probablement difficile à manier pour un Collectif. Je soupçonne que soixante personnes est une meilleure taille maximale. Également publié . ici
