Agile vs Cascade ? - CTOMultiplier

Dans un monde o\u00f9 l’agilit\u00e9 est devenue la norme pour la gestion des projets logiciels, se demander si le mod\u00e8le 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\u00e9 si, pour les projets d’impl\u00e9mentation et de personnalisation d’un produit chez les clients, la gestion de projet traditionnelle pourrait \u00eatre plus int\u00e9ressante que l’utilisation d’une m\u00e9thodologie agile. Et la v\u00e9rit\u00e9, c’est que cela m’a sembl\u00e9 \u00eatre une bonne occasion d’\u00e9crire sur ce que l’Agile apporte par rapport aux mod\u00e8les plus traditionnels, \u00e0 destination d’un public de managers qui n’est pas si familier avec l’agilit\u00e9.

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\u00e9e \u00e0 leurs contextes.

La premi\u00e8re chose \u00e0 comprendre est que le mouvement Agile est n\u00e9 en r\u00e9ponse aux probl\u00e8mes li\u00e9s aux pratiques traditionnelles de gestion de projet des ann\u00e9es 1990, comme le mod\u00e8le en Cascade. Voyons ce que l’Agile cherche \u00e0 r\u00e9soudre :

Avec le mod\u00e8le en Cascade, la livraison au client avait g\u00e9n\u00e9ralement lieu \u00e0 la fin du projet, et parfois \u00e0 certains jalons pr\u00e9d\u00e9finis lors de la phase de planification du projet. Le probl\u00e8me est qu’ils ont r\u00e9alis\u00e9 que cette fa\u00e7on de travailler signifiait souvent que ce qui avait \u00e9t\u00e9 d\u00e9velopp\u00e9 ne r\u00e9pondait pas aux besoins r\u00e9els du client ou que ces besoins avaient chang\u00e9 pendant le d\u00e9veloppement. Cela entra\u00eenait que des projets entiers \u00e9taient jet\u00e9s apr\u00e8s des ann\u00e9es de d\u00e9veloppement. Pour r\u00e9soudre ce probl\u00e8me, l’Agile promeut des livraisons it\u00e9ratives fr\u00e9quentes qui permettent de :
- Livrer de la valeur au client \u00e0 un stade pr\u00e9coce
- Impliquer le client pendant le d\u00e9veloppement 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\u00e9sultats pour le client et consid\u00e8re le logiciel livr\u00e9 comme un moyen d’aider le client \u00e0 atteindre ces r\u00e9sultats ;
  - 1. que l’\u00e9quipe de d\u00e9veloppement ne perde pas de temps \u00e0 travailler sur des choses qui ne servent pas le client ;
  - 1. qu’il ne s’\u00e9coule pas trop de temps entre le moment o\u00f9 quelque chose est d\u00e9velopp\u00e9 et le moment o\u00f9 il est valid\u00e9 par le client, car il a \u00e9t\u00e9 d\u00e9montr\u00e9 que plus ce d\u00e9lai est long, plus le changement sera co\u00fbteux (intuitivement, on peut comprendre qu’il est beaucoup plus facile de modifier un document r\u00e9alis\u00e9 hier que d’en modifier un r\u00e9alis\u00e9 il y a un an).

Comment savoir si l’Agile est adapt\u00e9 \u00e0 votre projet :

Les projets sont-ils parfaitement sp\u00e9cifi\u00e9s d\u00e8s le d\u00e9part ou manquent-ils souvent de d\u00e9finition ?
Y a-t-il un avantage pour mes clients si je livre de la valeur le plus t\u00f4t possible puis de mani\u00e8re incr\u00e9mentale ? Ou au contraire, mes clients ne tirent-ils profit que lorsque tous les engagements sont livr\u00e9s ?
Y a-t-il une courbe d’apprentissage pour mes clients lors de l’utilisation de mon logiciel que je pourrais att\u00e9nuer en livrant le logiciel plus t\u00f4t ?
Par le pass\u00e9, lorsque mon client recevait le logiciel, correspondait-il toujours parfaitement \u00e0 ses besoins, ou les clients demandaient-ils souvent des modifications ?
L’\u00e9quipe r\u00e9alise-t-elle du travail qui est ensuite abandonn\u00e9 ?

Dans la gestion de projet traditionnelle, il y a g\u00e9n\u00e9ralement un Chef de Projet qui est responsable de toute la gestion du projet, discute avec les diff\u00e9rentes parties prenantes et planifie le d\u00e9roulement du projet du d\u00e9but \u00e0 la fin. L’\u00e9quipe de d\u00e9veloppement se situe g\u00e9n\u00e9ralement en dessous, \u00e9tant les ex\u00e9cutants mais avec peu de marge pour intervenir dans la d\u00e9finition, en r\u00e8gle g\u00e9n\u00e9rale. Le probl\u00e8me est que cette vision suppose que les aspects techniques doivent \u00eatre subordonn\u00e9s au business sans tenir compte du fait que cela peut signifier que des solutions extr\u00eamement co\u00fbteuses sont d\u00e9velopp\u00e9es ou que, dans certains cas, des solutions irr\u00e9alisables sont mises en place. Cela a un impact direct sur le business. L’Agile, en revanche, propose que les \u00e9quipes techniques et business travaillent davantage comme des partenaires, avec l’id\u00e9e que la solution propos\u00e9e satisfasse le business tout en \u00e9tant techniquement r\u00e9alisable. Cela n\u00e9cessite de donner un r\u00f4le plus important aux ing\u00e9nieurs de l’\u00e9quipe, ce qui leur permet de se sentir importants et partie prenante du projet, plus engag\u00e9s et plus performants.

Comment savoir si l’Agile est adapt\u00e9 \u00e0 votre projet :

Mes chefs de projet ont-ils du mal \u00e0 planifier et \u00e0 pr\u00e9voir correctement le co\u00fbt d’un projet ?
Le logiciel que je d\u00e9veloppe poss\u00e8de-t-il une certaine complexit\u00e9 technique ?
Le logiciel contient-il parfois des d\u00e9fauts de conception ou ne couvre-t-il pas enti\u00e8rement certains cas d’utilisation ?
L’\u00e9quipe semble-t-elle d\u00e9sengag\u00e9e ou peu impliqu\u00e9e ? Toutes les id\u00e9es viennent-elles du PM, et si le PM ne propose rien, rien ne se fait ?

Dans la gestion de projet en Cascade, la fa\u00e7on de travailler et les processus sont g\u00e9n\u00e9ralement bien d\u00e9finis et ne sont pas remis en question ni soumis \u00e0 une r\u00e9vision continue. Lorsqu’il y a des probl\u00e8mes, des approches traditionnelles telles que le remplacement de personnes ou l’ajout de personnel \u00e0 l’\u00e9quipe sont utilis\u00e9es. Cependant, de nombreuses preuves montrent que l’ajout de personnes \u00e0 un projet en retard tend \u00e0 le retarder davantage, car les membres de l’\u00e9quipe d\u00e9j\u00e0 surcharg\u00e9s devront consacrer du temps \u00e0 former les nouveaux membres, qui ont une courbe d’apprentissage pouvant \u00eatre de l’ordre de plusieurs mois. L’Agile, en revanche, met l’accent sur la fa\u00e7on de travailler, en acceptant qu’elle ne sera jamais parfaite et qu’elle doit \u00eatre continuellement revue et optimis\u00e9e. Cela se fait par des m\u00e9thodes empiriques dans lesquelles la performance du processus est mesur\u00e9e \u00e0 travers des m\u00e9triques, des ajustements et des changements sont effectu\u00e9s en fonction de ces m\u00e9triques et des observations de l’\u00e9quipe lors des r\u00e9trospectives \u00e0 chaque it\u00e9ration de d\u00e9veloppement (qui durent quelques semaines). Consid\u00e9rant que nous vivons dans un monde en constante \u00e9volution, l’Agile nous permet de nous concentrer sur l’am\u00e9lioration du processus pour nous adapter aux nouveaux contextes et b\u00e9n\u00e9ficier des nouveaux outils et fa\u00e7ons de faire \u00e0 mesure qu’ils apparaissent, tant qu’ils ont du sens pour nous.

Comment savoir si l’Agile est adapt\u00e9 \u00e0 votre projet :

Je connais souvent des retards dans mes projets et je ne suis pas s\u00fbr de la raison ?
Les personnes de l’\u00e9quipe se plaignent-elles fr\u00e9quemment de la fa\u00e7on de travailler ou du processus ?
Mon processus a-t-il subi peu de changements ces derni\u00e8res ann\u00e9es ?

La concurrence pour les ing\u00e9nieurs est actuellement assez \u00e9lev\u00e9e et ces derni\u00e8res ann\u00e9es, cette tendance ne fait qu’augmenter (si vous parlez \u00e0 des CTO et des leaders techniques, ils vous diront probablement que c’est l’une de leurs plus grandes pr\u00e9occupations). Cela permet aux d\u00e9veloppeurs de devenir de plus en plus exigeants et s\u00e9lectifs lorsqu’il s’agit de rejoindre une entreprise. Le salaire, bien que crucial, n’est pas la seule raison pour laquelle un d\u00e9veloppeur change d’entreprise ; des \u00e9l\u00e9ments comme la technologie, les opportunit\u00e9s de d\u00e9veloppement de carri\u00e8re et le travail d’\u00e9quipe sont \u00e9galement pris en compte. Il est vrai que pas mal de d\u00e9veloppeurs ne sont pas tr\u00e8s satisfaits de Scrum comme m\u00e9thode de travail, mais il est difficile de croire qu’ils seraient motiv\u00e9s pour rejoindre une entreprise utilisant le Waterfall des ann\u00e9es 90. Bien s\u00fbr, le monde des d\u00e9veloppeurs est h\u00e9t\u00e9rog\u00e8ne et il est difficile de g\u00e9n\u00e9raliser, mais je dirais que la plupart des programmeurs seniors (et moins seniors) seront int\u00e9ress\u00e9s par la m\u00e9thodologie qu’ils vont utiliser. Et je suis s\u00fbr 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\u00e9sint\u00e9r\u00eat et si ce sont les profils que nous voulons pour notre \u00e9quipe.

Comment savoir si l’Agile est adapt\u00e9 \u00e0 votre projet :

Je me soucie d’attirer les talents, et je suis conscient que les d\u00e9veloppeurs 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\u00e9 un framework Agile, comme Scrum, mais qu’il y ait le sentiment que l’am\u00e9lioration attendue ne s’est pas produite. Cela peut arriver et arrive pour une multitude de raisons telles que : le manque de personnes dans l’\u00e9quipe qui comprennent r\u00e9ellement l’Agile, l’adoption d’un framework inadapt\u00e9 \u00e0 notre r\u00e9alit\u00e9 (Scrum est tr\u00e8s r\u00e9pandu mais ce n’est pas la seule alternative et souvent pas la plus recommand\u00e9e, vous pouvez lire sur les diff\u00e9rentes alternatives ici), la mise en oeuvre de pratiques sans adopter les valeurs et principes agiles (c’est-\u00e0-dire ne pas changer l’\u00e9tat d’esprit), le manque de compr\u00e9hension 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 \u00e0 accueillir les changements de p\u00e9rim\u00e8tre du projet et \u00e0 impliquer le client pendant le d\u00e9veloppement comme le meilleur moyen de s’assurer que le r\u00e9sultat obtenu est optimal (connu sous le nom de co-cr\u00e9ation). Il met \u00e9galement en \u00e9vidence l’importance pour la technologie et le business de travailler main dans la main comme moyen d’obtenir les meilleurs r\u00e9sultats \u00e0 un co\u00fbt ma\u00eetris\u00e9. Et il promeut une nouvelle culture dans laquelle l’am\u00e9lioration continue permet d’optimiser le business tout en prenant soin du bonheur de nos clients et de nos \u00e9quipes. Cependant, l’Agile n’est pas non plus parfait, et ces derni\u00e8res ann\u00e9es, de plus en plus d’initiatives ont \u00e9merg\u00e9 qui parlent des nombreux probl\u00e8mes rencontr\u00e9s dans sa mise en oeuvre et de la fa\u00e7on de faire \u00e9voluer la philosophie en utilisant les enseignements des 20 ann\u00e9es depuis la d\u00e9finition du manifeste Agile.

Si vous \u00eates confront\u00e9 au dilemme de choisir quelle m\u00e9thodologie de travail adopter, ma recommandation est de parler \u00e0 quelqu’un d’exp\u00e9riment\u00e9 avant de vous lancer dans un choix bas\u00e9 sur des crit\u00e8res peu solides. Une m\u00e9thodologie inappropri\u00e9e peut mettre des b\u00e2tons dans les roues de la performance d’une \u00e9quipe.