Scrum est-il mort à l'ère de l'IA ?

Avant même que l'IA ne conquière le monde, je n'étais plus convaincue par Scrum.

J'ai commencé comme développeuse de bases de données et de logiciels, avant même que Scrum n'existe. J'ai appris la gestion de projet classique, l'agilité, suivi toutes sortes de formations et collectionné une quantité de certificats. J'ai travaillé comme cheffe de projet, Scrum Master, Agile Coach — toute la palette — toujours dans des équipes logicielles et data au sein de très grandes organisations.

Il y a quelques rares exemples dans de grandes entreprises que j'ai vus fonctionner vraiment bien en matière d'agilité, et ces équipes n'utilisaient pas du tout Scrum. La plupart de ce que j'ai vu était insupportable, épuisant, éprouvant pour les nerfs.

Voilà, simplement pour donner le ton de mon opinion personnelle et privée.

Et pourquoi est-ce que je pense ainsi ?

Parce que ce théâtre de processus et ce cimetière de tickets ont pris des proportions absurdes dans certaines organisations. Le côté cascade, la sur-coordination, la façon dont on se marche sur les pieds parce que trop de rôles font la même chose, la façon dont les choses importantes ne sont tout simplement pas faites.

C'est devenu de plus en plus absurde et cela n'avait plus rien à voir avec la façon dont je travaillais il y a très, très longtemps, avant que l'agilité n'existe : directement avec les collègues métier, directement pour les utilisateurs.

Je pense qu'au fil des décennies, le plus grand problème a été qu'une immense vague de personnes non techniques a inondé Scrum — des personnes qui, n'ayant jamais été ingénieurs, n'avaient aucun cadre de référence personnel sur ce qui est réellement possible en termes de performance, et se sont donc toujours rabattues sur le sujet humain, parce que c'était leur seul cadre de référence, et au final il n'est plus question que de :

Nous sommes tous assis en cercle et chantons Kumbaya.

Terrible.

Donc : merci, merci, merci que l'IA bouleverse maintenant tout. Merci pour cela. Je ne saurais assez la remercier.

La question est maintenant : que fait-on ?

Je sais que pratiquement toutes les entreprises du monde, à de très rares exceptions près, ont d'une manière ou d'une autre des tickets et des sprints. Certaines en ont encore plus, mais c'est à peu près le point commun. Les rôles diffèrent en partie, mais tout le monde a d'une manière ou d'une autre des sprints, des tickets, et désormais des agents IA — ou presque tout le monde.

Et maintenant, le grand chaos commence.

Et je veux aider à mettre de l'ordre dans ce chaos, car c'est possible avec des moyens simples et de manière très différente de ce que la plupart des gens pensent.

La première étape que vous devez franchir est : ne vous accrochez pas aux frameworks.

Élargissez plutôt votre regard.

Il circule ce mythe selon lequel, avant l'agilité, il n'y avait que le cycle en cascade, ce qui est une absurdité totale. Je n'ai jamais été dans un projet en cascade et, comme je l'ai dit, je développais déjà des logiciels alors que beaucoup d'entre vous n'étaient pas encore nés.

Il existait déjà avant l'agilité tant de façons de travailler et de méthodes différentes, et même après l'invention de Scrum, beaucoup de nouvelles sont apparues.

S'il vous plaît, ne vous cramponnez pas à un playbook détaillé quelconque.

Ce qui est amusant, c'est que le Scrum Guide indique dès la page 4 que Scrum repose sur le Lean Thinking, et personne ne s'y intéresse sérieusement — et c'est précisément là que les choses tournent mal.

Le Lean Thinking trouve ses racines dans les années 1950, lorsque Toyota a inventé le Lean Production System.

Bien, pensez maintenant de manière pragmatique.

Si vous êtes jeune et n'avez jamais connu autre chose que Scrum ou une version modifiée de Scrum, vous avez été conditionné à penser que tout est d'une manière ou d'une autre uniforme. Toujours un rythme de deux semaines, puis certains ont des jalons trimestriels, puis il y a toujours des tickets, puis il y a toujours des dailies. C'est toujours à peu près pareil, morcelé, toujours à peu près de la même durée et toujours plus ou moins identique. Et ce n'est pas le monde réel.

La vie se déroule par phases. Ça descend, ça monte. Les saisons suivent des cycles. La nature a des cycles. C'était un énorme inconvénient de tout ce Scrum — essayez, s'il vous plaît, de vous détacher mentalement de cette uniformité et pensez que maintenant, quand l'IA écrit du code si vite et accomplit pour vous toutes sortes d'autres choses à une vitesse folle, vous avez besoin de différentes séquences de travail, de durées différentes, d'aspects différents, et qui doivent donc être gérées différemment. En même temps, pour qu'une grande entreprise ne sombre pas dans le chaos, vous avez besoin d'une certaine stabilité — nous y viendrons dans un instant.

Mais tout d'abord, il faut comprendre ceci :

1. AVANT que l'agent de codage ne soit lancé, il y a une séquence
2. Puis il y a la séquence pendant laquelle l'agent de codage agit
3. et ensuite il y a encore une autre séquence, dans laquelle on valide la solution, on mesure quelque chose et on en tire des enseignements

Vous devez intégrer ces différentes séquences dans un rythme organisationnel, et cela n'a finalement pas grand-chose à voir avec des sprints de deux semaines.

Pour avoir la paix, on peut aussi emballer le tout d'une manière ou d'une autre dans des sprints de deux semaines, mais cela aura une tout autre allure que votre configuration Scrum actuelle. Détachez-vous donc de l'uniformité et pensez en phases différentes.

La première phase : QUOI et COMMENT

La première phase est la suivante : il faut désormais consacrer beaucoup plus de matière grise à déterminer CE QUE l'on veut réellement construire, puis vient la réflexion sur COMMENT on veut le construire, et seulement ensuite vous lancez l'IA. Ces phases sont actuellement discutées sous les termes de jugement et de gouvernance. Je ne dois pas nécessairement traiter ces phases avec Scrum et des tickets. Mais je dois désormais investir beaucoup plus de temps et de réflexion dans ces phases avant que les agents IA ne se mettent au travail. Il existe pour cela de nombreuses méthodes utiles.

Pour ce que l'on veut construire, nous revenons aux bons vieux classiques que sont l'orientation client, la centricité client, la proposition de valeur et tout ce qu'on voudra. Tout cela est vieux comme le monde. Cela n'était parfois pas fait dans la cérémonie Scrum uniforme. Donc retour aux devoirs : que veut réellement votre client, utilisateur ou citoyen ? Vous devez désormais investir plus d'efforts dans cette séquence, car construire n'est plus le problème.

Dans cette phase, vous utilisez bien sûr aussi l'IA pour la recherche, pour des expériences ou pour créer des prototypes, mais vous avez besoin de méthodes supplémentaires que Scrum n'a jamais eues. Il est ici tout à fait utile de regarder ce que propose Shape Up, et je trouve qu'on peut tout à fait en reprendre des idées et les appliquer même dans un immense groupe, à savoir l'idée de se demander :

Quels sont nos paris, quelles sont nos hypothèses, combien sommes-nous prêts à y investir, et au-delà de quels seuils de mesure arrêtons-nous tout parce que nos hypothèses ne tiennent pas ?

J'étais présente lorsque cela était vécu exactement ainsi dans des groupes mondialement connus. Il n'y a aucun argument pour dire que cela ne fonctionne pas dans une grande entreprise. Cela fonctionne. Il n'est pas nécessaire de faire une réorganisation ni un projet de changement. C'est tout simplement la volonté des dirigeants de le faire ainsi.

Les dirigeants qui sont sponsors, qui disposent du budget, et tous les autres qui portent une responsabilité dans ce contexte doivent simplement s'asseoir ensemble et dire : d'accord, réfléchissons désormais ensemble aux hypothèses que nous avons, aux expériences avec lesquelles nous voulons les valider, à nos paris. Au lieu de simplement remplir un backlog de tickets.

Ensuite peut venir la phase où l'on découvre ce dont l'utilisateur, le client, le citoyen a réellement besoin. Puis vous avez besoin de personnes capables de fixer un cadre en matière d'architecture, de qualité et de gouvernance avant d'envoyer l'IA le construire.

La phase de construction : liberté dans des limites étroites

Et ce qui est beau, c'est que, comme l'IA peut construire si vite, vous n'avez besoin de personne pour coordonner les humains. Donnez aux équipes la liberté de se coordonner elles-mêmes en fixant à l'avance des limites et des règles du jeu étroites.

Lorsqu'il est clair quel pari on veut faire, combien de financement est mis à disposition, lorsqu'il est clair — ou que l'on a des hypothèses sur — ce dont l'utilisateur, le client, le citoyen a besoin, vous avez alors besoin d'une période pendant laquelle cela peut être construit, pendant laquelle les experts métier et les ingénieurs avec des agents IA décident eux-mêmes à quelle fréquence ils se parlent et se coordonnent, et dans quelles réunions.

Je vais vous dire comment c'était autrefois. Je restais simplement huit heures dans une pièce avec les personnes qui voulaient quelque chose, et nous faisions le travail ensemble. Quand j'ai commencé comme développeuse, il n'y avait pas de réunions. Cela n'existait pas. La culture n'existait pas. Nous travaillions simplement ensemble. Nous, c'étaient les techniciens et les gens du métier. Nous étions assis ensemble toute la journée dans une pièce et travaillions les uns avec les autres. Le mot « meeting » n'existait même pas en Allemagne. Il y avait en Allemagne le mot « Besprechung », et les Besprechungen avaient lieu environ une fois par mois et étaient mortellement ennuyeuses. On n'y allait que parce que le chef pensait qu'il fallait faire ce genre de chose. Le vrai travail pouvait se faire sans réunions.

Et revenir à cette façon de travailler, où l'on travaille simplement ensemble pendant huit heures, me semble très sain — et merci, chère IA, de nous ramener à la normale. Aujourd'hui, cela s'appelle Forward Deployed Engineer, mais le concept est ancestral.

Car il était parfois insupportable que les ingénieurs soient interrompus des millions de fois par jour par tous les canaux possibles, et que, lorsqu'ils avaient enfin cinq minutes dans le daily pour travailler ensemble, on les coupe parce que le daily ne doit durer que 15 minutes. Cela doit cesser complètement. Désolée, quelle absurdité. Laissez simplement les gens faire leur travail.

Valider, mesurer, apprendre

La période pendant laquelle on teste si un pari est gagnant était déjà limitée par Shape Up, ce qui est une amélioration par rapport à Scrum, car dans Scrum les sprints continuent simplement pendant des mois, encore et encore et encore. Mais maintenant, avec l'IA, la durée d'un sprint est peut-être de nouveau trop longue.

Réfléchissez donc à la durée dont vous avez besoin pour découvrir si ce qui a été construit avec l'IA était vraiment la bonne chose. Selon ce dont il s'agit chez vous, cette période peut aussi être très courte.

Il est extrêmement important qu'à la fin il y ait toujours un apprentissage, non seulement pour une personne mais pour une équipe, et que celui-ci soit porté au-delà de l'équipe dans l'organisation.

Il faut une certaine cadence. Lorsqu'une grande entreprise a plusieurs équipes et qu'elles travaillent toutes désormais avec des agents IA, il faut une cadence dans laquelle les apprentissages sont échangés entre les équipes. Cela peut à son tour être un rythme ; que vous l'appeliez sprint ou autrement n'a pas d'importance. Le rythme doit correspondre au rythme de l'entreprise. L'apprentissage a idéalement lieu après que le tout a déjà été testé en production. Sans véritable retour des utilisateurs, citoyens ou clients, il ne vaut rien.

Un tel apprentissage doit aussi être digéré et exploité. Un apprentissage dont on parle seulement, puis on se sépare et on ne change rien dans la suite du travail, est totalement inutile. Cela signifie qu'il doit y avoir une phase dans laquelle les apprentissages changent quelque chose, et ce à tous les niveaux : dans le déroulement, dans le contenu, dans les décisions, dans la qualité, dans la gouvernance. Autrefois, on appelait cela le processus d'amélioration continue.

S'il vous plaît, s'il vous plaît, s'il vous plaît, s'il vous plaît, arrêtez de parler uniquement de sentiments et de sujets psychologiques. Bien sûr, il y a toujours là aussi du potentiel et une marge de progression. Mais ce n'est pas l'objectif principal du travail. Je vais au travail pour travailler. L'objectif principal, c'est le travail.

Cela signifie que les apprentissages doivent alimenter le travail, et si votre seul apprentissage est que vous devez mieux collaborer, désolée, vous n'avez pas fait correctement vos devoirs. Apprendre signifie : vous savez quelles hypothèses étaient fausses, quelles nouvelles hypothèses vous pouvez maintenant formuler, quel retour l'utilisateur, le client, le citoyen a donné, ce que disent les données, quelle était la qualité, comment s'est passé le déroulement, auriez-vous pu être plus rapides, meilleurs ? Comment était la communication ?

Bien, nous revoilà aux personnes. Cela en fait partie, mais cela ne peut jamais occuper tout l'espace. Et si le seul apprentissage de chacune de vos discussions est que le leadership n'est pas bon, désolée, il faut alors reparler de toute la configuration. Il ne s'agit pas ici de « ceux d'en bas contre ceux d'en haut » et inversement. Collaboration est le mot magique.

Les rôles : le travail plutôt que les titres

Parlons donc maintenant des rôles. Je ne suis pas fan des rôles. Je suis fan de découvrir quel travail doit réellement être fait, pour ensuite écrire un prénom et un nom indiquant qui fait ce travail. Oubliez les rôles et les titres. Je connais des groupes qui les ont abolis il y a plus de dix ans parce que cela n'apporte tout simplement rien.

Il y a tant de travail, le travail ne manquera certainement pas. Je ne crois pas que quiconque doive craindre qu'il n'y ait plus de travail. Bien au contraire : si l'on ouvre son regard, il y a même plus de travail qu'avant. Et réaliser quelque chose de génial doit être si amusant que le titre n'a absolument aucune importance.

Je pense aussi que nous devrons constamment apprendre quelque chose de nouveau. C'est pourquoi je ne peux pas me reposer sur une quelconque description de rôle.

Il faut savoir piloter les agents de codage, savoir définir l'architecture et la qualité, savoir déterminer ce qui doit être construit, savoir formuler des hypothèses, savoir formuler des expériences, savoir définir des KPI mesurables, trouver des données mesurables qui contribuent aux KPI, créer les conditions pour pouvoir travailler en paix, et, et, et, et, et. Tant de travail.

Notez toutes les activités.

Ensuite : tous les développeurs, analystes métier, ingénieurs, Scrum Masters, Product Owners, team leads, leaders X, Y, Z, que sais-je, combien de dirigeants vous avez et comment ils s'appellent tous. Notez simplement leurs prénoms et noms.

Vous avez la liste des activités, puis on fait correspondre : qui fait quoi ? Et cela n'a pas besoin d'être gravé dans le marbre, cela peut changer de temps en temps.

Et après quelques mois, de nouveaux intitulés de rôles vous viendront peut-être à l'esprit, ou vous apprendrez en tant qu'organisation et direz : de toute façon, tout se mélange. Tout se mélange. Peu importe. Nous travaillons ensemble. Vous pouvez volontiers garder le titre de rôle de votre contrat de travail, personne ne vous le retire, mais dans le travail quotidien le travail doit simplement être fait, et chaque travail a de la valeur, et dans chaque travail je dois apprendre, et nous commençons tous à apprendre quelque part, et personne ne sait tout. Alors détendez-vous.

Je l'ai trop souvent vu en direct et en couleur. Les gens ont peur. Les gens ont trop à faire. Les gens ont trop peu à faire. Chacun développe sa stratégie pour s'en sortir tant bien que mal dans la vie. Et cela engendre des choses stupides et totalement inutiles.

J'ai déjà vu des gens planifier des réunions uniquement parce qu'ils ne savent pas quoi faire d'autre. C'est pourquoi il est si important que vous investissiez quelques jours simplement pour découvrir quel travail doit être fait et qui fait ce travail. Ce sera comme une libération.

Il y a des gens qui ont vraiment peur. Ils sont totalement déstabilisés. Ils veulent donner le meilleur d'eux-mêmes et ne savent pas où ni comment. Et ils ne vous le diraient jamais, et ils ne le montreront jamais non plus.

Grâce à mon expérience de vie — je suis déjà un peu plus âgée — j'ai désormais un assez bon flair pour cela, et combien de fois ai-je vu quel immense soulagement naît lorsque quelqu'un prend les choses en main de façon à ce que personne ne perde la face.

Restez détendu. N'en faites pas un drame. N'en faites pas une thèse de doctorat. Notez simplement le travail à faire, les noms à côté, et c'est tout.

Tickets, backlog et vraie performance

Que vous utilisiez encore des tickets ou non dépend un peu de la façon dont vous organisez cela avec les agents IA. Pour ce que les humains préparent et finalisent par phases, je dirais qu'une page wiki avec un simple tableau suffit. Je pense que l'époque de la maintenance de tickets morcelés est révolue.

Et pour être honnête, un backlog plein de choses qui ne sont jamais terminées a toujours été méga, méga non agile, car le Lean Thinking — la racine de l'agilité, issue des années 1950 — connaît huit types de gaspillage, Muda, et les tickets dans le backlog sont un parfait exemple de gaspillage.

Saisissez l'occasion de repenser tout Scrum et de revenir à la performance. Non pas la performance au sens de : nous atteignons des jalons, nous produisons beaucoup de tickets, nous relisons comme des fous ce que font les agents IA — mais la performance au sens de : le client a adoré ce que nous avons fait. Nous gagnons beaucoup plus d'argent, nous réduisons les coûts, nous gagnons plus de clients, nous conquérons de nouveaux marchés. De tels critères de performance, et très important : nous apprenons.

Au moment où vous faites quelque chose de formidable, gagnez beaucoup d'argent et n'apprenez rien, vous construisez du legacy. Saisissez l'occasion d'un nouveau départ.

Pour chaque problème d'entreprise désormais déstabilisé par Scrum et l'IA, je pourrais vous montrer des conseils et solutions pragmatiques pour vous en sortir sans réorganisation massive ni projets de changement. Pour cela, je dois savoir sur quoi vous travaillez en ce moment. Contactez-moi. J'écris aussi actuellement un playbook pour que vous puissiez le mettre en œuvre sans faire venir de coûteux consultants. Je me réjouis de vos retours.

FAQ

Avons-nous encore besoin de Scrum ?

1. Scrum fonctionne-t-il encore avec des agents IA ?

On lit sur les réseaux sociaux des AI engineers qui ont construit une équipe Scrum composée d'agents IA. Cela fonctionne, mais cette réponse ne vous aide pas dans une organisation plus grande.

Je pense que c'est ainsi : Scrum, tel que vous le connaissez, ne fonctionnera plus très longtemps. Cela dépend aussi du degré d'avancement de votre développement logiciel avec des agents IA.

Le changement se fera par phases.

Tout d'abord, il est certainement judicieux d'avoir une forme de cadence. Si toute l'organisation pense et travaille en sprints, on peut d'abord laisser les choses ainsi, mais les utiliser différemment.

La composition des équipes, en revanche, ne fonctionnera plus. Les tickets morcelés non plus. Les rôles vont changer. La revue va exploser — qui doit relire tout ce que l'IA crée si rapidement ? Décider ce qui est construit et comment prendra plus de temps, mais pendant ce temps on ne peut pas développer, ce qui fait naître des rythmes différents au sein d'une équipe.

Les structures de direction autour des équipes Scrum devront changer si vous les avez laissées intactes lors de l'introduction de Scrum à l'époque. Plus vous travaillerez avec des agents IA, plus vous remarquerez que Scrum atteint ses limites, à l'intérieur comme à l'extérieur de l'équipe Scrum.

2. Scrum a-t-il encore un sens quand les agents IA développent plus vite que les humains ?

Mon opinion personnelle : non. Il existe de meilleures façons de structurer et d'organiser la nouvelle manière de travailler. Les grandes organisations dans lesquelles j'ai travaillé pendant la transformation agile laissaient aux équipes la liberté d'appliquer Scrum ou non, et le véritable changement a eu lieu dans les structures de direction et dans la manière de mener les initiatives. Même avant l'IA, Scrum ne convenait pas à tout. Quand les agents IA travaillent, il n'est pas nécessaire d'attendre 2 semaines, et personne ne peut relire la quantité produite.

Néanmoins, il doit y avoir un moyen de décider : qu'est-ce qui vaut la peine d'être construit ? Comment le validons-nous ? Quelle est notre boucle de feedback ? Que dit l'utilisateur/le client/le citoyen de notre solution ? Combien de budget cela vaut-il ? Comment faisons-nous la gouvernance ?

Scrum n'a de toute façon jamais entièrement répondu à toutes ces questions. Certaines organisations utilisaient donc déjà d'autres méthodes avant l'IA, et certaines n'ont fait que représenter Scrum comme une cascade en tickets. Si ce dernier cas correspond plutôt à la façon dont cela est vécu chez vous, Scrum n'a plus de sens avec des agents IA. Il est alors bien plus judicieux de regarder d'abord le niveau de vol au-dessus : sur quelle base décidons-nous ce qui est fait, comment le validons-nous, quelles sont nos boucles de feedback, avons-nous des critères d'arrêt et qu'en dit le client/l'utilisateur/le citoyen ?

3. Avons-nous encore besoin de sprints quand les agents IA peuvent travailler 24h/24 et 7j/7 ?

Pas pour les agents. Mais vous avez besoin de rythmes différents pour les humains de l'organisation. Vous avez besoin d'un rythme où l'on décide de ce qui est construit, d'un autre pour les boucles de feedback, d'un autre pour les décisions de gouvernance, d'un autre pour l'apprentissage dans l'organisation, d'un autre pour les changements de cap, d'un autre pour les décisions budgétaires, et ainsi de suite. Ces rythmes doivent être réunis dans une cadence commune. Que vous continuiez à utiliser le mot sprint ou non est secondaire. Mais les différents rythmes ne peuvent en aucun cas tous durer 2 semaines. Certains seront plus courts, d'autres plus longs. Ces sprints de 2 semaines avaient aussi un énorme inconvénient. L'humain et la nature fonctionnent par cycles. L'IA vous ramène à travailler par cycles, ce qui est un grand progrès. Vous devez prévoir du temps pour décider ce qui est construit et comment, puis l'IA le construit assez rapidement, et peut-être s'est-on trompé et le rejette-t-on. Vous avez maintenant la liberté de choisir vous-même ces périodes. Cela facilite énormément le travail, car toutes ces activités ne se ressemblent pas et ne doivent plus être comprimées dans des tickets identiques et des sprints identiques. Saisissez cette chance !

4. L'agilité est-elle dépassée à cause des agents IA ?

Bien au contraire. Les valeurs agiles sont intemporelles. Mais il faut honnêtement dire que le terme « Agile » est vraiment devenu insupportable. Et laisser simplement ce sujet reposer. Plus personne ne peut l'entendre.

Il vaut mieux devenir concret, offrir une aide pratique concrète. Le Lean Thinking aide beaucoup plus pour cela.

Prenons par exemple les 8 types de Muda, le gaspillage. Au moment où vous travaillez avec des agents IA, vous faites passer le gaspillage à l'échelle s'il existait déjà auparavant. Il est donc très judicieux de s'y intéresser.

Ou prenons les limites de travail en cours de Kanban. Si des dizaines d'agents IA travaillent désormais en parallèle et que vous ne limitez pas cela consciemment, vous limitez le délai de traversée, car il y a toujours un goulot d'étranglement quelque part. Un délai de traversée plus court signifie que vous attendez plus longtemps le retour sur investissement. Cela peut même se calculer mathématiquement.

« Éviter les erreurs inutiles » est un autre principe utile de la philosophie Lean, qui devient extrêmement important avec les agents IA. Avant que l'agent IA n'automatise quelque chose, vous devez bien réfléchir au cas d'usage, sinon vous faites passer à l'échelle des erreurs évitables et pourriez vous ridiculiser.

Ce ne sont que quelques exemples. L'agilité a été dérivée du Lean. Le Lean existe depuis les années 1950. Je recommande donc de revenir aux racines, de les recombiner avec les connaissances actuelles, puis de les appliquer concrètement au travail avec des agents IA.

Repenser Scrum ou le remplacer complètement

5. Quelle est la meilleure alternative à Scrum pour les équipes AI-native ?

Scrum a été introduit dans le monde entier, qu'il convienne ou non. La plupart du temps, ce n'était même pas vraiment du Scrum. Si vous avez maintenant des équipes AI-native, plusieurs facteurs comptent avant de décider quelle façon de travailler vous convient le mieux. Vous avez absolument besoin d'une collaboration directe entre les utilisateurs/clients/citoyens — ou quelqu'un qui représente ce groupe — et les AI engineers. Vous avez besoin d'une boucle de feedback. Vous avez besoin de critères permettant de décider si et comment quelque chose est construit, et pourquoi quelque chose est rejeté. Vous avez besoin d'une gouvernance. Les petites équipes peuvent s'organiser elles-mêmes, mais doivent être impliquées dans les points que je viens de citer. Je recommande de s'intéresser au Lean Thinking et à Kanban. Shape Up a aussi des éléments utiles. L'important est de modifier la façon de travailler pour qu'elle corresponde à votre initiative.

6. Scrum vs. Shape Up — lequel est meilleur pour le développement assisté par l'IA ?

Shape Up possède des éléments précieux qui aident les humains à décider ce qui doit être construit. Une fois que c'est clair et que les agents IA travaillent, les agents IA peuvent utiliser une sorte de Scrum. Scrum atteint ses limites quand on combine agents IA et humains, car aucun humain ne peut relire la masse, et les agents IA n'ont pas besoin non plus d'un Scrum Master humain. Mais ils doivent savoir ce qui doit être construit et comment, et Shape Up offre pour cela des éléments utiles. Voir aussi cet article : Shape Up vs. Scrum — une amélioration de mon point de vue

7. Kanban est-il meilleur que Scrum pour les équipes avec des agents IA ?

Kanban a un grand avantage : le travail est limité. Les limites de travail en cours, aussi appelées limites WIP. C'est utile pour les équipes qui travaillent avec des agents IA. D'une part, on limite le travail que font les agents IA, car sinon on surcharge les humains qui les pilotent ; d'autre part, on limite le travail un niveau de vol plus haut, à savoir combien de projets ou d'initiatives sont traités simultanément dans une ou plusieurs équipes.

Kanban n'a pas de réunions ni d'événements prescrits. Cela donne aux équipes la liberté de les organiser elles-mêmes.

Kanban mesure combien de temps il faut de l'idée jusqu'à l'utilisation en production, cela s'appelle le lead time. Et Kanban mesure combien de temps il faut depuis le moment où l'on commence à mettre en œuvre l'idée jusqu'à l'utilisation en production, cela s'appelle le cycle time.

Ce sont, dans le travail avec des agents IA, des indicateurs plus pertinents que les tickets par sprint ou les story points (les story points n'ayant d'ailleurs jamais été conçus pour mesurer, mais nous y reviendrons plus bas).

Kanban aide à penser et à travailler de façon plus orientée outcome et impact. C'est pourquoi, à mon avis, il est meilleur pour les équipes déjà très avancées dans le travail avec des agents IA.

Cela suppose toutefois que l'équipe de direction comprenne Kanban et le vive aussi aux niveaux de vol supérieurs. Je recommande ici de s'intéresser aux Flight Levels du Dr Klaus Leopold.

Mesurer et planifier vs. simplement faire

8. Les story points ont-ils encore un sens avec des agents IA ?

Non. Clairement non. Les story points sont un sujet sensible, il y a beaucoup de disputes à leur propos. Je ne veux pas rouvrir les vieilles discussions. Seulement ceci : une équipe bien rodée n'a à un moment donné plus que 5 ou 8 story points par ticket, parce qu'elle a réussi à découper les lots de travail de façon régulière et petite, à bien les comprendre, et parce que la manière de travailler commune est harmonisée. Et si tout a de toute façon le même nombre, on peut aussi s'en passer.

Maintenant, avec les agents IA, il est extrêmement important de mesurer l'OUTCOME. J'entends par là : quelle valeur ajoutée pour le client/l'utilisateur/le citoyen apporte ce qui vient d'être construit ? Vous devez de toute urgence arrêter de mesurer le nombre et la durée des lots de travail. Suivez ce conseil ! Si les agents IA construisent très vite et beaucoup et que rien de tout cela n'apporte au final une valeur ajoutée mesurable à l'entreprise, vous pourrez certes impressionner avec une excellente mesure, mais vous manquerez le véritable objectif !

Quelle est donc la réflexion la plus importante sur le sujet des story points, des estimations et des mesures ? Comment mesurons-nous la valeur de ce qui est construit ici ? Pour cela, vous avez besoin de KPI adaptés et PAS de story points.

9. Avons-nous encore besoin de la vélocité ?

Je vous le demande : quelle signification a la vitesse d'une équipe composée d'humains qui utilisent des agents IA si ce que l'équipe construit n'apporte aucune valeur à l'entreprise ?

L'IA est méga rapide. Pourquoi mesurer cela ? Ce sont les humains, les goulots d'étranglement.

Il est tout à fait judicieux de mesurer où les déroulements ralentissent et s'engorgent. Mais pour cela, je n'utilise pas la vélocité comme indicateur, mais d'autres KPI, comme par exemple le temps qu'il faut de l'idée jusqu'au moment où la solution est utilisable en production par les clients/utilisateurs/citoyens.

Vous mesurez ainsi à quelle vitesse vous pouvez, en tant qu'organisation, mettre quelque chose en œuvre. C'est une mesure importante. La vitesse à laquelle une équipe construit quelque chose n'en est qu'une petite partie, car avant que l'équipe ne commence et après qu'elle a terminé, des choses se passent éventuellement en dehors de l'équipe, et elles doivent être incluses dans la mesure.

À retenir : à l'ère des agents IA, mesurez de façon orientée outcome tout au long de la chaîne de processus et arrêtez de mesurer l'activité des étapes partielles.

10. Comment mesurer la productivité d'une équipe quand les développeurs travaillent avec des agents IA ?

Il est absurde de mesurer la productivité d'une équipe. C'est une métrique illusoire. Elle vous donne peut-être un sentiment rassurant, mais en mesurant la productivité d'équipe, vous ne contribuez en rien au succès de l'entreprise. Toutes les équipes intelligentes du monde savent comment se comporter pour faire augmenter de telles métriques absurdes. En mesurant la productivité d'équipe, vous ouvrez un jeu absurde que vous ne pourrez d'ailleurs jamais gagner.

Commencez à apprendre comment mesurer avec des KPI business si ce que font les développeurs avec des agents IA contribue réellement aux objectifs de l'entreprise.

Je le dis si franchement parce que cette question révèle que vous devez de toute urgence changer votre façon de penser.

Les ingénieurs sont des gens intelligents. Quelle que soit la mesure de productivité que vous voulez mettre en place, les ingénieurs vous impressionneront avec des chiffres.

Mais si ce qui est construit n'est pas du tout ce dont l'entreprise a besoin, à quoi sert alors une équipe méga productive ?

Ou si, avant que le travail n'arrive dans l'équipe ou après qu'il l'a quittée, tout va terriblement lentement, à quoi cela sert-il alors ?

Ou si l'équipe a beaucoup de dépendances dans lesquelles rien ne change et qui la freinent, que dit alors la mesure ?

Ou si, à un moment donné, il était judicieux de construire ce qui a été construit, mais qu'un certain temps plus tard cela n'a plus de sens parce que le monde a continué de tourner, à quoi vous sert alors la confirmation de la productivité de tous ?

À RIEN !

Il est tout à fait judicieux de mesurer où les déroulements ralentissent et s'engorgent. Mais pour cela, je n'utilise pas la vélocité comme indicateur, mais d'autres KPI, comme par exemple le temps qu'il faut de l'idée jusqu'au moment où la solution est utilisable en production par les clients/utilisateurs/citoyens.

Il existe des KPI techniques comme la fréquence de déploiement, le change failure rate ou le nombre de bugs. Ils ont du sens lorsque la valeur business est mesurée en même temps à l'aide de KPI.

11. L'estimation a-t-elle encore un sens avec l'IA ?

Pas au niveau des tickets. À un niveau de vol plus élevé, oui. Si dans votre organisation plusieurs équipes travaillent sur une initiative plus importante, il est tout à fait judicieux d'utiliser une forme d'estimation pour comprendre quand et comment les différentes parties s'assemblent en un tout.

Processus et cérémonies vs. vitesse

12. Quelles cérémonies Scrum ont encore un sens avec des agents IA ? Avons-nous encore besoin de daily standups quand des agents IA font une grande partie du travail ?

Les agents IA peuvent faire du Scrum entre eux. Mais ils font alors tous les événements Scrum d'un sprint en une journée.

Les humains d'une équipe doivent conserver les événements Scrum dont ils ont besoin, car les personnes qui travaillent ensemble doivent continuer à se parler chaque jour. L'important ici est toutefois la flexibilité concernant l'ordre du jour. Je recommande de laisser l'équipe décider elle-même quel ordre du jour est le plus utile actuellement pour chaque événement Scrum, car cela change. Mieux vous construisez la configuration globale des agents IA, moins les humains ont besoin d'entrer dans les détails.

13. Avons-nous encore besoin du sprint planning avec des agents IA ?

Mon professeur d'informatique à l'université disait toujours : La planification est le remplacement du hasard par l'erreur. Planifier signifie que quelqu'un a un plan. Cela signifie que quelqu'un part du principe que le plan est bon. Partir du principe qu'un plan est bon est naïf.

Une approche mature est la suivante : je formule des hypothèses et je réfléchis à la manière de les valider ou de les réfuter. Quelles expériences puis-je mener et comment les mesurer ?

Avec des agents IA, vous devriez commencer à travailler sur la base d'hypothèses. Les agents IA travaillent incroyablement vite. Ils peuvent effectuer rapidement les validations.

Le planning n'a alors plus que la fonction de faire comprendre aux humains ce que les agents IA vont faire ensuite, et de fournir aux agents IA les instructions écrites pour cela.

Cela peut se dérouler de façon totalement différente d'un planning Scrum.

Les agents IA décomposent ensuite entre eux les tâches en sous-tâches et effectuent éventuellement aussi une sorte de planning.

L'important est qu'avant que les humains ne lancent les agents IA, vous soyez au clair sur les hypothèses que vous avez formulées et sur la manière dont vous voulez mesurer si vous aviez raison ou tort.

14. Avons-nous encore besoin de rétrospectives quand une partie de l'équipe est composée d'agents IA ?

Vous avez besoin d'un événement régulier dans lequel vous recevez le feedback des clients/utilisateurs/citoyens sur votre solution.

Vous avez besoin d'un événement régulier dans lequel vous comprenez et consignez les apprentissages des individus et des équipes, et traduisez ce qui a été appris en changements de la solution, de la démarche, de la structure, du système, etc.

Vous avez besoin d'un événement régulier dans lequel vous discutez de ce que les mesures des KPI business et orientés outcome signifient pour la solution et pour le travail des équipes et des agents IA.

Le nom que vous donnez à cet événement n'a pas d'importance. Il doit avoir lieu régulièrement, traiter ces points avec discipline et être en mesure de réellement mettre en œuvre ce qui a été discuté.

Vous pouvez bien sûr aussi parler de sentiments et de sécurité psychologique — mais si cela constitue chez vous l'essentiel d'une rétrospective, votre configuration globale n'est pas encore mûre. Parler principalement de sentiments en rétrospective est le signe que l'équipe de direction n'a pas encore compris comment mettre en place l'AI Operating Model de façon que le travail des équipes avec des agents IA contribue à la valeur business.

15. Avons-nous encore besoin de Jira avec des agents IA ?

Jira, Azure DevOps ou des outils similaires remplissent différentes fonctions. Il ne s'agit pas seulement des tickets du sprint. On peut s'en servir pour planifier au-delà d'un sprint, pour coordonner et planifier entre équipes. On peut les utiliser pour la gestion des tests. Jira et Azure DevOps sont aussi des outils capables de représenter des pipelines entièrement automatisés d'un processus DevOps complet sur différents environnements (ou d'en fournir les intégrations).

Lorsque vous travaillez avec des agents IA, la question se pose de savoir quelles fonctions de Jira restent nécessaires et lesquelles disparaissent. À mon avis, les niveaux d'abstraction transverses aux équipes et aux sprints restent importants. Tout comme une structure de test et DevOps qui fonctionne. Vous avez aussi besoin d'une sorte de recueil écrit des choses que les agents IA doivent faire. Cela peut être des tickets. Mais cela peut aussi être résolu autrement. Cela dépend beaucoup de votre propre organisation et du degré d'autonomie de vos agents IA, qui dépend à son tour de la manière dont vous avez déjà préparé l'architecture et la gouvernance.