Agile, une prise de risques incontournable ?

Mettre en œuvre la méthode Agile, impose de considérer comme acceptable ce qui peut ressembler à un pari et à une perte de certitudes. C’est choisir un raccourci difficile pour accélérer le retour, en acceptant ce qui serait un risque intolérable sans la confiance que chaque alpiniste doit avoir dans le reste de la cordée.

Ne pas doubler les contrôles

Plus concrètement, et dans une vision  de management , ce n’est pas en rajoutant des couches de contrôles plus ou moins agiles sur les couches de contrôles classiques existantes, que l’on obtient de l’agilité. Le plus souvent cet alourdissement du reporting se réalise  dans des contextes de production (organisationnels ou techniques) inchangés. La seule voie acceptable est de donner tous les moyens nécessaires à l’équipe ayant exprimé formellement (dans une charte de projet) sa volonté de passer  à l’agilité.  Ensuite, il faut faire confiance à son engagement moral, mais jeter régulièrement un œil sur l’affichage mural en général et sur le burn-up chart en particulier.

Accepter ce qui semble être un risque

L’approche  Agile à risques volontairement courus, n’est pas évidente pour beaucoup de managers. Changer une vision culturellement sécuritaire,  - du moins c’est ce qui est pensé malgré la régularité des problèmes en cours de projet - et modifier fondamentalement des habitudes de travail généralement acquises depuis le début de carrière, n’est déjà pas  chose aisée. Souvent, la transition n’est rendu possible que par un changement de poste, d’entreprise ou de culture et, occasionnellement, de pays. Parfois, dans les cas les plus durs,  le catalyseur du changement est l’approche d’un dénouement fatal.  L’organisation sclérosée, passe alors brutalement dans un mode survie, où  tout ce qui semblait inutile ou intolérable avant, devient brusquement le parachute d’un siège éjectable (ou bien une bouée de sauvetage si vous préférez les métaphores aquatiques). Ainsi se présente le plus souvent le plongeon dans l’espoir d’un mode itératif-Incrémental-adaptatif de production proclamé Agilité !

Changer réellement d'habitude

En presque trois décennies d’adaptatif, ou de "méthode Agile" comme on dit maintenant, j’ai observé de nombreuses organisations rechercher, sans jamais l'obtenir, une efficience opérationnelle dont elle souhaitait profiter des bienfaits. Cela perdure depuis les années 90, de méthode en méthode. Pourtant, selon Albert Einstein, la définition de la folie  "c’est de refaire toujours la même chose, et d’attendre des résultats différents". 

Simple mais pas indolore

La question qui vient immédiatement à l’esprit est alors "pourquoi - si c’est aussi simple - de nombreuses organisations n’y parviennent pas ?". 

La réponse n’est pas non plus très compliquée : c’est peut-être simple, mais ce n’est généralement pas indolore. De plus, l’approche élémentaire de la sous-méthode nommée Scrum a phagocyté toutes les autres méthodes raisonnablement complètes et cohérentes. Le fait que cette no-méthode  génère plus de problèmes, de doutes, d’échecs, et finalement de rejets, ne réduit en rien les espoirs des amateurs qui, le plus souvent ne l’ont jamais pratiqué, mais en ont fait un dogme. Je ne parlerais même pas de ceux qui, persuadé d’être agile, se contentent de remanier leurs anciennes habitudes (dans la couleur de quelques post-it), mais sans changer grand-chose sur le fond à leurs habitudes. Là encore la raison est simple : Il y a  plusieurs "espace-temps" ou Scrum n’ose pas jeter un œil. Le premier de ces no-man’s lands où s’épanouis l’homo scrumiste, s’étant auto-nommé Sprint 0 (c’est plus joli que "la décharge des anciens documents inutiles mais toujours à produire").

Plus de technique et moins de bla bla

Les  vraies techniques agiles, permettant : la maîtrise des communications interpersonnelles, l’expression du réel besoin, sa juste documentation, la qualité du produit et le contrôle des demandes de changements en cours de projet, ne sont même pas abordé par Scrum. Plus grave, le principe même de l’Agilité (la notion d’adaptation du produit au besoin) est carrément refusée (interdiction méthodologique de modifier sérieusement le besoin en cours de développement ou déjà développé). Comme la réalité impose souvent des changements, ceux-ci sont donc quand même effectués par les équipes, mais avec pour contrepartie la perte de contrôle du périmètre du produit et de la capacité de reporting du réel travaillé par l’équipe.

Devant ce qui ressemble de plus en plus à un piège au fond d‘une impasse nommée Scrum,  il n’est pourtant pas trop tard pour réagir. Il y a dans Scrum trois ou quatre techniques qui préexistaient à cette méthode et qui sont parfaitement utilisables, même dans leur nouveau jargon franglisant (présence indispensable du métier baptisé Product Owner, équipe de composition homogène dans tous les sens du terme, nomination d’un responsable ScrumMasterisant des communications avec l’extérieur).  En fait, à condition de comprendre les limites dangereuses de cette no-méthode, il est possible d’y trouver des équilibres  de substitutions acceptables et d’y adjoindre les techniques indispensables à l’agilité concrète : vrai reporting mural temps réel, métrique du changement, etc.   Alors, il n’est pas impossible de conserver les trois ou quatre mots du vocabulaire scrumisant, dont le principal avantage est d’être suffisamment déroutant pour nécessiter, parfois, un vrai questionnement organisationnel sur le fond.

Le piège du simplisme

Tous ces points étaient déjà des évidences en 2001, lorsqu’après l’Agile Manifesto, est sorti le premier livre présentant Scrum (par Schwaber et Beedle).  Voilà pourquoi, dès cette époque,  j’avais proposé aux USA  le principe  initial de  PUMA, une simple proposition d’unification  devenue en 2007 le Processus Urbanisant les Méthodes Agiles.  Cette approche ouverte pouvait donc être considérée comme une solution "clé en main" aux principaux problèmes auxquels était confronté le monde Agile. Dix années plus tard, après de multiples communications, à part quelques entreprises en ayant bénéficié, qu’en dit le reste de la communauté soit disant agile ? Rien ou pas grand-chose, car lorsque qu’un consultant réalise la totalité de son business avec un truc aussi vaseux que Scrum, il est évident qu’il n’a aucun intérêt à cracher dans la soupe.  Voilà, il vous faudra donc encore, en tout cas pour le moment, composer avec cette calamité.

La religion du Just do it

Conclusion : pour orienter une vraie tentative d’agilité, il faut que l’organisation s’en donne les moyens et en accepte les exigences de simplification managériale. Les compromis conduisant à tous les renoncements, leur acceptation n’est plus possible. C’est le prix  à payer pour obtenir un résultat satisfaisant.  Exactement comme dans Star Wars, où maître Yoda disait à Luc Skywalker, dont les tentatives d’utiliser « la force » se soldaient par des échecs répétitifs : N’essaie pas ! Fais-le, ou ne le fais pas ! Il n’y a pas d’essai !. En clair : Just do it !