Si je devais refaire une transformation continuous delivery de zéro

Comme je ne sais pas trop ce que je vais faire l’année prochaine, c’est le bon moment pour se poser et de se demander comment je ferais une transformation continuous delivery si je devais en refaire une. J’annonce la couleur, je vise la lune.

Je vais faire mon vendeur de tapis / promoteur (pour parler process com) pour lancer le débat, je ferai en un an ce que j’ai fait en 3. Quand je dis “je”, je parle de moi avec mes amis coachs craft et devops. Ça vous intéresse de savoir comment je ferai, eh bien, je vais vous le dire.

Les transformations Agile / Continuous Delivery que j’ai vues ressemblent généralement à ça :

• On fait des pilotes Agile sur quelques équipes
• On généralise l’Agile
• On se frotte à des problèmes techniques et on rajoute la couche technique
• Les problèmes d’organisation ressortent et on remet en cause les process et l’organisation
• Et au fait, on aimerait bien ne pas régresser

C’est super progressif, mais super lent.

Cela a pu être nécessaire, car les ressources pour le faire n’étaient pas nécessairement disponibles sur la place parisienne et qu’il fallait les former. Cela n’est plus vrai aujourd’hui. Et donc comment aller vers du continuous delivery (of value) et gagner un avantage concurrentiel business. Me voici au pied du mur (ou du Fitz Roy pour ceux qui connaissent)

Et donc :

• Je tape dans deux process majeurs à savoir le budget et le recrutement
• Je remplace la gestion de projet par une démarche produit voir expérience utilisateur si je peux. Je coache le métier sur du développement produit à base de lean start up and co et j’embauche des UX designer.
• Je change l’organisation pour l’aligner business. À ce niveau, je dois commencer à m’éloigner des discussions livrables pour parler valeur
• Agile & continuous delivery everywhere. Maintenant, on attaque les coachings terrain et on met tout le monde en mouvement en même temps.

Clairement, c’est une approche disruptive pour une société qui voit le continuous delivery comme une condition de survie.

Recrutement

L’approche traditionnelle de “je forme en bas et je monte au fur et à mesure”, c’est bien, mais comme c’est lent, je passe ma vie à reformer dès que des nouveaux arrivent. Autant diminuer l’effort en prenant des bons. Si je prends des coachs, c’est majoritairement au début pour prendre les personnes qu’il faut. Côté technique, codingame (ou un truc dans le genre) comme premier filtre sur l’algorithmique, puis kata et revue de kata pour tester les qualités de clean code et testing. Côté maitrise d’ouvrage, des exercices de découpage de besoins métier et d’interviews utilisateurs. Je teste aussi la capacité à livrer de la documentation de manière incrémentale. Dans la pratique, je mets un coach dans tous les recrutements avec véto possible et j’implique tout le monde dans le recrutement et pas juste le chef qui décide.

Budget

Comment on peut être agile quand les projets à faire sont déterminés de manière annuelle avec roadmap annuelle et reporting sur l’avancement. Sans fluidification budgétaire, point de salut. Passons à un budget glissant (cf principe du beyond budgeting). Dis comme cela, c’est facile. Dans la pratique, cela frotte beaucoup, mais le gain est tellement énorme. Le nombre de projets que je vois aller au bout alors qu’ils auraient dû être coupés ou réorientés est juste trop important. Je suis soft, j’avais envie de dire énorme.

Projet vers produit

C’est la suite de la partie budgétaire. Nous allons maintenant devoir donner de l’avancement en fonction des impacts business et non plus de livrables IT. Cela veut dire repenser l’approche et donc amener des outils de mesure de l’impact et non des outils de mesure du coût. Il y a tout ce qui tourne autour de la validation des hypothèses (lean start up, interview métiers, sketching, prototypage, …) et aussi autour de la métrologie. On peut tout mesurer, l’essentiel est de savoir quelle décision on veut prendre avec une mesure. Un des changements le plus important que j’ai vu, c’est en changeant un modèle d’expression de besoins et en rajoutant une question “qu’est-ce que tu pourras faire demain que tu ne peux pas faire aujourd’hui ?”. Sur ce thème, cela risque de frotter avec les communautés de chef de projet. D’où la question sur le recrutement.

L’organisation

Avant de m’attaquer à la polyvalence des équipes, je regarde la traditionnelle question du hamburger. Est-ce que j’ai une organisation alignée business ou couche technique. Si c’est la deuxième réponse, on peut essayer des transformations agiles d’équipe, mais cela va tellement frotter que le ratio énergie/impact sera mauvais. Il vaut mieux mettre les pieds dans le plat tout de suite plutôt que de faire du palliatif. Cela n’est pas un hasard si j’ai mis la gestion produit avant, cela va tellement pousser à un alignement business que cela facilite grandement cette étape.

Les mains dans le cambouis

Y a plus qu’à. L’avantage d’avoir faire les autres étapes avant, c’est que quand on arrive à cette étape, on a déjà du meilleur staff, un alignement valeur, une couche managériale alignée… Et donc là, c’est roule ma poule, cela peut aller super vite. Les derniers accompagnements que j’ai faits avec un bon staff dès le début ont duré environ 3 mois. Si je compare par rapport à une transformation classique d’une équipe qui s’étale plus sur 6 mois, c’est 2 fois plus rapide. Et c’est d’ailleurs vrai en délai comme en charge.

Ma conclusion

Est-ce que c’est réaliste et dans quel cas l’appliquer ? C’est clairement un pattern que je ferais si l’organisation au sens large est convaincue qu’il devient urgent(issime) de bouger. Il doit par contre permettre de refaire une grande partie du retard avec la concurrence en un à deux ans. Aujourd’hui, je ne suis pas capable de le faire et donc si quelqu’un essaie ainsi, je veux bien du feedback et apporter de l’aide. Reste plus qu’à sauter à l’eau :-)