Pourquoi passer à la gestion de projet agile ?
/https://medias.yama-cms.com/fbe88647624e76d5bcdec2d0e89dc506/2024-01/65a54c99322ce647985153.png)
Les principes fondateurs de l’agilité sont exposés sur le manifeste agile. Succession de guidelines et de conseils à destination des professionnels afin de leur permettre de maximiser la valeur de leur produits. Attention à ne pas prendre ce document trop au premier degré ! Comme tout manifeste, il pose les bases et ne représente pas une vérité absolue (big up aux fondamentalistes religieux). Ce manifeste doit représenter une inspiration et doit être grandement adapté afin de coller aux besoins de vos équipes et à votre culture d’entreprise.
On les connait bien les éternels insatisfaits, les perfectionnistes qui changent d’avis comme de chemise. Attention, ils sont déjà extremement néfastes sur de la gestion de projet classique, mais sur une démarche d’agilité, ils peuvent très vite pourrir complètement un produit. Non ! Votre produit ne sera pas parfait du premier coup ! (ni du vingtième d’ailleurs)
Ne les laissez pas tout remettre en cause au gré de leurs lubies, maintenez le cap même si tout n’est pas rose. Je vous le rappelle, l’objectif c’est le MVP. C’est lui qui vous dira ce qu’il faut garder et ce qu’il faut changer.
Un bon gros lieu commun, mais vous n’y couperez pas. La communication est la garnatie de votre réussite. C’est pour cela que l’on a autant de cérémonies (stand up, kick of, sprint, sprint retrospectives, revues de backlog…) , autant d’opportunités de se parler, de se challenger, de vraiment écouter l’autre et de mettre sur pied une vision commune du produit.
Les sprints c’est le money time, c’est là que vous vous rendez compte si l’agilité vous apporte vraiment ou si vous n’êtes que sur une posture agile. La préparation, la cohérence et la priorisation sont essentiels à la réussite de votre sprint. Vous n’imaginez pas le nombre de sprints en échecs à cause de mauvais choix. Le plus souvent on veut trop en faire ! Le développeur se retrouve démuni face à une montagne de tâches et va soit bâcler son travail, soit complètement se démotiver devant l’ampleur de la tâche. Soyez réaliste, appuyez vous sur les avis des développeurs. N’hésitez pas à enlever des features ou à revoir des périmètres pour garantir une faisabilité. Rien de pire que de finir un sprint en ayant traité la moitié des tâches prévues…
Dernier piège bien connu des agilistes. Il concerne surtout les grosses structures. J’ai travaillé dans de nombreux grands groupes qui se targuent d’être agiles cependant, rares sont ceux qui appliquent véritablement les préceptes de l’agilité. La plupart du temps on se retrouve avec des cahier des charges monstrueux qu’on essaie de faire rentrer tant bien que mal dans un backlog complètement illisible, ajoutez à cela des cyles de mise en prod qui prennent des mois… Mais bon, ils affichent qu”ils sont agiles, j’imagine que ça fait bien en CODIR…
En conclusion, l’agilité c’est bien, mais faire de l’agilité pour faire de l’agilité ça ne sert à rien. En général si vous tombez dans au moins 2 de ces pièges c’est que vous n’êtes pas prêts à être agiles, soit par manque de formation soit parce que votre culture d’entreprise est enracinée trop profondément dans le waterfall… Dans les deux cas, ne vous obstinez pas et prenez du recul. Parfois les choses prennent du temps !