Intermédiaire

La méthode agile n’existe pas

noagilemethodo-smallDepuis 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 !

zx762Malgré 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.

cam3-49f169fA 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

 

Kaizen-2.svgL’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 !

 

Nombre de vue : 2917

COMMENTAIRES 7 commentaires

  1. Cyril dit :

    Merci, je voulais écrire un article sur les dérives agiles et puis magie, vous l’avez fait. Les valeurs de l’agile sont malmenées, il faut les rappeler encore et encore. Merci

    J’ai fais un billet sur la démocratisation de l’agile cette semaine : “L’agile n’est plus sexy, c’est la norme! Le nouveau challenge des agilistes? Survivre!” @cyril_lakech https://medium.com/@cyril_lakech/l-agile-n-est-plus-sexy-c-est-la-norme-le-nouveau-challenge-des-agilistes-survivre-76cfc467fe6f

    L’article demarre fort mais il est très (trop) long à mon goût.

    Ciao

  2. Olivier dit :

    Bonjour,
    Pour aller plus loin, j’ai les yeux qui saignent dès que je lis “la méthode Scrum”, voire, pour faire encore plus érudit “la méthodologie Scrum”.
    Une méthode est une recette qu’on suit étape par étape, on sait qu’on est au paragraphe 8 de l’étape 7 et qu’il reste 12 étapes. Bref c’est bien pour les contextes “compliqués”.
    Scrum est conçu et c’est écrit noir sur blans dans sa définition, comme étant un “framework”. C’est bien là sa force. Charge à chacun de trouver comment l’implémenter dans le contexte spécifique et “complexe” qui nous concerne directement.

    Yours
    Olivier

  3. Patrick BOBO dit :

    Bonjour Olivier,

    Je me suis fait la réflexion concernant le fait d’appeler Scrum une méthode/méthodologie au cours de la rédaction de mon article, et je n’ai finalement pas souhaité en parler ici pour ne pas forcer le trait de puriste.
    Mais je vous rejoins sur la nature de framework de Scrum. De la même façon qu’acheter une boîte à outils ne fait pas de vous un bricoleur, implémenter Scrum ne fait pas de vous un agiliste.

  4. quenechdu dit :

    Bonjour Olivier

    En effet, il n’existe pas de méthode agile. L’agilité est une évolution économique dans la gestion des entreprises aux USA. On peut retrouver l’histoire dans l’ouvrage “Théorie de l’entreprise Agile en 1971” et ensuite une forte pression du gouvernement américain en 1991 que l’on peut retrouver dans l’ouvrage “agile manufacturing 21st century competitive strategy”.

    Il est bien dommage que l’on ne parle que de Scrum et consorts pour parler d’agilité. A la finalité, nous avons galvaudé l’Agilité dans les entreprises en vendant des méthodes comme SAFE ou encore Scrum.

    Les entreprises Agiles (ASEA Brown Bover, GKN Aerospace, Fannie Mae, GoreTex, Northrop, etc) n’ont jamais utilisé de méthodes que ce soit des Scrum, SAFE, etc.

  5. Gabriel Klein dit :

    L’agilité pour moi c’est de s’adapter à la maturité de l’entreprise.

    J’aime bien prendre le modèle CMMI. Pour chaque composant d’un système ou d’une organisation on est à différents niveau, et on change régulièrement de niveau.

    J’enlève ou renforce des processus en fonction de l’évolution du produit, mais aussi de l’équipe et leur motivation.

    Quand on est en recherche d’une solution (en mode “R&D”), avoir des objectifs, des délais est important, mais c’est impossible d’avoir des dates précises. Une méthode très structurée n’a aucun sens.

    Quand on doit livrer un client, d’un produit qu’on connaît, une approche très structurée donne de meilleurs résultats.

  6. […] Une petite mise au point s’impose face à la montée en puissance du buzz-word-bingo-bullshit que représente l’expression « méthode agile » http://blog.soat.fr/2016/02/la-methode-agile-nexiste-pas/  […]

  7. Kamel dit :

    Le terme agile a en effet été déformé et donc souvent employé à contresens. Selon moi, c’est une façon de répondre aux demandes du client d’une manière différente : on plonge les mains dans le cambouis immédiatement en acceptant que les productions finales ne soient pas des objets parfaits, mais correspondent au maximum aux attentes des bénéficiaires finaux et aux objectifs quantitatifs et qualitatifs fixés au départ dans le cahier des charges. Cela peut être très efficace dans le domaine du e-learning, où il faut constamment donner le pouvoir aux utilisateurs finaux afin de ne pas dévier vers des projets qui ne satisferont pas la demande finale du client.

AJOUTER UN COMMENTAIRE