Tôt ou tard, vous allez forcément solliciter vos collègues pour prendre note de leurs attentes, de leurs besoins et des enjeux pour l’organisation dans son ensemble. Cela étant fait, lorsque le déploiement aura été entamé, vous leur reviendrez à intervalles réguliers pour rendre compte de l’avancement du projet. Vous vous assurerez de leur satisfaction et de la pertinence de la démarche dans le contexte -forcément changeant- de votre activité.
Figurez-vous que ce processus de va-et-vient permanent entre besoins et solutions, entre demandeurs et experts, c’est l’essence même de l’agilité. Vous voilà comme M. Jourdain, vous faites de la prose (et de l’agilité) sans le savoir !
Alors, l’agilité, plus concrètement, c’est quoi?
Fin des années 90, les informaticiens se retrouvent face à une nouvelle donne: leurs utilisateurs ne sont plus en face d’eux, ils sont sur le web. Or un utilisateur sur le web, c’est un utilisateur qui est loin. On ne l’entend plus beaucoup. Il s’exprime de façon peu claire, peu audible, il zappe vite, sa disponibilité est limitée. Exit les cahiers des charges détaillés. Il faut se mouiller, lancer des fonctionnalités dont on n’est pas sûr de la façon dont elles vont être reçues, imaginer des besoins qui n’ont pas encore été formulés, et avancer prudemment sur ceux qui l’ont été, parce que les utilisateurs changent d’avis tout le temps.
C’est là que l’on commence à se rendre qu’à force de tout planifier à l’avance, comme le préconisent les bonnes vieilles méthodes de gestion de projet de l’époque (Prince2, PMBOK etc), on va souvent dans le mur. Entre le moment où l’on démarre et celui où l’on atterrit, le monde a changé et l’atterrissage se termine parfois en crash mémorable.
Une politique des petits pas commence à émerger. Bien-sûr on continue à se soucier de comprendre et de documenter les besoins des utilisateurs, mais on le fait plus prudemment, plus sobrement, en laissant la porte ouverte à ce qui est entretemps devenu une quasi-certitude: ils vont rapidement changer d’avis. Au lieu de documenter de grandes stratégies, on consigne les besoins un par un, en veillant à l’extrême clarté de leur formulation (un enfant de 10 ans devrait pouvoir les comprendre).
Le corollaire, c’est qu’on livre dorénavant “à la petite cuillère”, petit morceau par petit morceau, en veillant à constamment aller chercher du feed-back chez les utilisateurs. Les cycles de production ont été raccourcis à l’extrême. Les itérations sont courtes. A la fin de chaque cycle, les utilisateurs sont consultés. Est-ce bien ce que vous vouliez? En quoi ce qui vient de vous être livré impacte-t-il vos attentes? Etc.
Cousin germain de l’agilité, la démarche lean émerge au même moment. Ce n’est pas le produit fini qui compte. D’ailleurs, ça n’existe plus, un “produit fini”. Quand on est fini, c’est que l’on est mort… Place au MVP. Le “Minimum Viable Product” devient le nouveau mode de pensée, presque un style de vie: j’ajuste et j’améliore mon produit de manière fréquente et incrémentale, en livrant le minimum nécessaire pour faire bouger le système, pour faire réagir mes clients et pour leur apporter le surcroît de confort ou de satisfaction qu’ils attendent.
Courant 1998-1999, une méthodologie commence à émerger: SCRUM. C’est un mot qui a déjà été utilisé ici, et que vous allez encore le croiser. Nous y reviendrons.
En 2001, un groupe de développeurs s’offre un weekend au vert et accouche du Manifeste Agile. Cela reste un document de référence pour décrire les valeurs, les intentions et les comportements qui caractérisent une approche agile.
Un ingrédient essentiel de l’agilité, c’est la fréquence élevée de ce mouvement de va-et-vient entre expression des besoins et formulations de petits morceaux de solution. On y préfère les petits pas aux grandes enjambées.
Si ce mouvement de va-et-vient est suffisamment rapide (disons, par exemple, une fois toutes les deux semaines), vous êtes agile. Entre l’expression d’un besoin et le fait d’y apporter une réponse appropriée, les cycles sont courts.
A contrario, si vos mouvements de va-et-vient sont lents (basse fréquence), vous livrez peut-être davantage à chaque fois, mais vous constaterez sans doute que vos utilisateurs ne semblent pas parfaitement satisfaits. Si vous travaillez sur base de cycles longs (exprimés en mois plutôt qu’en semaines), il y aura forcément un fossé (pouvant aller de la petite rigole au grand canyon) entre ce que les utilisateurs auront demandé et ce que vous livrerez. S’autoriser à livrer rarement, c’est prendre le risque de perdre le pouls du monde qui change et de la vie qui est à l’œuvre. Disons-le franchement: si vous livrez peu fréquemment, vous n’êtes pas agile. Entre l’expression des besoins et l’émergence des solutions, les cycles sont longs et tout le monde s’ennuie.
Ma tante qui fait du reiki parlerait de taux vibratoire. Si vous avez de fréquent mouvements de va-et-vient, c’est que vous avez un taux vibratoire élevé. Cela atteste d’un grand niveau d’énergie. Cela ouvre les portes vers un niveau de conscience élevé. Si cette interprétation un peu new age vous met dans l’inconfort, nous pourrions simplement parler de “momentum”: votre projet CRM en a sous le pied. Ca bouge. Ca vit.
L’agilité, c’est donc une question de fréquence. A intervalles réguliers, vous livrez à vos collègues “un petit morceau de CRM”, ces petits morceaux s’enrichissant les uns les autres pour former une solution cohérente, en évolution permanente et qui s’enrichit de manière incrémentale. Chaque fois que vous livrez, vous en profitez pour collecter le feedback des personnes concernées, vous en tirez les leçons et vous profitez de l’occasion pour vous lancer dans un nouveau round d’investigation des besoins de votre organisation. Si vous le faites toutes les deux semaines, vous êtes agile. C’est aussi simple que cela.
Vous allez peut-être devoir ajuster votre vocabulaire. Il y a certaines expressions que vous n’utiliserez plus. What’s in a name…?
Basta les « spécifications ».
On les remplace par des #user_stories.
Au feu le « cahier des charges ».
On le remplace par un #backlog.
Oubliés les « go live ».
On le remplace par la #continuous_delivery.
Exit le « first time right ».
On le remplace par #failfast.
Fini le « on time & on budget ».
On le remplace par #every2weeks.
Plus de « project management ».
On le remplace par du #continuousimprovement.