Agile vs Cascade ? - Fractional CTO

Dans un monde où l’agilité est devenue la norme pour la gestion des projets logiciels, se demander si le modèle en Cascade et la gestion de projet traditionnelle est une option semble inimaginable. Pourtant, l’autre jour, en discutant avec un manager, il m’a demandé si, pour les projets d’implémentation et de personnalisation d’un produit chez les clients, la gestion de projet traditionnelle pourrait être plus intéressante que l’utilisation d’une méthodologie agile. Et la vérité, c’est que cela m’a semblé être une bonne occasion d’écrire sur ce que l’Agile apporte par rapport aux modèles plus traditionnels, à destination d’un public de managers qui n’est pas si familier avec l’agilité.

Je souhaite donc revisiter (sans trop approfondir) le pourquoi de l’Agile et poser quelques questions que les leaders peuvent se poser, afin de comprendre si l’Agile est une philosophie adaptée à leurs contextes.

La première chose à comprendre est que le mouvement Agile est né en réponse aux problèmes liés aux pratiques traditionnelles de gestion de projet des années 1990, comme le modèle en Cascade. Voyons ce que l’Agile cherche à résoudre :

Avec le modèle en Cascade, la livraison au client avait généralement lieu à la fin du projet, et parfois à certains jalons prédéfinis lors de la phase de planification du projet. Le problème est qu’ils ont réalisé que cette façon de travailler signifiait souvent que ce qui avait été développé ne répondait pas aux besoins réels du client ou que ces besoins avaient changé pendant le développement. Cela entraînait que des projets entiers étaient jetés après des années de développement. Pour résoudre ce problème, l’Agile promeut des livraisons itératives fréquentes qui permettent de :
- Livrer de la valeur au client à un stade précoce
- Impliquer le client pendant le développement en demandant des retours pour ajuster le cap, en garantissant :
  - 1. que la solution serve les objectifs du client. Note importante : l’Agile se concentre sur les résultats pour le client et considère le logiciel livré comme un moyen d’aider le client à atteindre ces résultats ;
  - 1. que l’équipe de développement ne perde pas de temps à travailler sur des choses qui ne servent pas le client ;
  - 1. qu’il ne s’écoule pas trop de temps entre le moment où quelque chose est développé et le moment où il est validé par le client, car il a été démontré que plus ce délai est long, plus le changement sera coûteux (intuitivement, on peut comprendre qu’il est beaucoup plus facile de modifier un document réalisé hier que d’en modifier un réalisé il y a un an).

Comment savoir si l’Agile est adapté à votre projet :

Les projets sont-ils parfaitement spécifiés dès le départ ou manquent-ils souvent de définition ?
Y a-t-il un avantage pour mes clients si je livre de la valeur le plus tôt possible puis de manière incrémentale ? Ou au contraire, mes clients ne tirent-ils profit que lorsque tous les engagements sont livrés ?
Y a-t-il une courbe d’apprentissage pour mes clients lors de l’utilisation de mon logiciel que je pourrais atténuer en livrant le logiciel plus tôt ?
Par le passé, lorsque mon client recevait le logiciel, correspondait-il toujours parfaitement à ses besoins, ou les clients demandaient-ils souvent des modifications ?
L’équipe réalise-t-elle du travail qui est ensuite abandonné ?

Dans la gestion de projet traditionnelle, il y a généralement un Chef de Projet qui est responsable de toute la gestion du projet, discute avec les différentes parties prenantes et planifie le déroulement du projet du début à la fin. L’équipe de développement se situe généralement en dessous, étant les exécutants mais avec peu de marge pour intervenir dans la définition, en règle générale. Le problème est que cette vision suppose que les aspects techniques doivent être subordonnés au business sans tenir compte du fait que cela peut signifier que des solutions extrêmement coûteuses sont développées ou que, dans certains cas, des solutions irréalisables sont mises en place. Cela a un impact direct sur le business. L’Agile, en revanche, propose que les équipes techniques et business travaillent davantage comme des partenaires, avec l’idée que la solution proposée satisfasse le business tout en étant techniquement réalisable. Cela nécessite de donner un rôle plus important aux ingénieurs de l’équipe, ce qui leur permet de se sentir importants et partie prenante du projet, plus engagés et plus performants.

Comment savoir si l’Agile est adapté à votre projet :

Mes chefs de projet ont-ils du mal à planifier et à prévoir correctement le coût d’un projet ?
Le logiciel que je développe possède-t-il une certaine complexité technique ?
Le logiciel contient-il parfois des défauts de conception ou ne couvre-t-il pas entièrement certains cas d’utilisation ?
L’équipe semble-t-elle désengagée ou peu impliquée ? Toutes les idées viennent-elles du PM, et si le PM ne propose rien, rien ne se fait ?

Dans la gestion de projet en Cascade, la façon de travailler et les processus sont généralement bien définis et ne sont pas remis en question ni soumis à une révision continue. Lorsqu’il y a des problèmes, des approches traditionnelles telles que le remplacement de personnes ou l’ajout de personnel à l’équipe sont utilisées. Cependant, de nombreuses preuves montrent que l’ajout de personnes à un projet en retard tend à le retarder davantage, car les membres de l’équipe déjà surchargés devront consacrer du temps à former les nouveaux membres, qui ont une courbe d’apprentissage pouvant être de l’ordre de plusieurs mois. L’Agile, en revanche, met l’accent sur la façon de travailler, en acceptant qu’elle ne sera jamais parfaite et qu’elle doit être continuellement revue et optimisée. Cela se fait par des méthodes empiriques dans lesquelles la performance du processus est mesurée à travers des métriques, des ajustements et des changements sont effectués en fonction de ces métriques et des observations de l’équipe lors des rétrospectives à chaque itération de développement (qui durent quelques semaines). Considérant que nous vivons dans un monde en constante évolution, l’Agile nous permet de nous concentrer sur l’amélioration du processus pour nous adapter aux nouveaux contextes et bénéficier des nouveaux outils et façons de faire à mesure qu’ils apparaissent, tant qu’ils ont du sens pour nous.

Comment savoir si l’Agile est adapté à votre projet :

Je connais souvent des retards dans mes projets et je ne suis pas sûr de la raison ?
Les personnes de l’équipe se plaignent-elles fréquemment de la façon de travailler ou du processus ?
Mon processus a-t-il subi peu de changements ces dernières années ?

La concurrence pour les ingénieurs est actuellement assez élevée et ces dernières années, cette tendance ne fait qu’augmenter (si vous parlez à des CTO et des leaders techniques, ils vous diront probablement que c’est l’une de leurs plus grandes préoccupations). Cela permet aux développeurs de devenir de plus en plus exigeants et sélectifs lorsqu’il s’agit de rejoindre une entreprise. Le salaire, bien que crucial, n’est pas la seule raison pour laquelle un développeur change d’entreprise ; des éléments comme la technologie, les opportunités de développement de carrière et le travail d’équipe sont également pris en compte. Il est vrai que pas mal de développeurs ne sont pas très satisfaits de Scrum comme méthode de travail, mais il est difficile de croire qu’ils seraient motivés pour rejoindre une entreprise utilisant le Waterfall des années 90. Bien sûr, le monde des développeurs est hétérogène et il est difficile de généraliser, mais je dirais que la plupart des programmeurs seniors (et moins seniors) seront intéressés par la méthodologie qu’ils vont utiliser. Et je suis sûr qu’il y en aura d’autres pour qui cela n’a pas d’importance, mais dans ce cas, nous devrions nous demander pourquoi ce désintérêt et si ce sont les profils que nous voulons pour notre équipe.

Comment savoir si l’Agile est adapté à votre projet :

Je me soucie d’attirer les talents, et je suis conscient que les développeurs ont de plus en plus de choix et exigent plus qu’un bon salaire ?

Il se peut aussi que l’organisation dans cette situation ait adopté un framework Agile, comme Scrum, mais qu’il y ait le sentiment que l’amélioration attendue ne s’est pas produite. Cela peut arriver et arrive pour une multitude de raisons telles que : le manque de personnes dans l’équipe qui comprennent réellement l’Agile, l’adoption d’un framework inadapté à notre réalité (Scrum est très répandu mais ce n’est pas la seule alternative et souvent pas la plus recommandée, vous pouvez lire sur les différentes alternatives ici), la mise en oeuvre de pratiques sans adopter les valeurs et principes agiles (c’est-à-dire ne pas changer l’état d’esprit), le manque de compréhension et de soutien de la direction, etc. Si vous souhaitez mieux comprendre pourquoi l’Agile ne fonctionne pas toujours, vous pouvez lire cet article.

En conclusion, l’Agile vise à accueillir les changements de périmètre du projet et à impliquer le client pendant le développement comme le meilleur moyen de s’assurer que le résultat obtenu est optimal (connu sous le nom de co-création). Il met également en évidence l’importance pour la technologie et le business de travailler main dans la main comme moyen d’obtenir les meilleurs résultats à un coût maîtrisé. Et il promeut une nouvelle culture dans laquelle l’amélioration continue permet d’optimiser le business tout en prenant soin du bonheur de nos clients et de nos équipes. Cependant, l’Agile n’est pas non plus parfait, et ces dernières années, de plus en plus d’initiatives ont émergé qui parlent des nombreux problèmes rencontrés dans sa mise en oeuvre et de la façon de faire évoluer la philosophie en utilisant les enseignements des 20 années depuis la définition du manifeste Agile.

Si vous êtes confronté au dilemme de choisir quelle méthodologie de travail adopter, ma recommandation est de parler à quelqu’un d’expérimenté avant de vous lancer dans un choix basé sur des critères peu solides. Une méthodologie inappropriée peut mettre des bâtons dans les roues de la performance d’une équipe.