Waterfall et transition Agile

Modèle en V et Agilité

Le modèle en V et l’agilité sont deux réponses à deux questions différentes. Chacun de ces modèles sont les meilleures réponses à ces questions qu’on connaisse à ce jour. Des dizaines d’années (40 pour waterfall et 20 pour agile) d'affûtage dans une direction donnée.

La question à laquelle répond le modèle en V est “Comment s’assurer de faire tout le cahier des charges dans le budget ?”. Un projet réussi dans ce modèle de la DSI classique est un projet qui respecte le cahier des charges en maîtrisant les coûts, les délais et la qualité finale. Donc il faut s’assurer que le cahier des charges ne bouge pas, qu’on pense à tous les éléments dès le début et qu’on dépense le moins possible dans la réalisation.

La question à laquelle répond le modèle Agile est “Comment s’assurer d’atteindre l’objectif business dans le budget ?”. L’idée de l’agilité c’est de recoller la définition d’un projet réussi avec la définition de l’entreprise : un projet réussi est un projet qui rapporte plus que ce qu’il a coûté. Le but n’est plus de tout faire dans le budget, mais de trouver le chemin le plus court vers l’objectif.

Quand on vous dit qu’avec l’agile vous irez plus vite pour moins cher, ça n’est vrai que si vous changez la question à laquelle vous répondez. Sinon c’est un mensonge.

Adopter le modèle Agile quand votre objectif est de répondre à la première question, de réaliser le cahier des charges dans le budget, n’aura que des résultats très marginaux : les performances vont augmenter légèrement, les coûts aussi.

Les objectifs de l’agilité

Donc le but de l’agilité c’est de mieux réussir les projets, quand réussir un projet veut dire s’assurer qu’il rapporte plus que ce qu’il a coûté.

L’agilité c’est la rencontre explosive entre deux idées, deux constats :

Le 1er constat, c’est que chaque idée de business, de projet, de fonctionnalité est en fait une hypothèse, un pari et que le seul moyen de savoir si l’hypothèse est bonne, c’est de la mettre entre les mains des utilisateurs.

Dans le modèle classique, on considère chaque idée comme un besoin. C’est du dur, il n’y a pas de question. Mais si on s’inquiète du résultat de chacune de ces idées, alors il faut admettre la part d’incertitude, admettre que ces besoins n’en sont peut être pas. Plutôt que de dire “il faut faire ça”, on apprend à dire “on pense que si on fait ça, alors on obtiendra tel résultat”.

Il y a donc un enjeu à faire de plus petites hypothèses, de plus petits paris et de les valider ou les invalider au plus vite : c’est mieux de perdre deux jours de travail que deux ans suite à une mauvaise idée.

Donc le 1er objectif de l’agilité c’est d’adopter des outils et des pratiques qui permettent de raccourcir le délai entre l’idée et la mise entre les mains des utilisateurs.

Le 2ème constat c’est la conséquence directe du premier : on fait des hypothèses, on les met rapidement dans les mains des utilisateurs… et on apprend.

Si c’était une bonne idée, est ce qu’il n’est pas plus intéressant de continuer à extraire de la valeur plutôt que de passer à l’idée suivante ? Si le résultat n’est pas exactement là, est ce qu’il est possible d’ajuster ? Si l’idée était en fait mauvaise, voire nocive, est ce qu’il ne vaut mieux pas revenir en arrière ?

Le projet mené de façon agile est une succession rapide d’idées et d’apprentissages. Chaque apprentissage apporte un changement, dans le code, dans le produit fini, dans la roadmap.

Donc le 2ème objectif de l’agilité c’est d’adopter des outils et des pratiques qui permettent d’accepter le changement et les apprentissages tout au long du projet.

Transition agile en V ou transition agile agile

Malheureusement, dans le milieu, beaucoup de transitions agiles sont menées comme des projets en V. J’ai souvent vu des transitions dont les critères de succès étaient la conformité à la méthode (scrum ou safe), au lieu de s’inquiéter des résultats.

Le but ce n’est pas d’être Scrum. D’ailleurs, ce n’est pas parce que vous êtes Scrum que vous êtes agile. Scrum vous permet de devenir agile.

Le but ce n’est pas non plus d’être agile. Le but c’est de mieux réussir vos projets.

Si le critère de succès est la conformité à la méthode, alors la transition est très facile : on met tout le monde de la DSI 2j en formation certifiante© à la Défense et le tour est joué. J’ai même vu des sociétés de conseil qui envoyaient des consultants fraîchement sortis de l’école pour des transitions Safe. Encore une fois, si l’objectif est seulement de coller à la spec, n’importe qui peut le faire.

Si le critère de succès est une meilleure réussite des projets, alors on se rend compte que la transition est dure et complexe et qu’elle concerne toute l’entreprise, pas seulement la DSI.

La transition agile est très dure, pour tout le monde

Pour réussir les projets, toutes les personnes impliquées de près ou de loin dans les projets vont devoir changer leurs façon de travailler.

Beaucoup d’initiatives agile ont lieu uniquement dans la partie réalisation (moa + dev + test) et sans changer la question sous jacente. En général, le résultat pour l’entreprise est négligeable.

La transition agile doit se faire aussi chez le management et la direction, dans le produit (métier et utilisateurs) et chez les opérations (prod).

Après 30 ans de renforcement par les objectifs dans le modèle en V, les employés sont affutés et spécialisés pour aller dans cette direction. En changeant de modèle, vous allez vous rendre compte que certaines compétences qui étaient très utiles deviennent obsolètes et d’autres vont devenir vitales et il faudra les acquérir.

Il est impératif que la direction protège les employés et les aide à changer. Toute transition qui se fait sans que la direction et le management mouillent le maillot est vouée à l’échec.

Les managers d’équipe vont aussi devoir changer, parce que les modèles d’équipe vont changer. On passe de centres de services où le manager est un superviseur qui attribue les tâches et optimise les pourcentages d’affectation aux équipes transverses autonomes qui gèrent leurs tâches et qui sont affectées à 100% (les feature teams). Il va falloir aligner, accompagner, mentorer et aider les équipes plutôt que de leur dire quoi faire et comment.

Les développeurs ont un objectif traditionnellement : faire un code conforme à la spec et qui fonctionne. Maintenant il s’ajoute un deuxième objectif qui change radicalement la façon de travailler : le code doit être facilement changeable. Il doit être fait pour retirer tous les risques liés aux changements. C’est seulement comme ça que l’équipe pourra suivre un rythme d’hypothèses / validations / apprentissages élevé.

Les testeurs vont devoir apprendre à écrire leurs suites de tests avant que le développement ne commence, comme une partie des spécifications. Ces tests devront être, dans la mesure du possible, automatisés par l’équipe de développement. Tout le temps gagné sur le pointage pourra être consacré aux tests exploratoires.

Le changement MOA vers PO est un des plus durs. Un rythme plus “temps réel”, des spécifications plus poussées, et cette toute nouvelle dimension qu’est l’apprentissage en cours de projet !

La partie produit (PO + métier + utilisateurs) voit son principal outil, la roadmap, changer complètement à cause de cette simple question : qu’est ce qu’il se passe si une des idées est mauvaise ? (Il y en aura plus d’une)

Enfin, vous avez une démarche produit agile et une équipe de réalisation qui travaille vite et bien, mais si vous ne pouvez livrer qu’une fois par mois et qu’un retour en arrière ne peut se faire que par patch, vous n’irez pas loin. La partie ops doit profiter du mouvement DevOps pour re-répartir les tâches et permettre de nouvelles capacités comme le delivery continu, la mise en production progressive et les retours en arrière faciles, tout en continuant de garantir la stabilité, performance et sécurité des applications.

Ça fait beaucoup de choses à changer et à apprendre. Et ça demande à ce que tout le monde s’investisse réellement. Ça ne peut pas être une initiative locale si on souhaite obtenir des résultats à l’échelle de l’entreprise.

---

Bonus : bien choisir son coach

Quand vous faites appel à un coach pour vous aider dans votre transition, il faut bien cadrer son domaine d’intervention en amont !

Ne pensez pas que les coachs sont interchangeables. J’ai vu trop souvent un mandataire prendre un coach “générique”, ne pas avoir cadré sa mission et être déçu parce qu’il est intervenu ailleurs que là où on l’attendait.

Vous ne trouverez pas de coach qui soit compétent pour vous aider à la fois au produit, à la réalisation, à la prod, pour le management, l’organisation, le passage à l’échelle etc... Vous aurez très certainement besoin de plusieurs coachs pour tout couvrir.

Une bonne façon de constituer l’équipe de coach est d’en trouver un qui nous plaît et de lui demander de proposer des profils pour le reste de l’équipe. S’ils savent déjà travailler ensemble, c’est un bon point pour vous.

Enfin, la botte secrète, une question à vous poser avant d’embaucher un coach : quels sont les critères de succès de sa mission ? C’est une question que j’ai commencée à poser en entretien pour m’assurer d’être sur la même longueur d’onde que mon client. Autrement dit : “Imaginons, nous sommes un an plus tard et vous êtes ravi de mon intervention. Quels résultats on peut observer ?”