L'Agilité sans en parler...

Promesse d'un monde meilleur, révolution dans la gestion des projets IT, l'Agilité et notamment Scrum ont apporté la conviction que l'amélioration continue était un pilier de notre évolution. Puis, la technique évoluant, DevOps (2009) et Continuous Delivery (2010) ont apporté de nouvelles promesses, à grands renforts de nouveaux concepts. Et avec, une nouvelle sensation d'être en expérimentation perpétuelle. La notion d'expertise est devenue relative, emportée par l'émergence continue de nouveaux concepts et de technologies nouvelles.

Les organisations n'ayant pas de capacité d'adaptation ont subi cette évolution, en tentant de greffer certains concepts Agiles en surcouche à leur organisation qui ne l'est pas du tout.

Et sans surprise, à partir de là, les dérives sont apparues, les choses ont commencé à se gâter. Pourtant, nous restons convaincus que le fond de l'approche Agile est et restera clé dans le succès de la plupart des grands projets. Peut-être suffit-il de moins en parler pour obtenir les clés et démarrer rapidement une transformation ?

Dans ce billet, nous allons voir comment les dérives ont pu engendrer la méfiance des organisations, et comment neutraliser cette méfiance en changeant la forme de l'approche, sans toucher au fond.

Ecueil #1 : Plus accessible pour vendre du bullsh**

Parfois plutôt que d'en comprendre le principe, et donc de savoir adapter ces principes et outils à leur contexte, certains ont préféré adopter un maximum des buzzwords de l'Agilité pour cocher un maximum de cases. C'est la loi de Goodhart : une régularité statistique, soumise à des fins de contrôle et qui donc a tendance à perdre sa crédibilité : je fais des sprints, alors je suis Agile. J'ai un pipeline, alors je fais de la CI/CD. J'ai un Sonar, alors je fais de la qualité.

Pour vendre DevOps à une organisation, présenter des CV d' "experts devops" ne devrait pas suffire. Il y a besoin de s'approprier quelques concepts clés, ce qui suppose de travailler orthogonalement à ses propres objectifs pendant quelque temps, quand on n'est pas un profil technique.

Déjà Scrum permettait de rajouter "sprint" à coté de n'importe quel nom de service pour faire cool et vendre sans trop perdre de crédibilité. DevOps a introduit d'autres notions plus techniques de container, everything as code, pipeline de déploiement, et autres termes plus abscons les uns que les autres. Il était plus facile de s'emparer de la tendance en faisant émerger des mosaïques de produits et de concepts, autant de plats à la carte sans conseiller pour autant le menu le plus approprié.

Et là, ça s'est encore plus gâté.

Ecueil #2 : La secte et le Dark Agile

Historiquement, les Scrum Master ont toujours martelé l'importance de respecter et mettre en œuvre les concepts de l'Agile, en donnant parfois l'impression - à tort - aux clients que leur besoin passait au second plan. Dans les pires cas, l'Agilité devenait la destination et non plus le voyage.

La méfiance vis-à-vis de l'Agilité (souvent réduite à Scrum), devait alors être combattue en rassurant les organisations quant à la compréhension de leurs enjeux.

Mais la tâche était ardue : alors que les repères de l'Agilité devenaient de plus en plus rassurants, avec DevOps les organisations ont soudainement vécu le rebranding des Scrum Master en coach Agile. Les livraisons sont devenues continues plutôt que 2 fois par mois, les recettes aussi. Les équipes infras ont laissé leur chaise et leur VM (Virtual Machine ou machine virtuelle) aux SRE (Site Reliability Engineers ou équipe de moyens de production). Les sprints et les versions n'avaient plus lieu d'être. Sans pour autant améliorer les stratégies de déploiement qui vont avec. On livrait plus souvent, mais pas forcément le bon produit et le produit bien fait. Bref, l'assurance si difficilement acquise avec les repères de l'Agilité s'est alors effritée. Scrum était mort, En France, on parlait alors de FRAgilité, et globalement de Dark Agile. Dès lors, on a pu constater un rejet grandissant de ces buzzwords au sein des institutions qui avaient vécu ces dérives. Et DevOps a subi les mêmes travers. Tout un champ lexical s'est galvaudé et...

...ça s'est ultragaté.

Bottom-up

DevOps et Agilité partagent les mêmes valeurs, répondent au même manifeste et convergent vers le même objectif. Une tonne de littérature disserte déjà sur le sujet, qui n'est pas celui de cet article.

Pour réussir une transformation Agile, il est nécessaire d'abord de mesurer les goulets d'étranglement de la performance du delivery, puis de fixer des objectifs mesurables vers lesquels tendre, et enfin renforcer la collaboration entre les équipes et la bonne dose d'automatisation des processus.

C'est pourquoi l'adoption de ces concepts doit être une évidence en réponse aux irritants, et non une contrainte pour l'organisation. Pour cela, de solides fondations doivent être assurées.

Voyons comment on peut terminer cet article sans [buzzword], et évaluons si l'approche est plus convaincante. Moins de mots, moins de maux ?

"Connais-toi toi-même"

Il n'existe aucune boite à outil magique capable de résoudre les problèmes d'une organisation qui ne se connait pas. "Mon service met 3 mois à mettre une release en production, c'est un problème mais par où commencer ?"

Deux outils se complètent de manière efficace à cet effet, et existent déjà depuis très longtemps. D'abord un bon vieux RACI (matrice des responsabilités : Responsible, Accountable, Consulted, Informed) étendu aux activités projet, développement mais aussi moyens de production (un RACI DEVOPS).

On floute notre savoir-faire, c'est normal. Vous souhaitez un RDV, contactez niji.tech@niji.fr !

L'apport principal à ce stade est de se mettre d'accord sur les responsabilités de chacun, et aussi de tracer les activités non couvertes.

Ensuite, il est nécessaire de définir une équipe de transformation. Vous devez vous entourer d'experts dans leur domaine, des leaders qui sauront coacher l'organisation cible et qui seront les ambassadeurs du changement. Idéalement, une équipe de développement déjà missionnée sur du delivery, qui saurait provisionner quelques points d'effort régulièrement à investir dans cette transformation.

Enfin, la cartographie de la chaine de livraison (Value Stream Map ou VSM). Ce travail permet de prendre conscience de ses propres dysfonctionnements. Sont-ils humains, organisationnels, techniques, légaux ? Comment délivre-t-on aujourd'hui ? Où sont les goulets d'étranglement de la performance ? Plus tard, les colonnes de mon tableau d'avancement [kanban] seront inspirées de cette cartographie. Mon outil de déploiement [pipeline] aussi.

Réaliser une VSM c'est souvent compliqué et long. Parce qu'on doit multiplier les rendez-vous avec des interlocuteurs qui sont en général peu disponibles, et qui n'ont jamais fait ce travail et doivent donc eux-mêmes prendre du temps pour retrouver les infos. Il faut voir cette étape comme un investissement nécessaire pour mesurer le point de départ de la transformation. C'est à ce moment que la présence de votre équipe de transformation sera importante.

Avec la VSM, on peut déjà cibler les douleurs, et cadrer les actions de transformation requises: sur quels types de gaspillages pouvons-nous intervenir ?

• Surproduction

• Surstockage ou stocks inutiles

• Transports et déplacements inutiles

• Surprocessing ou traitements inutiles

• Mouvements inutiles

• Erreurs, défauts et rebuts

• Temps d’attente et délais

• Sous-utilisation des compétences

Un simple diagramme permettra de faire émerger naturellement les chantiers les plus porteurs de retour sur investissement, fournissant ainsi un précieux outil d'aide à la décision.

En matière de conduite du changement, les actions à victoire rapide (quick wins) sont synonymes de gains : engagement, crédibilité et légitimité. Vous feriez mieux de les prioriser et les adresser en premier, ou les déléguer à votre équipe. La matrice d'Eisenhower vous permettra de préciser davantage les priorités, et d'identifier les actions à déléguer.

Vous avez maintenant la vision à court terme de la transformation technique, n'oubliez pas d'y inclure également des actions d'accompagnement du changement. Gamification, rewarding des équipes qui auront appliqué certains changements, communication horizontale et verticale sur les succès, events etc. Ne sous-estimez pas l'effort à y consacrer car vous allez amener du changement et devrez donc anticiper l'impact dans le quotidien des humains, et donc sur la gestion des résistances, ce qui sera sans doute le plus gros frein, nous y reviendrons.

L'efficience par le chaos

Les concepts clés derrière les buzzwords sont apparus par l'observation du terrain.

"Trouvons un moyen de travailler ensemble"

Dans les organisations trop riches en processus top-down, il suffit d'une anomalie en production pour s'apercevoir que les développeurs se réorganisent instinctivement en mode survie, quitte à contourner les règles, pour une meilleure synergie et efficacité. Mais travailler de la sorte conduit à l'épuisement. Les organisations qui savent observer ce phénomène capitalisent et tirent bénéfice des réflexes des développeurs, et deviennent efficientes. (SOAT, 2017).

Pour cela, il faut de la place pour l'expérimentation. Mais cet effort ne peut se quantifier. Or, nombre d'organisations exigent encore planning, chiffrage et contrôle en toute circonstances.

"Chiffrez moi ce POC (Proof Of Concept)"

Alors, vous vous résignez à devoir fournir un chiffre.

Avec le risque de tomber dans une logique de design-to-cost (expérimentez pendant 5 jours) sans garantie d'aboutir à un résultat. Sans résultat, la méfiance de l'organisation vis-à-vis de l'expérimentation grandit. Dans le cas où le POC aboutit mais à un résultat négatif, l'appréciation sera évidemment négative. S'il est positif, le projet en sortira grandi mais on n'aura pas anticipé le coût du POC. Dans tous les cas, c'est compliqué. Comment faire ?

"Je laisse faire parce que ça avance mais je n'ai pas l'impression que le projet est sous contrôle"

"ça" désigne un environnement mouvant où la spécification du besoin évolue dans le temps, dans lequel il est important de conserver sa capacité d'adaptation. Cela signifie que de nouvelles relations humaines seront créées au cours du projet, de nouveaux outils seront adoptés, des refactoring ambitieux auront lieu et tout ceci est normal. C'est la recherche pathologique de gain à court terme qui pénalise l'amélioration continue, et donc le gain à moyen-long terme.

Alors dézoomons un peu, et considérons ces coûts comme un investissement, qui nous aura permis de livrer plus tôt que les autres, et regardons l'avantage concurrentiel que cela nous a procuré. Et mesurons un gain financier à bien plus grande échelle, dans lequel le coût de notre POC vient se diluer. La pilule passe alors bien mieux. C'est l'incapacité à mesurer ce gain à plus large échelle qui constitue l'écueil, et non le manque de visibilité sur l'avancement du POC. Je sais, c'est facile à dire mais souvent dans la vraie vie, mon interlocuteur n'est pas objectivé directement sur le TTM (Time to Market) et il sera sans doute nécessaire d'accéder à son supérieur, voire n+2 ou davantage. Et ainsi espérer redéfinir ensemble les objectifs de chacun pour déverrouiller de nouveaux potentiels d'accélération. Avec la résistance naturelle que cela sous-entend, c'est donc l'étape la plus complexe comme nous l'évoquions plus haut.

Plus de blocage

Dans les organisations les plus matures, on peut se risquer à expérimenter l'agilité à l'échelle, mais les changements peuvent être coûteux et longs, donc pas forcément super [Agile]. Et ce n'est pas le type d'organisation qui nous intéresse, nous on aime la difficulté. Donc parmi les quick-wins de transformation que nous évoquions plus haut, certaines peuvent s'appliquer à tous et nous aider à grandir en maturité plus progressivement.

Supprimons la colonne "bloqué" de nos tableaux d'avancement [kanban]. Un ticket en statut bloqué tombe dans un trou noir où le temps peut s'arrêter des semaines, des mois. Sans raison. Un ticket est toujours actif chez quelqu'un (nommons-le Gilles), donnons lui plutôt à ce Gilles une colonne où s'exprimer, et invitons-le à notre café de synchro [daily scrum]. Et tant qu'à faire, calculons le temps moyen que passent les tickets dans sa colonne pour tracer la tendance par rapport à la situation de départ (cf value stream map) : faisons-nous mieux, moins bien ou pareil à chaque étape du processus ? La méthode à Gilles fonctionne-t-elle ? Cela peut aussi étayer l'analyse d'un burndown qui burn dans le mauvais sens : de nouvelles dépendances apparaissent.

Le burndown aura souffert...

On se retrouve alors dans un comité bien plus large, où chaque équipe en dépendance est représentée par un de leurs membres, lequel aura la responsabilité de mener l'action à son terme ou de réaffecter le ticket si lui-même connait des dépendances.

Avantage : nul besoin d'aligner les cadences [sprints] des différentes équipes, comme cela serait nécessaire avec Safe par exemple. Gilles s'engage à sanctuariser du temps chaque semaine pour abattre les actions qu'on lui aura attribuées. Aussi, cela responsabilise Gilles sur la priorisation des actions à mener pour délivrer notre produit. Moins de maux, plus démo.

Inconvénient : comme évoqué plus haut, sans un RACI préalablement complété et signé par tous, il sera compliqué d'obtenir leur engagement. Les tickets risquent aussi de faire des allers-retours entre deux équipes qui se rejettent la responsabilité. Le RACI peut toutefois être ajusté au cours de ces meetings pour mieux adapter la théorie à la réalité du terrain.

En synthèse

L'approche bottom-up décrite dans cet article met l'accent sur la connaissance de son organisation, la collaboration, et la mesure des gains. Il s'agit de retours d'expérience parmi tant d'autres, mais qui ont fait leur preuves pour contribuer à neutraliser cette méfiance vis-à-vis de la hype suscitée par l'Agile et le DevOps.

Retenons que l'efficacité découle de l'observation et de l'expérimentation, plutôt que de la planification stricte. Ce sont les ingrédients d'une transformation réfléchie et adaptée aux besoins spécifiques de chaque organisation, une transformation calée sur la respiration de l'organisation, qui sait donc saisir les opportunités mais qui sait aussi prendre le temps d'accompagner le changement.