Cauchemar Agile – le piège de l’attrayante optimisation locale

« L’Agilité, est-ce vraiment supposé fonctionner ainsi ?! »

Vicky, une ancienne chargée de projet passionnée d’Agilité et devenue Scrum Master dans l’élan de la transformation de sa grande organisation, a l’impression de vivre un cauchemar pire que ses souvenirs du modèle traditionnel.

La planification du sprint de son équipe est au point mort. L’équipe a identifié plusieurs dépendances externes, qui sont toutes sous la responsabilité de différentes équipes de service fonctionnant avec Kanban. La refonte de la conception doit passer par le Product Owner du Kanban des architectes pour être priorisé. Le « Maître-Kanban » du système central des clients lui a récemment expliqué que sa demande n’était pas conforme à la définition d’entrée de l’équipe. Son équipe doit mieux la justifier.

Finalement, l’équipe d’accès aux environnements a récemment fait face à plusieurs enjeux de production et bien qu’en cours, la demande de l’équipe de Vicky s’est vu arrêtée, compromettant un élément majeur du prochain sprint. Quand elle en vient à considérer l’intégration cadencée du prochain train de livraison (release train), la pression pour livrer les engagements de la dernière planification inter-équipes est énorme, car ses composantes sont essentielles pour débloquer au moins deux autres équipes Scrum.

Comment va-t-elle faire pour traverser ce cauchemar qui, non résolu, va mettre beaucoup de pression négative sur son équipe d’ici la prochaine revue qui aura lieu dans deux semaines ?!

Qu’est-ce que l’optimisation locale?

L’optimisation locale est une conséquence fréquente d’une mise en place de techniques et méthodes Agiles, sans la compréhension générale des valeurs et principes derrière ces méthodes et sans considérer l’effet global en termes de valeur d’affaires pour le client final.

Je vais utiliser un exemple mentionné ci-dessus, l’exemple d’un Kanban de l’équipe des architectes. Si dans l’organisation il y a plusieurs centaines de projets en parallèle, ce qui est fréquemment le cas dans des grandes entreprises, la conclusion est souvent qu’il est impossible d’avoir un architecte à plein temps sur chaque projet.

Après avoir constaté l’inefficacité d’une affectation à 10% par projet, accompagnée par un coach Agile, l’équipe pourrait être séduite par une approche Kanban. Cela permettrait de grouper tous les architectes dans une équipe auto-organisée à temps plein qui fournirait un « service d’architecture » pour des besoins précis des projets.

À lire aussi : Quand laisser l’équipe échouer?

Ceux-ci seraient organisés dans une liste d’attente priorisée (c’est à dire un backlog) par une personne désignée et pris en charge par les architectes seulement si leur capacité le permet. Bien qu’attrayante, cette solution présente les principales caractéristiques d’une optimisation locale.

Perte de vue du client final

La fragmentation en petits morceaux des travaux précis qui entrent dans ce Kanban rend possiblement très difficile d’avoir une vue d’ensemble de la vision d’affaires et du besoin du client. Cela risque d’avoir un des répercussions négatives sur les solutions partielles envisagées, du moins du point de vue de l’utilisateur final.

Réduction de l’autonomie opérationnelle globale

En ayant optimisé le travail d’un groupe fonctionnel essentiel autour de l’efficience d’exécution interne, l’équipe vient de créer un goulot d’étranglement pour tous les projets travaillant sur les besoins du client final. L’accent est très orienté sur la maîtrise des processus de travail et la montée en compétence d’un nombre restreint de membres de l’équipe, au détriment de l’autonomie de l’organisation au complet.

Découvrez les concepts essentiels de la méthode Kanban. Concevez et mettez en place un tableau des tâches pour une équipe unique.  Découvrez le cours Team Kanban Practitioner

Surcroît de coordination requis

Dans une situation dans laquelle des équipes Kanban/Scrum dépendent autant les unes des autres pour la réussite de chacune d’entre elles, un besoin de coordination et d’intégration émerge naturellement. Souvent, il en résulte une « sur-coordination » avec une croissance des contrôles opérationnels, afin de garantir le bon fonctionnement de l’ensemble. Le Scaled Agile Framework propose une vision très séduisante de comment toute cette coordination pourrait s’orchestrer à l’échelle de l’organisation. Toutefois, l’adoption d’un modèle aussi prescriptif est souvent parsemée d’embûches majeures et n’offre que peu de résultats probants au niveau de l’entreprise.

Vers une vue holistique

Une difficulté majeure que des organisations à fortes racines traditionnelles vivent actuellement vient de leur façon d’évoluer au cours de leur croissance. Dans un effort de planification et de contrôle de l’exécution, et pour utiliser l’expertise de la façon la plus efficiente et maîtriser l’ensemble des risques en amont, les organisations se sont dotées de structures souvent très verticales, divisées par nature de travail et type d’expertise.

Or, dans ces mêmes organisations les flux de créations de valeur sont horizontaux, traversant souvent de nombreux domaines fonctionnels pour créer ensemble un produit ou un service dont le client est satisfait. Afin de rendre cette dichotomie efficace, les organisations ont répondu par une augmentation du nombre de processus et de contrôles pour s’assurer que les ensembles arrivent au résultat prévu.

De la vision à la discontinuité, en passant par le financement, la conception, le développement, les essais, l’implantation, l’exploitation, la maintenance et l’évolution pour ne nommer que ceux-là, le cycle de vie d’un produit se traduit par un nombre phénoménal de transferts de dossier, d’approbations, de transmissions de connaissances, de documentations, etc.

En implantant des techniques Agiles sans essayer de prendre une vue plus holistique (moins fragmentée), on finit par obtenir des avantages très localisés, aucunement alignés sur une vision d’affaires et un besoin du client final. Il est difficile d’espérer les gains tangibles de l’Agilité au niveau global si la transformation des techniques locales n’est pas accompagnée par une remise en question, à tous les niveaux de l’organisation, des pratiques actuellement acceptées.

Si on revient à Vicky, la stratégie qui a potentiellement le plus de chances de réussir est celle de rendre visible ce cauchemar afin de conscientiser ceux qui peuvent influencer l’introduction d’une solution plus durable. Même si cela ne risque pas de résoudre tous ses problèmes au jour un, en acceptant silencieusement le statut quo, Vicky est susceptible de se faire du tort à elle-même ainsi qu’à l’organisation sur le long terme.

Le changement ne vient pas par magie. Il est le fruit de l’effort soutenu de personnes conscientes qu’il est possible de travailler différemment et qui finit par faire basculer certaines « vérités » organisationnelles. Finalement, si cette stratégie ne fonctionne pas, il ne faut pas oublier qu’il y a d’autres organisations autour de vous qui ont déjà fait beaucoup de chemin et qui apprécieraient votre talent à sa juste valeur. Elles pourraient vous offrir un environnement plus humain pour vivre l’Agilité.