Les années passent et l’Agilité est toujours là. Son déploiement est désormais généralisé, ou presque. Bien sûr tout n’est pas rose. Toute technologie, solution ou produit qui vit un tel niveau de massification augmente son risque d’être mal utilisée, détournée, mal comprise. Je ne blâme personne, il me semble que c’est la logique des choses.
Cependant, toutes ces années de mise en place de l’Agilité au sein des équipes, dans des organisations si différentes et commentées par de nombreux(ses) conférencier(e)s m’amènent aujourd’hui à vous partager cette liste d’erreurs, de facteurs d’échec, de risques, bref des éléments qui vont exercer des contraintes sur votre Agilité.
Pour plus de clarté, j’ai classé ces éléments par thèmes, mais il en existe d’autres qui peuvent être précieux pour vous. Si vous en connaissez, n’hésitez pas à nous écrire à contact@supertilt.fr pour les ajouter à l’article.
Je réutilise volontairement une terminologie issue de SCRUM car les rôles, outils et rituels sont désormais passés dans le vocabulaire agile commun.
Management
- Ne pas faire confiance à l’équipe ou à l’Agilité, continuer à faire du micromanagement
- Blâmer l’agilité car les résultats ne sont pas à la hauteur
- Casser/brider arbitrairement les initiatives agiles ou le déroulement de l’agilité
- Ignorer les meilleures pratiques agiles connues et documentées
- Détruire les croyances agiles de l’équipe sans comprendre comment elles se sont construites
Equipe
- Échouer à chaque fin d’itération à livrer ce que l’équipe s’était engagée à faire
- Reporter systématiquement le travail non-fait d’une itération à l’itération suivante (version encore pire : sans informer le Product Owner)
- Ne pas créer d’équipe pluridisciplinaire (par exemple : les développeurs travaillent isolément des testeurs, etc.)
- Penser qu’un gros projet a besoin de grandes équipes même s’il est reconnu que plus la taille de l’équipe est importante, plus la productivité décroit
- Rester sur les théories d’Agilité ou des méthodes, sans tenir compte de la réalité et des besoins du contexte
Product Owner
- Ne pas communiquer la vision du produit à l’équipe et aux sponsors
- Ne pas faire attention à l’avancement réel de chaque itération et ne pas évaluer objectivement la valeur de ce progrès
- Définir le contenu des itérations
- Remplacer un document de planning avec un plan dans la tête que vous seul(e) connaissez
- Avoir une seule personne qui agit en tant que Product Owner (qui travaille sur le produit) ET Scrum Master (qui accompagne son équipe)
Processus
- Personnaliser un processus agile sans avoir terminé au moins un ouvrage de référence sur le sujet
- Supprimer et personnaliser des processus agiles sans maîtriser leur compréhension et les impacts humains
- Suivre des pratiques agiles sans comprendre les principes
- Ne pas améliorer en continu
- Ne pas changer les pratiques techniques
- Se convaincre qu’on peut faire tout le travail demandé donc que l’ordre importe peu
Thème Maître Agile (ou Scrum Master si vous êtes en Scrum)
- N’avoir personne dédiée à l’animation de l’Agilité de l’équipe
- Forcer une personne à prendre le rôle d’animation agile de l’équipe
- Faire tourner les membres d’une équipe jeune sur l’Agilité pour assumer l’animation agile
- Changer le titre “chef de projet” en “Scrum Master”
- Donner un titre de Scrum Master à un membre d’une équipe qui ne fonctionne pas du tout en Scrum
Que faire de tout ça ?
Établir cette liste n’est pas suffisamment constructif à mon goût. Elle prendra son sens si elle devient autre chose qu’une collection de constats. C’est pour cela que je vous invite à faire en équipes l’un des exercices suivants lors de votre prochaine rétrospective ou sur un temps collectif créé spécialement pour l’occasion :
Loto des erreurs :
Imprimez la liste et distribuez-la à chaque membre de l’équipe. Pour chaque ligne, chacun(e) a le choix suivant :
- Rayer la ligne car l’erreur n’a aucun sens chez vous
- Laisser la ligne telle quelle car vous estimez qu’elle est valable chez vous
Dans l’intérêt de l’exercice, ne commencez à débriefer collectivement que lorsque chacun(e) a terminé la mise à jour de sa liste.
Partagez vos résultats entre vous et entamez une conversation libre sur les zones de convergence et de divergence que vous observez.
À la fin, une action concrète à mener par l’équipe doit émerger.
Priorisation des erreurs :
Écrivez chaque erreur sur une carte et classez-les avec les erreurs ayant le plus d’impact chez vous en haut et les moins impactantes en bas.
Une fois le classement établi, discutez en équipe de ce que votre classement fait ressortir et des pistes d’actions que votre équipe doit imaginer pour la prochaine itération.
La longue liste
Répartissez l’équipe en sous-groupes. Chaque sous-groupe aura en charge l’un des thèmes. Donnez à chaque sous-groupe la mission de trouver un maximum d’erreurs en lien avec le thème. Définissez un temps suffisant pour mener cette réflexion. Chaque sous-groupe est ensuite invité à restituer aux autres leurs trouvailles. Certaines erreurs devraient faire écho à certains aspects
Les bons conseils
Afficher la liste des erreurs en grand face à l’équipe. Définissez un temps de travail et trouver un bon conseil pour chaque erreur nommée. Concluez la séquence par les grands apprentissages que ce moment vous a apportés.
Pour conclure, bien que l’Agilité soit désormais largement adoptée dans de nombreuses organisations, cela ne signifie pas pour autant que son déploiement soit exempt d’erreurs, de facteurs d’échec et de risques. La liste d’erreurs présentée dans cet article, peut vous donner des pistes de réflexions d’actions concrètes à envisager pour améliorer votre pratique de l’Agilité. N’oublions pas que c’est en apprenant de leurs erreurs et en s’adaptant continuellement que les équipes peuvent être véritablement agiles et prospérer dans un environnement en constante évolution.
