L’époque où l’Agilité était inconnue de la plupart des organisations et des équipes est révolue. L’Agilité est partout (parfois décriée mais c’est un autre débat), enseignée dans les écoles, retenue comme démarche de travail dans la plupart des équipes. Mais au-delà de la simple étiquette (agile), votre équipe est-elle sur la voie de l’Agilité ? Qu’a-t-elle encore à apprendre ? Quelles sont ses marges de progression ?
Je tente dans cet article d’aborder la question de la maturité des équipes agiles. Je reçois souvent des demandes d’audit, une question controversée puisqu’il n’existe pas à ce jour de modèle clair, scientifique et reconnu par une communauté de pairs. Pourtant de plus en plus d’équipes ayant un vécu agile peuvent se demander légitimement où elles en sont.
Cet article s’adresse aux éditeurs de logiciels, aux ESN, aux DSI et à toutes les autres formes d’organisations ayant retenu l’Agilité comme choix de travail collaboratif et à toutes les équipes qui sont encore en phase de réflexion, prêtes à franchir le pas.
Le niveau 1 : l'Agilité centrée sur un métier
Les équipes qui se disent agiles font souvent le choix d’une approche itérative et incrémentale (souvent inspirée de Scrum). Il est fort probable que dans l’équipe on retrouve une personne portant le titre de Product Owner, une autre celle de Scrum Master, le reste de l’équipe … ayant souvent le même métier.
Prenons l’exemple de l’informatique, si c’est votre domaine, observez votre équipe. Si vous n’y voyez que des développeurs, il est probable que votre équipe se pose pas mal de questions, parmi les plus récurrentes on retrouve : comment intégrer les retours des testeurs dans nos itérations ? Que veut dire « terminé » ? D’ailleurs, à bien y regarder, l’Agilité c’est bien une histoire de développeur, non ? Et comment gère-t-on les stories techniques ? Comment faire des estimations et avoir des plannings fiables ?
Être au “niveau 1”, c’est déjà la preuve que vous avez engagé une démarche. Néanmoins, cette Agilité reste trop centrée sur celles et ceux qui font et est souvent considérée comme un outil d’accélération de la production.
Le point commun entre toutes les équipes en situation d’Agilité niveau 1, c’est qu’elles posent souvent des questions ne trouvant pas de réponses suffisamment satisfaisantes. La raison est souvent simple : les fondamentaux et la rigueur de la méthode agile retenue ne sont pas suffisamment respectés. L’équipe espère tirer partie de la mise en place de l’Agilité mais sans investir les efforts suffisants. C’est le cas par exemple avec une équipe espérant améliorer son Agilité en n’investissant que 30 minutes toutes les 3 semaines pour ses rétrospectives. L’amélioration continue nécessite un investissement plus important.
Les Agilités de niveau 1 sont souvent des démarches s’inspirant d’approches, d’outils, de techniques, de pratiques venant agrémenter le quotidien. Parfois certains choix de retenir des outils ou des pratiques dits agiles ont tellement perturbés le rythme de l’équipe qu’ils se sont révélés comme étant finalement de mauvais choix. Les témoignages catastrophiques de daily meeting qui n’en finissent pas, ne sont qu’une infime partie des exemples possibles.
En Agilité niveau 1, la notion d’équipe agile est encore trop succincte, trop basique. Celle-ci embarque encore trop peu d’acteurs qui sont en dehors de l’équipe et qui pourtant devrait en faire partie.
Le niveau 2 : l'Agilité comme début de décloisonnement
Les Agilités de niveau 2 témoignent de la mise en œuvre d’une des composantes essentielles à l’Agilité : la pluridisciplinarité.
Souvent les équipes informatiques au niveau 2 intègrent des développeurs et des testeurs, et parfois un autre profil (UX par exemple).
La dynamique de l’équipe est sensiblement différente. La notion de « Terminé » intègre le travail de chacune des personnes. Pour les personnes ayant l’habitude de travailler en silo (développement, puis test), c’est une petite révolution pour ne pas reproduire la logique de cloisonnement des métiers à chaque itération.
On cherche par exemple à éviter que les développeurs livrent le travail aux testeurs quelques jours seulement avant la fin de l’itération au risque de recréer une logique de rush de fin d’itération (traduction : terminer le travail prévu) qui serait intenable à moyen et long terme.
L’évitement de cette logique fatigante (l’Agilité doit rimer avec un rythme soutenable) passera par le dialogue, l’exercice répété de travailler avec l’autre et donc apprendre ses contraintes sans les rejeter mais en cherchant à trouver des solutions ensemble.
Ce qui distingue l’Agilité niveau 2 par rapport au niveau 1 est sans doute l’abandon de la logique de confrontation (le travail des autres n’est pas assez ceci ou cela pour que JE puisse travailler) pour basculer dans une logique coopérative (qu’est-ce que JE peux proposer à mon échelle pour traiter une contrainte, comment puis-je contribuer).
L’Agilité niveau 2 est également plus exigeante car elle n’est pas forcément innée, logique, en ligne avec nos croyances et nos habitudes de travail. Il ne faut pas sous-estimer le cheminement que cela va demander à certains et l’accompagnement à investir pour y parvenir.
Les Meetups de l'Agilité
Vous voulez échanger et expérimenter autour de l’Agilité ? Rejoignez-moi dans ce groupe Meetup. Il est ouvert au néophytes ou experts, praticiens ou non de l’agilité, quels que soient votre métier ou secteur d’activité.
Prochains événements :
- Comment évaluer l’Agilité de son organisation ?
- Quelle Agilité mon équipe doit-elle choisir pour démarrer ?
Le niveau 3 : L'Agilité centrée utilisateur
L’Agilité niveau 3 intègre une pluridisciplinarité plus large, de bout en bout c’est à dire de l’expression des besoins à la livraison aux utilisateurs finaux. C’est d’une facilité déconcertante quand on l’écrit : un besoin est formulé, l’équipe (composée de différentes compétences nécessaires) le traite (production, test, packaging, documentation, etc.) et le livre en production. Facile non ?
Dans les faits, pour que cette histoire se déroule et se répète avec fluidité, il y a beaucoup plus qu’un processus :
- L’industrialisation des procédés : l’équipe a souvent automatisé énormément de tâches, elle est outillée et veille à maintenir un haut niveau d’excellence technique
- La connaissance et transversalité des compétences : le collectif s’est construit longuement et se connaît. L’entraide est une valeur présente. Un équipier n’hésitera pas à proposer, à demander et à accepter de l’aide
- L’utilisateur est intégré en permanence : l’Agilité a dépassé la simple logique d’amélioration de la production. C’est avant tout une approche qui permet de s’assurer que les travaux menés vont dans le sens du développement de l’organisation ET des attentes des utilisateurs.
L’Agilité niveau 3 est hautement exigeante pour les équipes. Elle implique également un environnement favorable des soutiens de tous bords : moyens, ressources humaines et management.
S’il est difficile d’accéder à ce niveau, il ne faut pas sous-estimer les efforts nécessaires pour le maintenir.
Vous ne vous retrouvez dans aucun de ces niveaux ?
En lisant cet article, vous vous êtes peut-être retrouvé(e) dans une forme d’entre 2. C’est sans doute parce qu’un article qui pose des limites bien définies ne saura jamais être le miroir de toutes les situations et de leur complexité. Vous êtes peut-être en Agilité 1,5 ou 2,5, à vous de voir. D’ailleurs, peu importe le numéro du niveau dans lequel vous êtes, ce qui compte c’est la prochaine étape que vous voulez atteindre avec votre équipe.
Autre possibilité, après la lecture des 3 niveaux, vous ne vous êtes absolument pas retrouvé(e) dans ce déroulé. Je formule plusieurs hypothèses :
- L’ Agilité n’est qu’une “étiquette” dans votre organisation. On utilise « Agile » parce que ça fait bien mais dans les faits il ne se passe pas grand chose. La solution pourrait être d’arrêter de parler d’Agilité, vous souffrirez moins 🙂 Ou alors commencez à appliquer quelques pratiques agiles (tenir un daily meeting de 15 minutes sur la durée est déjà un sacré progrès)
- Vous êtes dans un système parallélisé, vous n’avez pas un fonctionnement d’équipe. On attend sans doute de vous de la réactivité et pas un fonctionnement itératif. Une approche en flux est sans doute à étudier de plus près (par exemple Kanban)
- Vous êtes dans un service marketing, commercial, support client ou autre. Vous êtes encore en phase de réflexion pour savoir à quoi l’Agilité pourrait ressembler. Vous recherchez un discours adapté à votre réalité
Demandez votre audit agile
Toutes les équipes, les organisations, les modèles économiques, les produits ont leur singularité. Si toutes les équipes peuvent accéder à l’Agilité, il convient de voir celle qui est la plus respectueuse des personnes et de la culture en place et d’envisager quel peut être le projet d’évolution de l’Agilité.
Je vous invite à prendre quelques minutes pour répondre à ces questions et demander votre audit agile. Je répondrai à chaque demande et je vous proposerai mes pistes de réflexions en fonction de votre situation.
