Trop de bonnes ou bons coachs agiles ont du mal avec ce mot. Comme si l’agilité, le “a” word, était devenu tabou, malsain. Comme si sa récupération par la politique et les prestigieuses entreprises de conseil en stratégie, ou sa déclinaison en programme de transformations transverses, avaient sali la beauté originelle du manifesto. Il y a de ça.
Pourtant c’est une des plus belles révolutions que nous a apporté le nouveau siècle, à nous, informaticiens et informaticiennes notamment, qui travaillons dans l’informatique de gestion ou son avatar l’Internet.
Et bien quitte à enfoncer des portes ouvertes, j’ai envie de résoudre ça. En commençant par faire le constat que c’est un peu comme d’habitude : parce que c’était trop compliqué de tout prendre, au moment du "copier-coller" on en a plus ou moins volontairement oublié une partie. Comme quand on sélectionne une phrase avec sa souris, mais qu’elle bute contre le bord du bureau, et qu’on se dit qu’on tapera ce qui manque. C’est juste une imposture, un mot qui se vide de son sens, un tour de passe-passe sémantique. C’est bien un problème de vocabulaire, et que je vous propose de résoudre, justement, en changeant de vocabulaire.
Cet article a été mis en scène lors de la FlowCon 2018.
Les trois actions de l’agilité
Pour construire mon discours, je vous propose de partir de la grille de lecture suivante. L’agilité a changé trois façons de faire : la façon d’apporter de la valeur, la façon d’interagir, mais avant tout la façon d’écrire (du code, des tests, des spécifications fonctionnelles, et aussi des plateformes).
L’agilité a changé notre manière d’apporter de la valeur : on parle de product management.
MVP, lean startup, incrément fonctionnel, A/B testing, cycle court, valorisation du feedback, client au centre… et j’en passe. Pour construire le meilleur produit, on est passer de l'expertise à l'expérimentation. L’agilité a changé la manière de définir un produit.
L’agilité a changé la façon d’interagir : on parle de méthodes et d’organisation.
Privilégier la parole à l’écrit, partager l’information de manière à rendre autonomes les équipes terrains, qu’elles puissent prendre la décision le plus tôt possible et créer des équipes de taille réduite, multidisciplinaires, pour réduire les surcoûts de communication… Et alors s’organiser en squad, chatter et feature teams : l’agilité, c’est bien changer les modes d’organisation.
L’agilité a changé notre façon d’écrire : et là, on parle de la nature profonde des gens.
Pas besoin de faire un dessin : entre les quatre-cents pages de spec d’il y a vingt ans et le fichier excel des user stories en given/when/then, ce n’est pas la même chose. Côté exploitation, le devops oblige les ingénieur·e·s système à rédiger leur plateforme au lieu de procédures de déploiement. Enfin, côté développeur et développeuse logiciel, l’extreme programming, premier fondement historique de l’agilité, est souvent vécu comme contre-intuitif, et demande de revoir sa façon de penser le code par rapport à une découverte naturelle (ou scolaire) de la programmation.
Et c’est ça qui pour moi est fondamental : changer sa façon d’écrire demande de se changer soi-même. Accompagnez un développeur ou une développeuse qui n’a jamais fait de TDD, pour qu’il ou elle en fasse, demande une empathie profonde, une écoute attentive, enseigner par l’exemple, individuellement et petit à petit… c’est plus qu’une conduite du changement, c’est changer la nature profonde de sa personne.
La constitution d’un double système
Il faut noter que ces trois axes ne sont pas indépendants. La façon d’écrire, comme de construire un produit, a changé la façon d’interagir. Et réciproquement. C’est ce qu’on appelle un système. De même, pour insister sur ce côté systémique, l’agilité a aussi permis d’affirmer que l’équipe doit aussi être vue comme un produit de son propre travail. Elle évolue. Chaque itération apporte une nouvelle version du produit-logiciel, mais aussi de l’équipe, grâce aux rituels permettant l’amélioration continue (par exemple les rétrospectives). Une des conséquences de cette approche est résumée dans la phrase citée par Jessica Kerr : “Great teams makes great people” (et non forcément l’inverse. Relisez-là si vous ne la connaissiez pas avant, et répétez-là chaque matin si vous avez du mal à aller au boulot).
Mais cela n’est que la partie émergée du système : la partie immergée est le logiciel.
En effet, on doit aussi considérer que les équipes (“en haut”) forment un système avec le logiciel (“en bas”) qu’on développe. Suivant cette considération, l’agilité a donc bien fait évoluer ce dernier comme suit.
D’abord, changer la façon d’écrire rend le système plus transparent, insiste sur sa qualité intrinsèque.
Ensuite, changer la manière de construire le produit, permet de se concentrer sur la qualité extrinsèque (et donc de l’améliorer).
Enfin, changer les modes d’organisation va se voir dans l’architecture, elle devient modulaire, autonome, en services. C’est une expression (ou une justification partielle) de la loi de Conway.
J’ai envie de rapprocher cela de la séparation que l’on fait entre le monde du problème (“le monde réel”) et le monde des solutions (“le logiciel”). Et si l’on suit le fil, on pourrait déduire (rapidement) que changer la nature des personnes, c’est agir sur leur qualité intrinsèque du produit, changer la façon de construire un produit agit sur la qualité perçue ou extrinsèque du produit, et changer l’organisation c’est le modulariser.
La grande imposture de l’agilité
Cela vu, je peux aller droit au but : la grande imposture de l’agilité a été de proposer aux organisations des transformations agiles, en omettant la première composante, celle consistant à réapprendre à écrire. Comme si, pour devenir agile, il suffisait de changer l’organisation d’une part, la façon de définir le produit d’autre part, sans se soucier de changer la nature profonde des membres des équipes.
Mon explication viendrait du fait que Scrum aurait mis en exergue une manière d’organiser les interactions. Suite à quoi, trop de consultants aurait voulu faire copier-coller en en oubliant le tiers. Mais cela ne fonctionne que si on change aussi la façon d’écrire (c’est à dire de produire).
Je pense que cela s’est fait volontairement. Changer les gens, c’est le plus compliqué, c’est beaucoup plus simple de les considérer comme des ressources d’une organisation.
L’intendance suivra.
C’est pour moi ce qui fait qu’une partie au moins de la communauté du développement logiciel le vit mal. Elle rejette le mot agilité (the “a” word), et a construit d’autres qualificatifs, comme le software craftsership.
Après, j’ai lu pire : quand le monde politique s’accapare le mot pour créer des ministères agiles, et alors ne garde plus que le “product management” dans leur discours. Aux oubliettes l’impact sur l’organisation !
Comment avoir pu oublier la composante écriture de l’agilité, alors que l’agilité vient de là ? De ce que j’ai entendu, sans le vivre, extreme programming et agilité était au début la même chose. L’agilité a ensuite envahi produit et organisationnel. Les programmeurs et les programmeuses, sous la houlette marketing d’uncle Bob, l’ont réintégré sous la forme de software craftership (en lui ajoutant une dimension revendicative, d’après Cyrille Martraire dans sa synthèse historique).
Je ne suis pas le premier à le dire, juste répéter qu’effectivement Scrum seul n’optimise en rien la qualité intrinsèque de votre produit : si vous faite de l’agilité sans produire de la qualité, attention à la gueule de bois !
Dites au gens qu’ils vont devoir changer
On ne parlera pas assez des managers et des patrons ou patronnes, qui vont être obligées de laisser certaines prérogatives au placard. Libérer le contrôle par exemple (ça ne veut pas dire le supprimer, ça veut dire l’effectuer au bon niveau et au bon moment).
On ne parlera pas assez du ou de la business analyst qui va devoir accepter que tout ne soit pas parfait, ni ce qu’il ou elle spécifiera, ni ce qu’on lui livrera, qu’il ou elle restera continuellement un enfant, apprenant à marcher en marchant.
On ne parlera jamais assez de l’architecte, qui va devoir se remonter les manches, trouver les meilleurs compromis entre modularité et coordination, et accepter de déléguer une partie de sa responsabilité aux développeurs et aux développeuses (every developer should be an architect).
On ne parlera jamais assez du testeur et de la testeuse, qui devra apprendre à intercaler son travail entre chaque étape du développement, voire devenir développeur, développeuse, ou… disparaître.
Et, finalement, on ne parlera jamais assez du développeur ou développeuse et de son nouvel·le ami·e l’ingénieur·e système. Il va falloir les accompagner, leur nouvelles responsabilités vont vite les dépasser : ils ou elles vont devoir être architectes, testeurs ou testeuse, responsables des plateformes, et même, responsables de leur capacité de production (sans en être propriétaire, attention).
Mais c’est là toute la puissance du “crafts”. Je ne peux imaginer une organisation produisant du logiciel devenir agile sans que ses développeurs et ses développeuses n’apprennent les bonnes pratiques de crafter.
Promouvoir le flow ?
Crafter, pour moi, ce n’est que le bon nom de l’agilité rapporté au métier consistant à programmer. De même le devops est le nom de l’agilité rapporté au métier d’ingénieur·e système. De même product management est le nom de l’agilité rapporté au métier de marketing produit.
Les seules qui manquent à l’appel ? Les méthodes. L’agilité n’a pas de nom propre quand on la rapporte à son aspect organisationnel. C’est un hold-up. Ça me fait penser à la Russie qui n’a jamais dit qu’elle se séparait de l’URSS, héritant de facto de tous les sièges que l’URSS avait dans les instances internationales. On parle de méthodes agiles tout du moins, et on a envie de les rendre constituants exclusifs de l’agilité dans sa globalité.
Les métiers de dev, d’ops et de BA ont réussi à se créer une identité agile propre, à s'émanciper, à se construire contre. C’est douloureux, ça demande de la violence, accepter des pertes. Mais non, l’aspect organisationnel aime se confondre tout entier avec l’agilité. Je le répète, c’est une usurpation de certaines organisations voulant réduire l’agilité à ses méthodes.
Un mot commence à ressortir : le flow. Je ne suis pas emballé, ça me fait aussi penser au flow de Mihaly Csikszentmihalyi, qui se rapporte plutôt à un état psychologique optimal. Mais en relisant Don Reinerstein, en lisant la raison pour laquelle la conférence française “Lean Kaban “ s’est renommée FlowCon (“Nous aidons tous ceux qui veulent fluidifier leurs organisations”), je me dis qu’à défaut de mieux, on pourrait utiliser ce mot.
En tous cas ne parlez plus d’agilité quand vous voulez parler strictement des aspects organisationnels de votre transformation agile, et évitez l’expression glissante de “méthodes agiles” : utilisez, à défaut d’un nouveau mot, de flow. Et répétez que transformation agile = Crafts (dont Devops) + Flow + Product Management.
Alors, seulement, ce jour là, je ne serai plus coach agile.
Pour la suite : http://ajiro.fr/articles/2018-02-20-flow_coach/
Salut, merci !
Non les testeurs ne doivent pas disparaitre, ils doivent réinventer leur métier, comme les développeurs l’ont fait. Un testeur ne doit pas tester le travail d’un développeur, comme tu le dis, c’est au développeur de le faire. Un testeur ne doit pas passer sa journée à implémenter des tests Séléniums. C’est encore une fois un travail de développeur.
Pour moi, la casquette de testeur doit se décliner en 2 activités :
1. Avant le développement : aider les développeurs à trouver tous les cas de test, et les plus tordus. Nécessite une connaissance parfaite du métier, de l’appli et de la technologie utilisée.
2. Après le développement : tester l’application dans son ensemble (et pas que la fonctionnalité). Voir si le tout est cohérent. Trouver les parcours foireux. Quid des perfs ? Et un petit audit sécurité ?
Ils sont encore rares ces testeurs mais ils arrivent 🙂