Méfiez-vous de SAFe (Scaled Agile Framework for Enterprise), une incarnation impie des ténèbres
… ou peut-être pas.
Si vous préférez que SAFe parle pour lui-même, vous pouvez utiliser le lien ci-dessus. Il y a des centaines de pages de documentation, des heures de vidéos, 15 cours de formation différents, et plus encore. Si cela vous parait un peu trop, je ferai de mon mieux pour expliquer le fonctionnement de SAFe au fur et à mesure que jévalue chaque point.
Au plus haut niveau, appelé le « Portfolio », SAFe préconise le financement de «chaînes de valeur» indéfinies – qui représentent généralement un produit, une gamme de produits ou un type de client. Cependant, la fonction de gestion de portefeuille Lean (LPM) qui contrôle le financement (probablement les mêmes personnes auparavant responsables des budgets de projets de type cascade), est seule habilitée à approuver quelles Portfolio Epics (grandes initiatives) sont transférées dans chaque flux. Les épopées ne sont pas des explications sur un problème qui doit être résolu. Ce sont des idées préformées sur la meilleure façon de résoudre ces problèmes.
Nous pouvons tout de suite voir des signes de la mentalité de la vieille école consistant à considérer les équipes comme une fonction de « livraison » au lieu dune fonction stratégique. les penseurs de niveau proposent des idées, et les acteurs de bas niveau les exécutent. On ignore la possibilité que les personnes les plus proches du travail soient les mieux équipées pour prendre des décisions à ce sujet. Fuir cet état desprit erroné est un objectif fondamental de la SAFe ne parvient pas à accomplir à distance.
Un problème similaire réapparaît lorsque nous examinons un niveau légèrement inférieur.
SAFe rassemble de petites équipes produit (souvent des équipes Scrum) dans « Agile Release Trains « – groupes déquipes avec une couche supplémentaire de rôles de gestion couvrant chaque groupe au niveau de ce que lon appelle le » niveau du programme « .
En général, ces rôles entravent lautonomie des équipes. Ils ajoutent des frais généraux de processus et de communication disproportionnés avec la valeur quils fournissent.
Ces rôles incluent un chef de produit (PM), un S ystem Architect (SA) et un Release Train Engineer (RTE).
Le SA et le PM définissent et décomposent des tâches plus importantes (souvent héritées du processus de portefeuille ci-dessus), puis les transmettent au
Le Product Owner et léquipe pourraient théoriquement être en mesure de prioriser dautres travaux plus petits par rapport au travail qui leur est imposé, mais ces efforts ont une visibilité et une adhésion limitées par le haut. Il y aura une pression naturelle pour traiter le travail provenant du point le plus élevé comme le plus important – même si chaque membre de léquipe pense que dautres éléments seraient plus précieux. Pour cette raison, le rôle du Product Owner est réduit à lécriture dhistoires et à la vérification des critères dacceptation, au lieu dêtre le point unique de responsabilité pour le leadership produit qui était lintention dorigine du rôle.
Larchitecte système nest pas en mesure dêtre proche des travaux dingénierie proprement dits, de sorte que le plan architectural quils transmettent peut être déconnecté de la réalité de louvrage. Ces types de rôles étaient une caractéristique des grands projets en cascade de conception initiale et sont bien préservés dans SAFe.
Les ingénieurs de Release Train définissent un processus et une cadence cohérents entre les équipes et gèrent de nombreuses tâches opérationnelles. En fin de compte, cela laisse moins de place aux équipes individuelles pour modifier, améliorer ou expérimenter leurs propres pratiques dune manière qui sécarte des normes établies.
Parfois, tous ces problèmes se répètent à nouveau avec lajout dun « Large Niveau de la solution »- groupes de groupes déquipes ayant des rôles analogues à ceux du niveau du programme, mais couvrant les trains de lancement. Lorsque cela se produit, les mêmes problèmes sont susceptibles de se répéter, mais le niveau de solution semble être moins souvent mis en place.
SAFe est (souvent) fourni avec Rally – ENCORE limitant lautonomie de léquipe
SAFe est souvent un package avec le logiciel de gestion de projet Rally. Rally est le type de logiciel auquel vous vous attendez une entreprise qui utilise SAFe pour créer – elle est surchargée de fonctionnalités, floue, déroutante, instable et par conséquent difficile à apprendre et à utiliser.
La proposition de valeur dadopter Rally pour le leadership est quelle sera en mesure de voir des rapports qui leur donnent une image simple et unifiée du Progrès et problèmes dans toute lentreprise.
Bien sûr, cela signifie que tout le monde dans lentreprise doit non seulement utiliser Rally, mais aussi lutiliser de manière cohérente. Encore une fois, cela ne peut être réalisé que par dictée descendante. Le rallye et sa façon de penser le travail sont imposés à toutes les équipes, quels que soient leurs préférences, leur contexte ou leur adhésion. Pour avoir réellement toutes les informations cumulées, il faut des frais généraux incroyables en matière destimation et de suivi, ce qui ralentit tout et peut être extrêmement perturbateur pour lexécution du travail.
De plus, les rapports de niveau supérieur ne sont même pas particulièrement utiles. Il se concentre sur les choses que Rally suit – des mesures comme le volume de points dhistoire livrés (littéralement inventés) ou la quantité de bogues corrigés (une mesure terrible de la «qualité du produit»).Si la direction ignore ces statistiques, les frais généraux quelles ajoutent ne serviront à rien. Sils parviennent aux métriques, les statistiques seront truquées pour que les équipes aient lair bien et soient laissées seules. Les estimations seront surchargées, les petits travaux seront exagérés, et cela peut facilement conduire à une rupture de confiance.
SAFe adopte la pire approche possible pour gérer les dépendances
A la dépendance est un cas où une équipe doit attendre que quelque chose soit fait ailleurs avant de pouvoir terminer son propre travail. SAFe est structuré autour dune attitude rétrograde selon laquelle les dépendances sont une réalité immuable qui doit être acceptée et gérée. Il les désigne même parfois comme un avantage stratégique. En réalité, lorsque vous considérez les dépendances comme une mauvaise chose – à minimiser à chaque occasion – vous constaterez peut-être que ces opportunités sont nombreuses et que profiter delles se traduit principalement par des avantages. Voici quelques suggestions que SAFe sous-estime ou ignore totalement:
- Encouragez une culture de sourcing interne où une équipe peut soumettre le travail à la base de code dune autre équipe sans avoir à dépendre deux au-delà accepter la fusion
- Permettre aux membres de léquipe déchanger facilement des équipes de manière temporaire ou permanente lorsque cela est judicieux
- Concentrez-vous sur le recrutement, la structuration et la formation des équipes pour quelles répondent à leurs propres besoins sans aide extérieure
En fait, SAFe choisit de gérer les dépendances en se concentrant davantage sur la planification, les processus, la hiérarchie et la normalisation. Comme on pouvait sy attendre, cela entraîne de nombreuses réunions qui interfèrent avec la capacité de faire le travail. Il impose cette approche à travers un déploiement universel qui affecte à la fois lensemble de lorganisation. Aucune considération nest donnée aux domaines qui auraient pu être autonomes sans la structure lourde supplémentaire.
SAFe est excessivement orienté vers la planification
Une caractéristique fondamentale de SAFe est lidée denviron 10 semaines Incréments de programme (PI). Vous pouvez penser à ces sortes de sprints énormes qui contiennent tous vos sprints normaux.
Chaque PI commence par un événement de planification PI qui dure environ deux jours. La planification de lIP nécessite également des activités de pré-planification et de post-planification au niveau du programme.
Il y a certainement une valeur à ce que les gens se réunissent en personne pour établir des relations, partager des informations et sorienter autour dobjectifs. Dun autre côté, utiliser cette fenêtre de temps limitée pour faire des plans de 10 semaines de user stories spécifiques en fonction de fonctionnalités prédéfinies, puis exiger un engagement envers ces plans est beaucoup moins utile.
Dès que la planification PI prend fin, ces plans sont créés sur la base la compréhension et de nombreuses hypothèses deviendront obsolètes dès que quelque chose de nouveau sera appris. Les équipes seront continuellement déchirées entre sen tenir au plan quelles ont appris na pas de sens et réorienter les attentes pour des raisons que ceux qui les précèdent ne sont peut-être pas en mesure de comprendre.
SAFe est orienté autour du volume, pas de valeur
Dans toute cette focalisation sur les mesures de volume, lestimation et le travail de barattage tout au long du pipeline, le concept de ce qui est réellement précieux ou réussi est facilement perdu. On suppose souvent que plus de travail expédié à lextérieur doit avoir de la « valeur », même si lexpérience du produit en souffre et que les utilisateurs ne bénéficient pas des fonctionnalités supplémentaires.
SAFe est conscient des critiques selon lesquelles il nest pas axé sur la valeur et a récemment ajouté à sa documentation le «design thinking», le «customer centricity» et dautres concepts pour compenser. Jusquà présent, je ne suis pas convaincu quil apporte des changements significatifs dans son processus qui font de la place pour ces choses. , et il sefforce même de les comprendre en premier lieu.
Par exemple, la définition de SAFe des «clients» laisse la porte ouverte à la définition des parties prenantes de lentreprise ou de ceux qui financent les flux de valeur comme étant des «clients». est très différent de réorienter tout le monde (y compris ceux qui fournissent le financement) pour se concentrer sur les besoins des utilisateurs finaux utilisant réellement le logiciel, un élément central de la pensée de conception.
SAFe est inutilement complexe
SAFe a un avantage naturel qui protège il de la critique; C’est tellement compliqué qu’il est difficile de le comprendre pleinement. Malgré le temps supplémentaire que jai passé à rechercher le cadre, je suis probablement toujours susceptible de me tromper ou de manquer des points importants. Cependant, labondance de la complexité est en soi une préoccupation légitime. SAFe a tellement de réunions, de points de contrôle, de valeurs et de méthodes quil est fondamentalement impossible de mettre tout le monde sur la même page.
SAFe limite les rétrospectives et lamélioration continue
Les rôles au niveau du programme et ci-dessus ne peut pas assister à toutes les rétrospectives des équipes.Cela signifie que les rétrospectives ne seront pas directement entendues par les personnes qui peuvent réellement changer la plupart des choses discutées.
La façon dont SAFe essaie de compenser cela nest pas suffisante.
Planification PI Cest le seul moment où tout le monde dans un Release Train est assuré dêtre ensemble en personne. Malheureusement, il contient une courte rétrospective liée uniquement au succès de lévénement de planification lui-même.
SAFe inclut un événement «Inspecter et adapter» vers la fin de chaque PI, mais il semble presque conçu pour être ignoré en fonction sur la difficulté à coordonner pour le RTE. Lorsquil est organisé, lévénement est amorcé en examinant – bien sûr – les mesures de volume du dernier IP. De plus, seules 30 minutes de lévénement sont allouées pour une rétrospective réelle où les problèmes sont soulevés et acceptés Si ce temps est réparti équitablement entre tous les membres dun Release Train de 100 personnes, chaque participant disposera denviron 18 secondes toutes les ~ 10 semaines pour soulever des problèmes dans un contexte où ils pourraient effectivement être entendus.
SAFe comporte également dautres éléments tels que des «tableaux dévaluation» où les équipes sont interrogées plus largement, mais ceux-ci tendent fortement à confirmer que les pratiques SAFe sont suivies, pas si elles sont efficaces ou non.
SAFe dégrade les concepts quil agrège
Une clé une partie de SAFe que je nai pas encore abordée est lagrégation de concepts existants tels que Scrum, Kanban, Lean Product, Lean UX et DevOPs.
Si vous nêtes pas familier, je vous suggère dexplorer chaque concept indépendamment au fil du temps plutôt que tous à la fois. Beaucoup sont précieux eux-mêmes, mais SAFe ne fait pas un excellent travail pour les synthétiser et peut parfois ajouter de la confusion. Exemple concret:
SAFe adopte systématiquement la manière dont ses pratiques suivent les principes «Lean-Agile». Lastuce est que «Lean-Agile» ne fait pas réellement référence aux principes «Lean» ou «Agile».
Au lieu de cela, les « principes Lean-Agile » sont une création du propre design de SAFe. Ce nouvel ensemble de « principes » déforme les concepts quil assimile. Par exemple, la page sur la décentralisation des décisions (classée au plus bas de tous les principes) se subvertit subtilement en soulignant limportance de centraliser la prise de décision pour de nombreux cas dutilisation. Dautres principes énumérés posent des problèmes similaires. Pour une personne qui est présentée à toutes ces informations en même temps, la signification réelle des concepts originaux peut être perdue.
SAFe nest pas Agile
Aujourdhui, de nombreuses façons dont SAFe est incompatible avec un état desprit Agile devrait être assez clair. Il est axé sur le plan, bureaucratique, compliqué, comprend beaucoup de processus souvent inutiles, désactive lautonomie de léquipe, et plus encore.
Mais peu importe si SAFe est Agile ou non, alors que ce qui nous importe vraiment, cest lefficacité ?
Oui. Cest le cas.
Les principes Agile ne sont que des principes Agile car ils ont été généralement reconnus et acceptés comme étant efficaces. Cette réflexion a résonné avec une communauté plus large de praticiens, cest pourquoi le mouvement a pris son essor. Si vous pensez que lagilité est un prédicteur de lefficacité, (une croyance probablement derrière une partie de lintérêt pour SAFe), alors il est très important que SAFe soit cohérent avec la pensée Agile. Tromper les gens sur ce quils achètent est une mauvaise chose et il nest pas faux de le dire.
Quen est-il de toutes les études de cas où SAFe a fonctionné?
Il existe environ 40 études de cas sur ladoption réussie de SAFe sur scaledagileframework.com. Les études de cas déchecs sont manifestement absentes. Contrairement à lacronyme, SAFe implique des changements simultanés à un nouveau processus énorme dans un énorme écosystème – un risque énorme. À moins que chacune de ces 40 entreprises prospères nait chacune 11 250 praticiens certifiés SAFe, il y a pas mal dentreprises dont nous nentendons pas parler.
De plus, je ne mets pas trop de valeur dans les études de cas exister. Même si les mesures de volume sur lesquelles ils se concentrent étaient vraiment précieuses, il est facile de choisir quelques statistiques qui donnent limpression que tout sest bien passé.
Pour nous concentrer sur un exemple spécifique, jetons un coup dœil à un extrait extrait de létude de cas sur limplémentation de SAFe chez Fitbit:
En 2016, la société de technologie grand public Fitbit a lancé quatre nouveaux produits sur le marché qui ont été bien accueillis par consommateurs et expédié plus de 22 millions dappareils. La livraison de son plus grand nombre de produits en un an est en partie due à lengagement de lentreprise et à son succès dans ladoption de SAFe® (Scaled Agile Framework®) comme moyen de faire évoluer léquipe pour atteindre les dates cibles.
© Scaled Agile, Inc.
Voici le cours de laction Fitbit au cours des cinq dernières années:
Ouais… 2016 semble être une excellente année pour Fitbit.
Maintenant, nous ne pouvons pas vraiment attribuer la chute de Fitbit à SAFe adoption avec la quantité d’informations dont nous disposons.Mais si une entreprise peut lutter autant et saluer toujours ladoption de SAFe comme améliorant la réactivité de ses décisions concernant les produits, je vais rétrécir les yeux de quelques degrés de plus en consultant le reste des études de cas.
Cest bien une étape de transition, non?
Si vous êtes quelquun qui voudrait faire valoir cet argument, vous devez penser que SAFe doit être abandonné. Sur ce point, nous sommes daccord!
Pour effectuer cette transition, nous devrons bien sûr passer du temps à signaler les parties qui ne fonctionnent pas bien.
Est-ce quelque chose que vous passé beaucoup de temps?
Même si cest le cas, SAFe est configuré de manière à vous empêcher deffectuer réellement la transition. Lautorité quil place entre les mains de la direction agit comme une légitimation de la mentalité de contrôle descendant. Cela va mal avec le manque de méthodes damélioration des processus que nous avons déjà couvertes. Lautorité de « personnaliser » SAFe au contexte approprié nest généralement pas disponible pour les équipes les mieux placées pour reconnaître ce qui ne fonctionne pas.
Nulle part dans la feuille de route SAFe il ne fait référence à lun de ses pratiques de base en tant que transition. Sil sagit dun cadre de transition, il ne fournit aucun type de plan de transition.
Lhyper-focus sur les certifications nuit également à la flexibilité du framework . Si vous passez des heures et des heures à travailler pour obtenir la certification, la certification devient une partie de votre propre valeur. Une transition vers quelque chose qui ressemble moins à SAFe peut sembler menacer cette valeur. Je ne peux blâmer personne davoir obtenu la certification dans un marché de lemploi là où les certifications comptent. Mais ces personnes ont la responsabilité particulière de prêter attention aux inconvénients de SAFe et aux moyens possibles de laméliorer ou de sen écarter.
Ces problèmes sont largement vécus
Je ne suis pas le seul à exprimant nombre de ces critiques – même si jespère être allé un peu plus loin en les reliant aux pratiques spécifiques du cadre. Si vous cherchez des témoignages corroborants, en voici quelques-uns:
Ken Schwaber, co-développeur de Scrum a exprimé de sérieuses inquiétudes à propos de SAFe dès 2013.
Nicholas M. Chaillan , Directeur des logiciels de lUS Air Force, déconseille «dutiliser des cadres rigides et normatifs tels que Scaled Agile Framework (SAFe)».
Steve Denning, contributeur de Forbes, qualifie SAFe dêtre «particulièrement préoccupant» dans son article sur comment repérer les faux Agiles.
Marty Cagan du Silicon Valley Product Group explique comment SAFe est contraire à létat desprit des entreprises de la Silicon Valley.
Restez en sécurité là-bas (pas SAFe)
Alors que SAFe a certainement reçu beaucoup de critiques , mon sentiment personnel est que cette critique na peut-être pas atteint un large public au-delà de certains cercles en ligne. Cela est particulièrement probable si lon considère le nombre croissant dentreprises qui adoptent le cadre chaque jour.
Pour de nombreuses personnes, lidée quil y a quelque chose qui ne va pas avec SAFe – ou quelle est en conflit avec les principes Agile – peut être complètement nouveau.
Une discussion accrue visant un public plus large peut probablement aider. Jespère aborder ce sujet plus en détail à lavenir et détailler les autres alternatives disponibles.
Pour linstant, même si vous ne travaillez pas dans un environnement SAFe, ce nest pas une excuse pour être complaisant . Les préoccupations que jai exposées ici doivent être considérées comme un avertissement plus large – même les idées les plus sensées peuvent facilement être cooptées, corrompues et confuses si vous ny prêtez pas attention.