L’organisation agile « en pagaille »

La plupart des entreprises de technologie et de services connaissent les méthodes agiles ; elles les ont peut-être testées ou mises en place dans certaines parties de l’organisation, dans leurs équipes informatiques ou de R&D, voire plus largement.

L’agilité a-t-elle finalement été un choix gagnant pour toute l’organisation ?

J’ai vu des entreprises mettre en place des méthodes agiles dans leur organisation, en particulier dans leur informatique ou leur R&D (avec Jira ou d’autres outils, avec des sprints, des epics, des stories…), pour améliorer leur performance, mieux communiquer, avoir une vision plus claire de leurs développements et des actions à mener, mieux gérer les changements de périmètre et mieux se connecter aux utilisateurs et aux équipes produit.

Cela a-t-il vraiment résolu les problèmes de ces entreprises ?

Je pose la question parce que les méthodes agiles peuvent créer une vraie déconnexion entre les équipes de développement et le reste de l’organisation, en particulier les product owners et les dirigeants métier. Cette déconnexion peut être profonde : priorités mal alignées, communications différentes, façons différentes de rendre compte de l’avancement, perte de la vision d’ensemble au profit de détails minuscules…

Dans certains cas, l’agilité a pu aider du point de vue de l’informatique ou de la R&D, tout en provoquant de nombreuses perturbations dans d’autres parties de l’entreprise. Plus encore, l’agilité peut être détournée et utilisée par l’informatique ou la R&D pour servir leurs intérêts techniques, sans vraiment servir l’entreprise ni les objectifs et attentes de sa direction. Le risque est que les équipes informatiques ou de R&D se servent de l’agilité pour se cacher derrière une liste de stories, d’actions, de complexité et de choses à faire, afin de se protéger de tout engagement (pour de nombreuses raisons que je ne détaille pas ici). L’informatique ou la R&D peuvent même créer leurs propres codes projet et leurs propres priorités, sans qu’ils soient nécessairement alignés sur les métiers, ce qui réduit la maîtrise de l’avancement et complique les arbitrages. Les équipes métier ne comprennent pas vraiment pourquoi, sont frustrées et doivent devenir plus techniques pour comprendre, parce qu’elles veulent savoir si le projet sera livré dans les délais, la qualité et le budget prévus.

Dirigeant métier, responsable produit ou responsable de compte, avez-vous déjà été frustré par les réponses des « équipes agiles » quand vous leur demandez des dates de livraison, des jalons et des engagements ? Ces réponses ne vous aident pas forcément à rassurer vos clients, ou ne sont pas assez précises pour mettre à jour un plan de projet, ajuster votre feuille de route ou rendre compte de l’avancement à la direction générale.

Pour bien reconnecter les équipes agiles et les métiers (que je considère ici comme non agiles), les entreprises ont besoin d’un management intermédiaire vraiment talentueux et bien formé, et bien sûr d’excellents directeurs de programme et de produit. Un bon directeur de produit ou de programme comprendra l’importance d’aligner les indicateurs et les KPI des projets agiles sur les objectifs stratégiques et les valeurs de votre organisation. C’est essentiel, car cela réunit les équipes agiles et les parties prenantes autour d’un but et d’une direction communs. Et surtout, cela permet de démontrer la valeur et l’impact de vos efforts agiles à votre direction et à vos clients.

Les directeurs de programme et de produit sont devenus des acteurs clés, plus encore qu’auparavant. S’ils ne sont pas au meilleur de leur forme pour jouer efficacement le rôle de passerelle entre tous, vous êtes ou serez sûrement dans une organisation agile « en pagaille » !

Vous vous reconnaissez ? Respirez, vous n’êtes pas seul à vous débattre avec cela.

Contactez-moi, nous avons des solutions pour vous. Prenez rendez-vous ici