Scaled Agile Framework (SAFe) : est-il si parfait ?

Le développement logiciel agile semble avoir toujours existé. En réalité, la publication du Manifeste Agile remonte seulement à 2001. Le mouvement Agile a atteint ses objectifs. Il a transféré les pouvoirs et les responsabilités de la direction aux développeurs.

Aujourd’hui, le cadre SAFe – pour « Scaled Agile Framework » représente une tentative d’appliquer les principes d’Agile à grande échelle. Les principes de SAFe ont tout l’air d’être une extension logique d’Agile. Cependant, SAFe a été critiqué par des adeptes d’Agile de longue date, comme Ken Schwaber.

Les critiques de SAFe opposent trois objections principales à ce cadre :

1. une mauvaise compatibilité avec les équipes de production et d’assistance
2. une dette technique accrue
3. une dépendance excessive à la standardisation des points de scénario

Cet article propose une vue d’ensemble de SAFe.Il explique les problèmes soulevés par les critiques et aborde les solutions disponibles. Il aborde également la façon d’appliquer SAFe aux niveaux du portefeuille et du programme. Enfin, vous apprendrez à utiliser Release Dynamix [RDx] de Panaya pour la mise en œuvre et la gestion de SAFe dans votre organisation.

Qu’est-ce que SAFe ?

SAFe met en application les douze principes du Manifeste Agile au niveau de l’entreprise.

Parmi ces douze principes, on retient notamment :

• donner la priorité à la satisfaction de la clientèle en livrant en continu des logiciels qui apportent de la valeur
• tenir compte de la nature changeante des exigences des parties prenantes
• travailler en cycles courts et fixes

En résumé, ce cadre part des éléments clés du travail agile et les traduit en neuf nouveaux principes :

1. comprendre la valeur économique et métier d’un projet,
2. prendre des décisions à l’aide d’une approche méthodique,
3. prendre en compte les changements potentiels lors de la planification,
4. développer les produits par petites étapes,
5. définir des objectifs et délais réalistes,
6. limiter le plus possible la taille des lots,
7. travailler à un rythme constant (cycle de développement),
8. comprendre les besoins réels des parties prenantes,
9. décentraliser le processus de prise de décision.

Prenant appui sur ces fondements, SAFe a été créé pour fournir un cadre efficace au développement des projets basés sur les logiciels dans les grandes entreprises. Pour y arriver, il centralise le contrôle global du processus de développement sous la structure de direction de la société. Cela permet notamment aux grandes organisations de planifier à long terme. Elles peuvent synchroniser et coordonner les efforts à travers leur entreprise. Elles peuvent définir et atteindre leurs objectifs en matière de délais de mise sur le marché.

Pour vraiment comprendre SAFe, il suffit de s’intéresser à la façon dont il a aidé EdgeVerve Systems et Fitbit.

EdgeVerve Systems a constaté des améliorations majeures dans l’année suivant la mise en œuvre de SAFe. Ce cadre agile a permis de réduire le temps de déploiement des petits et grands produits à respectivement trois et six mois. SAFe a aidé EdgeVerve à détecter et résoudre les défauts plus tôt dans le cycle de développement du produit. Cela a permis de réduire le nombre de défauts de leurs versions logicielles et d’améliorer la satisfaction de la clientèle.

Fitbit a également intégré SAFe avec succès afin de créer des workflows transparents à travers l’ensemble de son écosystème logiciel et matériel. Fitbit a pu ainsi coordonner plusieurs équipes. Cela a permis de mettre en place un processus de développement et de déploiement aussi rapide que flexible. SAFe a fourni des mécanismes permettant de traiter les problèmes complexes de façon transversale en englobant toutes les équipes. En appliquant le Scaled Agile Framework, Fitbit a pu s’améliorer sur tous les fronts :

• Tâches en souffrance
• Dépendances inter-équipes des programmes
• Sécurité
• Conformité
• Marketing

SAFe : problèmes et solutions

En résumé, SAFe est « toujours Agile, mais en plus grand ». Dans ce cas, pourquoi de nombreux développeurs agiles se montrent-ils aussi critiques ? Pour comprendre pourquoi, penchons-nous à nouveau sur les trois objections que nous avons soulevées plus haut.

Une mauvaise compatibilité avec la production et l’assistance

Le développement agile a été créé par des développeurs. Il a été conçu pour résoudre de nombreux problèmes qu’ils rencontraient avec les processus en cascade. Si les approches agile et en cascade diffèrent dans leur façon de gérer la planification de projet, toutes deux s’appuient sur une planification basée sur un planning. Les services d’informatique d’entreprise, de production et d’assistance ont un fonctionnement différent. Ceux-ci se concentrent sur la gestion de la charge de travail au quotidien.

La charge de travail de l’équipe de production comprend souvent le traitement de tâches habituelles ou planifiées. Elle implique de s’occuper des événements imprévus et de travailler sur plusieurs projets à la fois. Le temps est limité et loin d’être suffisant compte tenu de la portée de la planification des versions qu’Agile nécessite.

L’équipe d’assistance peuvent envoyer un représentant à une réunion de planification de version, mais elle est souvent réticente à s’impliquer ou incapable de le faire. Surtout, elle n’a aucun contrôle sur ses tâches en souffrance. Si c’était le cas, les utilisateurs qu’elle assiste seraient certainement très contrariés. De plus, contrairement aux développeurs qui peuvent gérer leur propre emploi du temps, l’équipe d’assistance doit être disponible constamment, souvent 24 heures sur 24, sept jours sur sept.

La solution SAFe

Envisagez le DevOps comme solution. L’approche DevOps allie le développement et la production en automatisant les tâches de production courantes grâce à du code écrit. Les pratiques DevOps comprennent l’automatisation des tests, le contrôle des versions distribué ainsi que l’intégration, la livraison et le déploiement continus.

Une dette technique accrue

La dette technique fait partie de ces choses difficiles à définir. Pourtant, la plupart d’entre nous la reconnaissons lorsque nous la voyons. Dans le contexte de cet article, définissons-la comme l’accumulation de problèmes non résolus tout au long de la durée de vie d’un projet. Face aux situations difficiles, la plupart des gens essaient de retarder au maximum la prise de décision. La gestion de la dette technique d’un seul projet est une lutte constante. Cependant, si une équipe a conscience du problème, elle peut le prendre en charge grâce à des mesures collectives.

Dans un environnement SAFe, la responsabilité de la résolution de la dette technique est centralisée au sein de la direction de l’organisation. Cette centralisation peut être très bénéfique pour certains types de dette technique. C’est notamment le cas lorsque la dette découle des pressions exercées par les clients ou le marché, ou des politiques de l’entreprise relatives à l’allocation du temps, des ressources et du budget. Ces types de dette peuvent être résolus à l’aide d’une approche à haut niveau, ascendante et descendante.

Cependant, la centralisation n’est pas une bonne approche pour résoudre la dette technique apparue au niveau d’une équipe. Ce type de dette a des causes très précises : par exemple, une équipe de développement qui ne comprend pas les conséquences à long terme des décisions à court terme. Ce type de dette apparaît également dans les équipes instables ayant un taux de rotation élevé. La direction de l’entreprise doit jouer un rôle actif dans la résolution de la dette technique localisée. Autrement, un problème de dette de plus grande ampleur et plus difficile à résoudre émerge et devient plus toxique au fil du temps.

La solution SAFe

Le meilleur moyen de gérer ce type de dette technique est de suivre les principes d’Agile. Par exemple, déléguez les décisions de résolution des problèmes aux équipes chargées du développement et des tests logiciels. Donnez à ces équipes le pouvoir de définir leurs propres délais et de mesurer leur cadence de travail.Elles se sentiront responsables de leur travail et seront en mesure de traiter les problèmes au fur et à mesure qu’ils surviendront.Vous devriez créer une culture d’honnêteté et d’ouverture d’esprit afin d’encourager les employés à identifier, évaluer et résoudre la dette technique et tout problème lié à celle-ci.

La direction peut jouer un rôle important dans la gestion de la dette technique. Par exemple, en écrivant des critères standard d’acceptation et de sortie. La direction devrait définir avec clarté ce que l’on considère comme « terminé », et appliquer systématiquement cette définition dans tous les projets.La direction devrait également agréger des données issues des équipes individuelles et créer des systèmes en ligne offrant à tous une visibilité sur ces données.

Standardisation des points de scénario

L’estimation du temps que prendra une tâche particulière est un problème qui n’a jamais été résolu. La solution traditionnelle consiste à essayer de calculer le nombre de jours-personne nécessaires à la mise en œuvre d’un seul scénario utilisateur. Un chef de projet peut estimer que l’effort de mise en œuvre d’un scénario utilisateur nécessite un jour-personne. Il convient de noter que le nombre de jours-personne indique l’effort absolu nécessaire à l’exécution de la tâche. En d’autres termes, le chef de projet pourrait affecter deux développeurs à la tâche pour l’effectuer en deux fois moins de temps, mais l’effort global nécessaire resterait un jour-personne.

On reproche souvent à l’estimation basée sur l’effort de ne pas prendre en compte la complexité ou la difficulté de l’exécution de la tâche. À la place, le monde Agile (dont SAFe) a adopté les points de scénario.

Un point de scénario constitue une mesure de l’effort de mise en œuvre d’un seul scénario utilisateur qui prend en compte des facteurs supplémentaires. Par exemple, l’effort, la difficulté, la complexité et les risques. Les points de scénario sont exprimés sous la forme d’une valeur sur une échelle abstraite, comme une séquence de nombres, des tailles de T-shirt (S, M, L, etc.) ou la suite de Fibonacci. Par exemple, on peut utiliser une échelle de 1 (facile) à 5 (difficile), dont chaque chiffre correspond à un jour-personne d’effort. Ainsi, une tâche qui prend un jour-personne d’effort équivaut à un point de scénario.

Dans un environnement SAFe, la définition des points de scénario est confiée à la direction. Par conséquent, l’échelle utilisée pour mesurer l’effort devient plus abstraite et, pour faire simple, inutile. Elle donne également aux équipes individuelles l’impression qu’elles n’ont aucun contrôle sur le processus de développement ni aucune responsabilité vis-à-vis de ce dernier.

La solution SAFe

L’une des solutions les plus importantes consiste à donner aux équipes de développement l’autonomie dont elles ont besoin. Cela implique de leur faire confiance en leur permettant de définir leurs propres indicateurs. Les équipes de développement devraient pouvoir décider par elles-mêmes des actions à effectuer. La direction devrait également apprendre aux équipes à utiliser la vitesse comme un guide et non comme une mesure de la productivité et de la réussite. Là encore, la direction peut jouer un rôle important en éduquant et en formant les employés pour leur faire comprendre les pratiques de gestion de projet modernes et agiles.

Mettre en œuvre SAFe au niveau du portefeuille

Dans le contexte du cadre SAFe, c’est au niveau du portefeuille que la direction peut vérifier l’alignement de la stratégie d’entreprise avec l’exécution du portefeuille. Pour y arriver, il faut créer des chaînes de valeur claires qui facilitent la compréhension de l’investissement dans toute initiative donnée.

Le niveau du portefeuille SAFe rend compte des équipes et processus nécessaires au développement des solutions dont l’entreprise a besoin pour atteindre ses objectifs stratégiques. Il peut y avoir plusieurs portefeuilles SAFe dans une même entreprise.

Chaque portefeuille SAFe identifie les thèmes stratégiques du portefeuille qui le guident à travers l’évolution des objectifs métier et génère un flux constant de retours du portefeuille vers les parties prenantes de l’entreprise. Ces retours portent notamment sur :

• l’état actuel des indicateurs de performance clé de la chaîne de valeur des solutions du portefeuille,
• des évaluations qualitatives de l’adéquation de la solution actuelle avec sa mission.

Grâce aux mécanismes de gouvernance basiques nécessaires, notamment en matière de budget, la direction peut s’assurer que ses investissements dans des solutions apporteront le retour sur investissement (ROI) dont l’entreprise a besoin pour atteindre ses objectifs stratégiques.

Mettre en œuvre SAFe au niveau du programme

C’est au niveau du programme que la direction affecte les équipes de développement, les utilisateurs métier et d’autres ressources dédiées à une mission permanente de développement d’une solution. Toutes les ressources affectées à un seul programme sont prises en compte dans le train de livraison agile, l’ART (pour « Agile Release Train »). L’ART comprend également les équipes, rôles et activités au niveau du programme qui livrent un flux de valeur continu par étapes progressives. En général, un programme dispose de dates de début et de fin définitives et de ressources affectées de façon temporaire.

Cependant, les ART ont une longue durée de vie et, par conséquent, disposent d’une auto-organisation, d’une structure et d’une mission plus persistantes qu’un programme traditionnel. Les ART sont des organisations virtuelles formées pour éliminer les transferts et étapes inutiles. Ils permettent d’accélérer la livraison de valeur grâce à la mise en œuvre des pratiques SAFe.

Conclusion : faire fonctionner SAFe

À l’origine, le développement agile était une initiative concrète, créée par des développeurs pour des développeurs. Son adoption rapide s’explique notamment par le fait qu’il a décentralisé la prise de décision, donnant ainsi aux développeurs l’autonomie nécessaire pour prendre des décisions et agir sur la base de celles-ci de façon sensée.

SAFe est une tentative de tirer des enseignements du mouvement Agile. Optimisez la gestion de projet, la coordination et la prise de décision en les centralisant. L’un des nombreux avantages de SAFe provient de l’utilisation de la gestion de la chaîne de valeur, qui permet de mieux comprendre la valeur de ce que l’on développe et le temps nécessaire à chaque version.

Quelle que soit la façon dont vous conciliez les exigences d’Agile et de SAFe, Release Dynamix de Panaya [RDx] vous fournit les outils nécessaires à vos déploiements agiles et SAFe et les fait travailler pour vous. Contrairement à d’autres produits de gestion des versions, RDx a été conçu de A à Z pour gérer la livraison agile en entreprise à grande échelle. Il vous permet de suivre l’ensemble du processus de développement et de gérer votre portefeuille, votre train de livraison de projets et de versions, vos chaînes de valeur, vos spécifications, vos tests et vos risques. Il recueille également des données, affiche des indicateurs et des tableaux de bord. RDx génère des rapports qui vous apportent des renseignements exploitables et analyses essentiels.

Comme de nombreux cadres normatifs, la plupart des problèmes liés à SAFe proviennent d’une application trop rigide et d’un manque d’adaptation de ses principes aux besoins d’une organisation donnée. Au final, il est plus important de trouver la bonne solution que de respecter scrupuleusement les principes d’une méthode.

Release Dynamix de Panaya [RDx] peut vous aider à mettre en œuvre les éléments à la fois d’Agile et de SAFe qui répondent au mieux aux besoins et objectifs de votre tâche précise, que ce soit au niveau du programme, du projet ou du portefeuille.