Dans ce chapitre, nous nous attarderons sur un projet agile qui fût un « échec ». Par échec, je ne veux pas dire pas que le produit n’a jamais vu le jour mais plutôt que le projet, ou devrais-je dire le produit, a :
- Explosé les coûts prévus
- Explosé le temps prévu (près de 18 mois au lieu des 6 annoncés initialement)
- Eté beaucoup moins efficace que le même type d’application en cycle en V
Afin de savoir comment cela est arrivé – et donc de vous permettre d’éviter ces erreurs – nous allons étudier ce cas en le présentant, en resituant le contexte mais surtout en analysant les erreurs commises.
Il est important de noter qu’un grand nombre de ces erreurs ont été remontées et corrigées au cours et à la fin du projet. Ce projet, qui était le projet pilote, aura finalement été très instructif et aura permis de beaucoup mieux implémenter l’agilité sur les projets d’après.
Les différentes parties de ce chapitre seront :
- Le projet
- Contexte du projet
- L’équipe projet
- L’implémentation de l’agilité à l’équipe
- Les dérives liées au « cycle en V »
- L’impact de la non-qualité
- Epilogue du projet
- L’analyse des erreurs
- Pourquoi ces retards ?
- Echec sur l’état d’esprit
- Ce que ce projet a apporté
- Conclusion
Le projet
Tout d’abord, je tiens à préciser que le terme « projet » est voulu. Dans les méthodes agiles, on parle généralement de produit mais dans ce contexte nous verrons que l’aspect projet avec un cycle en V classique a fortement impacté de nombreuses décisions qui se sont avérées, sur le moyen terme, de graves erreurs pour un produit agile.
- Contexte du projet
Ce projet s’est déroulé au début des années 2010, il y a plus de 5 ans au moment où j’écris ces lignes. Le but du projet était de proposer une application mail mobile pour tablettes.
Nous étions dans une équipe expérimentée qui avait une forte expérience de ce type d’application. Cette même équipe avait, à ce moment, déjà développé avec succès des web-applications ainsi que des applications natives qui recevaient un très bon accueil de nos clients.
Forts de cette expérience et profitant du succès des autres applications développées, nous avons commencé le projet en toute confiance, en ayant décidé de développer cette application avec une méthode très récente et qui semblait prometteuse : le Scrum.
Nous avons commencé par nous former, étudier les différentes cérémonies, la gestion du backlog, des sprints…
Suite à cela nous avons commencé le projet.
- L’équipe projet
Nous étions conscients que cette application servait également de projet pilote pour cette méthode de développement et avions à cœur de bien faire. Pour composer l’équipe agile, nous avons fait appel à des développeurs expérimentés sur des application mails avec une lead tech (oui, notre lead tech était une femme, très compétente et consciencieuse), notre business analyste le plus compétent et expérimenté ainsi que moi-même. J’étais le testeur attitré car j’avais travaillé sur toutes les autres applications au fonctionnel similaire. Nous avions même un « ingénieur DevOps » – en fait l’équivalent d’un Ops – qui assistait à nos cérémonies et travaillait en partie sur le projet. En revanche, le langage de programmation était nouveau pour tout le monde.
Néanmoins, nous pouvons voir que, comme je l’ai conseillé dans le chapitre sur la transformation agile, nous n’avions pas donné ce projet pilote à une équipe de débutants.
Par rapport à la constitution d’une équipe « pluridisciplinaire » l’équipe était déjà habituée à travailler dans le même bureau et à beaucoup échanger, certaines bonnes pratiques agiles sont aussi des bonnes pratiques pour le cycle en V. En tant que testeur agile, j’ai travaillé sur 2 activités principales : la revue des spécifications et les tests, mais aussi sur d’autres projets, si besoin de testeurs pour des campagnes. Nous touchions dès lors un problème sur « l’équipe agile » car, à part les développeurs, les autres membres (le testeur, le DevOps, le business analyste) n’étaient pas à plein temps dans l’équipe. De même, lors des campagnes (manuelles) de test, l’automatisation s’étant avéré un échec, j’étais accompagné… d’autres testeurs, au lieu des autres membres de l’équipe agile.
- L’implémentation de l’agilité à l’équipe
L’agilité devait permettre de livrer plus vite l’application, le « temps nécessaire » alloué aux différentes fonctionnalités avait alors été diminué par rapport aux estimations de notre lead Tech afin de pouvoir livrer un produit complet dans le temps disponible (6 mois)
Bon, ça ne faisait pas très « agile » :
- Les membres de l’équipe n’étaient pas totalement dédiés à l’application
- il y avait des membres « temporaires » pour les campagnes de test
- la durée totale ainsi que le périmètre final étaient déjà prévus
Nous avions remarqué ces points, les avions fait remonter de manière informelle à notre hiérarchie mais avions tout de même décidé de commencer dans ces conditions. Le point fort de l’agilité n’est-il pas justement de savoir s’adapter ?
Nous avions donc décidé de commencer à travailler sur notre projet. Nous avions 6 sprints de 4 semaines chacun qui étaient prévus. Chaque sprint était déjà pré-rempli avec des User-story à livrer pour ces sprints. Bref, nous avions donc un périmètre (en terme de fonctionnalité et de temps) bien défini. Cela ressemblait déjà fortement à un Cycle en V, ou tout du moins à 6 mini cycles en V. Cette ressemblance s’est vite avérée être davantage que cela, ce qui a été la source d’un grand nombre de nos maux.
- Les dérives liées au « cycle en V »
C’est ici que le bât blesse. Le cycle en V que nous maîtrisions parfaitement a refait surface et a débordé un peu partout sur notre projet.
Certes, nous faisions des daily meeting quotidiens. Ces daily meeting étaient d’ailleurs bien implémentés et ne duraient jamais plus de 15 minutes, chacun parlait de ses tâches, de ses difficultés, … Nous avions également une présentation des User Story pour présenter le sprint backlog.
Néanmoins, le contenu du sprint était déjà convenu à l’avance et il était impossible de le modifier. De même, par manque de temps, nous n’avons pas fait de rétrospectives. A quoi bon ? On échangeait tous les jours, s’il y avait quelque chose à faire, il suffisait de le dire, non ?
Bref, nous nous sommes retrouvés dès le premier sprint avec un grand nombre d’US à implémenter. Ces US ne pouvaient pas être décalées car le deuxième sprint était déjà plein. Les développeurs ont donc développé aussi vite qu’ils ont pu, pour livrer l’ensemble des US à quelques jours de la fin du sprint. Comme pour du Cycle en V, les tests se retrouvaient à la fin. Et bien évidemment, comme pour un cycle en V avec des temps estimés trop faibles, les tests ont « retardé » la fin du projet… pardon, du sprint !
De plus, les développements ayant été faits trop vite, les tests ont remonté un fort taux d’anomalies plus ou moins bloquantes. Un certain nombre de ces anomalies ont été corrigées dans le 1er sprint qui aura finalement duré 6 semaines (au lieu de 4), les autres bugs, quant à eux, ont été ajoutés au sprint 2.
Sprint 2, l’histoire se répète avec un retard supplémentaire, dû au périmètre encore plus important que le périmètre suivant.
Et cela a continué jusqu’à la fin du sprint 4. A ce moment-là, l’impact de la non-qualité ne pouvait plus être ignoré !
- L’impact de la non-qualité
En agile, on a coutume de dire que la qualité est non négociable. La théorie explique que la dette fait un effet boule de neige, que l’on est vite dépassé et qu’à la fin, on ne peut plus rien garantir ou maintenir.
La pratique va encore plus loin !
Souvenez-vous du paragraphe précédent. « Certains bugs » étaient remis à plus tard, les développements étaient faits aussi rapidement que possible. Dans notre cas, le travail des développeurs s’est mué en 100% de correction de bugs. Malheureusement, chaque correction engendrait de nouveaux bugs… De nouveaux bugs étaient détectés à chaque utilisation, je n’avais besoin que de 10 secondes pour faire crasher l’application, le composeur n’envoyait pas tous les caractères que nous avions écrits… Bref, les nouvelles fonctionnalités ne pouvaient plus être développées, nous étions totalement bloqués avec l’impossibilité d’avancer sur le produit.
La solution, nous l’avions identifiée. Mais malheureusement trop tard. Elle s’avérait en fait assez simple. Cette solution était de mettre en échec les US qui n’étaient pas finies au sprint 1 pour les mettre au sprint 2. De revoir le backlog du sprint 2 en fonction et de faire une rétrospective. Cette solution n’était malheureusement plus implémentable et nous avions atteint un point de non-retour : 6 mois pour s’apercevoir que nous étions totalement bloqués !
- Epilogue du projet
Nous avons finalement décidé de repartir de (quasiment) zéro mais en étant, cette fois-ci, intransigeants sur la qualité, en gardant une durée de sprint toujours égale et en modifiant le périmètre si besoin. Nous avions également suivi, entre temps, des formations et ateliers de formateurs agiles compétents. L’expérience des 6 premiers mois a aussi permis à l’équipe de mieux appréhender le langage qui n’était pas connu au départ… En mettant réellement en place l’ensemble des cérémonies car nous avions appris – au prix fort – leur utilité.
Le projet est alors reparti sur de bonnes bases, les tests ont été le plus possible automatisés, les tests vitaux communiqués aux développeurs et le produit a pu être développé et proposer une version au niveau de qualité souhaité.
En revanche, certains reliquats du cycle en V sont restés. Nous considérions avoir atteint un produit minimal mais n’avons été autorisés à proposer le produit au client qu’une fois l’intégralité du périmètre développé. De plus, le « métier » qui n’avait pas assisté aux démos (je sais, ce n’est pas agile non plus) voulait avoir sa session de test (la partie tout en haut à droite du cycle en V) à la toute fin du projet.
Néanmoins, ce projet arriva à une fin heureuse… Mais une fin beaucoup plus tardive que prévue et un projet beaucoup plus onéreux également.
L’analyse des erreurs
- Pourquoi ces retards ?
Ce projet d’une durée prévue de 6 mois a finalement eu 1 an de retard. Il y a plusieurs raisons à cela, certaines ne sont pas liées à l’agilité et sont :
- Le fait d’avoir dévalué les estimations de notre Lead Tech (qui se sont avérées, à terme, exactes à plus de 90%). Ce problème n’est pas lié directement à l’agilité mais plutôt à la dérive liée au fait de passer à l’agilité : sortir l’application plus tôt ne signifie pas sortir l’application avec le même périmètre plus tôt !
- Avoir négligé la qualité dans le but de proposer plus rapidement quelque chose
- Avoir un périmètre figé, ce qui est contraire à l’esprit agile. En agilité, la variable, c’est le périmètre !
- Echec sur l’état d’esprit
Le principal problème sur ce projet vient justement du fait que l’application était considérée comme un projet et non comme un produit. Nous avons travaillé comme dans un cycle en V mais dans un carcan Scrum.
Le résultat a été désastreux. Ce qui peut être acceptable sur du cycle en V – c’est-à-dire faire des concessions sur la qualité avant une mise en service – est totalement incompatible avec le Scrum et les sprints où chaque concession se retrouve à coûter beaucoup plus à moyen, voire à court terme.
Un autre problème est que par « adaptabilité » de l’agilité nous avions compris que l’on pouvait faire tout et n’importe quoi, que le modèle d’adapterait. Là encore, cela s’est avéré totalement faux. L’agilité est là pour s’adapter au changement, aux retours des utilisateurs. L’adaptabilité n’est pas au niveau de la qualité, de la méthodologie ou même des processus (qui doivent être décidés par l’équipe et qui restent modifiable lors des rétrospectives) mais au niveau du périmètre. Malheureusement, nous avions implémenté exactement le contraire, tout était adaptable à volonté… sauf le périmètre.
- Ce que ce projet a apporté
Ce projet pilote, même s’il s’est avéré être un échec d’un point de vue projet s’est avéré être une mine d’informations. Il a joué son rôle de projet pilote en exposant les difficultés que tout autre projet aurait rencontré dans notre contexte.
Nous y avons notamment appris :
- L’importance de penser produit et pas projet : penser projet induit une dérive cycle en V avec les tests à la fin, garder toujours le même périmètre, utiliser le délai ou la qualité comme variable d’ajustement.
- L’importance d’automatiser les tests : l’exécution des tests prend très vite beaucoup de temps. L’agilité « force » une automatisation des tests qui peuvent revenir plusieurs fois dans la semaine.
- L’importance de bien gérer ses tests : et savoir trier entre les tests utilisés une seule fois et ceux qui seront utilisés.
- La puissance des tests exploratoires : avec la possibilité, après avoir ciblé des risques, de faire des sessions pour les couvrir sans concevoir et écrire à l’avance des tests qui ne seront exécutés qu’une unique fois.
- L’intransigeance sur la qualité : là encore, cela parait basique, on nous le répète à volonté, cela fait même partie des piliers de SaFe… Néanmoins on n’adhère généralement à ce concept qu’après avoir subi le « traumatisme » de la non qualité. Cela est encore plus important pour toutes les méthodes incrémentales (et donc toutes les méthodes agiles). On ne construit pas sur des fondations friables. En agilité, les fondations, c’est le produit lui-même !
- La flexibilité sur le périmètre : C’est le vrai point fort de l’agilité. On s’adapte aux retours des utilisateurs, à leurs demandes, on peut définir un produit minimal pour être en production plus rapidement.
- L’importance d’avoir une formation appropriée : on ne devient pas agile en lisant des livres. Une mise en pratique et formation appropriées, notamment à travers des ateliers, sont un passage primordial et permettent d’éviter un grand nombre d’erreurs.
- L’importance de chaque cérémonie Scrum… Et notamment la Rétrospective qui aurait permis, dès le sprint 1, de rectifier certains problèmes mais surtout de ne pas se retrouver dans l’impasse de la fin du sprint 4.
Au-delà de cet apprentissage, ce projet nous a permis de mieux cerner la « philosophie Agile ». Là où nous considérions, comme beaucoup, que le manifeste agile pouvait se traduire par l’abandon des processus et de la documentation, nous avons découvert qu’en fait ces derniers restaient très importants mais l’étaient moins que les interactions entre individus ou avoir des logiciels fonctionnels. Pour aller plus loin, je pourrais même dire que nous étions plus agiles avec notre pratique du cycle en V qu’avec notre implémentation initiale du Scrum !
Conclusion
Une transformation agile ne se décrète pas. Une transformation agile n’est pas simple. Une transformation agile prend du temps !
On ne devient pas agile du jour au lendemain.
De plus, il est important de noter que l’agilité n’est pas toujours la meilleure solution. Dans notre contexte, un cycle en V aurait objectivement été une bien meilleure solution (si on ne prend pas en compte le fait que l’on avait besoin d’un projet pilote) pour les raisons suivantes :
- Les contraintes de temps se sont avérées plus informelles que vraiment présentes
- Pas de nécessité de sortir « avant les autres » pour investir un marché
- Nous avions un périmètre défini et connu à l’avance (c’était particulièrement vrai avec notre expérience sur les autres applications au fonctionnel similaire)
- Nous maîtrisions très bien le cycle en V
Enfin, l’agilité ne doit pas être prise pour ce qu’elle n’est pas.
- Agile ne veut pas dire plus rapide : la rapidité est une rapidité d’arrivée sur le marché (le TTM ou Time To Market), en revanche, on ne sait pas avec quel produit. Ce qui est sûr, c’est que cela ne sera pas un produit final comme on peut le voir avec du cycle en V.
- Agile ne signifie pas non plus dire adieu à la documentation, aux processus et à la rigueur. L’agilité requiert une très grande rigueur (plus que le cycle en V) et ne permet pas d’avoir un produit défini à l’avance plus rapidement et moins cher qu’un cycle en V.
L’agilité c’est la possibilité d’avoir :
- Une mise sur le marché plus rapide
- Des mises à jour régulières
- Une adaptation plus réactive aux retours des utilisateurs
- Une gestion des changements fonctionnels liés à différents contextes
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
