Soyons en contact
19-12-2018 - 17:40 — 19-12-2018 - 17:45
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 :
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.