Si vous vous intéressez à l’agilité, le nom d’Alistair Cockburn vous est sûrement familier. Co-signataire du Manifeste Agile (2001) et créateur du mouvement Heart of Agile (ou “Cœur de l’Agilité”) en 2015, Alistair est l’une des figures de proue de l’agilité.
Nous avons eu l’immense plaisir de le recevoir dans nos locaux parisiens pour un meetup en toute intimité, avec Fabrice Bloch et Nicolas Mereaux, co-organisateurs des conférences Heart of Agile Paris.
Qu’est-ce que le mouvement Heart of Agile ?
Le mouvement Heart of Agile vise à recentrer l’agilité sur la simplicité face à la diversité des méthodes et techniques agiles, ce qu’Alistair Cockburn a brièvement expliqué via une métaphore caféinée : “Heart of Agile est le ristretto de l’agilité”. Heart of Agile regroupe l’essence même de l’agilité et cela se résume en 4 mots :
- Collaborer
- Livrer
- Réfléchir
- Améliorer
De nos jours, le monde change très vite et chaque personne, chaque entreprise, a besoin d’apprendre à être agile.
Les quatre mots du Cœur de l’Agilité répondent bien à ce besoin puisqu’ils sont utilisables dans n’importe quels domaines (gouvernement, projets sociaux, etc.), contextes ou équipe.
Pour rester dans l’esprit agile, ce meetup s’est déroulé dans le format préféré d’Alistair Cockburn : un ping-pong de questions/réponses, alimenté par des histoires et des exemples riches, et voici ce qu’il en est ressorti.
Lors de la rédaction du Manifeste Agile, d’autres mots que “agilité” ont-ils été envisagés ?
Si le mot “agilité” peut sembler évident aujourd’hui, il a fait l’objet d’un brainstorming de mots entre les 17 cosignataires du manifeste, à l’issue duquel deux mots sont sortis ex-aequo :
- “Adaptive” (adaptabilité/capable de s’adapter)
- “Agile“
Même si Alistair considère que ces deux qualités sont nécessaires – agilité pour les changements rapides et adaptabilité pour les changements plus lents – c’est finalement le mot « agile » qui a été retenu car il peut s’adapter à tous les projets, ce qui n’est pas le cas du mot « adaptive » (l’extreme programming, par exemple, est agile mais pas « adaptive » car fixe).
Dans un livre de Marty Caghan, le mot “découvrir” est particulièrement important : ce mot se retrouve-t-il dans la boussole Heart of Agile ?
Effectivement, « découvrir » rentre dans la catégorie « Livrer » car il s’agit d’une étape essentielle avant la livraison, celle où l’on sonde/teste le produit ou le concept. Alistair ajoute que les actions derrière ce terme doivent être traitées de la même manière que tout le reste du projet, et non en parallèle (double tracking) car « tout le monde doit parler au même moment d’un même sujet ».
Dans un contexte “non-software”, que répondre à la question “Qu’est-ce que l’agilité ?” ?
Dans l’optique d’inclure tous les domaines, Alistair préfère désormais utiliser la définition du dictionnaire : “l’agilité c’est avoir de l’aisance et de la promptitude dans les mouvements”.
L’agilité va permettre de délivrer précocement de la valeur tout en réduisant la bureaucratie.
“Lorsque l’on plante un olivier, il faut dix ans pour obtenir des olives, il en faut tout autant pour changer une organisation.”
Le Lean a-t-il eu une influence sur l’Agile ?
Certains des 17 cosignataires connaissaient le Lean mais ce n’était pas le cas d’Alistair. Au moment de la rédaction du Manifeste Agile, jamais le mot “lean” n’a été prononcé. Et, s’il est vrai qu’il y a des similitudes entre Lean et Agile, il y a aussi beaucoup de différences !
Que penser du fait qu’il faut faire un MVP (Minimum Viable Product) ? Comment faire comprendre au client la nécessité d’en faire un ?
Le terme MVP a fait l’objet de nombreuses différences d’interprétation, aussi, après avoir évité ce mot pendant 10 ou 15 ans, Alistair Cockburn préfère désormais utiliser le terme complet et non l’abréviation, “Minimum Viable Product“. Il s’agit d’un produit minimum qui apporte de la valeur, ce n’est pas un prototype.
Pour comprendre le concept de Minimum Viable Product, Alistair s’appuie sur l’exercice du “carpaccio d’éléphant“. Il part de l’ensemble des exigences du client (indiquées sur post-it par exemple) et met en évidence le moment où démarre le retour sur investissement. Il montre ensuite qu’il est possible de réduire un peu les exigences pour livrer le produit plus tôt que prévu initialement, afin que les premiers gains arrivent plus rapidement. Le client se rend ainsi très bien compte de l’utilité du Minimum Viable Product, l’objectif étant ensuite de continuer à réduire les exigences le plus possible afin d’obtenir le produit minimum viable.
Doit-on suivre une méthode ou peut-on la modifier ?
D’après Alistair Cockburn, une méthode est faite pour ne servir qu’une fois, elle est “jetable“. En effet, une méthode correspond à un contexte, un projet, une équipe…
Il est utile d’avoir recours à un process/une méthode comme point de départ, pour ensuite l’adapter petit à petit à son contexte/projet.
Au début d’un projet, Alistair recommande d’effectuer un brainstorming durant lequel l’équipe identifiera :
- d’un côté, ce qu’elle a aimé et ce qui a bien fonctionné par le passé ;
- de l’autre, ce qu’elle n’a pas aimé et ce qui n’a pas fonctionné par le passé ainsi que les pistes d’amélioration correspondantes.
À partir de là, l’équipe va se mettre d’accord sur les conventions qu’elle va appliquer pour ce projet et ce sera la base de la méthodologie de ce projet précis : “La méthodologie c’est [l’ensemble des] conventions que l’équipe est d’accord d’utiliser”.
Par la suite, chaque mois, l’équipe fera une mise à jour de ces conventions pour ainsi obtenir une méthodologie réellement personnalisée.
Le “Cœur de l’Agilité” (Heart of Agile) n’est pas un framework, c’est une boussole pour chercher sa direction en se posant notamment des questions sur la qualité de la collaboration sur un projet (comment l’améliorer, ce qui la gêne, etc.).
Parmi les quatre mots de Heart of Agile, lequel est le plus difficile à appliquer ?
Pour Alistair Cockburn, il s’agit incontestablement de « Réfléchir ». En effet, d’après lui, les gens savent collaborer (même s’ils ne le veulent pas toujours, mais c’est une autre histoire…). Cependant, ils ne prennent pas toujours le temps de se poser et de réellement réfléchir : “Les dirigeants devraient prendre 1h chaque mois et se consacrer à cette unique tâche.“
Pourquoi les “use cases” sont compris dans “Collaborer” dans la boussole ?
Il y a quelques années, lors d’une formation sur les use cases, Alistair expliquait que la rédaction de ces derniers nécessitait un dialogue entre les développeurs et le business. Quelques mois plus tard, à la surprise d’Alistair, la même entreprise lui a demandé une formation avancée sur les use cases.
Pourquoi ? Parce qu’ils pensaient que les use cases avaient permis de changer et d’améliorer leur organisation, ils souhaitaient donc, et ça se comprend, en apprendre davantage pour continuer à s’améliorer. Étonnant, car la mise en place de use cases ne produit a priori pas de changement d’organisation.
Alors que s’est-il passé ? Tout simplement, les membres de l’équipe se sont mis à échanger davantage entre eux afin de définir ces use cases : ce ne sont donc pas les use cases qui étaient responsables du changement d’organisation mais bien la collaboration qui en a découlé !
Et enfin, quelques lectures inspirantes selon Alistair Cockburn :
- The Goal de E.M. Goldratt
- Situated learning: Legitimate peripheral participation de Lave et Wenger
- Turn the ship around de David Marquets
