Par le March 27, 2020

Les processus de changement traditionnels peuvent s’avérer aussi longs que fastidieux. Mais peut-on les rendre plus agiles ? Dans ce nouvel article de notre série consacrée à la stratégie Agile, je vous dis tout sur la gestion des changements et sur son approche Agile. Est-ce que ça marche ? Dans quel cas ? Et quels éléments fonctionnent et lesquels pas ?

La méthode Agile est-elle mieux adaptée aux changements standard ou non standard ?

Dans ma vidéo consacrée à la gestion des changements selon Agile, je vous expliquais que cette méthode me laissait assez perplexe. Mais, plus le temps passe, plus je pense que cette approche mérite finalement sa place dans notre activité.

Agile semble plus approprié aux changements non standard. Pour résumer, cette approche vous aide à gérer les éléments imprévisibles, tandis que les changements standard sont généralement conçus pour être les plus prévisibles possible. Prenez l’exemple d’un ordinateur portable. Vous sortez l’appareil de votre stock, y installez un système d’exploitation, des applications standard et le confiez à qui de droit. La routine.

L’approche Agile montrera plutôt toute l’étendue de ses capacités lors de changements non standard.

Quel est le bémol du processus ITIL traditionnel ?

La gestion des changements selon ITIL a vu le jour afin de vous aider à mettre en place les changements inhérents à votre infrastructure IT. De quoi éviter que le remplacement d’un serveur entraîne une panne de l’intégralité de votre réseau. Résultat : ce cadre comporte de nombreux points de contrôle et une multitude d’évaluations.

Si ces contrôles sont particulièrement utiles, ils sont très loin de vous faciliter la tâche en cas de changement non standard. Or, un processus complexe s’accompagne de nombreux inconvénients :

Introduire une demande de changement exige énormément de travail. Vous devrez concevoir des solutions techniques, générer des analyses d’impact, évaluer les risques et calculer les coûts liés à votre changement. Sans aucune certitude que votre changement verra bien le jour. Ou que vos infos seront toujours valables au moment de son application.
Le conseil consultatif des changements consacre énormément de temps aux demandes de changement. Dans certaines entreprises, le conseil consultatif se penche sur chaque changement, qu’il soit majeur ou mineur, urgent ou non. Cela oblige parfois 6 à 8 membres de ce conseil à se réunir pour discuter de demandes relativement simples.
Le processus de changement est une voie à sens unique. Vous devez absolument tout prévoir avant d’introduire une demande de changement. Après son approbation, il ne vous restera plus qu’à mettre en pratique ce que vous aviez couché sur papier. Vous avez obtenu de nouvelles informations dans l’intervalle ? Pas si simple de modifier votre projet en cours de route.
Le processus de changement peut s’avérer plus long que prévu. Tous les contrôles mentionnés plus haut viennent ralentir votre processus de changement. Il peut donc arriver qu’au moment d’enfin appliquer votre changement, vous réalisiez que vous avez oublié de soumettre vos dernières modifications au conseil consultatif des changements… qui ne se réunit qu’une fois par semaine.

Débarrassez vos demandes de changement du superflu

Attention, je ne dis pas que les processus et les contrôles sont superflus par nature. Bien au contraire : j’invite souvent les entreprises à recourir aux formulaires de demande de changement. L’analyse d’impact, quelle que soit sa forme, permet d’éviter des problèmes majeurs lors de la mise en place d’un changement.

Mais ces formulaires sont-ils vraiment indispensables à chaque demande ? Je pense que non. Vous pourrez aider vos équipes à faire le bon choix en trouvant le juste équilibre entre réduction maximale des risques et confiance absolue envers les membres de votre service IT. Un équilibre que vous pourrez atteindre grâce à la gestion des changements selon Agile.

Le gestionnaire des changements : responsable produit du backlog des changements

L’approche Agile révolutionne essentiellement les tâches du gestionnaire des changements et du conseil consultatif des changements. La méthode traditionnelle définit principalement le gestionnaire des changements comme un gestionnaire des processus. La méthode Agile bouscule cette vision et invite ce gestionnaire à adopter un rôle plus social et plus axé sur le cœur de chaque projet.

Voici les responsabilités du gestionnaire des changements Agile :

Vous rassemblez et classez les attentes de toutes les parties prenantes. Vous introduisez les demandes de votre backlog comme demandes de changement. Pour résumer, le backlog est une liste reprenant vos tâches par ordre de priorité. Pour les classer comme il se doit, vous devrez rester attentif aux activités de l’ensemble de votre entreprise. Vous analysez les demandes de changement, comparez les différents enjeux et les problèmes posés. Priorisez vos projets sur la base de cette comparaison et revoyez votre ordre de priorité à intervalle régulier, par exemple toutes les deux semaines.
Vous vous assurez que les demandes de changement sont claires et concises. Pas besoin de compléter tout un formulaire pour chaque demande. Veillez simplement à disposer de toutes les informations dont vous avez besoin pour classer vos demandes en fonction de leur priorité. Par exemple : quel problème souhaitez-vous résoudre avec cette demande ? Quelles sont les solutions envisageables ? Quelle serait la portée de cette demande ? Inutile d’être hyper complet et d’indiquer votre solution globale, la stratégie d’application ou encore le budget nécessaire à cette demande.
Vous veillez à ce que les 5 demandes les plus importantes soient plus détaillées. Tenez-vous à cette règle de base : moins votre demande sera prioritaire dans votre backlog, moins elle sera détaillée. Ajoutez uniquement un briefing détaillé aux demandes que vous comptez traiter dans les plus brefs délais. Ce seront d’ailleurs les seuls projets que vous soumettrez au conseil consultatif pour approbation.

Le conseil consultatif des changements : des détails techniques au niveau stratégique

Mais, si le gestionnaire des changements consacre davantage de temps à rassembler et à classer les demandes de changement, que devient le conseil consultatif des changements ? Il continue à jouer un rôle essentiel dans le processus de changement, mais plutôt d’un point de vue stratégique. Voici les nouvelles tâches de ce conseil :

Approuver les demandes de changement essentielles. Ce volet de son activité reste relativement inchangé : déterminer si une demande est complète, l’approuver ou la refuser. Principale différence toutefois : le conseil consultatif se concentre désormais sur les demandes prioritaires, ce qui lui fait gagner énormément de temps.
Approuver l’ordre de priorité du backlog. Le gestionnaire des changements ayant déjà classé toutes les demandes, il revient au conseil consultatif d’approuver l’ordre de priorité du backlog. Si le gestionnaire des changements effectue correctement son travail, le conseil se contente généralement de demander l’une ou l’autre adaptation.
Donner son feu vert (ou son feu rouge) lors de moments clés. Dans le cas d’une application classique, le conseil consultatif donne son accord juste avant la mise en pratique d’un changement, par exemple durant la phase de test. L’approche Agile permet de travailler étape par étape, ce qui évite de devoir attendre le « verdict » final du conseil avant de lancer un projet. Mais, alors, à quel moment le conseil consultatif donne-t-il son accord ? Tout dépend de votre demande. L’équipe IT et le conseil définiront en amont l’étape durant laquelle interviendra ce dernier.

Une gestion des services plus agile

Envie de découvrir d’autres applications de la méthode Agile ? Consultez notre e-book consacré à la gestion des services Agile et découvrez tout ce que cette méthode peut apporter à votre service d’assistance.