Il y a méthode agile et méthode Agile.
Plus précisément, certaines méthodologies se font passer pour "Agile" alors qu’elles sont de la gestion de projet traditionnelle déguisée.
Apprenez à détecter la "vraie" agilité.
Si initialement l'approche Agile était surtout destinée au développement de logiciels, elle a rapidement été adoptée pour mieux accompagner la croissance des organisations et la bonne mise en œuvre de leurs projets.
La méthode Agile a fait tellement d'émules que, désormais, une large majorité des entreprises recherchent cette étiquette afin d'optimiser leur gestion de projet.
La demande a été suffisamment forte pour voir apparaître une offre adaptée. Et malheureusement, certains se sont mis à l'adapter en perdant de vue l'intention initiale. Par conséquent, des équipes censées être agiles ne l'étaient en réalité pas et donc les bénéfices n'étaient pas au rendez-vous.
Pire, des entreprises pensant faire de l’agilité ont été déçues et ne souhaitent plus en entendre parler. Elles n’ont pas compris qu’en fait elles n'avaient jamais mis en place de la “vraie” agilité.
L’agilité est un état d’esprit qui va au-delà de l’utilisation de certaines pratiques. Même s’il existe des pratiques couramment admises comme étant “agiles”, elles n’existent que pour satisfaire cet état d’esprit.
Or, il arrive que ces pratiques soient utilisées (ce qui fait penser à de l'agilité) sans en comprendre l'intention véritable. Dans ce cas, vous êtes dans la fausse agilité !
Penser qu’il suffit d’avoir un backlog, un daily meeting, un product owner et de fonctionner en sprint pour respecter les principes de l’agilité est une erreur.
Voici des indicateurs qui vous aideront à détecter si vous êtes dans une fausse agilité :
Non implication des utilisateurs finaux : c’est très mauvais signe si les utilisateurs finaux de votre produit ne sont pas impliqués durant la totalité du développement de votre produit.
L’équipe de développement n’est pas en contact régulier avec les utilisateurs : les membres de la ou des équipes de développement doivent observer et discuter régulièrement avec les utilisateurs finaux. Ils doivent également avoir des retours réguliers (satisfaction sur certaines fonctionnalités, rapport de bugs…).
Priorisation par la valeur : vous avez un problème si l’application des process est plus importante que la livraison rapide des fonctionnalité à valeur ajoutée.
Périmètre délimité : Vous n'êtes pas dans la bonne direction si vos parties prenantes ont des périmètres délimités et ne co-construisent pas (i.e. “Ce n’est pas mon travail”, "Ce n'est pas dans mon périmètre").
Automatisation : les tâches qui peuvent être automatisées ne le sont pas (tests, CI/CD).
Pour aller plus loin et bien comprendre ce qui caractérise une équipe (réellement) agile, en voici quelques principes de base qui forment les valeurs des méthodes d'agilité.
Une équipe agile est capable de s'adapter rapidement aux changements dans les besoins et les exigences des clients, ainsi qu'aux évolutions de son environnement.
Cela implique de travailler de manière flexible et de s'adapter aux changements de direction, plutôt que de suivre strictement un plan préétabli.
La relation avec les utilisateurs finaux est considérée comme étant cruciale pour la réussite d'un projet.
Les utilisateurs finaux sont les personnes qui vont utiliser réellement le produit ou le service qui est développé, et il est donc important de les consulter et de les impliquer tout au long du processus de développement.
En utilisant cette approche centrée sur l'utilisateur, les équipes agiles peuvent s'assurer que le produit final répond réellement aux besoins des utilisateurs finaux, ce qui augmente les chances de succès du projet.
Une équipe agile est plus autonome qu'une équipe lambda : elle lance rapidement de nombreux tests ciblés afin de vérifier que les fonctionnalités du logiciel ou du produit sont pertinentes et correspondent aux attentes de chaque client. Le projet avance plus vite et plus efficacement.
Par ailleurs, l'équipe agile œuvre de concert dans l'intérêt de l'entreprise et des utilisateurs finaux. Il n'y a pas d'individualité. Les compétences de chaque membre de l'équipe sont mises en commun.
Pour parvenir à cette autonomie et à cette collaboration, l'agililité apprend aux équipes à solliciter des objectifs clairs afin d'être alignées. Chaque membre d'équipe comprend alors comment il peut contribuer individuellement pour aider le groupe à atteindre les objectifs fixés.
Le rôle du manager évolue alors en "servant leader" où il sert d'abord ses employés, en les aidant à atteindre leurs objectifs et à développer leurs compétences, plutôt que de se concentrer uniquement sur les objectifs de l'entreprise. Ce style de gestion met l'accent sur la motivation, l'encadrement et le développement des employés plutôt que sur le contrôle et la supervision.
Réactivité, communication et transparence sont trois maîtres-mots dans toute organisation agile.
Prioriser le processus de création de valeur est également un marqueur fort d'une équipe agile.
Au lieu d'utiliser un processus rigide et planifié à l'avance, les équipes agiles utilisent une approche qui s'adapte aux changements et aux incertitudes.
Les processus peuvent alors évoluer si l'équipe estime que ce changement aidera à créer davantage de valeur pour les utilisateurs.
Même si les indicateurs peuvent être limités pour mesurer un état d’esprit, il existe cependant quelques indicateurs centraux pour savoir si vous allez dans la direction de la vraie agilité ou non.
Plus les réponses aux questions sont “oui”, plus votre chemin vers l’agilité progresse :
Vos équipes délivrent-elles des fonctionnalités à vos utilisateurs finaux après toutes les itérations ? Et sont-elles à l’écoute de leurs retours ?
Les retours utilisateurs sont-ils utilisés pour changer les priorités à court terme (< à 1 mois)
La vision stratégique est-elle définie et claire ? Chaque membre de vos équipes comprend-il en quoi il peut contribuer à cette vision ?
Les équipes sont-elles encouragées à changer leurs process en fonction de leurs apprentissages ?
L’ensemble de votre organisation est-il dans l’agilité ? (Certains services bureaucratiques peuvent-ils être un frein à vos équipes ?)
Nous pouvons également nous inspirer d’indicateurs issus du Lean pour mesurer l’efficacité du système :
Lead Time : temps nécessaire entre le moment où une idée émerge et celui où elle est mise à la disposition des utilisateurs.
Défauts : nombre d'erreurs ou de défauts produits par rapport à la production totale.
Temps d'arrêt : temps perdu pour les pannes ou les corrections de bugs.
En plus de connaître ces indicateurs à un instant donné, il est surtout intéressant de suivre leur évolution dans le temps et observer la dynamique.
Par exemple, si vos équipes ont de plus de plus de mal à livrer régulièrement des fonctionnalités car ils accumulent de la dette technique, vous perdez en agilité.
À noter que ces indicateurs sont vrais qu'il s'agisse d'une équipe ou d’agilité à l’échelle puisque l’intention reste identique.
- Comment testez-vous votre code ?
- À quel point vos développements, vos tests, la sécurité et le déploiement sont-ils automatisés ?
- Qui sont vos utilisateurs et comment communiquez-vous avec eux ?
- À quelle fréquence livrez-vous des fonctionnalités à vos utilisateurs ?
- Quels sont vos indicateurs de mesure pour le développement et les opérations ? Comment sont-ils utilisés pour éclairer les priorités, détecter les problèmes ? À quelle fréquence sont-ils consultés et utilisés pour le leadership ?
- Qu’avez-vous appris au cours de vos trois derniers cycles d’itération et qu’avez-vous fait à ce sujet?
- Qui sont les utilisateurs à qui vous offrez de la valeur à chaque itération ?
- Comment communiquez-vous avec les développeurs ? Ont-ils observé votre travail et posé des questions indiquant une compréhension approfondie de vos besoins ? À quand remonte la dernière fois où ils se sont assis avec vous et ont parlé des caractéristiques que vous aimeriez voir mis en œuvre ?
- Comment envoyer vous des suggestions de nouvelles fonctionnalités ou signaler vous des problèmes ou des bugs ? Quel type de rétroaction obtenez-vous à vos demandes/rapports ?
- Vous demande-t-on d’essayer des prototypes de nouvelles fonctionnalités logicielles ?
- Combien de temps faut-il pour qu’une fonctionnalité demandée apparaisse dans l’application ?
Mesurer le niveau de maturité agile d’une équipe ne revient pas à compter le nombre de points de vélocité ou d’événements Scrum en place.
Pour se rendre compte de la mise en place de la “vraie” agilité, nous devons mesurer l’avancement vers un état d’esprit.
Les questions que nous avons abordées ci-dessus peuvent vous aider à vous situer sur ce chemin.
Contact
julien.gardette@goveol.fr
Copyright 2022 Goveol