Faire pire en pensant faire mieux

Quoi de plus “désagréable” que d’avoir un Incident juste après une livraison.

Disons-nous le même clairement : l’Incident après une livraison est vécu comme une faute : faute professionnelle, faute des hommes, faute du système et faute des process… D’ailleurs les équipes sont souvent objectivées sur le nombre d’Incident Majeur (IM). Ce sujet est sérieux et nos clients directement impactés.

Comment-nous en prémunir ?

La réponse souvent constatée, et très naturelle, est d’apporter « plus » de professionnalisme.

Et que faisons-nous donc en tant que professionnel concerné, impliqué et compétent ?

Nous tentons d’améliorer tous les maillons de nos processus. En ajoutant : plus de tests, plus de garde-fous, plus de synchronisation, plus de scénario de résilience, plus d’instance et de comité, plus de validation …. bref toujours… plus… plus.. plus… et … plus…

L’objectif recherché : faire le HEAD SHOT, le tir parfait, la livraison parfaite et sans accroc. Essayer de prévoir et de répondre à l’imprévisible.

Est-ce que cela fonctionne ?

Si globalement la situation s’améliore, que les IM sont de moins en moins nombreux, la situation est-elle parfaite ? Avons-nous, comme nous l’avions ambitionné : prévenu et anticipé tous les IM ? La réponse est NON… oui les chiffres sont meilleurs, mais toujours trop haut, et nos clients sont toujours les premières victimes.

Alors que faisons-nous ?

Comme tout bon professionnel, nous allons améliorer nos processus : plus de tests, plus de garde fous, plus de réunions, plus de …, plus … , plus…. PLUS… PLUS… PLUS…. et PLUS…

STOP !!!!!!!

Posons-nous !! Finalement, ne courons-nous pas après une utopie ?

Les bénéfices sont certes palpables… mais posons-nous la question : qu’avons-nous concédé ? Combien nous coûtent nos PLUS … PLUS … PLUS … ? Quel est le revers de la médaille ?

Le constat est GLACIAL 🥶

Entre le moment où nous décidons de livrer les nouveaux développements terminés et stables, et leur livraison effective en PRODUCTION, donc mise à disposition de nos utilisateurs, il faut compter plus de 20 jours : de la création du package à la MEP (Mise en Production) … 20 jours…

Durant ces 20 jours, nous ne chômons pas : nous vérifions, revérifions, établissons des scénarios de retour arrière, faisons des répétitions, nous synchronisons, nous nous réunissons en comité pour vérifier, ensemble, que rien n’est oublié, nous venons discrètement la nuit faire les mises en prod…. 20 JOURS …

20 Jours, n’est-ce pas bien ?

Que nous dit l’étude ACCELERATE ? Nous nous devons d’être dans les meilleurs, alors comparons-nous aux meilleurs. Combien de temps faut-il donc aux meilleurs pour livrer un développement finalisé en production ?

Les meilleurs sont capables de livrer: « Plusieurs fois par jour ».

« Plusieurs fois par jour » VS « 20 jours », c’est CHOQUANT !!!

Nous pouvons nous rassurer :

• QUESTION 🙋‍♀️ : “Oui, mais combien d’Incidents Majeurs ont-ils générés ?”
• REPONSE : “Désolé, mais cette question n’a plus de sens.”

Choquant aussi comme réponse, non ? Le postulat qui anime notre sentiment de professionnalisme est balayé d’un revers de la main…

Mais pourquoi le nombre d’IM n’est plus vraiment une question ?

Quand vous êtes capables de livrer “plusieurs fois par jour”, que l’acte de « LIVRER » n’est même plus un événement, vous ne voyez plus votre métier de la même manière. Il n’y a même plus de sujet … en un claquement de doigts 🫰 vous avez livré un développement à vos clients. Nous ne sommes plus dans les mêmes temporalités.

Un IM → 🫰, un IM → 🫰, un Im → 🫰, un I.. → 🫰

Un 🫰 et le I perd son M…

En mettant au coeur de nos préoccupations la vitesse de déploiement, nous rebattons toutes les cartes. Nous avons simplement pris le contre pied de la problématique, au lieu de la renforcer, de rentrer dans son jeu...

Conscientiser le changement nécessaire de Mindset

Ce n’est pas facile de se mettre en ordre de marche pour livrer “plusieurs fois par jour”, ça peut même paraitre un “voeu pieux”. Mais une chose semble sûre : essayer c’est générer une dynamique, et concentrer nos énergies sur cet axe se fait poser les bonnes questions. Car pour livrer plus vite, il faudra : un mindset agile, de l’automatisation, des déploiements canari, du feature flipping, de l’agile testing, de l’excellence etc….

ET CECI doit être notre priorité avant même de se poser les questions : “faisons-nous les bonnes choses”, ou “faisons-nous les choses bien”. Il est impossible de passer de “20 JOURS” à “plusieurs fois par jour” sans se remettre profondément en question. Désolé : “QuickWin” et “mesurette” ne suffiront pas.

Ce constat est principalement tiré de la lecture de l’étude ACCELERATE, que je vous recommande encore chaudement. Elle m’a personnellement changé, remettant en cause nombre de mes croyances. Il est même encore difficile aujourd’hui, plusieurs années après, d’appréhender complètement ses impacts dans notre quotidien … un peu comme l’agilité finalement 😂

Alors, êtes-vous prêts à relever le défi ?