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.