Manifeste Agile #4 : l’ adaptation au changement plus que le suivi d’un plan

manifeste agile
manifeste agile

Le Manifeste Agile nous explique qu’une des valeurs importantes des méthodes agiles est :  l’ adaptation au changement plus que le suivi d’un plan. Comment pouvons nous transformer ça concrètement ?

Pour rappel, les 4 valeurs du manifeste agile sont :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Nous allons voir en 4 articles complets, les possibilités déjà évoquées pour répondre à chacune de ses valeurs sans pour autant s’arrêter à la méthodologie Scrum.

Nous avions déjà commencé par traiter les trois premières valeurs du Manifeste Agile lors de trois premiers articles :

Articles :

Manifeste Agile #1 : les individus et leurs interactions plus que les processus et les outils
Manifeste Agile #2 : des logiciels opérationnels plus qu’une documentation exhaustive
Manifeste Agile #3 : la collaboration avec les clients plus que la négociation contractuelle

Article : Le manifeste agile : 4 valeurs et 12 principes

L’adaptation au changement

Les méthodes agiles insistent énormément sur l’adaptation sur différents points différents :

  • Adapter les processus par rapport au besoin
  • Adapter le scope selon les feedbacks et les besoins
  • Etre capable de s’adapter au moindre changement

Tout ces points peuvent se voir de différentes manières.

Adapter le scope

Parfois la scope initialement prévu en début de projet doit être adapté pour différentes raisons.

Quand on travaille en méthode agile, je rappelle que les équipes réalisent de nombreuses itérations en invitant régulièrement les utilisateurs clés et parties prenantes à voir l’avancement du produit ; il est possible que ceux-ci changent d’avis sur l’intérêt d’une fonctionnalité ou de sa présentation en la voyant en réel voire en la testant. Dans ce cas, l’équipe n’hésitera pas à récupérer leurs feedbacks pour modifier le scope.

Il est important d’accepter de changer le scope et non de persister sur le plan initial qui ne semble plus totalement adapté au besoin.

C’est d’ailleurs pour expliquer cela que l’agile iron triangle a été créé. Contrairement aux anciennes méthodes de gestion de projet où on expliquait que le scope était fixe (du au fait de devoir aller au bout du plan initial) contrairement au ressources et au temps qui pouvaient évoluer, les projets réalisés en méthodes agiles permettent d’avoir un scope adaptable (et de l’accepter) et d’avoir les ressources et le temps clairement définis.

Voici la représentation de l’agile iron triangle :

agile iron triangle
agile iron triangle

Article : Qu’est-ce que l’agile iron triangle ?

Le fait d’écrire les user-stories (US) bien découpées au fur et à mesure et de ne pas tout écrire à l’avance (de façon complète) permet de pouvoir adapter le scope facilement et de limiter au maximum la perte de temps.

Voici un exemple simple (il existe d’autres méthodes) :

  1. Ecrire le résumé des US (En tant que…. Je souhaite…..) en initialisation du projet ou au moment d’une demande de modification/amélioration.
  2. Extreme Quotation si vous avez besoin d’avoir une roadmap estimative
  3. Ecriture complète de l’US (règles de gestion, test d’acceptance, critère d’acceptance…) le sprint précédent pour proposer l’US en grooming

Cette façon d’écrire les US permet d’adapter facilement le scope sans avoir la frustration d’avoir écrit inutilement des user-stories complètes.

Dans les méthodes agiles, il est très important d’être très souple sur le scope du produit afin de proposer un produit beaucoup plus proche des besoins de ses utilisateurs ; ceci n’est pas possible avec les méthodes dites traditionnelles comme le cycle en V ou d’autres concepts waterfall.

Adapter les processus et l’environnement

Dans une entreprise, le contexte est en continuel changement. Il ne faut pas hésiter à faire régulièrement des points pour adapter les processus voire pour améliorer l’environnement de travail afin de tenter constamment de tendre vers une organisation optimum.

Le Scrum par exemple propose la rétrospective pour pousser les équipes à s’améliorer à chaque itération et le Crystal Clear propose la Reflection dès qu’un problème ou obstacle survient afin de les résoudre.

On appelle ce concept de pratiques d’amélioration continue, le Kaizen. Je vous laisse regarder l’article associé si vous voulez en savoir plus sur ce sujet.

Article : L’Agile aime la philosophie Kaizen

Si les équipes veulent également faire profiter de leurs améliorations qu’ils ont adopté aux autres équipes afin que l’adaptation soit encore plus optimale, il est possible également d’appliquer la pratique du Yokoten que nous venons de voir cette semaine sur ce blog.

Article : Yokoten, la diffusion des bonnes pratiques

« plus que » le suivi d’un plan

Je ne le répèterai jamais assez car j’entends encore de mauvaises interprétations de ce type de phrase : « plus que » ne veut pas dire qu’on ne suit pas un éventuel plan.

Il est important de fixer des objectifs, une vision et un plan de développement surtout dans les entreprises qui ont besoin de reporting complets. Avec les méthodes agiles on se refuse juste que ce plan soit presque contractuel aux yeux de l’ensemble des acteurs du produit ou qui gravitent autour de ce dernier.

Les équipes, les parties prenantes et les éventuels managers accepteront que ce plan puisse changer avec le temps dès que le besoin se fait ressentir. C’est justement là la force des méthodes agiles : être réellement structurées tout en proposant une souplesse intelligente.

Conclusion

J’espère que cet article vous aura bien éclairé sur la quatrième valeur agile qui est “l’ adaptation au changement plus que le suivi d’un plan” car elle est parfois mal interprétée par certaines équipes et on peut encore voire certaines équipes totalement oublier l’importance de l’amélioration continue en adaptant le scope, les processus voire les pratiques au fur et à mesure.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

2 Commentaires

  1. Bonjour,
    Je vous remercie de cet article.
    J’ai une remarque concernant la notion d’adaptation du scope.
    Personnellement, je pense que laisser le scope du projet indéfini pourrait entrainer en effet une mal compréhension du scope/périmètre. Ainsi que ça sera l’opportunité au client de rajouter et de changer complétement son besoin ce qui impacte par la suite les délais, et le contrat par conséquent…
    Il se peut que j’aie mal compris cette notion, mais je me trouve assez confuse entre respecter un budget alloué et accepter des changements aussi importants que ceux correspondant au scope.
    Je vous remercie de m’éclairer la dessus, et me corriger si je me trompe.
    Keep it up

    • Oui le client pourra tout changer mais pas le temps qu’il a payé pour la mise ne place du produit. Après si il s’apercoit que ça marche pas, il devra rajouter du budget. Cependant le PO est là pour rappeler les risques au client.

1 Rétrolien / Ping

  1. Le manifeste agile : 4 valeurs et 12 principes - Blog Myagile Partner

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.