Pourquoi travailler en agilité ?

06 janvier 2020

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.