Les plus grosses erreurs de la transformation de la livraison vers Agile expliquées

Alors que les entreprises adoptent le cloud et des solutions logicielles hébergées, l’objectif de devenir plus « agiles » est souvent mis en avant. Cette aspiration devrait idéalement concerner l’ensemble de l’organisation et s’appliquer de manière uniforme.

En théorie, la transformation des processus pourrait être simple. Il est possible d’instaurer des rituels Scrum, de réassigner des employés à de nouvelles fonctions (comme Scrum Masters, Product Owners, Delivery Managers ou membres d’équipes Scrum).

Des outils tels que Jira, Azure ADO ou Miro peuvent être déployés et rendus obligatoires. Mais comment assurer la cohérence entre ces outils ? Comment faire évoluer l’état d’esprit, les comportements et les méthodes de travail ? Il est clair que ces changements ne s’opéreront pas de manière fluide et rapide. Penchons-nous sur les raisons de ces difficultés.

Qu’est-ce qu’une initiative de transformation de la livraison et pourquoi les entreprises l’adoptent-elles ?

Actuellement, un grand nombre d’entreprises fonctionnent selon un modèle de livraison en cascade. Cela implique les étapes suivantes :

Planification initiale du résultat final ou du produit, accompagnée d’une estimation du coût.

Début de la collecte des besoins, avec des discussions approfondies sur chaque détail du produit final, objections, questions, accords, nouvelles discussions et validations.

Estimation globale et validation des budgets prévus.

Conception de la solution, impliquant des réunions avec les parties prenantes, la création de documents et leur examen par ces dernières. Validation et approbation de la conception fonctionnelle et technique finale.

Mise en œuvre de la solution, correspondant au développement du produit final.

Phase de tests : tests unitaires, système, fonctionnels, d’intégration, de performance, de régression, d’acceptation utilisateur, et potentiellement d’autres en fonction de la culture d’entreprise. Documentation, examen et approbation par les parties prenantes.

Déploiement de la solution en production, où les utilisateurs ciblés commencent à utiliser le produit final.

Planification d’une phase de support pour corriger les éventuels bugs.

Ce processus peut s’étendre de quelques mois à plusieurs années. Les utilisateurs ne voient le résultat final qu’à son terme. Après cette longue attente, le moment de la vérité (ou de l’échec) arrive.

Si le produit final doit être modifié pendant ce long processus, on parle de demande de modification. La conception doit être réexaminée, retravaillée et validée de nouveau, ce qui allonge le calendrier du projet.

Il est évident que ce processus n’est pas agile. Tout changement implique de recommencer l’ensemble du processus.

Passage à l’Agile

Comment sortir de ce cadre et adopter l’agilité ? Les équipes fonctionnent en mode cascade depuis des décennies, voire des siècles. Elles ont des rôles et des responsabilités définis avec lesquels elles sont à l’aise et sont réticentes au changement. La principale raison est que ce changement implique souvent une perte de pouvoir.

C’est pourquoi ce type de changement génère une résistance importante.

#1. Restructuration des équipes

La première étape, relativement simple, est la restructuration des équipes en équipes Scrum, en fonction des domaines fonctionnels ou d’une autre division logique.

La division se déroule généralement sans difficultés ; le problème émerge lorsque l’on constate que les personnes sont toujours rattachées aux structures d’origine. Même si elles font partie d’une nouvelle équipe Scrum, elles n’y sont pas entièrement intégrées. Elles travaillent encore selon l’ancienne configuration car elles ont toujours des responsabilités non transférées lors de la restructuration des équipes. Les responsables se soucient davantage des nouvelles tâches à démarrer que de celles qui doivent être terminées.

Ainsi, l’équipe Scrum n’est pas une équipe dédiée à 100%. Elle est composée de personnes qui ont toujours des tâches en cours. Le temps consacré aux travaux de l’équipe Scrum est moindre que celui attendu par les responsables.

Dans le même temps, les employés doivent réaliser les tâches initiales et les nouvelles activités au sein des équipes Scrum. Cette situation est vouée à l’échec dès le départ.

#2. Planification des cérémonies Scrum

Il est facile de demander aux équipes de planifier des appels réguliers (cérémonies de sprint). Du moins, en supposant que les équipes Scrum ne soient pas dispersées sur plus de trois fuseaux horaires (ce qui est fréquent).

Les difficultés commencent lorsque les employés ne participent pas régulièrement aux cérémonies. L’absentéisme, en fonction des personnes et de la fréquence, peut entraîner différents problèmes. Par exemple :

Si les Product Owners sont absents lors des cérémonies de planification et de raffinement, l’équipe n’a pas de nouvelles tâches. Ou la description des tâches est si floue que le reste de l’équipe ne peut pas les réaliser.

Si les Scrum Masters manquent les réunions, l’équipe n’a pas d’encadrement Scrum et risque de se perdre avec le temps.

Si les développeurs sont souvent absents, ils ne peuvent pas se coordonner et la communication devient plus difficile. Des réunions supplémentaires sont alors nécessaires pour rattraper le retard, ce qui engendre une perte de temps.

En fin de compte, ces absences ne sont pas toujours dues à la négligence des employés. L’organisation ne leur permet pas de participer aux réunions (voir ci-dessus les affectations parallèles).

#3. Stabilité de l’équipe

Une équipe Scrum peut avoir une structure et des cérémonies. Mais si elle n’est pas stable pendant une période prolongée (idéalement au moins six mois, voire un an selon mon exigence personnelle), elle ne progressera pas et ne s’améliorera pas réellement.

Dans ce cas, il est peu probable que l’équipe Scrum devienne autonome et qu’elle gère les sprints de manière autonome. Il faudra constamment former et éduquer les membres de l’équipe pour qu’ils comprennent les principes et processus Scrum. C’est un problème chronophage.

Ce problème est souvent sous-estimé, notamment par la direction. Considérer les employés comme de simples « ressources » et planifier leur « utilisation » d’un trimestre à l’autre est un mauvais choix.

#4. De nouveaux rôles pour les mêmes employés

Un autre obstacle est la réaffectation des personnes à de nouveaux rôles. Les personnes qui dirigeaient auparavant les équipes avec un pouvoir décisionnel peuvent devenir Product Owners, par exemple. Ce rôle est important dans une équipe Scrum, mais peut être perçu comme une dégradation par rapport à la configuration existante.

Les Product Owners doivent collaborer avec le Scrum Master ou les Program Managers. Ils sont toujours responsables du contenu, mais moins des processus de livraison. Cette situation implique de renoncer à des responsabilités antérieures, ce qui est difficile à accepter.

#5. Méthodes de travail

Cette question revient fréquemment : nous devons apprendre de nouvelles méthodes de travail pour rester compétitifs sur un marché en constante évolution où l’agilité est essentielle. Mais que signifie réellement cette expression « nouvelles méthodes de travail » ?

De mon point de vue, l’objectif des responsables est clair : accomplir (beaucoup) plus en moins de temps. Après la mise en place des équipes Scrum, on s’attend à ce que chaque membre produise des résultats concrets et documentés au quotidien. Si ce n’est pas le cas, les responsables s’interrogent sur l’efficacité du processus agile.

Les responsables s’attendent à ce que chaque heure compte et à ce que les équipes Scrum n’aient pas de temps mort, car il n’y a probablement pas de temps pour mettre en place tous les processus Scrum. Voici, en résumé, la signification des « nouvelles méthodes de travail » du point de vue des dirigeants.

Cette attente est irréaliste. S’attendre à ce que les employés de l’entreprise travaillent plus dans le même laps de temps, simplement parce que certains processus ont changé, est une illusion. Bien sûr, certains employés pourraient augmenter leur productivité, même si cela reste une minorité. Mais même ceux-ci sont vite submergés par les tâches supplémentaires.

Écart entre l’objectif et la réalité

Il est indéniable que la description de l’objectif final est pertinente et logique. Elle s’articule autour des principes suivants :

Des équipes Scrum stables travaillant sur des arriérés indépendants, avec des KPI et des OKR clairs.

Les Product Owners doivent élaborer des feuilles de route solides et planifier un contenu hiérarchisé pour respecter des délais précis.

Contenu de l’arriéré défini avec des fonctionnalités détaillées avant le début des travaux.

Processus de test fiables exécutés en parallèle des activités de développement de sprint.

Mises en production régulières, au moins une fois par mois, idéalement à la fin de chaque sprint.

Suivi des risques et problèmes, communication entre les équipes Scrum en cas de dépendances.

Cependant, en réalité, aucun de ces points n’est facile à atteindre.

Les équipes Scrum sont formées, mais leur composition change constamment (d’un trimestre à l’autre). On investit du temps pour former les équipes aux processus Scrum, et dès qu’elles commencent à adopter ces nouvelles méthodes, on réorganise les équipes pour la période suivante. Les feuilles de route sont modifiées, reportées ou annulées.

Les Product Owners n’ont pas de vision claire des détails de la feuille de route. Par habitude, ils délèguent les tâches de création du contenu de l’arriéré directement à l’équipe. Par conséquent, l’équipe n’a pas le temps de développer le contenu car elle doit déterminer au préalable ce qu’elle doit développer.

Les tests sont uniquement manuels et nécessitent des sous-étapes, des validations et des processus complexes. Il est donc impossible de les terminer lors du même sprint que le développement.

Par conséquent, la mise en production est retardée de plusieurs sprints.

La communication entre les équipes Scrum est désorganisée et inefficace. Chaque équipe a de nombreuses activités à réaliser lors de chaque sprint. Les Product Owners ont tendance à surcharger l’équipe en tâches. L’équipe est incapable de tout réaliser et est constamment stressée par les délais.

Correction des erreurs

Fort de mon expérience dans des projets de transformation agile, je souhaite résumer certaines des plus grandes erreurs que j’ai rencontrées et donner mon avis sur la manière de les surmonter.

#1. Des responsabilités adaptées aux rôles

Si vous essayez de modifier la définition des rôles et de répartir les responsabilités d’une manière différente que prévu par Scrum/Agile, l’initiative est vouée à l’échec.

Les Product Owners doivent être responsables du contenu et de la gestion de l’arriéré. Ils sont responsables des retards et doivent agir pour les résoudre. Ils ne doivent pas avoir d’influence sur l’affectation des membres de l’équipe Scrum ou sur les décisions relatives au budget du projet.

Les Scrum Masters ne sont pas responsables du contenu de l’arriéré. Ils sont chargés d’orchestrer les cérémonies et de former l’équipe aux méthodes de travail agiles. Ils ne doivent pas être le secrétaire des Product Owners. Au contraire, ils doivent protéger l’équipe de développement du Product Owner et des parties prenantes externes.

Chaque équipe Scrum doit avoir un responsable de la livraison. Cette personne fait le lien entre le Product Owner, le Scrum Master et l’équipe de développement dans une configuration viable. Elle définit les processus de livraison et résout les risques, problèmes ou conflits potentiels. Le responsable de la livraison est la personne idéale pour décider des questions de personnel et de budgétisation du projet. Elle doit créer un environnement où chacun peut donner le meilleur de soi-même.

L’équipe de développement est chargée de développer les tâches à partir de l’arriéré. Elle peut aider le Product Owner à créer du contenu pour certaines tâches (principalement techniques), mais elle n’est pas responsable ni imputable de la création du contenu de la feuille de route.

#2. Équipe stable

Investir dans la formation agile de l’équipe est important et doit être un processus rapide. La perte de ces connaissances après quelques mois est une perte de temps pour tout le monde.

Les cinq premiers sprints peuvent servir de phase d’apprentissage pour que l’équipe se familiarise avec les activités Scrum de base. Une fois ces notions acquises par l’ensemble de l’équipe, le processus d’amélioration continue peut commencer. Mais si les membres de l’équipe changent régulièrement, vous vous retrouverez dans un cycle constant de transferts de connaissances et de formation.

Cette équipe n’atteindra probablement jamais son plein potentiel et la direction se demandera pourquoi elle était plus performante avant la transformation agile.

Il est donc essentiel de construire l’équipe, d’investir dans les connaissances et, une fois que l’équipe est à l’aise avec les nouveaux processus, de maintenir sa composition et de la faire progresser. C’est le début du chemin vers la perfection.

#3. Matrice RACI

Il est recommandé d’établir et de valider la matrice RACI (Responsable, Accountable, Consulted, Informed) entre toutes les équipes avant le démarrage des activités. Cela peut éliminer une grande partie de la confusion dès le début.

C’est essentiel, surtout lors des premières étapes des initiatives de transformation. Sans cela, les employés se poseront des questions sur leurs responsabilités dans chaque situation, notamment celles qui n’ont pas été explicitement abordées lors des communications de l’équipe.

Voici un exemple de matrice RACI pour certaines responsabilités. Votre projet peut avoir un ensemble différent. L’important est de prendre en compte les responsabilités les plus pertinentes.

Tâche	Demandeur	Responsable de la livraison	Product Owner	Scrum Master	Équipe de développement
Sessions de planification de sprint	C/I	A/I	R	C/I	I
Livraison de l’incrément de release	N/A	A/I	I	C/I	R
Revue de sprint	C/I	I	R	I	S
Rétrospective de sprint	I	I	A/I	R	C/I
Affiner l’arriéré	I	A/I	R	C/I	I

Conclusion

Il y aurait encore beaucoup à écrire car il existe de nombreux obstacles qui peuvent faire échouer une transformation agile. L’objectif était de souligner certains problèmes qui, selon moi, se répètent fréquemment.

L’initiative en elle-même est une bonne idée. Cependant, elle peut vite devenir un cauchemar pour tous les participants si certaines règles fondamentales ne sont pas respectées. J’en ai souligné quelques-unes, mais faites preuve de bon sens et tout devrait bien se passer. 🙂

Enfin, consultez les bonnes ressources d’apprentissage pour la certification Agile.