La méthode agile n’existe pas
Depuis quelques temps, l’Agilité est devenue la “nouveauté” à la mode dans les entreprises françaises. Un intérêt prononcé pour les diverses méthodologies s’est progressivement déclaré et, avec lui, une multitude de déviances ont fait leur apparition. En cette heure où les expressions telles que “la méthode agile” ou “scrum full compliance” font partie du vocabulaire courant, il est temps de remettre les pendules à l’heure.
Un constat pas tellement amiable
Du fait de ses racines anglo-saxonnes, l’Agilité s’est développée en France assez longtemps après avoir été éprouvée à divers endroits du globe. Après des décennies de cycle de V, certains l’ont accueillie à bras ouverts, tandis que d’autres, plus méfiants, voire récalcitrants, s’y sont totalement opposés. L’Agilité étant maintenant de plus en plus présente au sein de l’IT en France, il est possible de prendre un peu de recul, ce qui nous mène au constat suivant : la compréhension de l’Agilité, dans ses concepts comme dans les pratiques liées aux différentes méthodes, est souvent erronée ou détournée, non sans conséquence.
La méthode agile
Vous l’avez croisée vous aussi, n’est-ce pas ? Cette fameuse “méthode agile” qu’on retrouve dans tant de descriptions de poste.
Vous travaillerez avec la méthode agile !
Nous proposons un contexte suivant fortement la méthode agile.
Nous aimerions mettre en place la méthodologie agile et vous semblez être le candidat idéal pour nous y aider !
Malgré le non-sens que représente cette expression pour les agilistes initiés, c’est l’un des buzz words les plus utilisés à l’heure actuelle dans le recrutement IT. L’origine de cette déformation se trouve dans la compréhension erronée de l’Agilité, au sens global. Pour nombre d’acteurs du monde IT, l’Agilité, c’est Scrum. Cette dernière étant la méthodologie agile la plus utilisée, l’amalgame a été rapidement fait, tandis que Kanban, Extreme programming ou toutes les déclinaisons du Lean se sont vues oubliées dans les méandres de l’Agilité à la sauce française.
Rigidité et incompréhension
Il est assez fréquent de retrouver deux catégories de travers dans les entreprises qui se sont mises à l’Agilité de la mauvaise façon : l’extrême rigidité des pratiques et l’incompréhension des concepts.
Mr Dupont, manager d’une petite équipe de développement, doit accéder à la requête de son supérieur de passer à l’Agilité. Après avoir fait l’acquisition d’un guide de Scrum, il l’a survolé, faute de temps pour le lire, et en a extrait ce qui ressemblait à des processus. Se reconnaissant dans les deux rôles, il porte les casquettes de Product Owner et de Scrum Master, ce qui lui semble être la transition logique depuis son précédent poste.
Malgré sa bonne volonté, Mr Dupont démarre sur des bases fragiles et erronées. Faute d’accompagnement, il a l’impression de faire exactement ce qu’il a pu voir dans le livre, alors ça devrait fonctionner…
Tous les matins, il a fixé une réunion d’une heure à toute l’équipe, le Daily Scrum Meeting. Pendant cette heure, il demande à chacun de ses développeurs de lui faire un rapport d’avancement et remarque que ses développeurs sont souvent bloqués. De plus, les rapports semblent se suivre et se ressembler. Mr Dupont commence à penser que ce DSM n’a pour seul effet que de faire perdre du temps.
En tant que Product Owner, Mr Dupont essaye de rester ferme sur ses positions et de refuser les demandes du métier qui arrivent après le démarrage de son sprint. Le métier s’impatiente, l’application commence vraiment à souffrir et Mr Dupont ne comprend pas bien ce qu’il a manqué dans sa mise en place de Scrum. En fait, Mr Dupont est en charge d’une équipe de support de production et la méthodologie qu’il a choisie n’est absolument pas adaptée à son contexte.
De par son manque de connaissances sur le sujet, notre manager s’est lancé dans une transformation qui ne pourra aboutir qu’à un échec. Sa compréhension de la méthodologie en est restée à l’aspect technique des choses, à savoir les différents artefacts et cérémonies à mettre en place, sans en intégrer les concepts porteurs.
La fin de sprint est censée être porteuse d’amélioration, car c’est le moment où on organise la rétrospective. Mr Dupont a posé un créneau d’une heure, pour ne pas perdre trop de temps sur le travail de l’équipe. Pour ne pas s’embarrasser d’un format complexe, il décide de demander tour à tour à ses développeurs de lui dire ce qui ne va pas et ce qui fait qu’ils n’ont pas été capables de boucler le sprint. Sous pression, les développeurs ne parleront que pour tenter d’excuser le retard sur le travail prévu.
Après quelques sprints sur le même ton, Mr Dupont abandonnera l’Agilité, avec le sentiment d’avoir été escroqué sur la fiabilité de ces soi-disant méthodologies.
Aussi caricaturale que puisse paraître cette petite histoire, il y a eu des Mr Dupont, il y en a encore et il y en aura sûrement d’autres dans le futur. Si l’intention de départ est bonne, c’est l’approche qui pêche : en essayant de forcer l’application des différents éléments de sa méthodologie pour s’y conformer à la lettre, on n’arrive souvent à rien d’autre qu’à fragiliser l’organisation et à dégoûter les différents acteurs. De même, tenter de mettre en place une méthodologie sans en intégrer les concepts porteurs au préalable tend très rapidement à détourner l’utilisation des différents éléments, jusqu’à en perdre l’utilité voire à les rendre dangereux pour l’équipe.
Full compliance
Le marketing a encore frappé et a signé le coup d’envoi de la course à la “full compliance”. Le principe de full compliance consiste, comme son nom l’indique, à être en parfaite adéquation avec quelque chose. En l’occurrence, on retrouve souvent Scrum derrière cette expression, dans le monde de l’Agilité. Ainsi, on rejoint la rigidité des pratiques, puisqu’on en vient à essayer de poser son calque Scrum sur l’entreprise, jusqu’à ce qu’on ait réussi à en faire une copie parfaite. J’aime autant vous dire que ça se fait généralement dans la douleur et que ce n’est absolument pas une garantie de réussite.
Mais outre le fait que l’on ne s’y prenne pas de la bonne façon, la notion même de full compliance représente un non-sens en Agilité. Un des principes communs à toutes les méthodes agiles est l’amélioration continue. Ainsi, certaines méthodologies ont elles-mêmes évolué pour intégrer des éléments d’autres méthodologies. Si vous êtes Scrum Full Compliant, vous n’avez pas d’User Stories par exemple, puisqu’elles viennent d’Extreme Programming.
L’adaptation, un élément capital du progrès
Avant de parler d’adaptation, rappelons un fait qui fera grincer des dents bon nombre d’agilistes convaincus : de nombreux très bons produits ont été réalisés en cycle en V ou en Waterfall, et d’autres le seront probablement encore dans le futur. L’Agilité n’est pas, et ne sera jamais, une solution universelle.
Comme je le mentionnais à la fin de la partie précédente, les méthodes agiles ont évolué en injectant dans leurs différents fonctionnements des éléments d’autres méthodologies. Ainsi, de nombreux éléments issus d’Extreme Programming, comme les User Stories, le refactoring ou le Test Driven Development, se retrouvent dans toutes les équipes de développement, quelle que soit la méthodologie. De même, Kanban peut parfaitement fonctionner en Sprint, même si c’est initialement un élément de Scrum.
A l’image de cette évolution des méthodologies, les équipes agiles doivent évoluer vers le fonctionnement qui semble être le plus approprié à leurs contextes. Choisir une méthodologie adaptée à sa situation est la première étape d’un bon fonctionnement et permet généralement de poser des bases solides et d’éprouver les différents éléments pour identifier ceux qui ne correspondent pas ou pourraient être améliorés. Parfois, l’expérimentation vous mènera même au constat que la méthodologie que vous aviez choisie au début n’était pas la bonne et qu’une autre est bien plus adaptée à votre contexte.
Si vous aviez encore des doutes, vous devez maintenant avoir compris pour quoi “la méthode Agile” ne peut pas exister. S’il existe quelques méthodes bien définies, elles sont déclinées en autant de variantes qu’il y a de contexte et peuvent même avoir plusieurs variantes dans un même contexte, tant la part des individus est grande.
Malgré l’importance capitale de l’adaptation dans la mise en place d’une méthodologie agile, les principes fondamentaux de celle-ci ne sont pas pour autant à mettre de côté. En effet, certains éléments veillent au bon fonctionnement de l’ensemble et sont vitaux pour la méthodologie. Par exemple, si vous êtes partis sur une base de Scrum et que vous décidez de ne plus faire de Daily Scrum Meeting, la communication interne de votre équipe en prendra un sérieux coup. De même, si vous retirez les Rétrospectives parce que vous pensez ne plus rien avoir à améliorer, vous réaliserez votre erreur probablement trop tard. Et parce que Scrum n’est pas l’Agilité, sachez que si vous arrêtez de mesurer le temps de cycle de votre Kanban, vous en perdez presque tout l’intérêt.
L’adaptation doit être, comme les actions d’une rétrospective, faite de changements concrets et réfléchis, qui permettront à l’équipe de mieux fonctionner, ce qui nécessite de pouvoir mesurer la différence. Dans la mesure du possible, restez SMART !
Kaizen, l’amélioration continue
L’amélioration continue est la pierre angulaire de l’Agilité, si bien que nous connaissons même sa traduction en japonais : Kaizen. Quelle que soit la méthodologie concernée, il y a toujours un élément dont l’objectif final est de servir la cause de l’amélioration continue : Scrum préconise la rétrospective, le Lean veille à la suppression du gaspillage, Kanban se marie très bien à la théorie des contraintes, etc.
Les manières de s’améliorer sont multiples et sont extrêmement liées aux contextes dans lesquels sont mises en place les méthodologies, mais il reste un point immuable : quelle que soit la façon dont vous allez vous améliorer aujourd’hui, vous aurez une autre façon de vous améliorer demain. Ce principe est particulièrement visible en Kanban : pour faire simple, on cherche à détecter le plus gros point de ralentissement dans notre système, puis on focalise tous nos efforts dessus, pour l’améliorer. Une fois cette amélioration réalisée, on cherche le prochain plus gros point de ralentissement et on recommence. Et ainsi de suite.
Cette notion d’amélioration continue est ainsi la principale détractrice de la full compliance, puisque l’état de full compliance que vous aurez atteint le jour J sera peut-être un état qui ne sera plus satisfaisant au jour J+1. Et si vous restez fixés sur cette notion, parce qu’elle sonne bien sur vos descriptions de poste, vous aurez manqué l’essentiel de ce que l’Agilité peut apporter à votre organisation.
Sur ce…
… Je vous laisse faire vous-mêmes l’expérience de l’amélioration continue et de l’adaptation des méthodologies à vos contextes. Quant à ceux qui n’auraient pas encore franchi le pas, j’espère vous avoir aidés à réaliser que partir du bon pied est important, pour ne pas tomber dans les anti-patterns et les détournements classiques. L’accompagnement agile reste toujours la meilleure solution pour vous mettre en ordre de marche dès les premiers jours !