Pourquoi travailler en agilité ?
Sans doute dĂ©formĂ© par le domaine dans lequel jâĂ©volue, je vois et jâentends de plus en plus parler dâagilitĂ©. AgilitĂ© dans les mĂ©thodes de dĂ©veloppements de produits, agilitĂ© dans le fonctionnement des entreprises, toujours plus nombreuses Ă se targuer dâĂȘtre full agile.
Ătre agile, câest quoi ?
Le Larousse donne les définitions suivantes :
Qui a de lâaisance et de la promptitude dans les mouvements du corps ; souple, alerte
Qui est vif, prompt Ă comprendre
Ce sont des notions de mouvements, de facilité et de vitesse.
Pour une entreprise cela revient Ă adapter son organisation, ses process, ses produits, et surtout sâadapter et Ă©voluer rapidement.
Pour un projet, le maĂźtre mot est le mĂȘme : sâadapter. Sâadapter rapidement aux parties prenantes, aux difficultĂ©s rencontrĂ©es, aux nouvelles demandes.
Une autre vision dâun projet
Dans un projet mené de façon classique type cycle en V, il y a un début et une fin. La fin du projet est définie au début, typiquement dans un cahier des charges.
Les Ă©tapes sont dĂ©crites prĂ©cisĂ©ment, de mĂȘmes que les fonctionnalitĂ©s et les livrables.
En face on vient coller un budget correspondant au temps et aux ressources associĂ©es, donnant le budget global, un rĂ©tro planning disant quand le projet commence et quand il sera terminĂ©. Mais soyons honnĂȘte : combien de projets se dĂ©roulent selon le plan prĂ©dĂ©fini ?
Câest lĂ un grand intĂ©rĂȘt de lâapproche agile.
Au-delĂ des mĂ©thodes, elles-mĂȘmes adaptables aux hommes, lâagilitĂ© permet de pivoter Ă nâimporte quel moment dâun projet pour aller lĂ oĂč la plus grande valeur ajoutĂ©e sera apportĂ©e. Le projet a un dĂ©but, mais la fin nâest pas figĂ©e.
Les grandes fonctionnalitĂ©s seront dĂ©finies, le comment et quand, non. LâavancĂ©e du projet et les changements de prioritĂ©s, de cap, du marchĂ©, on peut tout imaginer, modifieront au fur et Ă mesure le chemin pour arriver Ă un but.
La cible est dĂ©finie, mais elle est flou et se prĂ©cise au fur et Ă mesure de lâavancĂ©e du projet.
Lâillustration par un cas concret
JâĂ©tais en RDV il y a peu pour un site e-commerce. Notre client souhaitait avoir une roadmap prĂ©dĂ©finie avec la liste des fonctionnalitĂ©s. Ok, mais quelles sont toutes les fonctionnalitĂ©s qui seront dĂ©ployĂ©es ? Personne nâest en capacitĂ© de le dire dĂšs le dĂ©but finalement.
Dâautant plus quâil y a des liaisons Ă faire avec un ERP, des spĂ©cificitĂ©s mĂ©tiers pas encore identifiĂ©es, une organisation dans laquelle il faut rentrer, autant de paramĂštres qui peuvent faire Ă©voluer des choix au fur et Ă mesure que le projet avance.
La meilleure façon pour nous dâaborder un tel sujet et justement lâagile, et le fonctionnement par sprint. Un sprint est une itĂ©ration avec un dĂ©lai dĂ©terminĂ© dans lequel nous allons avoir dĂ©fini les objectifs Ă atteindre pour la fin du sprint.
Un sprint se concentrera par exemple sur une reprise des donnĂ©es, un autre sur la liaison ERP, un autre sur des fonctionnalitĂ©s marketing, sur de lâautomatisation, etc.
Finalement un tel site nâest jamais terminĂ©, il y a toujours des modifications et Ă©volutions Ă apporter. Les prioritĂ©s peuvent changer, fonctionner en agile nous permet de les changer et de modifier le contenu du sprint suivant.
Vous voulez finalement insérer les avis clients plus tÎt que prévu ? Lier une solution de logistique automatisée ? Ok, on décale quelle(s) fonctionnalité(s) ? Pour quel sprint ?
Cela nous permet aussi de livrer rĂ©guliĂšrement est dâĂȘtre dans une approche dâamĂ©lioration continue.
On sait oĂč on va, mais on ne sait pas comment ni dans quel ordre, et finalement ce nâest pas important. Car ça change en fonction des prioritĂ©s et des difficultĂ©s rencontrĂ©es au fur et Ă mesure de lâavancĂ©e du projet.
Si vous avez votre roadmap dĂ©finie, une difficultĂ© non prĂ©vue (comme un partenaire qui ne livre pas des accĂšs Ă temps) va reculer la date de livraison du projet final. Et pourtant cela arrive souvent, dâautant plus en multipliant les parties prenantes sur le projet.
Lâagile permet dâĂ©viter ces Ă©cueils et de rebondir sur un autre sujet pour revenir sur le premier plus tard quand tous les Ă©lĂ©ments seront disponibles.
Finalement vous nâaurez pas le projet disponible quand il sera terminĂ©. Vous lâaurez avant. Pas finalisĂ© mais viable, apportant dĂ©jĂ de la valeur ajoutĂ©e, et il sera complĂ©tĂ© au fil du temps apportant chaque fois plus de valeur ajoutĂ©e.
Cette illustration montre assez bien la diffĂ©rence entre lâapproche classique et lâagile :

Une approche différente, donc une pensée différente.
En tant que client, cela nécessite de penser différemment. Au lieu de penser budget et fonctionnalités figées, il faut penser budget et solution avec ce budget.
Je reste sur mon e-commerce.
Jâai mon cahier des charges, il est validĂ©. Mon budget et de 50kâŹ, dans 4 mois (si le dĂ©lai est tenu) jâai mon site e-commerce qui contiendra la liste des fonctionnalitĂ©s dĂ©crites. Puis on sâaperçoit quâon a oubliĂ© une fonctionnalitĂ©, je veux rajouter un module de cross-selling spĂ©cifique. Les Ă©changes qui sâen suivent peuvent ressembler à ça :
- Bonjour, je veux rajouter un module de cross-selling qui fait ça, ça et ça.
- Ok, je vous fais un devis complémentaire.
- [âŠ]
- Nous avons estimĂ© la charge Ă X temps soit Y âŹ. Avec le planning actuel ça dĂ©calera la livraison du site de Z temps.
Maintenant la mĂȘme discussion en mode agile :
- Bonjour, je veux rajouter un module de cross-selling qui fait ça, ça et ça.
- Ok, je vais lâestimer avec lâĂ©quipe.
- [âŠ]
- Nous avons estimĂ© la difficultĂ© lors du poker planning Ă 8 points. Lors dâun sprint lâĂ©quipe dĂ©veloppe entre 30-32 points en moyenne. Si vous voulez lâimplĂ©menter lors dâun sprint il faudra enlever ou dĂ©caler un quart de celui-ci.
- La livraison sera décalée ? Il y a un coût supplémentaire ?
- Tout dépend de vous : rien ne change sauf les fonctionnalités finales si on fait un remplacement, à vous de définir vos priorités, ou on rajoute un sprint, donc du temps et du budget, si vous voulez ajouter ces nouvelles fonctionnalités.
Je simplifie lâĂ©change, mais vous aurez compris lâidĂ©e. Je lâespĂšre du moins.
LâagilitĂ© permet dâavancer par itĂ©ration dans lâidĂ©e dâune amĂ©lioration continue. Analyse, dĂ©finition, crĂ©ation, implĂ©mentation, test, livraison. Et on recommence pour livrer une nouvelle solution partielle.

Ce cycle agile fonctionne de la mĂȘme façon que le design thinking, les approches sont similaires. Dans les deux cas on itĂšre et on avance, en continu.
Le gros avantage de ces mĂ©thodes agiles et de pouvoir sâadapter rapidement et Ă tout instant Ă un changement.
Vers la fin des plannings et des budgets ?
Une autre notion Ă bien comprendre dans lâagilitĂ© est quâon ne dĂ©clare pas une tĂąche en temps mais en difficultĂ©. A partir de ces difficultĂ©s on va calculer une vĂ©locitĂ© (X points par sprint en moyenne), permettant de donner une idĂ©e de la fin dâun projet en additionnant les points restants dans un product backlog (liste des fonctionnalitĂ©s Ă dĂ©velopper pour le produit). Si toutes les fonctionnalitĂ©s sont Ă faire.
En dĂ©finissant les prioritĂ©s, les must/should/could have et en connaissant la vĂ©locitĂ©, vous serez capable dâestimer ce que vous pourrez avoir pour tel ou tel budget.
Le planning ? Voyez le contenu des sprints Ă venir, et vous aurez une idĂ©e de ce que vous aurez pour telle date. Sauf si vous changez les prioritĂ©sÂ
DĂ©finir un budget pour avoir une liste de fonctionnalitĂ©s prĂ©cises nâest donc plus nĂ©cessaire. En agile Ă partir dâun budget vous pourrez avoir une liste de fonctionnalitĂ©s qui pourra Ă©voluer en fonction de vos besoins pour maximiser la valeur ajoutĂ©e.
En tant quâagence câest une grosse difficultĂ© dâexpliquer cette diffĂ©rence et de la valoriser. La rĂ©ponse classique Ă©tant du genre « jâai besoin de savoir ce que je vais avoir pour mon budget ».
Pourtant Ă lâusage les solutions livrĂ©es en mode agile sont plus proches besoins rĂ©els des utilisateurs.