L'Agilité dans les structures mastodontes

Le recours à l'Agilité dans les grosses structures, dans les mastodontes au legacy invraisemblable, est un défi à l'entendement.

Le haut Management ne s'intéresse qu'à la diminution des coûts quoi qu'il annonce publiquement avec candeur ou sans, avec honnêteté ou machiavélisme. Personne ne s'intéresse au credo de l'Agilité qui est moins la diminution des coûts que l'augmentation et l'accélération de la livraison de valeur Business au client final. Habitude, quand tu nous tiens ! Difficile de se séparer de cette… idée obsessionnelle qu'est le coût ! Et impossible – naturellement – de faire l'impasse sur le sujet !

En général l'introduction de l'Agilité se fait en revoyant la seule l'organisation des équipes sans nécessairement entamer la réorganisation de … l'organisation elle-même, ou à peine. On pense qu'il suffit d'un Scrum Master, d'un Sprint Planning, d'un Sprint Review ou d'une rétrospective et le tour est joué. Personne ne bouge véritablement de sa ligne. Tout le monde attend que ce soit l'autre qui sorte du bois. Des exemples ? Vous voulez des exemples ! En voici quelques-uns :

• Le processus de mise en production n'est pas revu, ou s'il l'est, il est mis à mal par la nécessité de coller à la gouvernance en place, par les petites baronnies multiples qui cherchent à protéger leur mode de fonctionnement et leur pouvoir ou plus simplement … leur confort. Le processus de rollout reste largement sous-optimisé et personne n'a véritablement intérêt à le rendre plus "lisse". C'est le What's in it for me ?
• Autre exemple : le processus de financement (funding) reste centré sur la notion de projet (des initiatives qui démarrent à un moment précis et qui finissent à une autre moment précis, du moins telle est l'ambition) bien que les Agilistes s'époumonent à démontrer la supériorité d'un modèle qui finance la réalisation de produits ou le financement d'équipes assemblées sur le long terme (je rephrase : qui commencent à un moment précis mais qui n'ont pas de date de fin connue), end-to-end.
• Il est pénible pour les experts en Agilité — et en Lean Startup — de faire entendre raison sur un processus d'idéation ou d'innovation respecté dans ses fondements car ce processus est intégré à l'organisation existante sans le distinguo pourtant nécessaire entre les parts d'une organisation qui doivent s'occuper de la découverte d'un modèle (produit, processus, outil, {...} et de son exploitation. Ils restent largement influencés par les HiPPO (highest paid person's opinion, highest paid person in the office).
• Les Business Cases restent pour la plupart purement déclaratifs sans véritable vérification des hypothèses, avec gonflement des bénéfices attendus, et plus vite souvent que ce que le marché adjugera, avec contraction des coûts et des délais, avec ristourne sur les risques. Et jamais ils ne se proposent de découvrir; toujours ils affirment savoir !, sans que le client ou utilisateur final soit réellement consulté ou alors, juste parce qu'il le faut (il suffit de donner l'impression !).
• Les boucles de feedback (liaison la plus directe possible entre le développement d'un produit et ses différents utilisateurs) sont quasiment inexistantes et s'invitent excessivement rarement dans le débat bien qu'on sache éperdument bien que des métriques activables (Beware the vanity metrics!) soient indispensables pour ré-orienter le produit vers ce que l'utilisateur veut réellement.
• Les équipes, pourtant de long terme, sont démantelées aussitôt le produit mis en production (ou le projet fini) et ce malgré l'engagement de maintenir les équipes en place au-delà de l'horizon du projet.
• La synergie entre Ops et Devs (le mouvement DevOps) reste contraint à l'automatisation des procédures de build et de test sans aucun travail de fond quant à la nécessité d'intégrer les concerns des Ops dans la construction du code par les Devs. Le Management ne comprend même pas de quoi il s'agit lorsqu'on parle de DevOps, un terme dont il saupoudre pourtant ses nombreux discours et pour lequel chacun y va de sa propre définition (et je n'ai pas entendu une seule définition qui satisfasse ce que le mouvement DevOps se propose de résoudre et cela quel que soit le niveau où on se permet d'en parler !)
• La nécessité du YBIYRI — You Build It, You Run It n'est pas appréhendée correctement avec la priorisation qui va bien. Les définitions restent dans le vague.
• Le processus d'Asset Management n'est pas étudié sous son angle global en intégrant notamment les processus d'Incident et de Problem Management. On continue à les exécuter comme avant, comme ITIL le réclame sans davantage de réflexion. On continue à effectuer de nombreuses optimisations locales sans s'occuper vraiment de la totalité de la Value Stream
• Etc. Etc.

Tous ces changements sont nécessaires, profonds et difficiles. Les gens qui conseillent ou organisent la transformation digitale des très grandes organisations vous le confirmeront. Mais ce qui me frappe, c'est un autre pan de l'histoire : l'incroyable dette technique, le pattern commun de tous ces mastodontes ! … le poids inimaginable de leur legacy !

La dette technique ou le poids du legacy ! Nous y sommes … voilà le réel problème … et à tout bien considérer, il n'y en a pas d'autre. On connaît l'expression de "code spaghetti". On devrait lui ajouter les expressions "architecture spaghetti" et "organisation spaghetti! Il s'agit de voir ici les impacts qu'ont les applications les unes sur les autres : la modification d'une application (ou d'un composant) entraîne de facto des adaptations dans une série d'autres applications ou composants end-to-end. Ces mastodontes si puissants sont pris au piège (the Tar Pit) comme le décrit si bien Frederick P. Brooks : No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. Dans ces conditions comment s'organiser en équipes agiles centrées sur la mise au point de produits end-to-end ? C'est tout bonnement impossible sans que soit respecté le sacro-saint principe "Build and Deploy Independently" ce qui ne retient pas du tout l'attention du Management par ostracisme, distraction et condescendance, ou même plus simplement par bêtise et absence de compétence : cela, c'est technique, Monsieur. c'est autre chose !, entend-on. Punaise, quand donc le Management comprendra que l'Agilité sans excellence technique est vouée à l'échec ? Inutile d'attendre les bienfaits de l'Agilité si la flexibilité du code et de l'architecture sont inexistantes. Bien plus ! Pas besoin d'attendre le moindre changement sans révision profonde de tout ce code qui croupit sur des machines, code qui n'a plus d'expert, code qui n'a plus d'âme, code qui ne remplit plus son contrat d'origine à défaut d'encore remplir la fonctionnalité de base attendue, code qui entraîne dans sa chute toute l'organisation, code suicidaire !

Qu'on soit banque, assurance, mutualité, administration, secrétariat social, industrie … l'urgence est moins à l'Agilité qu'à la nécessité de remettre en condition la coeur de la machine, à savoir le code qui fait battre la pompe ! Il est indispensable de le moderniser, de le rendre indépendant (construction et déploiement). Cela l'est d'autant plus dans toutes ces entreprises qui, parfois sans vraiment le savoir, sont devenues des sociétés IT !

Cet article est paru sur le site de Lato Sensu Management sous sa forme originale.