Ce que le métier ne comprend pas de l'agilité
L'écart entre l'intention et la mise en œuvre
Il n’est pas rare t’entendre parler d’agile dans la bouche des directions et des métiers.
Le sens n’est pas le même que dans la tête de l’IT.
Côté IT on fait référence au travail continu de toute une communauté de praticiens depuis une trentaine d’année, avec bien entendu le Manifeste pour le développement agile de logiciels de 2001 ainsi que ses frameworks comme Scrum, XP, SAFe et bien d’autres. C’est un véritable corpus, autant méthodologique que philosophique.
Côté direction et métiers on est sur une définition beaucoup plus intuitive : on parle, de manière intuitive, de l’efficacité et de la capacité à saisir des opportunités.
Dit comme cela, ça ne semble pas contradictoire. On pourrait même se dire que c’est la même chose, juste que l’IT a outillé cette définition, l’a concrétisée et rendue actionnable.
Dans les faits, on constate clairement un désalignement. Le même mot qui amène à des conséquences radicalement différentes selon la bouche qui l’utilise.
En caricaturant, c’est le fameux « allez, on est agile ! » qui sert à faire passer tout et n’importe quoi. 🫣
Les itérations, pont entre adaptation continue et gestion du chaos
Un des piliers de l’agilité dans le domaine du logiciel est le développement incrémental et itératif.
On le présente généralement par opposition au waterfall où l’on ferait l’ensemble des livrables est une seule fois, là où l’approche incrémentale et itérative passe par de multiples livrables intermédiaires. Ces itérations servent autant à compartimenter les risques que pour introduire des boucles de feedback. Ce sont ces boucles de feedback qui permettent l’adaptation en cours de projet et qui augmentent ainsi fortement les chances que le projet apporte les bénéfices visés.
C’est la fameuse promesse de l’agilité !
Les itérations apportent une capacité à s’adapter en continu.
Pour autant, il y a un autre concept qui se cache derrière le principe des itérations. C’est celui d’apporter de la stabilité dans un environnement complexe, imprévisible voire chaotique. Pour accomplir les activités de développement, pour construire une solution, cela nécessite un cadre et des consignes qui ne changent pas en permanence. Impossible d’implémenter une spécification qui changerait à chaque fois qu’on la consulterait à nouveau ! Cette réalité peut d’ailleurs faire vite déraper certains développeurs vers une incompréhension complète de l’agilité et donc de son rejet en bloc, avec une exigence aveugle que « les specs soient sèches » avant de se mettre au travail.
C’est là qu’interviennent les itérations. Il n’est pas juste question de découper un plan complet et définitif en jalons intermédiaires, mais bel et bien de construire et d’affiner progressivement le plan, au fil des itérations.
Dans le cadre de chaque itération, un plan est bien défini pour cette dernière.
Être agile, ça ne veut pas dire arrêter de planifier. Au contraire, on planifie (voire on contractualise) souvent, très souvent — a minima à chaque itération.
Flux continu, flux tiré et Kanban
Il n’y a pas que le fonctionnement en itérations. Quid des équipes qui fonctionnent en flux continu ?
Tout d’abord, soyons clairs qu’un fonctionnement en flux continu (type Kanban) ne s’oppose pas à un fonctionnement par itérations (type Scrum). Bien au contraire ! Les équipes Scrum les plus performantes utilisent systématiquement Kanban en complément de Scrum.
En particulier des pratiques comme le déploiement continu (continuous delivery) encouragent et reposent sur un travail en flux continu type Kanban, sans que cela ne soit aucunement contradictoire avec Scrum. Justement, cela permet de mettre en place un Scrum qui prend de la hauteur, où les itérations successives au cours d’un même sprint Scrum ne sont pas un découpage séquentiel de l’objectif de sprint mais une logique d’apprentissage où l’on construit rapidement une première réponse à l’objectif de sprint et que l’on va ensuite faire évoluer de manière incrémentale, jour après jour.
Ainsi, c’est plutôt le fait de ne pas utiliser Kanban en complément de Scrum qui serait une mauvaise pratique ! 😁 1
DoR et DoD (Definition of Ready, Definition of Done)
Si on continue de tirer la ficelle du flux continu, on en arrive aux DoR et DoD, soit les conditions d’entrée et de sortie du flux de travail de l’équipe.
C’est une autre manière de reboucler avec la dynamique d’itération, à l’échelle des éléments de travail à plus petite granularité qu’à l’ensemble de l’itération.
Là encore, DoR et DoD servent de gardes-fous qui garantissent qu’on a une micro-session de stabilité dans un univers en perpétuel mouvement. Stabilité qui reste essentielle pour pouvoir aller au bout du travail et générer des apprentissages.
Sans DoR ni DoD, on fait du sur-place.
L’agilité, c’est l’extrême rigueur
Peu importe comment on tourne les choses, pour être agile, il faut être très rigoureux. J’aime bien parler de ce prérequis en disant que « l’agilité, c’est l’extrême rigueur. » 2
Bien sûr, l’agilité c’est d’abord un état d’esprit, et cet état d’esprit est nécessaire pour en tirer les bénéfices intuitifs de l’agilité — c’est à dire de réussir à saisir les opportunités lorsqu’elles se présentent. Si on creuse cette notion d’état d’esprit, on découvre qu’il faut un certain nombre d’atouts pour pouvoir être agile, comme l’état d’esprit de croissance (growth mindset), la sûreté psychologique, la capacité à prendre du recul.
Mais ces éléments, seuls, ne sont pas pérennes. Ils peuvent amener à l’ère des héros3 ce qui peut apporter d’immenses bénéfices à court terme, mais qui à nouveau n’est pas soutenable.
Pour être soutenable, rien ne remplace l’excellence technique, ainsi que cette fameuse rigueur ou discipline.
Derrière cette phrase « l’agilité c’est l’extrême rigueur » j’implique aussi que l’agilité ce n’est pas l’absence de processus, bien au contraire. Et c’est justement parce que l’on maîtrise pleinement ces processus que l’on arrive à être agile : parce qu’on les maîtrise tellement qu’on arrive à les informaliser et ainsi à les appliquer comme une seconde nature. On va vite, sans jamais rogner sur la qualité, et c’est cette même qualité qui permet d’aller vite. C’est ça, l’agilité.
Et en dehors de l’IT ?
Exemple du Lean
Admettons, l’agilité nécessite énormément de rigueur, de discipline et de planification — et c’est justement ce qui permet d’être agile, c’est à dire d’être efficace et de pouvoir saisir des opportunités. (pour revenir à la définition intuitive citée en introduction)
On pourrait tout de même se demander : OK, mais c’est peut-être différent en dehors de l’IT ?
Pour répondre à ce questionnement, je vais cette fois évoquer le Lean et ses différentes variantes, autant dans le domaine du manufacturing que dans l’ingénierie.
Il y a énormément de choses à dire à propos du Lean. En ultra-résumé, le Lean impose de formaliser une démarche d’amélioration continue via la mesure et des boucles d’expérimentation courtes. Autant dire que le constat est le même que celui que j’ai fait plus haut à propos de l’agilité.
Ce n’est en soi aucunement surprenant : le Lean est un des parents de l’agilité. Dans sa dernière version, le Scrum Guide rattache Scrum au Lean et non plus à l’agilité. L’utilisation de Kanban en informatique est courant (je l’évoquais plus haut comme un élément nécessaire pour compléter Scrum). Les notions de flux, de visualisation, de focus sur l’utilisateur sont autant de concepts au cœur du Lean et qui sont des piliers de la mise en œuvre de l’agilité.
La rigueur comme fondement de tout mode de fonctionnement qui apporte des bénéfices, c’est universel !
Partie émergée vs partie immergée
On ne peut pas dire que qualifier l’agilité d’être efficace et capable saisir des opportunité, ce soit une mauvaise définition. Par contre, c’est simpliste.
C’est une bonne définition théorique, abstraite, qui communique les bénéfices visés ainsi que les comportement attendus par les différents acteurs.
Cela n’aide par contre aucunement à mettre en œuvre l’agilité. Et c’est là que tout se joue, que toutes les nuances apparaissent, jusqu’à une apparente opposition, comme la nécessité d’être rigoureux pour pouvoir s’adapter.
On pourrait utiliser la métaphore de l’iceberg : on voit la partie émergée mais on n’imagine pas tout ce qu’il se passe sous la surface. On est tous d’accord sur la partie émergée, mais seule l’une des deux populations est consciente de tout ce qu’il se passe sous la surface. Et c’est de là que viennent les incompréhensions !
La majorité des équipes n’ont pas acquis cette nuance. L’arrivée de l’IA change un peu la donne car elle permet de construire des solutions complètes en une seule journée sans trop forcer. Malgré tout le modèle dominant dans les grands groupes reste de viser une release par sprint, pour conclure le sprint. On n’est alors ni dans le continuous delivery ni dans cet état d’esprit canonique de Scrum où l’on itère sur la solution au sein même du sprint ni dans l’utilisation de Kanban pour y arriver.
Sur ce point, nous avions fait deux vidéos pertinentes sur Scrum Life : une première qui articule cette notion qu’un sprint devrait ressembler à un travail d’itération quotidien, et une seconde qui fait le lien entre continuous delivery et Scrum.
J’affectionne et porte cette définition « l’agilité, c’est l’extrême rigueur » depuis pas mal de temps. J’ai pu en rentrer dans le détail de ce que j’entends par là lors de ma première interview sur On part en prod !
(La vidéo est longue, le moment où nous parlons spécifiquement de ce sujet commence vers 41:19 😊)
« L’ère des héros » c’est le nom que j’avais trouvé pour qualifier cette situation où le système fonctionne en se reposant sur des efforts individuels et héroïques récurrents voire permanents — potentiellement jusqu’au stade où c’en est devenu une situation normale tellement elle est habituelle. C’est le sujet d’une de mes conférences, dont voici une captation ci-dessous.