Last update: 02/06/2016 13:53

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 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 :

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 !

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X