L’adjectif agile est beaucoup employé et assez peu expliqué. C'est tout l'objet de ce papier (en 4 questions), que de faire le lien entre un mouvement né en Californie au début des années 2000 et ce que peut faire un manager au quotidien.
D’où vient le mouvement agile ?
Historiquement, l’Agile vient du développement informatique dans les années 1990. C'est absolument clé pour en comprendre la logique. La première caractéristique de cette activité, c’est qu’elle n'a pas de limite comme celle inhérente à la fabrication de produits physiques. Quand on fabrique des stylos ou des automobiles, il existe des spécifications claires, des coûts associés aux matériaux et un nombre limité de façons dont ces produits peuvent être utilisés par les clients. Forts de ces limites d’utilisation du produit, les ingénieurs parlent peu avec les clients finaux, durant la fabrication de la voiture ;) Or, le logiciel n’a pas ces limites donc ce niveau de prévisibilité. La formule serait plutôt : on sait quand ça commence ; on ne sait pas quand ça finit… et sous quelle forme ! Cette incertitude s’est accrue pour deux raisons. Tout d'abord, les coûts de création ont baissé et si le client a une imagination débordante, les options ou combinaisons possibles de fonctionnalités ont explosé ! Ensuite, les conditions du marché ont évolué : un concurrent peut lancer un produit similaire avant que vous n'ayez terminé le vôtre, une start-up peut disrupter votre marché, vous obligeant à bouger. L’agilité devient alors une qualité primordiale. Les auteurs de l’Agile Manifesto (1) ont d’ailleurs abordé le développement logiciel avec des principes plutôt qu’un éventail de tactiques spécifiques pré-établies. Au coeur de ces principes, une conviction : «Nous préférons réagir au changement plutôt que de suivre un plan.» Ainsi, face aux incertitudes, l’Agile Manifesto préconise de travailler en cycles courts (sprints) en associant le client à l’origine du travail. Ce qui donne l’opportunité de faire une pause à la fin de chaque cycle pour réfléchir ensemble à ce qui a été fait, ce qu'on a appris et quelles sont les prochaines étapes : est-ce qu'on continue dans la même direction ou on change de cap (être agile) ? Dans tous les cas, on repart sur un autre cycle court.
En quoi ça concerne le management ?
On peut en effet se poser la question du lien entre une façon de développer un logiciel et le management des équipes au quotidien. Le lien se matérialise par une analogie : le management s’est inspiré du mouvement Agile dans la prise en compte du client, de la complexité et de la vitesse, cette fois à l’échelle de l’entreprise. L’Agile Manifesto est d’abord écrit pour mieux répondre au besoin du client du développement logiciel. Dans le management, l’Agile repense la structure même de l'entreprise, autour du client. Ça se traduit dans la façon de considérer la hiérarchie et l’organisation du travail. Mettre le client au cœur du dispositif, c'est tenter de résoudre son problème plutôt que d'appliquer une procédure. L’Agile oblige à raisonner par valeur ajoutée plutôt que par territoire. Comme cette valeur ajoutée est dans la tête des gens, l’Agile consacre la suprématie des relations interpersonnelles sur les processus. Ceci se concrétise par la fréquence des itérations entre les acteurs. On règle les problèmes, ensemble, en se parlant, par delà les silos. L’acteur agile considère les différentes parties de l’entreprise comme ses clients - des personnes et des groupes dont les besoins diffèrent, et qu’il convient de comprendre. Cette volonté de résoudre des problèmes se retrouve jusque chez les managers. Agiles, ils cherchent à supprimer les contraintes qui empêchent les équipes plutôt que de leur déléguer ce travail. Ce n’est plus un leader-qui-sait mais un manager qui veille à montrer qu’il ne détient pas le savoir ou la solution, pour permettre aux collaborateurs de le surprendre avec leurs propositions. L’Agile favorise des entreprises aux structures hiérarchiques de plus en plus plates, Le manager agile est un facilitateur qui fournit une direction et une vision à long terme. Il aide les membres de l'équipe à comprendre ce qu'ils doivent faire et comment ils peuvent le faire sans les micro-manager. Il en a conclu qu'il devait essayer de prendre le moins de décisions possible. Il se dégage ainsi du temps pour faire définir et ordonner les priorités stratégiques, renforcer les capacités organisationnelles afin d'atteindre les objectifs. Dans l'organisation du travail, les entités qui se reconfigurent autour du client sont moins confortables que ceux qui s'en soucient peu. Le client suppose une coopération interne des salariés où chacun peut venir sur le territoire de l'autre afin d'anticiper sur ce qui va suivre, en continuant ce qui a été effectué et en évitant toute rupture dans l'action présente. Dans une bureaucratie technique classique, l'organisation est claire et permet une sécurité des acteurs. « J’ai mon territoire clairement défini. Il m'appartient. Je fais ce que je suis supposé faire et le résultat d'ensemble n'est pas mon problème (2) ». La limite de l'exercice tient au fait que, dans cet environnement plus dur, l'agilité doit aller jusqu'à la gestion des carrières. Les acteurs qui font l'effort d'être agiles ne doivent pas courir d’un « sprint » à l’autre, en continu. Mais ce constat n'a pas encore été traité dans les entreprises : on multiplie les équipes agiles sans autre considération que leur succès immédiat plutôt que de penser à leur maintien sur le long terme. Au risque d’une « agile fatigue »…
Comment ça marche ?
On a vu que la complexité logicielle augmentait avec les possibilités technologiques. On poursuit l’analogie avec l’entreprise. Plus une entreprise a de clients, plus elle a des produits, des marchés et des départements etc. : les entreprises sont des systèmes complexes dans des environnements complexes. Tout se passe en même temps et les problèmes ignorent toute autorité centrale. Or, pour un meilleur contrôle d'un système complexe, la plupart des décisions doivent être prises dans les sous-systèmes. Avec ce principe, le manager descend les décisions et les responsabilités à un niveau où quelqu'un a des informations plus précises que lui et où la décision devient plus simple à prendre. A cette échelle, les prévisions sont limitées et nécessitent des ajustements rapides (agiles) et coordonnés au fur et à mesure que les événements sont connus. Le mouvement agile est d'abord taillé pour affronter la complexité. C’est une solution simple à mettre en oeuvre : des livrables, des missions pour les livrer, des cycles durant lesquelles l'équipe s'attache à livrer. De ce fait, un objectif purement quantitatif de vente ne gagnerait rien à être géré en mode agile. En revanche, un objectif consistant à acquérir un nouveau segment de clients comporte une part de complexité dans laquelle l'agilité peut s'avérer utile. Confrontée à un problème important et complexe, l’équipe managée en agile le décompose en modules, Cette déconstruction permet de concevoir des objectifs concrets, clairs, limités, auxquels une petite équipe (gage d’efficacité) peut s’identifier. Parce que le problème est souvent multi causes, cette petite équipe est multidisciplinaire. Double effet Kiss Kool : la mobilité intra-organisationnelle permet d’augmenter l’engagement psychologique des collaborateurs : ils se tiennent responsables des résultats (tels que la croissance, la rentabilité et la fidélisation de la clientèle), plutôt que des seuls moyens mis en oeuvre (tels que les lignes de code ou la conformité dans l’application des procédures). Idéalement, l’atteinte d’un objectif agile ne doit d’ailleurs pas être lié à des récompenses ou des incitations. La motivation extrinsèque déforme le comportement et a des conséquences qui vont souvent à l'encontre de l'objectif lui-même. Au lieu de cela, un objectif doit répondre aux désirs intrinsèques des acteurs. Ce qui signifie concrètement que les équipes agiles se forment ad-hoc pour traiter les problèmes qu’elles rencontrent. Ceci réduit les niveaux de contrôle et d’approbation nécessaires, accélérant le travail et augmentant la motivation des équipes. Les méthodes Agile renforcent aussi la communication et la prise de décision au sein d'une équipe. Améliorer ces caractéristiques intrinsèques du travail permet plus d’autonomie, de responsabilité, de variété dans les tâches… et cela conduit généralement à une augmentation simultanée de la satisfaction vis-à-vis du travail. L’idée sous jacente, c’est qu’avec l’Agile, le collaborateur n’est jamais un pion impuissant qui ne ferait que subir un problème qui le dépasse. Le reporting, symbole de la hiérarchie s’il en est, devient collectif en passant à un tableau de bord partagé (virtuel ou réel) accessible à tous et alimenté par tous. C’est l’équipe qui construit et régule les plans d’actions. Le projet collectif favorise la collaboration. Dans l’Agile Manifesto, elle opère pour la première fois entre le client et l'équipe de développement informatique avant même la livraison du produit. Symboliquement, elle met côte à côte des acteurs qui jusqu'à présent étaient face a face. On peut emprunter le principe hors du champ du développement informatique : ce changement de position facilite les résolutions de problèmes : l’équipe chargée de résoudre le problème est plus empathique et comprend mieux le besoin du client. Lequel, de son côté, comprend mieux les éventuelles difficultés de l'équipe. Cette collaboration aplanit les silos dans la gouvernance quotidienne de l'entreprise. Elle élimine beaucoup de jeux politiques car elle dévoile chaque acteur. Elle permet la confiance qui naît de la proximité entre ces acteurs. Cette confiance autorise alors des délégations plus larges de mission et donc une autonomisation des acteurs. L'innovation se retrouve, de facto, entre les mains des acteurs, qui sont les plus proches des clients. Ce sont les essais/erreurs (le « test & learn » voire le « test & fail & learn ») et des boucles de rétroaction avec ces clients qui développent des solutions pour chaque problème. En conséquence, l’échec est dédramatisé ; ce qui facilite un apprentissage permanent (mes fameux learning leaders).
Et ça marche tout le temps ?
Tout d'abord, ce n'est pas la panacée universelle : les opérations de routine telles que l'entretien de l'usine, les achats et la comptabilité ne gagnent pas grand chose à utiliser les principes Agile. Ensuite ça peut échouer. Mais, généralement, c'est un problème de transformation des façons de faire vers l’Agile plutôt que des remises en cause des principes agiles eux-mêmes. Si la culture de l'entreprise est toujours coincée dans le Command&Control, l’organisation parle «Agile» mais n'y croit pas. Elle se trouve en en contradiction avec les valeurs Agile (l'initiative part de l'individu). Or, dans beaucoup de grandes entreprises, les équipes doivent suivre les approches prescrites plutôt que de définir et de concevoir des approches sur mesure. Certains acteurs au lieu de transformer les valeurs organisationnelles et de travailler sur la transition de la culture, s'attendent à ce que l'Agile « s’intègre » dans l'existant. Les chances de succès, au-delà de poches isolées d’équipes agiles, sont alors minces. De nombreuses organisations commencent leur transition vers l’Agile en pensant que c'est l’Objectif final. Mais l’Agile ne fonctionne pas tout seul ; il oblige à prendre en compte plusieurs capacités organisationnelles : autonomisation et discipline, alignement (voir ici), ouverture et transparence. L’idée peut séduire mais la mise en oeuvre prend du temps et les entreprises doivent être patientes, ce qui n'est pas leur qualité première. Enfin, si l'équipe Agile est complètement et seulement concentrée sur la productivité et la technologie et non sur le client ou la valeur ajoutée qu'elle peut lui offrir, l’échec du projet est probable. Et souvent, la productivité immédiate intéresse plus les leaders Command&Control qu’une hypothétique autonomie des acteurs…
Mais il faut prendre conscience que les atouts qui ont permis aux leaders d'exceller dans les structures tayloriennes peuvent désormais les faire dérailler. Les pratiques qui mettaient l'accent sur la précision et l'excellence de l'exécution grâce à une prise de décision hiérarchique vont maintenant à l'encontre de la flexibilité dont ces leaders ont besoin. La construction du collectif que suppose l’Agile permet, cette souplesse. Le besoin pour les entreprises de remobiliser leurs salariés, de libérer les talents et les potentiels d'un management longtemps exclusivement hiérarchique, est à ce prix.
Les suites logiques de ce papier sont :
Webinaire : "Réfléchir à l'Agile dans son entreprise". Durée 1h00. Ce webinaire se co-conçoit avec les agilistes maison. Il permet de dégager des perspectives plutôt que d'appliquer des recettes, utile quand on veut étendre le principe Agile à l'entreprise entière.
Formation distancielle "Les 5 composantes du management agile". Durée 0,5 jour. Cette formation détaille les grandes composantes du management agile : recommandé pour tous les managers en découverte.
(1) Agile Manifesto en VO ici
(2) François Dupuy, Sociologie du changement, 2004
Photo : Marta Wave