Comment échouer dans l’agilité

Rares sont les personnes qui maîtrisent parfaitement l’agilité. C’est pourquoi il existe de nombreuses informations sur les méthodes agiles pour vous guider en vous expliquant ce qu’il faut faire pour être agile et le rester. Nous, on vous dit ce qu’il ne faut surtout pas faire :

Echec-300x225

 

Dans notre étude sur les chiffres de l’agilité , nous avons pu avoir un premier aperçu des causes majeures d’échec des projets agiles. Nous avons souhaité approfondir ce sujet. Nous nous sommes donc intéressés à la conférence pour Menaversity d’Amr Noaman le fondateur du Lean & Agile Egypte et le coach Agile Mohamed Amr qui nous font part de leurs réflexions sur les raisons d’échec des projet agiles.

Confondre « faire de l’agile » et « être agile »

Faire de l’agile c’est se focaliser sur les pratiques, les outils tandis qu’être agile repose sur les valeurs et les principes de l’agilité : être agile c’est un état d’esprit. Il faut savoir que la pratique de l’agilité avec des outils tels que SCRUM ou autre ne représente qu’une partie minime du temps passé sur un projet agile. Ce qui dominera sera l’état d’esprit agile, c’est lui que vous devez garder tout au long du projet. Il faut absolument avoir en tête les 4 valeurs de l’agile Manifesto à savoir :  Les individus et leurs interactions, Des logiciels opérationnels, La collaboration avec les clients, L’adaptation au changement et ses 12 principes qui en découlent.

La nuance est importante à cerner entre le « faire » et le « être ». Par exemple, faire de l’agile c’est respecter le processus SCRUM, faire un tableau Kanban ou encore organiser des Stand up Etc. Seulement être agile c’est plus que çà. Le « Being Agile » c’est l’état d’esprit, la mentalité. Vous pouvez utiliser  tous les outils de l’agilité possibles et imaginables, si vous n’avez pas cet état d’esprit agile vous serez bloqués à un moment ou à un autre. On ne peut pas être agile seulement en adoptant un groupe de pratiques de l’agilité (Scrum, Extreme Programming etc…). Être agile repose sur la réactivité, la façon de se comporter tout au long du projet agile, la manière de communiquer, de penser : il faut penser agile ! Si vous vous réunissez lors d’une Stand Up avec vos équipes mais qu’ils ne saisissent pas  l’intérêt, les valeurs du Stand Up mais qu’ils sont présent juste par obligation, ce dernier sera totalement inutile. Il ne faut pas faire de l’agile juste pour faire de l’agile. L’équipe doit porter les valeurs de l’agilité.

Suivre les règles

Les règles sont faites pour être enfreintes. Il est impossible de suivre à la lettre tous les concepts et pratiques de l’agilité. Si vous n’adaptez pas ces règles à votre projet vous avez de grandes chances de foncer dans le mur. Brisez ces règles et personnalisez les ! C’est d’ailleurs une des 4 valeurs sur laquelle repose l’agilité : L’adaptation au changement. Il faut être flexible en étant capable de s’adapter et ne pas suivre forcément le plan initial. Et surtout n’hésitez pas à créer vos propres règles qui reposeront sur votre vision et/ou la vision de vos équipe de l’agilité. Il n’y a pas de limite à l’agilité : réinventez là de manière continue.

Ne pas tenter

Si vous partez en disant que vous n’avez pas besoin de telle ou telle pratique ou qu’elle ne marchera pas sans l’avoir testée au préalable vous passez forcément à côté d’une occasion. Car comme il a été dit plus haut il faut réadapter les pratiques à votre propre cas. Donc même si vous vous plantez cet échec sera positif : il vous permettra de rebondir car se planter c’est le seul moyen de savoir quels changements il faut appliquer pour s’améliorer.

Ne pas enseigner l’agilité aux équipes et aux clients

Il est important d’enseigner l’agilité aussi bien aux équipes qu’aux clients. Il ne faut pas réserver la transmission de connaissances uniquement à une partie de l’équipe ou aux managers seulement : tous les collaborateurs doivent être agiles. Tout le système, toute l’organisation est concernée. Si l’équipe comprend les valeurs de l’agilité et voit les bénéfices que cela peut apporter la pratique n’échouera pas.

De nombreux projets ont aussi échoué par la faute du manque de connaissances de l’agilité du client. Lorsqu’il n’est pas impliqué ou qu’il est tout simplement réfractaire aux pratiques de l’agilité, par exemple quand il vous dit que tout ce qui l’intéresse c’est de voir le projet quand tout sera prêt car il n’a pas le temps, à ce moment-là il est de votre devoir de lui enseigner les valeurs de l’agilité et ses retombées positives.

Que ce soit pour les clients ou les équipes : vous devez leur apprendre à penser différemment, travailler différemment en leur expliquant pourquoi ils doivent être agiles.

S’arrêter sur un échec

C’est pire que de ne pas tenter. Comme expliqué plus haut, chaque échec est positif, il permet de rebondir. Seulement si vous avez investi dans un projet, qu’il échoue et que vous vous en arrêtez là : tout cet investissement par à la poubelle. Il est important d’apprendre de cet échec et d’en tirer un enseignement pour les projets à venir. C’est la culture de l’échec.

D’ailleurs que ce projet échoue ou non vous aurez toujours des leçons à en tirer, des changements éventuels, des réadaptations : c’est la recherche de l’amélioration continue.

Laisser les mauvaises personnes jouer les mauvais rôles

Les rôles de chacun doivent être bien définis au préalable car sinon c’est le chaos. Chacun peut monter sur le territoire de l’autre ou inversement : le travail n’est pas fait car on pensait que c’était à un tel plutôt qu’un tel de le faire. Si tout çà n’est pas cadré dès le début, il y a beaucoup de chance de faire face à des difficultés d’organisation. Ces rôles doivent être définis de manière intelligente. Pour exemple : tous les chefs de projets ne sont pas forcément de bons Scrum Master et vice versa. (Voir comment repérer un bon Scrum Master)

Se focaliser sur des détails et pas sur la vision générale du projet

Vous vous devez d’établir un planning complet. Certes un des principes sur lesquels repose Scrum est le « sprint » suivi d’une démonstration au client, seulement vous ne pouvez pas planifier uniquement ces sprints sans avoir une vision globale du projet. Si vous ne le faites pas vous risquez de passer à côté de ce qui est important. Il faudra toujours regarder au-delà des itérations pour garder à l’esprit les principes fondamentaux du projet. Par exemple les équipes qui ne font que coder ce qui leur est demandé pour une fonctionnalité précise sans s’intéresser à l’architecture complète du projet sont un danger pour ce dernier.

Ne pas créer d’équipes avec différents profils/compétences.

Le point commun qui est ressorti entre toutes les sociétés qui ont réussi dans l’agilité est la conception de « Cross-Functional Teams ». Il faut créer des équipes où l’on peut trouver tous les membres détenant les compétences nécessaires à la réalisation complète d’un projet. Chez Agilaction nous appelons ces équipes les « Teams Projet », chacune a une identité bien à elle avec un logo et un nom et travaille pour un projet bien précis.

S’appuyer sur les outils plutôt que sur une réelle collaboration

L’agilité ne réside pas dans les outils. Utiliser JIRA ou autre ne vous fera pas devenir agile comme par magie. Nombreuses d’ailleurs sont les sociétés qui réussissent dans l’agilité seulement avec des outils type « papier crayon ». Il est certain que vous pouvez être amené à utiliser ces outils par nécessité mais l’agilité ce n’est pas un outil. L’important restera toujours la communication, la collaboration. Les outils pourront vous aider à maintenir une bonne communication mais ne pourront en aucun cas la remplacer. Les outils ne sont que des outils. Il est de votre devoir de vous impliquer personnellement dans la communication et la collaboration de vos équipes et ne pas laisser les outils s’en charger à votre place.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *