animal-animal-photography-bird-33101

Qu’est-ce que l’Agile?

Fashion alert: l’Agile, la nouvelle panacée

Si les neuromachins étaient à la mode il y a quelques années, c’est maintenant l’Agile qui tient le devant de la scène.

Pourquoi? D’où vient ce concept? A quoi peut-il servir?

Une fable

Le contexte

Il était une fois des informaticiens qui travaillaient pour un employeur. Mais, oui, vous savez, les gars du fond du couloir habillés bizarrement qui ne disent pas bonjour.

La mission

Un jour, leur employeur décréta qu’il voulait “gagner en productivité” en “automatisant certaines tâches”. Il avait lu ça dans un magazine chez le dentiste et trouvait que cela sonnait très bien.

La demande

Les informaticiens se mirent donc au travail: d’abord, afin de savoir ce qu’ils devaient programmer (c’est comme cela qu’on appelle leur art cabalistique), ils écrirent un gros livre très détaillé avec moult listes et schémas: les spécifications. Par exemple, si la comptabilité voulait automatiser le suivi du paiement des clients, alors les informaticiens organisaient des réunions, des séances, des ateliers, des déjeuners, des repas, des apéros… bref, tout forme d’occasion pendant laquelle ils pourraient parler avec des gens (nommés des utilisateurs) qui ne voulaient pas leur parler: “J’ai du boulot, moi”, s’entendaient-ils dire souvent.

Ce processus pouvait durer des semaines, voire des mois, parce que les utilisateurs ne savaient en général pas décrire précisément comment ils travaillent: “Je fais juste mon boulot, moi”; les informaticiens finissaient donc souvent par créer les spécifications de toutes pièces – c’était plus simple.

La création

Une fois les spécifications écrites, ils s’isolèrent dans leurs antres et se mirent à invoquer des forces maléfiques pour créer ex nihilo un programme: c’est l’outil que la comptabilité allait utiliser pour effectuer ledit suivi. Ce processus-là prenait aussi beaucoup de temps parce que les forces maléfiques, étant maléfiques, ne faisaient pas toujours ce que voulaient les informaticiens.

L’outil créé, il fallut le tester et apprendre aux utilisateurs du programme à l’utiliser. Ce ne fut pas simple parce que ceux-ci avaient souvent “autre chose à faire, j’ai du boulot, moi”. Cette phase prit aussi beaucoup de temps et d’énergie: les informaticiens assaillirent les utilisateurs de demandes de réunion, de séances et de working lunches (sorte de piège à utilisateur qui consiste à promettre de la nourriture en échange d’une attention plus ou moins soutenue). De guerre lasse, les utilisateurs firent semblant de tester l’outil et de suivre les formations (longues et ennuyeuses) des informaticiens. Ceux-ci purent alors crier victoire: le programme était entré en production: ils allaient enfin pouvoir passer à autre chose.

Ou pas.

Le résultat

Les utilisateurs se mirent immédiatement à se plaindre: l’outil n’était pas user friendly (sorte de concept indéfini permettant à un utilisateur de justifier de son refus d’utiliser l’outil sans autre forme d’explication), ne faisait pas exactement ce que leur précédent outil (appelé papiéstilo) faisait déjà et, en plus, n’était plus “adapté à notre façon de travailler et aux contraintes du marché”.  Ils firent remarquer aux informaticiens qu’entre le début et la fin de l’histoire, il s’était écoulé 24 mois et que même un éléphant mettait bas en moins de temps.

Ils refusèrent donc d’utiliser l’outil et allèrent chez Mediamarkt en acheter un plus joli.

Sa morale

Vous voyez que cette fable comporte certaines leçons intéressantes du point de vue de la rigidité du processus de création de l’outil. Quatre phases chronologiques distinctes décrivent ce processus : spécification, développement, test, mise en production. Il s’applique d’ailleurs à tous les domaines pour lesquels un changement doit être concrétisé: mise en place d’une procédure, implémentation d’un nouveau processus, etc. De plus, il semble parfaitement logique: il faut réfléchir avant de mettre du temps dans la construction de quelque chose; il faut tester avant de mettre dans le flux productif afin de minimiser les risques. Ce modèle en cascade (waterfall model) semble donc sorti du manuel du bon sens.

Pourquoi ne fonctionne-t-il pas?

L’histoire ci-dessus nous met sur la voie:

  1. Le temps de livraison de l’outil est beaucoup trop long – et ce n’est pas un effet de la fable: certains projets prennent bien plus de temps et peuvent même finir par être annulés;
  2. La durée de chaque phase est trop longue, surtout pour des utilisateurs devant jongler entre leur travail quotidien et ces nouvelles tâches; de plus, ce sont souvent les utilisateurs les plus productifs qui participent à ces projets, ce qui impacte souvent négativement l’activité de l’organisation;
  3. Il est très difficile pour les utilisateurs de réfléchir en termes de processus parce qu’ils n’en voient souvent qu’une petite partie: leurs tâches; si l’informaticien voit le salami, l’utilisateur n’en voit qu’une tranche;
  4. Les utilisateurs ont de la peine à imaginer leur nouveau fonctionnement et se rattachent donc systématiquement à l’ancien.

Sa résolution

Au début du nouveau millénaire, des développeurs de logiciels se sont mis à réfléchir à une manière de livrer leurs prestations plus rapidement, avec une meilleure qualité et une plus grande satisfaction des clients (internes ou externes), en prenant en compte les facteurs identifiés dans la fable. Ils sont arrivés aux conclusions suivantes:

  • Le processus en cascade est trop rigide
  • Le processus en cascade met trop de barrières entre prestataires (informaticiens) et bénéficiaires (utilisateurs, entre autres)

Ils ont donc indépendamment les uns des autres créé des pratiques, des méthodes et des philosophies du développement logiciel que l’on regroupe aujourd’hui sous la bannière de l’Agile.

La promesse Agile

Je ne vais pas vous faire la description détaillée du contenu du manifeste Agile.

Sa promesse, c’est celle:

  • D’une collaboration retrouvée entre prestataires et bénéficiaires,
  • D’une adaptabilité de cette collaboration en fonction des contraintes vécues

Cette promesse se concrétise en un ensemble de principes et de pratiques.

Les principes de l’Agile

Ils sont au nombre de quatre mais les trois les plus importants sont:

  1. Les personnes et leurs relations comptent plus que les processus et les outils
  2. La collaboration compte plus que le marchandage contractuel
  3. L’adaptation au changement compte plus que le plan initial

Concrètement, cela veut dire que:

  • Il n’y a qu’une équipe dans ce genre de projets: c’est l’union des prestataires et des bénéficiaires
  • A choisir, passer plus de temps en team building qu’en définition de processus
  • En cas de choix d’investissement à faire, privilégier la formation des collaborateurs plutôt que l’achat d’outils de gestion
  • Si cela se passe mal, recourir à la médiation plutôt qu’à la machine légale
  • En cas d’achat de prestation à l’extérieur de l’organisation, favoriser la discussion et l’entregent plutôt que les conditions contractuelles (prix y compris)
  • Quand le changement interviendra, le prendre comme une opportunité plutôt que comme une menace
  • Passer plus de temps à mesurer ce qui se passe qu’à établir un plan détaillé

Chacun d’entre nous peut adapter ces principes à sa situation. C’est d’ailleurs là que l’Agile est puissant: nous sommes tous les prestataires de quelqu’un d’autre! Parents prestataires de nos enfants, maris de nos épouses, collaborateurs de nos cheffes, entreprises de nos clients, institutions de nos bénéficiaires, etc. C’est un lien universel entre une première entité qui peut fournir à une seconde entité un service (une prestation) que celle-ci ne peut pas se fournir à elle-même.

Les pratiques de l’Agile

Les pratiques Agiles sont multiples. Comme l’Agile est plus un mouvement qu’une méthode, elles continuent d’évoluer. Heureusement, d’ailleurs: vous imaginez une méthode Agile tenue par une minorité de personnes qui définiraient précisément ses règles? Quelle ironie!

J’en retiens quatre:

  1. Planning poker
  2. Sprint
  3. Daily meeting
  4. Rétrospective

Ces pratiques sont ritualisées: heures fixes, objets symboliques, mots-clés. Ces rituels aident à l’intégration de cette culture Agile dans la culture de l’organisation.

1. Le Planning Poker

Même en Agile, il faut planifier, et ceci pour deux raisons. D’abord, il faut mesurer la vitesse à laquelle l’équipe produit ce qu’elle produit (nombre de pièces fabriquées par heure, nombre de lits refaits par heure, nombre de fonctionnalités ajoutées au logiciel par semaine, etc.) pour déterminer son efficience. Ensuite, il faut coordonner les efforts entre les différents membres de l’équipe.

Le Planning Poker est un processus collaboratif de planification. L’emphase est mise sur l’aspect collectif de la décision: chaque tâche est évaluée par l’ensemble des membres de l’équipe selon un protocole très précis:

  1. L’ensemble des tâches du Sprint (voir ci-dessous) est présenté;
  2. La tâche est expliquée ou définie par la personne qui en a la charge;
  3. Les membres de l’équipe qui devront l’effectuer choisissent individuellement une carte dans leur jeu (d’où le nom de Poker); la valeur sur la carte représente leur évaluation de la tâche en question;
  4. Tous les membres de l’équipe posent leur carte en même temps; si les valeurs sont trop distantes l’une de l’autre, la personne responsable de la tâche réexplique la tâche, ses tenants et ses aboutissants; les deux personnes qui ont posé les deux valeurs extrêmes expliquent leurs raisons;
  5. Une nouvelle évaluation est faite (étapes 3 et 4); le processus est répété jusqu’à ce qu’un consensus soit trouvé; si deux valeurs émergent, c’est la valeur qui a le plus de poids qui est choisie
  6. La prochaine tâche est évaluée.

Que peut-on évaluer avec cette méthode? Principalement deux choses: la priorité ou la durée d’une tâche.

Ce protocole assure que la voix de tous les membres de l’équipe sera entendue, condition sine qua non pour l’émergence de l’intelligence collective.

2. Le Sprint

Une période d’activité ininterrompue par les changements de planning est appelée un Sprint. Dans le monde du développement logiciel, ils durent typiquement de deux à quatre semaines; vous pouvez adapter leur durée à votre activité ou à votre cycle de production. Par exemple, pour une entreprise de production, la fabrication d’une série de pièces pour un client peut constituer un Sprint; pour un EMS, une semaine de nettoyage des chambres des résidents peut être considéré comme un Sprint.

Un Sprint commence toujours par un Planning Poker et se termine toujours par une Rétrospective (voir ci-dessous).

3. Le Daily Meeting

Tous les matins, l’équipe se réunit debout pendant 15 minutes; chaque membre de l’équipe répond aux trois questions suivantes:

  • Qu’est-ce que j’ai fait hier?
  • Que vais-je faire aujourd’hui?
  • Quels sont les obstacles que je rencontre

Les obstacles sont notés et traités par les personnes responsables.

L’objectif est double. Premièrement, identifier l’avancement des tâches du Sprint; deuxièmement, identifier les points bloquants, qu’ils soient techniques ou humains. D’ailleurs, la personne qui gère le Daily Meeting doit être attentive à permettre l’explicitation de ces obstacles; en effet, ils ont une influence directe sur la vitesse de l’équipe.

4. La Rétrospective

A la fin du Sprint, l’équipe se retrouve et effectue une rétrospective. L’objectif est de déterminer ce qui a fonctionné et ce qui n’a pas ou moins bien fonctionné,et pourquoi. Une chasse aux sorcières n’est pas à l’ordre du jour: il s’agit de parler de fonctionnements ou de comportements, et pas de personnalités ou de défauts.

C’est un moment de détente et de plaisir pour l’équipe, et c’est également l’occasion de remercier les personnes et de célébrer les succès. Les méthodes d’animation doivent varier pour assurer un élément de surprise donc de fun.

C’est un élément central de l’amélioration de la vitesse de l’équipe pour les prochains Sprints et un des facteurs favorisant la collaboration au sein de l’équipe puisqu’il provoque une prise de conscience du comportement donc un potentiel de changement.

Au-delà des principes et des pratiques

L’Agile peut très facilement être appliqué dans d’autres domaines de la vie professionnelle ou privée. Il suffit de se rappeler des facteurs qui font son succès: collaboration, adaptation, temps de cycle courts.

Un exemple frappant que j’ai entendu récemment est celui des ressources humaines: plutôt que de définir des plans de carrière (ça sent la rigidité à plein nez), pourquoi ne pas plutôt définir un plan d’acquisition de compétences? Chaque compétence est un sprint, et le tour est joué:

  • L’équipe est composée de la personne, de son chef et d’une personne des ressources humaines
  • Le Planning Poker aide à prioriser les compétences à acquérir
  • Un Sprint de 3 mois développe la première compétence
  • Le Daily meeting devient un Weekly meeting; l’équipe discute des points habituels, mais appliqués à l’acquisition de la compétence
  • A la fin du Sprint, la Rétrospective permet à l’équipe d’évaluer la compétence acquise et détermine la suite à donner

Cet exemple illustre parfaitement la mise en application des trois facteurs (collaboration, adaptation, temps de cycle courts). A partir de là, the sky is the limit: c’est votre besoin et votre imagination qui détermineront comment vous allez utiliser les principes de l’Agile pour vous rendre la vie plus facile.

Partagez cet article