Appliquer ADKAR en Agile, pas à pas.

Il est difficile d’évoquer la question de l’intégration entre la conduite du changement et Agile sans expliquer comment reconfigurer ADKAR en Agile. Cet article vous donne toutes les clés pour comprendre comment se construit une séquence de changement et quelles sont les spécificités du fonctionnement d’ADKAR dans le cadre d’Agile.

ADKAR en bref.

D’un point de vue organisationnel, le changement se définit comme la somme des transitions individuelles. On peut déconstruire le processus en cinq étapes consécutives. En ignorer une peut mettre à mal tous les efforts de transformation. Bien poser les bases du changement, c’est aussi s’assurer qu’il pourra être pérenne. Simple et efficace, la méthodologie ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) peut être synthétisée de la façon suivante :

Il n’y a pas de changement possible sans sensibilisation (Awareness) au besoin de changer. Un changement d’état d’esprit est nécessaire pour déclencher le processus, mais non suffisant pour faire du projet de transformation une réalité tangible. Franchir cette première étape signifie simplement que la personne a compris que le statu quo n’est pas une option et qu’elle saisit les risques qu’implique une posture attentiste. Une erreur tout à fait commune consiste à initier le changement en ignorant les deux premières étapes (Awareness et Desire) pour partir, somme toute assez intuitivement, de la troisième (Knowledge). On voit ici des organisations outiller les collaborateurs sans les avoir sensibilisés au préalable aux raisons stratégiques du changement et avoir fait le point sur les implications personnelles (le fameux What’s in it for me ? ou WIIFM), étapes pourtant indispensables pour éveiller la volonté de changer. La quatrième étape se réfère à la capacité à mettre en œuvre les compétences requises (Ability), c’est-à-dire à fonctionner de façon optimale dans le nouveau processus, à maîtriser l’utilisation des nouveaux outils et systèmes, à adopter de nouveaux comportements et un nouvel état d’esprit, à remplir un nouveau rôle, à être efficient au sein de la nouvelle structure hiérarchique et à comprendre les nouveaux modes d’évaluation de la performance. C’est à ce moment que le changement prend véritablement vie et que les activités de coaching peuvent faire une réelle différence. Enfin, les actions de renforcement (Reinforcement) et le monitoring ont pour objectif de rendre le changement pérenne, en évitant un retour aux modes de travail antérieurs, chose assez habituelle puisqu’inhérente à la nature humaine.

On peut évaluer le progrès en examinant le langage. Il reflète en effet la façon dont les collaborateurs vivent le changement à mesure que celui-ci se déploie. Avez-vous entendu un collaborateur dire « je comprends pourquoi … » ? Il s’agit du premier bloc constitutif du changement, celui de la sensibilisation. Ou peut-être « j’ai décidé de participer à … » ? C’est celui la volonté. Ou encore « Je comprends ce que je dois faire … » ? Il s’agit de la connaissance. « Je suis capable de … », c’est l’aptitude. Et enfin, « je continuerai à faire… », c’est le renforcement. Comme discuté ci-dessous, ceci reste valable en Agile, à la différence que les discours sont formulés à trois niveaux différents : le release, le projet et l’approche.

« ADKAR en Agile », illustré.

Il s’agit en fait de redistribuer les éléments de la méthode entre le niveau « projet » et le niveau « sprints ou releases ». Prenons un cas concret pour accompagner notre réflexion dans le reste de cet article, celui d’un nouveau système de commandes.

Le processus de sensibilisation doit-il être attaché au niveau du projet ou du sprint ? On s’accordera facilement sur le fait que cette étape est propre au niveau « projet ». Les collaborateurs doivent comprendre pourquoi le nouveau système de commandes est nécessaire. L’éveil d’une véritable volonté de participer à la mise en place [et mise à profit] du nouveau système constitue également une étape attachée au niveau « projet » - même s’il est parfaitement possible que quelqu’un exprime le désir de prendre part à tel ou tel release. Le point d’inflexion correspond aux phases de Connaissance et d’Aptitude, où les releases deviennent les niveaux opérationnels dominants d’ADKAR. Si le développement et le déploiement du système sont itératifs, découpés en livrables, il est logique que les employés soient outillés en fonction des exigences de chaque release ou versions du système. La connaissance concerne ce qui devrait être fait pendant et après un release, et l’aptitude renvoie à ce que le release exige en termes de performance. Le nouveau système de commandes doit être adopté de façon ininterrompue et parfaitement maîtrisé, malgré son caractère évolutif. Logiquement, le renforcement a lieu à la fois au niveau du projet et des releases. Dès que le système est déployé, en tout ou en partie, un suivi de son utilisation et des incidences reportées par les utilisateurs doit être mis en place pour asseoir le changement, prendre les mesures correctives nécessaires et alimenter le processus de développement par incréments – tout un ensemble d’actions qui s’inscrivent, comme on le sait, au cœur de la logique Agile.

Des méthodes traditionnelles à Agile.

Si vous opérationnalisez ADKAR dans un cadre en cascade, vous devez aligner le déploiement des actions liées au bloc « Aptitude » sur le déploiement ou mise en place du nouveau système de commandes de façon à créer les conditions optimales pour une transition réussie vers l’état futur. De là, vous pourrez « rétro » modeler la séquence ADKAR et définir quand développer les connaissances, stimuler l’intérêt des collaborateurs, sensibiliser et évidemment, envisager les activités de renforcement.

Qu’en est-il dans le cadre d’Agile ? Dans cette nouvelle configuration, vous allez d’abord travailler au niveau du projet, en sensibilisant vos collaborateurs à la nécessité de changer et en veillant à développer un réel intérêt pour le nouveau système de de commandes. Vous alignerez ensuite la connaissance et l’aptitude sur chaque release. Promouvoir des actions sur le plan de la sensibilisation et de la volonté à ce sous-niveau crée aussi des trajectoires itératives ADKAR. S’il est vrai que chaque release peut bénéficier d’activités de renforcement, la connaissance et l’aptitude restent les deux blocs prioritaires. Plus tard, et comme étape finale, vous renforcerez l’ensemble du projet.

De façon synthétique, le modèle ADKAR reste inchangé mais ses composants clés sont redistribués sur l’ensemble du projet et des releases. En tant que processus, il s’établit à trois niveaux interdépendants. Au niveau le plus élémentaire (celui du release), on attend des personnes qu’elles comprennent les raisons sous-jacentes à un release, qu’elles expriment le désir de participer et qu’elles sachent quoi faire en pratique. Mais ADKAR fait aussi sens au niveau du projet dans la mesure où les collaborateurs doivent comprendre pourquoi le nouveau système est nécessaire, doivent être impliqués et savoir comment procéder. Au méta-niveau, on trouve Agile en tant qu’approche. Parce qu’elle constitue un changement en soi, l’approche doit également faire l’objet d’un processus d’appropriation.

Ne manquez pas la suite de notre série. Nous vous donnons tous nos conseils pour appliquer les cinq leviers du changement en Agile !

 

 

Modèle ADKAR de PROSCI	Définition	Répond à :	Trois niveaux d’ADKAR
Awareness [prise de conscience]	…du besoin de changer	Pourquoi ? Pourquoi maintenant ? Si on ne le fait pas ?	« Je comprends pourquoi… » Pour ce release Pour ce projet ​Pour ce release
Desire [volonté]	…de participer et de soutenir le changement	Qu’est=ce=que ça m’apporte Motivateurs personnels Motivateurs organisationnels	« J’ai décidé de participer … » À ce release À ce projet À l’approche Agile
Knowledge [connaissance]	…sur la façon de changer	En contexte [après R&D] Connaissances pendant Connaissances après	« Je sais comment faire… » Pour ce release Pour ce projet Pour l’approche Agile
Ability [aptitude]	…à mettre en  œuvre les compétences et comportements requis	Taille des écarts K=A Barrières/Capacité Pratique/Coaching	« Je suis capable de bien le faire … » Pour ce release Pour ce projet Pour l’approche Agile
Reinforcement [pérennisation]	…pour maintenir les changements	Mécanismes Métriques Soutien	« Je continuerai à faire ce qu’il faut … » Pour ce release Pour ce projet Pour l’approche Agile