L'indice de maturité agile : une tendance en ce moment. Beaucoup de grandes structures ayant déployé du Scrum ou du Kanban ces dernières années, cherchent aujourd'hui à identifier leur maturité agile dans l'objectif d'évaluer l'impact de l'agilité en interne. Peux t-on réellement identifier son indice agile ?
Mardi, je croise X. dans les couloirs de la DSI du groupe la Poste. X. est coach agile pour le service intitulé SAM APPUI à la DSI. SAM APPUI est un service transverse, inter-socles, proposant des services en appui, tant d'un point de vue méthodologique, que déploiement d'infrastructures, déroulé de tests de charges, ou encore de paramétrages spécifiques d'outils type Jira, Confluence... X. m'informe du projet d'audit agile des équipes en interne.
Le DSI de la Poste a décidé de déployer de l'agile au sein des équipes ces 5 dernières années. Aujourd'hui, il souhaite visualiser le niveau de maturité agile de ses équipes. Logique me direz vous :)
Il est tout à fait sain de chercher à évaluer le niveau de maturité d'équipes que l'on a poussé à monter en compétences quelques années plus tôt sur de nouvelles pratiques.
J'ai donc été auditée par X. avec mon équipe lors d'un daily meeting entre 9h15 et 9h30. Je devais avoir rempli au préalable une grille d"évaluation de mes pratiques agiles en équipe.
Suite à l'audit, le résultat m'a été communiqué via un pourcentage basé sur 20 critères d'évaluation. J'ai bondi en parcourant les critères me trouvant en désaccord avec certains d'entre eux et pas vraiment en phase avec l'approche d'évaluation de la maturité agile . Je me suis donc interrogée sur ce qui serait à mon sens une évaluation en adéquation avec les pratiques déployées, l'expérience de l'équipe en Scrum ou Kanban, le respect du cadre posé par le Scrum Guide, et l'adaptation en interne à certaines contraintes projets ou environnementales.
Shu, Ha ou Ri ?
Ma première réflexion s'est portée sur le fait que chaque équipe à un niveau de maturité initial différent, une expérience Scrum (si l'on parle de Scrum) à l'échelle de l'équipe différente. Donc poser un état des pratiques utilisées ramené à un référentiel existant me semble intéressant. C'est d'autant plus vrai pour des équipes qui déploient du Scrum pour la première fois et sont encore à leurs premiers Sprints. Mais ce qui me semble d'autant plus intéressant, c'est la démarche d'amélioration continue présente au sein des équipes. Et c'est d'autant plus vrai lorsque ce sont des équipes déjà matures en Scrum. Ce qui est le cas de l'équipe avec laquelle je travaille actuellement. La question à se poser de mon point de vue est : comment s'assure t-on que l'on continue à apprendre ensemble ?
Le « Shu Ha Ri » est constitué de 3 étapes par lesquelles un novice doit passer pour acquérir une compétence ou maîtriser une technique:
- Shu : le disciple apprend les fondamentaux en suivant les règles édictées par le maître
- Ha : ayant maîtrisé les fondamentaux, le disciple applique les règles en les questionnant, en comprenant leurs subtilités et en cherchant les exceptions
- Ri : le disciple ayant maîtrisé les règles, il peut les transcender et les adapter
"Shu Ha Ri" peut être vu comme des cercles concentriques, avec le Shu dans le Ha, et le Shu et le Ha dans le Ri. Les techniques et connaissances fondamentales ne changent jamais. Dans la phase Shu, l'étudiant n'est juste pas encore prêt à explorer différentes voies.
A quel niveau évaluons-nous une équipe ?
- Au niveau Shu, à savoir sur le respect à la lettre du Scrum Guide (en s'assurant alors que la grille d'évaluation est bien iso avec la dernière version du Scrum Guide). L'évaluation se ferait donc basée sur les critères proposés par le Scrum Guide
- Au niveau Ha, incluant le Shu dans le Ha dans ce cas, à savoir le cadre du Scrum Guide dans des pratiques quotidiennes, qui elles même sont adaptées au mieux à la culture de l'organisation. L’évaluation se ferait alors à la fois sur ce qui reste du cadre posé par le Scrum Guide et parmi ce qui est différent de comprendre pourquoi il y a eu une adaptation et en quoi ça apporte un impact positif en interne au sein de l'équipe projet et de l'organisation entière elle-même.
- Au niveau Ri, incluant le Shu et le Ha dans le Ri, qui demande d'être passé par les étapes Shu et Ha pendant une période projet minimum (je dirais en nombre d'années). Dans ce cas, l'évaluation se porterait plus sur l'impact des pratiques agiles appliquées au quotidien à la culture et à la santé financière de l'organisation.
Et si ça soulève plus de questions que de réponses ?
J'ai toujours aimé l'idée d'audit parce que d'expérience, il soulève plus de questions que de réponses. C'est le cas pour moi encore aujourd'hui suite à cette demande en interne. Un audit, s'il est bien pensé, donne une image à un moment T de ce qui est fait ou non au sein d'une équipe. Puis il doit nous amener, en tant qu'agilistes à nous poser les mêmes questions régulièrement et à comparer les réponses pour prendre conscience des évolutions (ou régressions) et donc d'un potentiel indice de maturité.
Donc, cocher des cases sur ce qui se fait au quotidien au sein d'une équipe, why not ! Une grille de cases à cocher permet de se poser de bonnes questions, de prendre du recul.
Cependant, attention à ce que les questions soient simples, concrètes, et quantifiables sur une échelle proposée. Attention également à ce qu'il n'y ait pas d'interprétations possibles. Dans le cas de Scrum, le vocabulaire du Scrum Guide doit accorder tout le monde. Dès lors qu'une question peut être interprétée différemment selon la personne de l'équipe à qui elle est posée, cette approche d'audit perd toute sa valeur selon moi. J'aurais donc tendance à conseiller une approche ou les réponses sont saisies dès lors qu'il y a unanimité en équipe.
Est-ce réellement possible ? et si oui comment s'y prendre ?
Réaliser un audit sur des pratiques agiles basé sur des valeurs qualitatives, d'auto-organisation, et d'amélioration continue demande une vraie réflexion pour que les résultats soient intéressants à analyser.
Une chose est certaine, l'évolution d'une équipe dans le temps est ce qu'il y a de plus intéressant à mon sens. De ce point de vue là, l'intention de la DSI de relever ces critères tous les 3 mois est une bonne approche. Par la suite, si l'analyse est bien faite, avoir une image de l'évolution de la maturité des équipes à l'échelle d'une année par exemple avec un état tous les 3 mois est un indicateur intéressant. Et si l'on peut corréler des départs et des arrivées, des évènements en interne que ce soit de nouveaux process, de nouvelles technos... aux indices de maturités sur l'année, ça devient même très chouette.
J'ai mené en 2013 des ateliers en interne chez SOAT pour tenter de poser des indices de satisfaction dans les organisations. C'était le début des échanges autour du "Bonheur au Travail", les prémices du Management libéré pour d'autres. Je vous avoue qu'après plusieurs tentatives de questionnaires alliant "état des pratiques", "ressentis personnels" et "ressentis d'équipes", on a abandonné le projet concluant que le ressenti était propre à chacun et que de tenter de corréler des météos personnelles, d'équipes à des évènements majeurs en entreprise n'était pas simple.
Faire un état des pratiques Scrum est différent, et plus simple de mon point de vue dès lors que l'on part d'un référentiel commun, qui est le Scrum Guide, et que l'on porte ensuite son indice sur l'apprentissage, l'amélioration continue. Pour résumer, je ne vois pas aujourd'hui comment évaluer une organisation autrement que par l'amélioration continue. Après ce petit détour, rentrons un peu plus dans ce que pourrait être une évaluation de l'indice de maturité.
Quali vs quanti...
Évaluer un niveau de maturité agile au sein d'une équipe à base de données qualitatives, dès lors que l'on se tient aux mêmes données sur une grande période pour pouvoir les comparer et que l'on ramène le niveau de qualité à des pratiques identifiées clairement, ça fonctionne.
Évaluer un niveau de maturité inter-équipes, quand le niveau de maturité dépend intrinsèquement de sa composition initiale, de sa maturité initiale, de l'évolution de son auto-organisation, de l'amélioration continue sur des sujets spécifiques est plus complexe. Quoi qu'il en soit, il est toujours intéressant de se poser pour auditer un existant. Il est également intéressant d'avoir une personne externe à une équipe qualifiée "d'auditeur" si elle se positionne comme porteuse d'amélioration continue et non d'évaluation de la performance de l'équipe. Ce que recherche toute équipe, ce sont des "feedback" utiles, de l'échange de bonnes pratiques, des retours d'expérience de ce qui se fait ailleurs et pourquoi ça fonctionne dans leur cas.
Pour continuer mon histoire. Je reçois un fichier excel avant l'audit du daily meeting. Le fichier excel propose une sémantique pas toujours simple à comprendre et difficilement quantifiable pour certains critères. Je le rempli en le parcourant, sans plus d'entrain. Je le fait seule car il m'est adessé personnellement et demandé dans un délai court. L'approche ne me semble pas cohérente. Mon point de vue de Scrum Master, "gardien de la méthodologie" ne peut représenter le point de vue de l'équipe entière. Je le compléte donc en y ajoutant des commentaires et des propositions d'amélioration et décide d'écrire un post sur le sujet.
La grille d'évaluation initiale
Après réflexions et recherches sur le sujet, je choisis de repartir d'une liste écrite par Henrik Kniberg, en 2010 certes, traduite par Fabrice Aimetti et de l'adapter aux mises à jour du Scrum Guide de 2017, ainsi qu'aux pratiques internes de la Direction Courrier-Colis de la Poste.
Et du coup, il est agile mon projet ?
J'adapte ma grille. Peu de temps après en continuant à me documenter sur le sujet, je trouve une grille proposée par Agile Strides qui part également de la checklist d'Henrik et propose un fichier excel dynamique générant une analyse par grandes thématiques que je trouve assez complète. Je m'en inspire grandement, la traduit en Français, reprends les critères d'évaluation et y ajoute mes propres critères. Voici le fichier Scrum Checklits en Creative Commons d'Agile Strides
Qu'est-ce que cet exercice apporte à une équipe ?
Dans mon cas, je trouve l'opportunité intéressante pour se poser de bonnes questions en équipe, ou pourquoi pas comme thématique de rétrospective tous les 3 mois par exemple.
Certains points de la liste d'évaluation ne correspondront pas à tous les projets et d’autres peuvent manquer. Avant d’ajouter (ou retirer) un élément de la liste une approche d'évaluation pourrait être de s’assurer que cet élément fait l’unanimité dans l’équipe.
Et de proposer aux équipes d'être force de proposition en y ajoutant leurs propres critères. Vous créerez ainsi de l'engagement et verrez se dessiner des pratiques que vous n'imaginiez peut être même pas en interne. Invitez les équipes à ajouter leurs standards. Quelles sont les meilleures pratiques observées en mode projet ? Ayez une formulation simple, compréhensible par tout le monde pour votre grille d'évaluation afin de faciliter l'approche et maximiser le taux de réponses.
Une fois l’analyse effectuée, se réunir régulièrement permet de présenter les résultats. C’est l’occasion d’échanger, de comprendre les difficultés de chacun et de choisir des points que l’on souhaite améliorer ou suivre avec une attention particulière. C'est aussi un bon moment pour choisir de tester une nouvelle pratique.
L'objectif d'une telle approche doit être de réduire ou supprimer certains "pain points"'. En le présentant ainsi, ça devient un vrai outil d'amélioration continue.
Idéalement, ne l’appelez même pas grille d'évaluation ou indice de maturité agile qui pose déjà une approche de performance, mais orientez le nom autour de l'amélioration continue proposé comme une base de réflexion à des équipes motivées par l’amélioration de leur quotidien.