#8 Les points clés "Beware of SAFe"

Je suis très heureux de vous partager cet interview récent (10 Nov 2024) de Melissa Perri par la chaine Lenny’s Podcast, qui traite du sujet SAFe dans les entreprises, de son point de vue, et de sa vision vis à vis d’une organisation produit, et cela sans tabou 🔥

Dans cet interview de Melissa Perri, figure emblématique de la communauté Produit, partage son expérience sur l’adoption des méthodes agiles par les grandes entreprises, notamment à travers les frameworks à l’échelle comme SAFe (Scaled Agile Framework). Pour toute entreprise cherchant à moderniser son approche produit, ce retour d’expérience met en lumière les avantages et limites de ces méthodes, ainsi que les compétences essentielles pour évoluer vers une vraie culture produit. 🏢✨

Un framework agile rigide ne remplacera jamais une vraie stratégie produit. 🚀

Organisateur
Le podcast est animé par Lenny Rachitsky

Melissa Perri, est une Légende au sein de la communauté Prorduit : CEO de Product Institute et autrice d’ouvrages clés comme Escaping the Build Trap. Forte de son expérience dans les plus grandes entreprises, elle partage ses conseils pour réussir la transformation vers une culture produit.

De quoi parle-t-on ?

L’épisode aborde la manière dont les grandes entreprises, souvent non natives en technologie, adoptent des méthodes agiles pour mieux construire leurs produits. Melissa explique pourquoi certains frameworks, comme SAFe, sont populaires, mais peuvent poser problème lorsqu’ils sont appliqués.

Les différentes parties abordées

1. Origine des frameworks agiles ([00:00:06])
   Le Scaled Agile Framework (SAFe) a été conçu pour appliquer les principes de Scrum à grande échelle. Cependant, Melissa explique que bien souvent, les entreprises finissent par l'adapter profondément.

2. Les rôles de product owner et de product manager ([00:00:26])
   Le rôle de product owner en Scrum est avant tout de prioriser les tâches pour les développeurs, alors que celui de product manager est beaucoup plus stratégique.

3. Pourquoi SAFe est souvent mal utilisé ([00:26:36])
   Melissa critique la rigidité de SAFe, expliquant que, pour être efficace, ce framework devrait être modifié selon le contexte de l’entreprise.

4. Les problèmes de carrière liés aux rôles produits ([00:57:17])
   Elle aborde la confusion des titres et des carrières pour les product owners, qui aspirent à un rôle plus stratégique mais sont limités par la structure rigide de certains frameworks.

5. Importance de l'expérience produit au sein de la direction ([01:20:33])
   Melissa souligne que pour réussir une transformation digitale, il est essentiel que les entreprises intègrent la stratégie produit au niveau du C-suite.

6. Différences entre les entreprises tech et non-tech ([01:17:27])
   Enfin, elle rappelle que les entreprises SaaS et les grandes entreprises traditionnelles (banques, pharma) ont des besoins différents, et que copier les pratiques des géants de la tech sans les adapter n'est pas viable.

Pourquoi SAFe est souvent mal utilisé

SAFe est souvent mal utilisé car il est appliqué de manière rigide et standardisée, sans être adapté aux besoins spécifiques de l’entreprise ou à son contexte. Conçu initialement pour aider les grandes organisations à coordonner leurs équipes agiles à grande échelle, SAFe devient rapidement un poids lorsqu’il se transforme en une suite de processus bureaucratiques. Il tend à focaliser les efforts sur la gestion des processus (comme les sprints ou les réunions) plutôt que sur la création de valeur pour les clients. De plus, il sépare les rôles de product owner et de product manager, reléguant souvent les product owners à des tâches d’exécution, sans leur permettre de contribuer à la stratégie produit. Cette rigidité et cette surorganisation peuvent étouffer l’innovation, ralentir les cycles de développement, et détourner les équipes de l’objectif principal : construire des produits qui apportent une vraie valeur.

Gérer le budget (sans SAFe)

Melissa suggère d’abandonner le financement par projet au profit d’un financement par produit. Les équipes reçoivent un budget global pour expérimenter, construire et itérer en continu, sans être contraintes par des échéances rigides. Ce modèle permet de pivoter rapidement en cas de changement de priorités ou de marché. Les résultats (amélioration des métriques clés, satisfaction client, revenus) deviennent les principaux critères pour décider de poursuivre, ajuster ou arrêter un investissement. Enfin, la transparence budgétaire, associée à l’implication des équipes dans les décisions d’allocation, renforce leur engagement et leur efficacité.

Gérer les dépendances (sans SAFe)

Pour réduire les dépendances sans recourir à SAFe, Melissa Perry recommande de structurer les équipes autour de flux de valeur ou de produits spécifiques, et non autour de composants techniques. Ces équipes multidisciplinaires (design, développement, produit) doivent être autonomes et avoir tout ce dont elles ont besoin pour livrer des solutions de bout en bout. L’utilisation d’outils réutilisables, comme des API bien conçues ou des plateformes partagées, peut également diminuer les dépendances techniques. Enfin, une organisation claire des responsabilités évite les conflits, notamment en unifiant les rôles de product owner et product manager pour garantir une vision stratégique et opérationnelle cohérente.

PI Planning dans SAFe

Melissa Perry critique le PI Planning (Program Increment Planning) de SAFe, qui est souvent un élément central du framework, mais qui, selon elle, introduit des rigidités inutiles.

Le PI Planning est une pratique de planification trimestrielle ou semestrielle où toutes les équipes d’un Agile Release Train (ART) se réunissent pour planifier et synchroniser leurs tâches. Selon Melissa, ce processus pose plusieurs problèmes :

1. Rigidité excessive : Le PI Planning demande aux équipes de s’engager sur des livrables spécifiques pour toute une période, ce qui limite leur capacité à pivoter en fonction des retours clients ou des besoins émergents.

2. Focus sur l’exécution au détriment de la découverte : En remplissant les calendriers à l’avance, les équipes n’ont pas de temps pour la recherche utilisateur ou les tests d’hypothèses.

3. Complexité logistique : Rassembler de nombreuses équipes pour une planification de plusieurs jours peut être coûteux en temps et en énergie, surtout si la coordination est mal gérée.

Plutôt une planification agile, centrée sur la valeur

Melissa suggère une approche de planification plus légère et flexible, axée sur la création de valeur :

1. Cycles courts et ajustables : Plutôt que des engagements à long terme, les équipes devraient fonctionner par cycles trimestriels ou mensuels, en laissant une place à la découverte et à l’apprentissage continu.

2. Priorisation basée sur les résultats : Au lieu de planifier des livrables fixes, les équipes devraient définir des objectifs mesurables (OKRs) et ajuster leur travail en fonction des retours utilisateurs ou des données.

3. Synchronisation simple entre les équipes : Au lieu de réunions lourdes comme le PI Planning, elle recommande des rituels de synchronisation réguliers mais courts (exemple : revues trimestrielles ou rencontres inter-équipes ciblées sur les dépendances spécifiques).

Conseils pour appliquer une Culture Produit (vs appliquer un framework comme SAFe)

• Créer des équipes alignées sur les flux de valeur
  Organisez vos équipes autour des lignes de produits ou segments clients et non autour de composants techniques. Chaque équipe doit être responsable d’un produit ou d’un service qui apporte une valeur directe aux utilisateurs.

• Responsabiliser les équipes avec une autonomie complète
  Donnez à chaque équipe les moyens et l’autorité nécessaires pour prendre des décisions. Cela inclut un accès direct aux données des utilisateurs, aux métriques de performance, et aux outils nécessaires pour exécuter leur travail.

• Former des leaders produits forts
  Investissez dans des leaders expérimentés qui comprennent les besoins stratégiques et opérationnels du produit. Ces leaders doivent diffuser une vision claire et inspirer les équipes à adopter les bonnes pratiques.

• Intégrer la découverte produit dans le quotidien
  Encouragez les équipes à explorer et valider des hypothèses en permanence grâce à des entretiens clients, des tests utilisateurs et des expérimentations. Cette démarche permet d’éviter de travailler sur des solutions inutiles.

• Évaluer les résultats, pas les processus
  Mesurez le succès des équipes sur la base des résultats obtenus pour les utilisateurs et l’entreprise (ex. : adoption, revenus, satisfaction), et non sur la conformité aux cadences ou rituels agiles (comme les sprints ou les stand-ups).

• Simplifier les processus et les outils
  Adoptez uniquement les processus qui apportent une réelle valeur. Si un rituel ou un outil n’aide pas les équipes à mieux travailler ou à atteindre leurs objectifs, abandonnez-le ou simplifiez-le.

Ce qu’il faut retenir

L'adoption de frameworks comme SAFe dans les grandes entreprises doit être flexible pour réellement servir la culture produit. La clé de la réussite réside dans la capacité des équipes à adapter ces méthodes à leurs propres besoins, tout en s’assurant que les product owners acquièrent les compétences de product managers. Il est essentiel que la direction intègre pleinement la stratégie produit pour faire de cette transformation un véritable levier d’innovation et de croissance.

Pour Melissa Perry, le rôle de Product Owner tel qu’il est souvent défini manque de vision stratégique, étant trop focalisé sur la gestion de backlogs et l’exécution. Elle critique cette séparation entre Product Owner et Product Manager, qui limite l’impact du rôle sur la création de valeur. À ses yeux, le Product Owner devrait évoluer pour fusionner avec le rôle de Product Manager, devenant ainsi un acteur clé de la stratégie produit. Cela implique une autonomie accrue, l’accès direct aux utilisateurs et aux données, ainsi que des compétences en découverte et en analyse. Le but est de passer d’un rôle exécutant à un rôle stratégique, axé sur les résultats et la satisfaction des utilisateurs.