La méthode agile est elle l'universelle panacée?

Publié par Alain de Malglaive sur 14 Décembre 2016, 05:14am

Catégories : #assurance, #methode, #agilité, #methode agile, #progiciel, #logiciel, #B to C, #norme, #organisation, #MNO

Les méthodes, normes et organisations se succèdent la plupart du temps pour gommer les défauts des précédentes ou pour éliminer les points de blocage d'une organisation existante.

Parfois la version précédente est victime de son succès : Pour répondre à toutes les configurations Elle s'enfle d’addenda de toutes sortes qui prennent progressivement un caractère de lourdeur administrative. Le tout finit dans un boursouflement qui comme chacun sait finit lui même en Pschitt. La norme Iso9000 en est un assez bon exemple.

La plupart du temps, elles ont été mises en place pour un contexte particulier. En cas de réussite elles sont vite conceptualisées, théorisées pour être diffusées et applicables dans tous les contextes.

Comme toujours dans cette époque troublée, le dernier qui a réussit est la nouvelle figure Christique à suivre. Donc tout le monde suit le mouvement de peur de se retrouver le dernier ou d'avoir raté un épisode!

Il en va des méthodes comme le reste ou les experts de LA METHODE sont des gourous qui possèdent la solution à vos problèmes. Tous les autres ne peuvent être que:

de bon disciples à mettre en vitrine lorsqu'ils comprennent, écoutent et appliquent avec enthousiasme LA METHODE.
des gens intelligents à valoriser lorsqu'ils ne comprennent pas grand chose parce que petris dans leurs habitudes mais qui dans le doute executent avec un zèle visible LA METHODE
des impies qui ne perdent rien pour attendre lorsqu'il sont passablement dubitatifs, questionneurs et cherchent comment vont s'articuler LA METHODE avec le metier

Vous avez deviné je suppose dans quelle catégorie je cours...

Non pas que je trouve les apports de la méthode agile inefficace ! loin de la!

Les principes de séparation des pouvoirs (scrum/po), de partage des responsabilités et des engagement (poker/planning/dayly) et de transparence sur les objectifs assignés à l'équipe (sprint/burndown) me semblent des mesures nouvelles indispensables pour améliorer l'efficacité et la synergie d'une équipe de développement.

Des principes peuvent être constitutifs d'une méthode mais n'en sont pas la propriété exclusive.

D'autres principes considérés comme faisant partie du dogme, donc applicables en l'état, me semblent devoir être discutés: Par exemple l'autonomie complète d'une équipe est valable pour une appli web B to C mais diantrement plus compliquée lorsque votre produit:

est un progiciel multi_client multi_modules hyper paramétrable
embarque des règles métier complexes de type b to b, difficiles à comprendre pour un néophyte
a 15 ans de vie et donc embarque déjà un sacré maelstrom technologique,
nécessite de mettre en ligne 15 équipes agiles pour le faire évoluer dans le temps

Ce n'est pas le seul sujet qui pose problème.

Un problème n'existe que pour être traité me direz vous? Oui mais pas par une pirouette!

C'est pour l'instant la seule réponse que j'ai obtenu des gourous que j'ai consulté:
Avec des cérémonies et des communautés de partage on peut tout!
C'est le meilleur moyen de paralyser 15 équipes qui bossent sur le même socle!

Oui mais garantir la cohérence et la pérennité d'un produit de cette taille ne devrait pas être du domaine de la possibilité mais de la règle!

Méthode, Norme et Organisation => Règle... Ouille! une nouvelle contrainte!