(spoiler : il y a de grandes chances pour que ce soit votre faute)
Vous avez cherché de l’aide et vous êtes sûrement tombé sur des consultants “experts de l’Agile” (avec un grand A) et la seule chose qui à changé ce sont les mots utilisés ? Depuis des années, des mois, les équipes suivent Scrum ou autre chose et pourtant, votre produit est toujours truffé de bugs et les sprints ne produisent pas vraiment d’incréments livrables, et encore moins de valeur ? [Hello, Cargo Cult – voir la définition en fin d’article]
Une des raisons de cette stagnation, c’est à mon avis la phase de cadrage que vous proposent “les consultants Agiles”.
Bien qu’une phase de transmission de la vision produit soit indispensable, celle-ci ne doit pas prendre 2 semaines. Qu’est-ce qui vous empêche de prendre une hypothèse et de la tester, là, maintenant, tout de suite ?
Dans cet article, nous allons parler des transformations agiles qui n’avancent pas à cause d’une phase de “socle technique” ou de design visuel.
La phase de cadrage freine votre transformation agile
J’en ai parlé dans un précédent article, cette phase porte plein de noms différents : sprint 0, cadrage, phase de conception, etc… Mais c’est à chaque fois la même chose :
“On va mettre le socle technique en place au début, ça rassure et on va appeler ça agile”.
Suite à cet article sur le sprint 0, j’ai eu beaucoup, beaucoup de commentaires, venant de partout. Nan mais vraiment beaucoup. Sur LinkedIn, Twitter, en privé, de vive voix etc. Beaucoup de gens indignés, me répétant que cette phase de cadrage est ESSENTIELLE et nécessaire. Obligatoire même, pour ne pas faire n’importe quoi.
Et puis en creusant un peu avec eux (quand j’ai pu), immanquablement le discours change. Ce n’est plus “obligatoire”, cela devient : “nécessaire dans notre contexte”.
Ahhhh, le “dans mon contexte”. Il a bon dos le contexte !
Donc ensuite, il est facile de demander en quoi cette phase de cadrage aide le contexte. La réponse sort généralement de la bouche de mon interlocuteur en même temps que son cerveau comprend le problème : “Bah… on ‘est adapté au contexte, on fait avec.”
Status Quo
On fait avec. Voilà, où votre entreprise en est, et restera. Au lieu de vous attaquer au problème, vous avez vécu avec.
Banque, assurance, énergie. Tous dépensent sans compter pour des consultants “agiles” à la pelle. On prend des coachs agiles qui doivent apporter des solutions. On se repose sur eux, d’aucun dirait qu’on se décharge sur eux.
Et sous prétexte de faire une transformation lente, pas à pas, on s’embourbe dans des framework de cadrage qui ne rapportent qu’à ceux qui les vendent (à coup de coaching, certifications, formations…).
Et si vous dépensiez mieux votre argent ?
Prenons un cas concret du besoin de cadrage (vécu) : On doit faire un cadrage parce qu’il faut qu’on donne l’architecture technique 4 mois à l’avance aux équipes de l’infra pour avoir les serveurs.
Que peut-on faire ?
1/ On s’adapte. Ben oui, on est agile après tout. On fait avec.
Donc, pour chaque projets/produits, on préconise une phase de cadrage, qu’on appelle sprint 0 et qui dure 2 à 4 semaines suivant les cas, mais parce qu’il y a “sprint” dans le nom, ça va c’est agile, on peut cocher la case :
✅ Projet agile. Youpi je vais avoir ma prime.
Astuce : ça marche aussi si le nom du cadrage contient “scrum” ou “agile”.
Dans cette phase on va décider de ce qu’il y a à faire pour réaliser le produit. Puis on va en extraire un Minimum Viable Product (“MVP” si vous voulez une définition je vous invite à regarder la vidéo de Scrum Life de 10 minutes sur le sujet).
On a écrit, quand même, ce qui sera à faire au-delà du MVP, pour pouvoir mettre l’infra (les serveurs) qu’il faut en fonction de ça et avoir les machines à temps, dans 4 mois.
Et ça va, on a froissé personne. Le prochain projet “agile” fera de même. Les managers deviennent leur N+1 et d’autres clones prennent leur place. Et on écrira sur la tombe de l’entreprise :
“R.I.P
☠️
les managers avaient pourtant demandé aux consultants de tout prévoir.”
Une autre possibilité c’est de 2/ Adapter le contexte pour survivre.
Au moment où on comprend qu’on ne peut pas livrer aux utilisateurs à chaque sprint, même si on le souhaite, on stoppe les projets. Oui, tous les projets. Tout le monde travaille à corriger le problème une bonne fois pour toute.
C’est l’esprit Andon qui vient du système Toyota et que Wikipedia traduit par : “lumière où il faut aller”. Quand un poste de la chaîne de fabrication est un risque pour la production, alors toute l’énergie des ingénieurs est utilisée pour résoudre ce problème.
On peut engager de bons consultants, qui nous aideront à mettre en place les bonnes pratiques et le mindset devops en leur donnant un objectif clair et en travaillant avec elles et eux. Pas en attendant d’eux qu’ils fassent de la magie. C’est un travail collaboratif qui vous fera gagner énormément d’argent.
Une façon “2 bis” serait de Créer une bulle de changement en parallèle : Pour ne pas stopper toute l’entreprise, on crée une ligne de production parallèle et autonome. Sur cette ligne, les équipes peuvent livrer dans un environnement qu’elles contrôlent et elles sont constituées de toutes les compétences nécessaires : Métier, Dev, Ops, Légal, Sécurité, Marketing…
Et petit à petit, on bascule le reste de l’entreprise sur le même modèle, qu’on se sera créé.
Mais c’est pas possible dans MON contexte ! 😩
Si vous lisez ça en vous disant “dans la théorie oui, mais chez moi, c’est pas possible, je suis dans [la banque, l’assurance, le service publique, la défense, un environnement contrôlé… (rayer les mentions inutiles)]”, alors je vous mets au défi de me contacter pour m’expliquer en quoi votre contexte ne peut pas changer. Mais attention, soyez prêt à entendre que le vrai frein, c’est vous.
N’hésitez pas à lire un peu mon article sur le Cargo Cult.