Oui, l’Agile est exigeant

Cette réflexion fait donc suite à l’article Charlie, l’agilité et la méditation de Jean-Yves Reynaud, que je salue au passage.

Comme toujours j’ai la faiblesse de croire que les différences de point de vue sont accentuées, parfois, par des imprécisions, des flous sur le vocabulaire. Ou, plus précisément, que les nuances d’un propos sont inaudibles en fonction des circonstances. Quant au sujet – à savoir qui est exigeant entre un cadre agile et un Coach agile – je crois qu’il mérite un approfondissement, tant les répercussions peuvent être, à mon humble avis, lourdes de conséquences.

Vous avez dit “cadre agile” ?

Commençons par une réflexion toute simple.. en apparence : qu’est-ce qu’un cadre agile ? Prenons les deux cadres qui sont aujourd’hui des “standards de fait” :

  • Scrum pour une “petite” équipe (disons moins de 10 personnes)
  • SAFe pour les équipes plus importantes, ce qui est communément appelé agile à l’échelle.

Un cadre est constitué de pratiques (mais pas que), c’est ce qui est le plus “visible” car directement concret. Au Sprint Planning de Scrum correspond par exemple le PI Planning dans SAFe. Ces deux cadres sont itératifs (SAFe s’appuie intensément sur le flux tiré). L’itération dans Scrum est le sprint (quel drôle de nom dans une méthode agile qui respecte le principe de rythme soutenable…). SAFe est constitué de deux niveaux itératifs :

  • Program Increment : c’est l’itération de plus haut niveau, pilotée par le Product Management, en termes de features
  • ScrumXP : basée sur Scrum… et XP, c’est le niveau itératif plus fin.

Et, voyez-vous, un cadre suppose une étude attentive : la plupart des personnes que vous interrogerez vous diront que SAFe est basé sur des sprints et Scrum. Il suffit de lire quelques lignes de la description pour constater que c’est faux… par omission. L’étude d’un cadre tel que celui-ci exige donc une certaine capacité à ne pas trop se reposer sur l’acquis. Disons en quelques mots que SAFe utilise ce terme ScrumXP pour rappeler que la valeur de qualité intrinsèque (voir plus bas) est prise en compte dans le fonctionnement des équipes et se traduit par la présence de pratiques issues d’XP telles que ATDD, TDD, intégration continue.

Un cadre est constitué de rôles, Product Owner ou Product Manager pour piloter. D’artefacts et de concepts de pilotage, de développement : backlogs, codes de tests…

Enfin, un cadre est constitué de valeurs, principes (ce que Scrum nomme “piliers”). Qu’est-ce qu’une valeur ? C’est très simple : ce qui est important est une valeur. Concernant SAFe, nous retrouvons :

  • Qualité intrinsèque,
  • Transparence,
  • Alignement,
  • Exécution du programme.

Au risque de me répéter, “qualité intrinsèque” est une valeur de SAFe, donc quelque chose d’important. D’où ScrumXP et pas Scrum pour nommer les itérations des équipes.

J’ai la faiblesse de croire que cette caractéristique de SAFe (tout comme limiter le WIP) est exigeante, difficile à atteindre.

Considérer qu’un cadre agile n’est pas exigeant me semble être un message inapproprié : il laisse à croire qu’un cadre agile est une vitrine dans laquelle il est possible de “picorer” telle ou telle pratique. Ce qui est faux (du moins pour que ce soit efficace). Prenons l’exemple de la pratique “user story” de l’Extreme Programming. C’est un moyen d’exprimer les besoins détaillés d’un produit. Basée sur les interactions entre Utilisateur et système, cette pratique nécessite plusieurs conversations. D’où la pratique complémentaire qui est “customer on site” (Product Owner dans Scrum). C’est ce que l’on retrouve d’ailleurs dans le principe agile :

Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Pratiquer “user story” sans “customer on site” est donc risqué. Un cadre est exigeant car il demande :

  • de comprendre le cadre et les relations entre ses différents constituants, ce qui demande à mon sens un effort non négligeable, en particulier pour ne pas être le jouet de ses propres biais cognitifs,
  • une bonne vision du lien entre pratiques et résultats espérés.

Que se passe-t-il lorsque tout cela est absent ? Et bien, je ne compte plus le nombre de Product Owners qui m’expliquent une baisse de qualité, une lassitude des Développeurs, un manque de visibilité… après quelques mois ou quelques années de pratique agile. Bien sûr un léger mieux peut être constaté : plus de communication, de feed-back amènent quand même des avancées.

Ceci étant dit, il reste à voir comment gérer cette exigence du cadre choisi (et plus précisément des pratiques retenues, les user stories par exemple ne faisant pas partie de Scrum originellement).

C’est là que le rôle de l’accompagnant est important. Selon la situation de l’équipe, à lui d’être plus ou moins exigeant. Si l’accompagnant (typiquement “coach agile”) n’a pas conscience de l’exigence du cadre, il risque fort d’être très approximativement exigeant avec ses clients.

En conclusion, l’exigence du cadre agile est en quelque sorte un pré-requis à l’exigence du Coach. Les deux cohabitent finalement pour obtenir les bénéfices reconnus de ces approches :

  • meilleur moral des équipes
  • augmentation de la qualité des livrables et plus généralement de l’équilibre valeur / qualité
  • meilleure productivité due au nouveau fonctionnement.

Ce sont des signes de pratiques agiles réellement… agiles.