Publié le 30 mars 2020, mis à jour le 6 août 2021.
Avant d’analyser leurs divergences majeures, il faut comprendre l’intérêt du changement vers l’agile. Pour beaucoup de chefs de projet, les principes fondamentaux de l’agile sont contraires au management traditionnel ou aux compétences de leadership. À moins qu’il y ait un besoin vital de changer, notre nature humaine sera en résistance et se battra contre ce système.
La première raison pour adopter la méthode agile est qu'il est difficile de faire des plans sur plusieurs mois voire plusieurs années dans un monde en constante évolution, et tous les efforts fait pour se tenir à des étapes d'exécution spécifiques présenteront forcément des lacunes et des défauts. Ce sont ces changements permanents qui poussent les entreprises à adopter une culture d’open innovation et un nouveau style de leadership pour la faciliter.
L’approche verticale du management est remplacée par un leadership collaboratif qui permet aux équipes de planifier un projet et de prendre des décisions par elle-même. Ce management permet également de tirer profit des connaissances et des expériences de tout le monde puisqu’il est participatif.
Diriger vs. permettre à l’équipe de trouver sa direction
De manière générale, on considère que diriger une team pour lui faire atteindre un objectif précis est une excellente compétence de leadership. C’est l’analogie du berger qui mène son troupeau de mouton à travers un terrain hasardeux jusqu’à son paradis d’herbe fraîche. L’hypothèse de base est que le leader (ie le chef de projet) sait qu’elle est la meilleure manière d’allouer les ressources, de manager les risques et même de réagir aux changements, inévitables. On attend de l’équipe qu’elle suive le plan défini, et chaque modification, chaque adaptation doit passer par le chef de projet, qui apporte les corrections nécessaires après avoir consulté les autres partie prenantes.
À l’inverse, l’approche agile permet à l’équipe de trouver sa propre façon d’arriver aux objectifs. C’est alors au management d’investir davantage de temps et d’énergie en amont pour aider l’équipe à comprendre la vision globale du projet et la stratégie organisationnelle. A partir de là, le management fait confiance à l’équipe pour s’adapter et faire les ajustements nécessaires pour faire en sorte que cette vision devienne une réalité. Tous les obstacles et les changements de direction sont ouvertement discutés au sein de l’équipe, et le plan s’adapte de manière dynamique aux nouveaux apprentissages.
Éviter les échecs vs. s’attendre à échouer et rebondir rapidement
Le management de risque occupe une part importante d’un projet ; traditionnellement, c’est le chef de projet qui évalue en permanence les risques en jeu. Il travaille avec application pour surmonter ou atténuer ces risques et s’assure que l’équipe atteigne ses objectifs aux échéances prévues. L’échec n’est pas une option, ce qui le rend difficile à gérer lorsqu’il arrive. Beaucoup d’énergie est alors dépensée pour connaître la cause de l’échec et qui en est responsable. Généralement, toute l’équipe - y compris le chef de projet - est tenue pour responsable et tout le monde fini découragé, avec le moral de l’équipe en déclin.
À l’inverse, le mindset agile reconnaît qu’échouer est parfois naturel, et que l’on a plutôt intérêt à échouer rapidement pour voir le plus tôt possible ce qui marche et ce qui ne marche pas. Cette manière de voir les choses admet aussi qu’il n’y a pas de chemin tout tracé vers l’innovation et l'exécution, et que c’est à l’équipe de trouver sa voie à travers une expérimentation permanente et les apprentissages qu’elle apporte. La voie par défaut est d’essayer de nouvelles choses, même si le risque d’échouer est élevé dans les phases initiales du projet. Le leadership collaboratif encourage donc l’équipe à échouer rapidement et à rebondir le plus vite possible pour réussir à atteindre ses objectifs de manière dynamique.
Limiter les changements de périmètre vs. avoir un périmètre flexible
Le changement est souvent perçu comme une force négative dans la gestion de projet classique, puisqu’il éloigne l’équipe de sa direction originelle, direction qui a été définie pendant de longues et épuisantes sessions de planification pendant plusieurs mois. Les réunions pour traiter ces changements, où l’on évalue les modifications proposées par rapport au périmètre déterminé en amont, plutôt que d’essayer de comprendre pourquoi ces altérations sont requises, sont faites pour limiter les changements de périmètre. Si les modifications proposées obligent à décaler les deadlines ou à retravailler un aspect du projet, elles sont habituellement rejetées purement et simplement ou repoussées à la prochaine phase du projet.
La méthode agile considère le changement comme une force constante, et la meilleure manière de l’appréhender et de rester flexible. Cette approche part du principe qu’il vaut mieux délivrer un projet en se basant sur les informations les plus récentes que s’accrocher à des renseignements qui ne sont sans doute plus d’actualité. Même si cela implique de renoncer ou de reprendre des mois de travail, le changement sera envisagé si les informations disponibles ou les feedbacks indiquent qu’il produira un meilleur résultat, qu’il s’agisse d’un tournant majeur dans la direction du projet ou un tout nouvel objectif.
Investir dans un résultat spécifique vs. investir dans la santé et la progression de l’équipe
Le focus dans la gestion de projet classique, c’est de délivrer un projet en se basant sur un périmètre, un niveau de qualité attendu et un planning. Il s’agit d’un résultat précis, aux contours clairement définis et réalisables ; pourtant, le projet peut tout de même être un échec s’il ne prend pas en compte d’autres accomplissements, comme le développement de compétences, pour les membres de l’équipe, qui ne seraient plus pertinentes sur le marché. La progression et le bien-être de chaque individu d’une équipe, par exemple, ne relève pas de la responsabilité d’un chef de projet ; elle incombe généralement à d’autres organisations.
Pour la méthode agile en revanche, la santé et la progression de l’équipe font partie intégrante du rendu de projet. À intervalles fréquents, les membres de l’équipe sont encouragés à partager leur ressenti sur le moral général de l’équipe et la confiance qu’elle a dans sa capacité à atteindre les objectifs du projet. Si le moral de l’équipe est bas, on cherche à comprendre les raisons qui sont ensuite adressées par l’équipe elle-même ou le management. Une équipe dont la santé est bonne est aussi une équipe énergique et enthousiaste qui peut délivrer au-delà des attentes et stimuler une culture d’innovation.
Coordonner les efforts individuels et collectifs vs encourager l’auto-organisation et la collaboration
Dans la gestion de projet classique, le chef de projet est responsable de coordonner les efforts individuels et collectifs en prévoyant des points de contrôle et des réunions avec d’autres équipes, internes ou externes. C’est une tâche fastidieuse que de travailler avec toutes les équipes impliquées sur le projet, d’analyser leurs dépendances et de les démêler pour construire un plan clair et net pour faire avancer le projet. L’équipe se contente de faire remonter son besoin et d’attendre une réponse ou des instructions. Elle n’est pas dans une démarche proactive, elle ne s’organise pas par elle-même et ne collabore pas, en interne ou en externe, pour résoudre les problèmes rencontrés.
La méthode agile encourage l’équipe à s’organiser par elle-même et à collaborer, que ce soit avec des personnes en internes ou externes à l’organisation. C’est d’autant plus vrai dans un projet open source, où les équipes collaborent avec de multiples contributeurs et organisations selon leurs besoins et de manière spontanée. Dans ce cas de figure l’équipe comprend ce qui doit être fait et on lui fait confiance pour qu’elle le fasse de la manière qui lui paraît le plus appropriée. C’est l’équipe elle-même qui se donne les moyens de lever les dépendances à travers un flux constant de communication avec tous les contributeurs du projet.
Trouver des solutions vs. encourager l’équipe à résoudre les problèmes et les challenges
La plupart des projets rencontrent des obstacles et des challenges sous toutes formes. Dans le modèle traditionnel, c’est la responsabilité du chef de projet de trouver les solutions. Une procédure d’escalade claire est en place et remonte les problèmes, pendant que l’équipe attend qu’une solution leur soit présentée. Il arrive que l‘équipe se retrouve bloquée pendant plusieurs semaines voire mois en attendant qu’on leur propose une solution.
A l’inverse, en agile, lorsqu’on demande à l’équipe de résoudre ses propres problèmes, il se passe quelque chose d’extraordinaire : l’équipe prend le challenge et trouve des solutions innovantes pour sortir de l’impasse. La méthode agile met l’intelligence de chacun à contribution, plutôt qu’une seule, pour résoudre les problèmes et lever les blocages. La production participative et la réflexion collective permettent de surmonter les challengesde façon surprenante et remarquable.
La norme émergente
Le leadership et la gestion de projet classiques ont bien servi le monde de l’entreprise pendant la révolution industrielle, quand la préoccupation première était les machines-outils à usage spécifique, les usines et la production de masse. Une poignée de managers exécutifs qui comprenaient le marché, prenait les décisions en se basant sur des informations que les employés de plus bas niveau, aux fonctions très spécialisées, n’avaient pas forcément besoin de connaître.
Aujourd’hui nous vivons dans un monde interconnecté où les organisations font face à un climat économique difficile et à la concurrence internationale. Alors que les entreprises cherchent de nouvelles manières de croître, des nouvelles formes de leadership émergent et s’établissent. Les employés aspirent à davantage d’autonomie et d’investissement dans leur travail au quotidien. C’est dans l’intérêt des organisations de créer un environnement collaboratif pour encourager une culture de créativité et d’innovation, guidée par une approche agile de la planification de projet.
Merci à Ranjith Varakantam pour cet article, vous pouvez aussi lire la version originale.
Vous voulez être coach agile ? Padok recrute !
