Le Manifeste Agile nous explique qu’une des valeurs importantes des méthodes agiles est : la collaboration avec les clients plus que la négociation contractuelle. 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 deux premières valeurs du Manifeste Agile lors de deux 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
Article : Le manifeste agile : 4 valeurs et 12 principes
La collaboration avec les clients
Dans l’univers des méthodes agiles, on concentre notre énergie sur le client : nos produits doivent être 100% user-centric. Si il est facile de l’énoncer, il est beaucoup plus difficile de mettre en place cette nouvelle culture.
En méthode agile, on ne parle plus de projet mais on parle de « produit ». C’est une nuance très importante à comprendre car elle est une des base de culture agile.
Le client dès le framing
La meilleure façon de livrer un produit qui correspond aux utilisateurs clés est de les impliquer tout au long du produit ce qui ne se faisait jamais dans les méthodes traditionnelles de gestion de projet.
On définira les utilisateurs clés par tous les utilisateurs types de notre application ; par exemple pour un site ecommerce on aura : le client du site, l’administrateur du site, le logisticien, le webmaster (emerchandiser)…
Lorsque vous réaliserez un framing pour cadrer votre nouveau produit (voir sur de nouvelles fonctionnalités), vous tenterez régulièrement de faire des interviews des clients afin que votre futur produit réponde au mieux à leurs attentes.
Article : Comment lancer un framing de projet ?
Le client tout au long de l’exécution
Les équipes qui font par exemple du Scrum commencent a bien le comprendre : il faut inviter régulièrement les utilisateurs clés à des démonstrations du produit afin d’obtenir des feedback réguliers de leur part.
Souvent pour des différentes équipes, cette démonstration est réalisée dans le courant de la cérémonie « sprint review » réalisé en fin de sprint. On essaye d’y inviter les utilisateurs clés concernés par les fonctionnalités qui sont livrées en fin de sprint.
D’autres préfèrerons faire la démonstrations lors d’un autre moment dans le courant du sprint.
Le Product Owner va également régulièrement travailler avec ces clients pour créer les prochaines fonctionnalités ou les améliorations futures des fonctionnalités déjà livrées. Il les invitera à travailler ses points lors de workshop.
Plus que la négociation contractuelle
Rappelons que « plus que » ne veut pas dire qu’il n’existera pas de négociation contractuelle. Il est évident que des entreprises travaillent ensemble qu’en réalisant des contrats protégeant chaque parti en cas de conflit.
On va juste faire en sorte que le « contrat » ne viendra pas empêcher la « collaboration avec le client » qui est la base de qualité fonctionnelle que propose les projets en agile.
Les contrats que les entreprises faisaient il y a 20 ans interdisaient de travailler avec des méthodes agiles car le scope était intégralement définit dans un cahier des charges complet.
Ce type de contrat rendait impossible une réelle collaboration avec le client. Les idées du client ne pouvait pas avoir d’impact sur le produit final malheureusement.
Un contrat agile ?
En effet, plus le temps passe, plus on voit des contrat devenir agile. Au lieu, d’avoir un contrat basé sur un cahier des charges complet qui impose de livrer à 100% ce qui est indiqué au sein de ce dernier, on va plutôt réaliser des contrats de type régie ou régie forfaitaire.
En agile, nos contrats fixeront les ressources et le temps mais ne détermineront pas le scope comme le montre le Triangle Iron Agile ci-dessus.
Article : Qu’est-ce que l’agile iron triangle ?
Avec ce type de contrat, il sera tout a fait possible de créer un produit en collaboration avec les utilisateurs clés car ils pourront sans soucis amener le scope à changer régulièrement (nouvelles fonctionnalités, améliorations…).
On voit ces dernières années de plus en plus d’entreprises travailler sur cette forme ce qui facilite considérablement la mise en application de projets en méthodes agiles.
Le cadrage en temps réel avec les stakeholders
Si nos utilisateurs clés sont la base du produit que nous créons dans l’univers agile, on oubliera pas d’amener les stakeholders (parties prenantes) qui pourront faire office de contre balance quand le client en demande trop.
N’oublions pas qu’il reste indispensable de bien prendre un compte que la mise en place d’un produit a un coût et que les finances sont rarement illimitées dans les structures.
Les impliquer tout au long de la construction du produit permet également de s’épargner toute une négociation contractuelle ; pourtant leur présence permet de cadrer là où les utilisateurs ne cadre rien (ce qui est normal par ailleurs).
Conclusion
J’espère que cet article vous aura bien éclairé sur la troisième valeur agile qui est « la collaboration avec les clients plus que la négociation contractuelle » car elle est parfois mal interprétée par certaines équipes et on peut encore voire certaines équipes totalement oublier l’importance de mettre nos utilisateurs clés au coeur de leurs produits.
3 Rétroliens / Pings