Une méthodologie Waterfall déguisée en framework Agile
Auteur : Paweł Huryn
Source : A waterfall methodology masquerading as an Agile framework
Date : 20/05/2024
Traducteur : Fabrice Aimetti
Date : 20/05/2024
Traduction :
Je ne comprends pas ce phénomène. Chaque fois que je vois cette image, quelque chose meurt en moi ☹️
Une méthodologie en Waterfall qui se fait passer pour un framework Agile. Inapplicable pour le Product Management moderne.
Et pourtant, les entreprises continuent de la prendre au sérieux.
Ne soyons pas dupes. SAFe (Scaled Agile Framework) 6.0 est un nom marketing pour le Waterfall à grande échelle et le contrôle des personnes avec un processus lourd.
Des expressions comme "Design Thinking", "Lean UX" ou "Scrum" ne sont que de la poudre aux yeux.
En bref, voici comment cela se passe :
Le waterfall des exigences
Dans le domaine des produits, nous comprenons que les équipes autonomes se voient confier des problèmes pertinents à résoudre et qu'elles sont tenues responsables des résultats.
Mais dans SAFe, chaque trimestre, les équipes se réunissent pour deux jours de "PI planning". L'objectif est de s'engager sur des fonctionnalités spécifiques pour les 3 mois à venir.
Une usine à fonctionnalités (feature factory).
La dichotomie PM vs PO
Product Owner n'est pas un titre de poste.
Je considère la séparation des rôles comme l'un des pires anti-modèles du Product Management.
Mais dans SAFe, les Product Owners passent de longues heures à rédiger des spécifications détaillées et n'ont même pas besoin de parler aux utilisateurs :
"Les clients (...) peuvent avoir des relations directes ou indirectes avec le PO." - Scaled Agile, Inc.
Des administrateurs de backlog.
Une équipe d'exécutants
Dans le domaine des produits, nous comprenons que pour que la Product Discovery fonctionne, nous avons besoin d'une collaboration pluridisciplinaire (alias "trio produit").
Mais dans SAFe, les ingénieurs sont largement déconnectés du discovery. Les Product Managers effectuent une découverte en waterfall pour remplir le backlog de l'ART avec du travail pour le prochain trimestre.
Les ingénieurs et les designers ne sont même pas considérés comme des "collaborateurs clés" dans le Product Management.
Des ingénieurs indignes de confiance
Dans No Rules Rules, Reed Hastings et Erin Meyer soulignent l'aspect le plus critique de la culture de Netflix - diriger avec le contexte et non le contrôle.
Mais selon SAFe, on ne peut pas faire confiance aux ingénieurs en tant que professionnels. Le Product Owner revoit et approuve leur travail et s'assure que ce qu'ils ont fourni n'est pas un travail bâclé.
C'est dangereux et toxique.
Suivre le plan
SAFe prétend découper le trimestre en itérations. Mais l'objectif principal de "l'inspection et de l'adaptation" dans chaque sprint est de s'assurer que tout le monde suit le plan et que les fonctionnalités engagées sont livrées.
Ils recommandent ce qu'ils appellent un "Train de Livraison Agile" (Agile Release Train).
Avez-vous déjà vu un train agile ?
Conclusion
À la fin de la journée, les managers sont ravis.
Ils ont donné beaucoup d'argent à des consultants, la transformation a été rapide comme l'éclair. Ils n'ont pas à changer quoi que ce soit d'important, mais ils peuvent maintenant se dire "Agile".
Ce n'est pas une coïncidence si aucune organisation produit innovante et performante (Meta, Google, Airbnb, Dropbox, Uber, Apple, etc.) n'utilise cette méthode.
Aucun mot à la mode ne peut cacher sa véritable nature.
Qu'en pensez-vous ? Quelqu'un l'utilise-t-il encore ?
Faites-le moi savoir dans les commentaires.
P.S. Ça vous a plu ?
Consultez mon article complet et gratuit contenant l'analyse en profondeur : https://lnkd.in/dS2c-gkc
