Quand l'agilité n'est plus une fin en soi
Il est assez facile et tentant d’ajouter des réunions, d’imposer des processus, etc. pour « faire agile » … Pourtant, nous ne pouvons pas résumer les méthodes agiles à leurs artefacts ou leurs réunions.
Si nous commençons comme cela, nous allons rapidement voir les gens se présenter aux réunions, s’asseoir, et… rester sans savoir quoi dire, ni quoi faire. Nous pouvons alors engager un tour de table, où chacun va parler de ses sujets. Les membres de l’équipe vont alors rentrer dans un tunnel et décrire leur journée, puis se replonger sur leur ordinateur, guère plus concernés par les problèmes des autres.
Le problème n’est pas l’attitude des membres de l’équipe, mais la compréhension même de la Raison d’Être de ces réunions. Au-delà des rendez-vous quotidiens et hebdomadaires, il est important que tout le monde soit aligné sur la définition même du mot « agile ».
Qu’est-ce que l’agilité ?
Beaucoup de monde dit « faire de l’Agile » sans « être » agile… Et ce n’est pas un drame.
Les puristes me diront que Scrum exige d’être appliqué en mode tout ou rien : soit nous appliquons les rituels, les artefacts et attribuons les rôles dans les bonnes personnes, soit ce n’est pas Scrum. Dans le fond, ce n’est pas faux… Mais c’est précisément le moment où il faut prendre du recul et revenir à la philosophie de l’Agile – pas seulement de Scrum.
La philosophie
L’Agile est une approche qui privilégie les personnes, la valeur délivrée rapidement, la flexibilité et les retours en continu, plutôt que les processus rigides, la documentation lourde et les plans figés. Ce principe est parti d’un constat simple : quand le cadre est clair et que tout le monde est aligné sur l’objectif, alors chaque membre de l’équipe s’implique de façon efficace dans le produit et la création de valeur.
C’est une mentalité centrée sur l’adaptation et la collaboration pour créer de la valeur efficacement. Pas sur les processus. Autrement dit, se figer sur l’application stricte de Scrum, comme un processus miracle, va à l’encontre même de la philosophie Agile !
Le cycle Agile
Cette philosophie se décline sur 4 piliers fondamentaux : la transparence, l’inspection, l’adaptation et l’exécution. Les plus fins connaisseurs verront sans doute le parallèle avec le PDCA et le Lean.
Nous avons déjà exploré la transparence au travers d’un article entier. Elle est essentielle pour permettre l’inspection de nos processus, à travers laquelle nous identifierons les points forts et limites de nos processus tel que nous les appliquons. Nous pourrons alors les revoir, au sein de l’équipe, et les corriger pour les adapter au mieux à nos besoins. Enfin, le Lean étant une philosophie japonaise, ces processus doivent être exécutés de façon répétitive tels les Kata des arts martiaux, pour bien les maîtriser, les comprendre et… éventuellement les critiquer, nous entraînant par là même dans une nouvelle itération.
Ainsi, nous voyons que Scrum n’est pas un remède miracle. Il propose une application de cette logique, avec des rituels dédiés à l’inspection du produit, mais aussi des processus de l’équipe. Mais ce n’est pas la seule déclinaison des méthodes agiles existantes sur le marché de l’agilité.
Le rôle du manager
Le manager est souvent mis à l’écart, dans le processus Scrum et dans de nombreuses approches agiles, car l’équipe doit être autonome pour être performante. Nous avons eu l’occasion de l’évoquer dans notre précédent article sur la gouvernance, le manager devient pourtant nécessaire lorsque l’organisation commence à s’étendre.
Cette fonction découle de la division du travail et de la comptabilité en partie double, permettant de traiter le capital de l’entreprise indépendamment de celui de l’entrepreneur. Sans rentrer dans les détails administratifs et financiers, le manager gère une partie bien définie du capital de l’entreprise avec une mission claire, des objectifs clairs et un budget clair. Il est alors garant du bon emploi du capital à sa disposition et de sa maximisation. Les objectifs de l’entité dont le manager a la charge sont donc des objectifs financiers, qui doivent être reliés aux les objectifs de l’équipe (ou des équipes) sous sa responsabilité.
En milieu agile, maximiser le capital implique précisément d’éliminer le gaspillage organisationnel. Le rôle du manager est alors de fournir le cadre nécessaire pour protéger le focus de l’équipe, transformant les ressources financières en valeur concrète ; et les objectifs financiers en objectifs opérationnels.
De la théorie à la pratique
Quand l’entreprise croît : les équipes Produit
Les modèles d’organisation agiles sont alignés sur un point : pour être efficace et répondre aux besoins des utilisateurs, elle doit être pluridisciplinaire : chaque métier et chaque compétence essentiels pour répondre à ces besoins doit être présents au sein de l’équipe.
C’est d’ailleurs ce que nous appelons une organisation en équipe produit : celle-ci gère tous les outils, la plateforme et les ressources nécessaires à son produit. Par exemple, une équipe produit peut dépendre d’une brique gérée par une autre équipe pour l’identification et les autorisations des utilisateurs. Étant autonome, elle pourra néanmoins avancer en développant sa propre solution. Celle-ci restera alignée sur les bonnes pratiques communes à l’entreprise (notamment grâce à la gouvernance d’entreprise que nous avons vu récemment). De la sorte, lorsque la solution définitive sera opérationnelle, l’équipe produit pourra l’intégrer à la place de sa propre solution.
Un autre exemple que j’ai déjà vu concerne l’interface web de nos produits : j’ai déjà vu des sites web dont l’interface donnait une impression de « sapin de Noël » car chaque équipe avait sa propre application de la charte graphique de l’entreprise. Ce n’était pas gênant car les fonctionnalités étaient opérationnelles, et les différentes équipes se sont alignées au fur et à mesure que la charte était consolidée.
Ainsi, l’indépendance de l’équipe a permis l’un (progresser rapidement) sans empêcher l’autre (l’alignement final des équipes).
Maintenir l’alignement entre plusieurs équipes
Face aux imprévus, nous avons rapidement tendance à vouloir escalader. Pourtant, cette réaction est généralement contre productive. Au fil de mes précédents articles, nous avons abordé deux philosophies d’organisation : le Lean, axé sur la réduction du gaspillage et la maximisation de la valeur ; et le Management 3.0, favorisant l’auto-organisation et la collaboration des équipes. Toutes deux mettent l’accent sur la subsidiarité, qui consiste en des décisions au plus proche du terrain, là où réside la véritable expertise. En faisant confiance à ceux qui exécutent pour résoudre les blocages au quotidien, nous éliminons les lenteurs bureaucratiques et libérons l’initiative opérationnelle.
Dans un précédent article, nous avons déjà évoqué LeSS pour l’alignement sur les objectifs. LeSS propose d’instaurer des points de synchronisation réguliers, c’est-à-dire des rendez-vous courts et rythmés visant à mettre à jour nos objectifs communs. Ces moments partagés nous évitent de travailler en silo (chacun de notre côté) tout en maintenant une agilité maximale.
La proposition de LeSS avec la subsidiarité à laquelle nous encouragent le Lean et le Management 3.0 nous montrent comment réajuster notre trajectoire collective en continu, sur la base des réalités vécues par le terrain.
Dans ce même esprit, j’ai déjà vu à l’œuvre une application relativement simple consistant à rassembler toutes les équipes au sein d’une seule et unique réunion, mais avec une flexibilité totale. Ici, chaque équipe n’intervient que sur les sujets qui la concernent directement. Le manager cherchera ici à optimiser les flux : il lui incombe d’agencer l’ordre du jour pour que les interventions s’enchaînent de manière logique. Ainsi, un collaborateur sollicité au début de la séance peut rapidement retourner à ses tâches, sans avoir à attendre passivement la clôture de la réunion. Lorsque plusieurs équipes sont concernées par un sujet, celui-ci sera planifié au plus proche des interventions de ces différentes équipes dans l’agenda.
Avec cette rationalisation du temps, nous cherchons à respecter de notre mieux la concentration de chacun tout en renforçant la cohérence de notre collectif.
Comment une équipe Infra peut-elle être agile ?
Dans des organisations beaucoup plus lourdes et aux habitudes plus anciennes, nous ne pourrons pas toujours refondre toute l’organisation pour résoudre les problèmes de dépendance entre les équipes. Dans ces organisations, nous avons souvent des équipes métiers qui portent la spécialisation nécessaire à la gestion des ressources dont l’équipe produit aurait besoin. Typiquement la gestion des déploiements en production pourra passer par une équipe dédiée aux opérations, et la gestion de l’infrastructure elle-même pourra passer par une autre équipe dédiée. Cette équipe Infra pourra gagner en agilité, sans s’alourdir de processus inutiles, en adaptant quelques pratiques à ses besoins.
Nous devons rendre le travail visible grâce à Kanban : cet outil visuel issu du Lean permet de suivre le cycle de vie de chaque tâche (à faire, en cours, fait,…). L’enjeu principal consiste à limiter rigoureusement notre WIP (Work in Progress, ou travail en cours), c’est-à-dire le nombre de sujets traités en simultané par un même collaborateur. En structurant notre tableau pour séparer distinctement les projets planifiés des urgences imprévues, nous brisons l’illusion d’une capacité infinie et protégeons notre efficacité face aux sollicitations incessantes de l’organisation.
Nous gagnons ensuite à piloter notre infrastructure comme un véritable produit, en orientant nos efforts non pas vers la simple maintenance technique, mais vers la valeur concrète apportée à nos utilisateurs internes, comme les développeurs. Plutôt que de subir le quotidien, nous fixons un cap global d’amélioration que nous déclinons en chantiers à court terme, axés sur la réduction des frictions opérationnelles. En appliquant à nouveau le principe de subsidiarité, nous laissons l’équipe définir elle-même ces objectifs intermédiaires : puisque c’est elle qui subit les failles des systèmes au quotidien, c’est elle qui détient la légitimité pour choisir les combats prioritaires.
Enfin, il est important de sanctuariser du temps pour que ces projets de fond ne soient pas systématiquement étouffés par les urgences du moment. Il s’agit alors de bloquer une part fixe de notre capacité de travail (le temps et l’énergie disponible dans l’équipe) entièrement dédiée à l’automatisation et à la consolidation technique. En protégeant ce capital contre les interruptions extérieures, nous sortons durablement du rôle de « pompier » pour investir dans l’avenir, garantissant ainsi que notre agilité devienne une réalité tangible.
Conclusion
La méthode agile choisie n’est pas une fin en soi : il n’existe pas de méthode unique à laquelle toutes les entreprises et toutes les équipes devraient se conformer. La preuve la plus éclatante de ce fait est la multitude même de méthodes existantes : Scrum, Kanban, Extrem Programming, FAST, LeSS, Lean, SAFe,… Nous pourrions continuer longtemps le catalogue. J’ai même connu des méthodes éphémères et d’autres spéciales 1er avril (juste pour la blague)…
Le plus important est de bien comprendre la philosophie et la finalité derrière toutes ces méthodes agiles, et de partager cette compréhension avec toutes les personnes concernées : direction, managers, membres de l’équipe. Cette compréhension nous amène au deuxième point le plus important, car le fond de la philosophie agile réside d’une part dans notre capacité à être aligné sur les objectifs de l’entreprise, c’est-à-dire le meilleur moyen de répondre aux besoins des clients, et d’autre part dans le développement de l’autonomie de l’équipe, de sorte à accroître son efficacité.
Enfin, la clé fondamentale commune à toutes les méthodes agiles est l’expérimentation. Nous expérimentons sur nos produits, nous pouvons (et devons) également expérimenter sur notre organisation, et ainsi l’adapter à nos besoins.
Ressources
- Agile Manifesto
- L’Action humaine, de Ludwig von Mises
- The Toyota Way, de Jeffrey K. Liker
- The Scrum Guide
Write a comment