Être agile à l’ère de l’IA

Scrum a plus de 30 ans, les principes de l’Agile ont plus de 20 ans, et nous entrons maintenant dans l’Âge de l’IA, un nouveau monde étrange où l’intelligence est disponible en tant que service. Comment l’IA impacte-t-elle l’agilité ou les frameworks populaires comme Scrum ?

La plupart des pratiques et principes Agile sont basés sur des suppositions concernant le comportement humain et la productivité des équipes. Certaines de ces suppositions sont toujours vraies, mais certaines doivent être remises en question et réévaluées, ce qui impactera les pratiques.
Cet article est un mélange d’observation et de prédiction – ce que j’ai déjà vu se produire, et quelques spéculations sur ce que je pense qu’il va se passer dans un avenir proche.

En tant que lecteur, le principal à retenir est ceci : soyez prêt pour le changement. Je ne sais pas exactement comment les choses vont changer (cet article n’est que certaines de mes suppositions), mais je suis assez confiant que l’Agile à l’Âge de l’IA sera différent d’avant. Alors, prenez du recul, regardez attentivement comment vous travaillez aujourd’hui, et commencez à tout remettre en question.

Les équipes pluridisciplinaires

Lorsqu’on parle d’équipes et d’agilité, on imagine du travail effectué par de petites équipes auto-organisées et pluridisciplinaires. Pluridisciplinaire signifie que les membres de l’équipe possèdent différentes compétences qui se complètent. Le dessin ci-dessous utilise des cercles pour symboliser les connaissances et compétences qui se chevauchent de chaque membre de l’équipe.

Mais pourquoi avons-nous réellement besoin d’équipes pluridisciplinaires ?

L’hypothèse sous-jacente ici est que l’équipe a besoin d’un mélange de compétences complémentaires, sinon elle ne peut pas construire ce qu’elle est censée construire. Une équipe pluridisciplinaire possède toutes les compétences nécessaires pour construire de manière autonome un produit expédiable par incrément, avec un minimum de dépendances vis-à-vis des autres équipes. Les compétences complémentaires qui se chevauchent sont nécessaires à cela.

Mais avec l’IA générative, chaque personne a effectivement un collègue IA qui est incroyablement rapide et connaît tous les langages de programmation, tous les frameworks, tous les modèles, et possède bien plus de connaissances que n’importe quelle personne. En utilisant la même métaphore visuelle, ajouter un membre de l’équipe IA signifie ajouter un cercle de connaissances bien plus grand que n’importe lequel des cercles humains (bien qu’il y ait encore des connaissances humaines que le modèle d’IA n’a pas).

Les modèles d’IA ne sont pas encore parfaits, ils nécessitent une supervision humaine, mais une ou deux personnes possédant de solides compétences en ingénierie de prompts et ayant accès à un modèle d’IA générative de pointe seront plus performantes qu’une équipe agile pluridisciplinaire traditionnelle – tant en termes de vitesse que de qualité. Je le vis régulièrement moi-même – avec un collègue IA, je peux construire en heures ce qui aurait pris des jours, et construire en jours ce qui aurait pris des semaines.

Ainsi, les équipes pluridisciplinaires sont excellentes, mais elles ne sont pas aussi importantes qu’auparavant, puisque la connaissance n’est vraiment plus le goulot d’étranglement. Une équipe de 1-2 personnes + IA a accès à la plupart des connaissances dont elle a besoin.

Pourquoi 2 personnes ? Pourquoi pas 1 ? Parce qu’il est agréable d’avoir un autre humain avec qui parler, et plus facile de gérer des choses comme les vacances et les congés maladie.

Alors, que se passe-t-il réellement lorsque la taille de l’équipe se réduit à 2 personnes ? Licencie-t-on tous les autres membres de l’équipe ? Non, je pense que les entreprises intelligentes vont doter tout le monde de pouvoirs IA, au lieu de n’en doter que quelques-uns et de licencier les autres. Licencier un grand nombre de personnes pour cette raison risque de créer une culture de peur et un manque d’innovation – les gens ne seront pas incités à explorer davantage cette technologie, puisque l’efficacité accrue signifie plus de licenciements.

Prenons donc l’exemple où nous avions initialement 2 équipes pluridisciplinaires de 5 personnes chacune. Cela pourrait maintenant être divisé en 5 équipes de 2 personnes + IA.

Sur quoi ces équipes plus petites travaillent-elles ? Cela dépend du contexte. C’est un problème de luxe : “nous avons maintenant augmenté notre capacité de développement, que devons-nous en faire ?”.

Disons que les deux équipes plus grandes travaillaient ensemble sur un seul produit, en se concentrant sur différentes zones de fonctionnalités. Maintenant, nous avons 5 équipes plus petites, chacune étant plus productive qu’une équipe plus grande précédente. Nous pourrions faire en sorte que les 5 équipes travaillent sur le même produit, en se concentrant sur différentes zones de fonctionnalités comme avant. Le résultat est que nous ferons plus de choses sur ce produit. Ou peut-être que nous laissons 3 équipes se concentrer sur le produit existant, et 2 équipes travailler sur un nouveau produit, amplifiant ainsi la productivité globale de l’entreprise.

Équipes plus petites = Plus d’équipes

Une conséquence des équipes renforcées par l’IA est que nous aurons probablement des équipes plus petites, et plus nombreuses.
Des équipes plus petites signifient moins besoin de réunions et d’autres rituels de coordination interne. Si elles sont assises l’une à côté de l’autre (physiquement ou numériquement) et parlent informellement chaque fois que nécessaire, alors elles n’ont guère besoin de réunions formelles au sein de l’équipe – par exemple, il y a moins besoin d’une réunion quotidienne debout quand elles peuvent simplement parler à tout moment. Bien qu’elles puissent le faire de toute façon pour des raisons sociales.

D’autre part, nous avons plus d’équipes qu’avant. Donc, nous aurons un besoin accru de coordination entre les équipes, au moins si les équipes travaillent sur le même produit et ont des dépendances. En fait, si elles travaillent sur le même produit, peut-être que chaque équipe peut être vue comme un seul membre d’équipe dans une plus grande “super équipe” ou quelque chose du genre, et alors nous faisons des rituels comme les rétrospectives et les réunions de planification de sprint à un niveau équipe-des-équipes ?

Quoi qu’il en soit, je suspecte que la plupart des entreprises finiront par organiser une sorte de réunion quotidienne de synchronisation et une sorte de session de planification toutes les quelques semaines. Mais la structure des réunions sera différente des pratiques agiles traditionnelles, par exemple, elles seront probablement des réunions inter-équipes plutôt qu’internes à l’équipe, et les sessions de planification se concentreront probablement davantage sur le grand tableau plutôt que sur des éléments spécifiques du backlog.

Pour être clair : je ne sais pas où nous atterrirons. Mais je suis assez sûr que les choses changeront, car les hypothèses sous-jacentes à de nombreuses pratiques agiles sont renversées par l’avènement de l’IA Générative.

La principale compétence des développeurs n’est plus de coder

Une tendance claire est que les modèles d’IA deviennent vraiment bons pour écrire du code. Pas encore parfaits, mais suffisamment bons pour qu’il soit logique de laisser votre collègue IA écrire la majorité du code. Cela change fondamentalement le rôle. En tant qu’ingénieur logiciel, vous devez toujours être aux commandes, réfléchir à l’architecture, écrire les prompts, examiner les résultats et prendre la responsabilité de la qualité du code. Mais l’artisanat réel de l’écriture du code – pour la plupart, l’IA le fera plus rapidement et mieux que vous. C’est en partie vrai déjà aujourd’hui, et dans un an, cela sera probablement vrai 90% du temps. Un développeur logiciel qui insiste pour écrire tout le code manuellement à l’ère de l’IA risque de devenir un goulot d’étranglement et une source de bugs.

Donc, les développeurs deviennent essentiellement des mini-product owners, si j’utilise la terminologie Scrum. Leur travail est de décider quel code doit être écrit, non de l’écrire. C’est comparable à quand vous écrivez du code de haut niveau en utilisant un langage de programmation moderne, et que le compilateur le transforme en code machine – sauf que maintenant nous élevons cela d’un niveau et le modèle d’IA écrit également le code de haut niveau.

Votre collègue IA peut même travailler en arrière-plan. Imaginez cette conversation entre Bob, Lisa et leur collègue IA MrFixit autour d’un café le matin :

• MrFixit : “Bonjour tout le monde ! Quelques rapports de bugs sont arrivés la nuit dernière, deux d’entre eux étaient assez simples donc je les ai corrigés et mis en PR (pull requests)”
• Lisa : “Super, je vais le revoir dans un moment. Des trucs risqués là-dedans ?”
• MrFixit : “Eh bien, j’ai dû changer un peu la connexion. J’ai ajouté plus de tests donc c’est probablement bon, mais cette partie pourrait mériter un examen supplémentaire.”
• Lisa : “OK, je m’en occupe”.
• Bob : “Hé MrFixit, tu as vu cette discussion sur Slack concernant les failles de sécurité ?”
• MrFixit : “Oui, tu veux que je regarde ? J’ai quelques idées.”
• Bob : “Oui, s’il te plaît.”
• MrFixit : “OK, attends……. Voilà ! J’ai mis en place trois PRs, avec trois approches différentes pour résoudre le problème. Voir la description des PR pour les détails. Jetez un œil et faites-moi signe si vous voulez discuter de l’une de ces solutions.”
• Bob : “Génial !”.

Cela peut sembler assez exotique maintenant, mais dans un an, je pense que cela sera la norme pour de nombreuses équipes.

Le résultat : le codage n’est plus le goulot d’étranglement. Alors, que signifie cela pour des concepts comme les Sprints Scrum, une période limitée dans le temps (généralement 2-3 semaines) pour permettre à l’équipe de se concentrer sur le développement ? Eh bien, si le travail qui prenait normalement une semaine prend maintenant un jour, et le travail qui prenait normalement un jour prend maintenant une heure, avons-nous besoin de sprints ?

Des sprints d’1 journée ?

Je suppose que les sprints deviendront progressivement beaucoup plus courts, ou disparaîtront entièrement. Peut-être des sprints d’1 journée. Commencer la journée par une rapide synchronisation avec votre collègue humain et IA, décider sur quoi se concentrer aujourd’hui, puis terminer et publier avant la fin de la journée, et faire une rapide révision avant de rentrer chez soi. Le Daily Standup et la planification de Sprint deviennent essentiellement la même chose.

Avec plusieurs équipes travaillant ensemble, il y aura toujours besoin d’une réunion de synchronisation de niveau supérieur, peut-être une fois par semaine, pour s’assurer qu’elles sont alignées. Cela est vrai avec ou sans IA, mais le besoin s’accroît à mesure que nous évoluons vers plus d’équipes plus petites plutôt que quelques équipes plus grandes.

Comme je l’ai mentionné, je pense qu’il y a toujours un besoin humain pour une sorte de réunion de synchronisation et de planification toutes les quelques semaines. Mais le but et la structure de cette réunion changeront lorsque nous passerons à des cycles de développement plus rapides et plus courts, quand il n’y aura plus besoin de regrouper le travail en plusieurs semaines de travail juste parce que coder prend du temps.

Des spécialistes itinérants ou partagés ?

Et qu’en est-il des spécialistes ? Disons que nos équipes doivent traiter des bases de données et de la persistance, et ont besoin de connaissances spécialisées pour cela.

Traditionnellement, nous nous assurerions que chaque équipe pluridisciplinaire avait au moins une personne avec des compétences en base de données. Dans une équipe de 2 personnes renforcée par l’IA, les humains manqueront de certaines compétences et devront compter sur leur collègue IA. Est-ce que cela suffira ? Pour les tâches routinières, probablement oui. Mais parfois, pour des tâches plus avancées, un spécialiste humain sera nécessaire, par exemple pour formuler le prompt ou évaluer le résultat, ou peut-être pour construire des outils. Le spécialiste humain peut également aider à déterminer quels modèles et outils d’IA sont adaptés à la tâche en cours, ou même affiner les modèles pour les rendre meilleurs dans ce domaine de connaissance spécialisé.

Je suppose que nous aurons soit des spécialistes itinérants, soit des spécialistes partagés. Ce n’est pas une approche nouvelle, certaines équipes agiles le font de toute manière. Mais je pense que cela deviendra plus commun.

Par exemple, avec les 5 équipes ci-dessus, disons qu’elles utilisent toutes des bases de données. Peut-être qu’une ou deux des équipes ont réellement un spécialiste en base de données, parce qu’elles sont les équipes qui font le plus de travail sur les bases de données. Mais ce sont des spécialistes partagés qui parfois aident aussi les autres équipes.

Une alternative est d’avoir des spécialistes itinérants qui n’appartiennent à aucune équipe spécifique, mais qui vont là où leur besoin est le plus grand. Pour être clair, les modèles d’IA devraient posséder la plupart des connaissances spécialisées nécessaires, mais le spécialiste humain est là en complément pour lorsque nous atteignons les limites de l’IA, ou avons besoin d’une paire supplémentaire d’yeux de spécialiste humain pour évaluer le résultat.

Le rôle du Scrum Master ou du Coach Agile

Si vous avez un rôle comme Scrum Master ou Coach Agile ou similaire, cela inclut traditionnellement l’enseignement et le mentorat de l’équipe sur des sujets comme comment diviser efficacement une user story, comment mener efficacement une rétrospective, et comment travailler efficacement en équipe.

Une équipe renforcée par l’IA possède déjà toutes ces connaissances, si l’équipe choisit de les rechercher. Ainsi, votre rôle devient plus celui d’un coach et moins celui d’un mentor/enseignant. Si l’équipe veut savoir comment diviser une histoire, asseyez-vous avec eux et écrivez un prompt pour chatGPT (ou autre modèle). Vous connaissez cet adage populaire : « Donne un poisson à un homme, et tu le nourris pour un jour. Apprends à un homme à pêcher, et tu le nourris pour toute la vie ». Maintenant que les équipes pêchent leurs propres poissons, vous avez le temps de coacher et d’assister plus d’équipes, et de les aider à comprendre comment utiliser ces cannes à pêche.

La boucle de feedback des utilisateurs

Le retour d’information des utilisateurs reste une partie critique du développement agile, même à l’Ère de l’IA. Cependant, les pratiques changent. Nous serons en mesure de publier plus souvent, donc nos clients et utilisateurs devraient être prêts à recevoir de petites mises à jour fréquemment, au lieu de grandes mises à jour rarement. En conséquence, les utilisateurs peuvent prendre une part plus active dans le développement. Certains apprécieront cela, d’autres peut-être pas.

Si l’utilisateur n’est pas disponible aussi souvent que nécessaire, nous pouvons créer des utilisateurs fictifs en demandant à un modèle d’IA de jouer le rôle d’un type particulier d’utilisateur. Nous pourrions réaliser des recherches et des entretiens avec des utilisateurs fictifs en utilisant cela, et bientôt nous pourrons probablement aussi demander à l’utilisateur fictif d’essayer directement notre système et de nous donner son retour. L’utilisateur fictif ne sera pas aussi utile que le véritable retour des vrais utilisateurs, mais d’un autre côté, nous pouvons obtenir le retour plus rapidement et plus fréquemment, donc cela pourrait être un bon complément. Cela pourrait aider l’équipe à découvrir les problèmes de conception les plus évidents et importants.

Points supplémentaires à considérer

Juste pour le plaisir, j’ai donné l’intégralité de l’article ci-dessus à Claude Opus (le dernier modèle d’IA Générative d’Anthropic) et lui ai demandé de suggérer des points additionnels à ajouter. Voici la réponse non éditée, que j’ai trouvée plutôt bonne :

• Impact sur le backlog produit et la priorisation : Avec des équipes renforcées par l’IA livrant plus rapidement, le backlog produit pourrait nécessiter d’être mis à jour plus fréquemment. Le rôle du Product Owner pourrait évoluer pour se concentrer davantage sur la priorisation stratégique et la gestion des parties prenantes.
• Changements dans l’estimation et la planification : Les techniques traditionnelles d’estimation, telles que les points de story ou les jours idéaux, pourraient devenir moins pertinentes lorsque l’IA peut accélérer significativement le développement. Les équipes pourraient devoir adopter de nouvelles approches pour la planification et la prévision.
• Adaptations dans les cadres Agile : Des cadres Agile populaires comme Scrum, Kanban ou SAFe pourraient devoir être adaptés pour accommoder les changements apportés par l’IA. Par exemple, la durée et la fréquence des événements comme la Planification de Sprint, le Scrum Quotidien et la Revue de Sprint pourraient devoir être ajustées.
• Impact sur la dynamique d’équipe et la collaboration : Bien que l’IA puisse améliorer la productivité, il est essentiel de considérer son impact sur la dynamique d’équipe et la collaboration. Les équipes pourraient devoir trouver de nouvelles manières de favoriser la connexion humaine, la créativité et l’innovation dans un environnement piloté par l’IA.
• Apprentissage continu et développement des compétences : À mesure que l’IA prend en charge certaines tâches, les membres de l’équipe pourraient devoir se concentrer sur le développement de nouvelles compétences, telles que l’ingénierie de prompts, la sélection de modèles d’IA et l’évaluation des résultats. L’apprentissage continu et l’amélioration des compétences deviendront encore plus cruciaux à l’Ère de l’IA.
• Considérations éthiques et transparence : Les équipes devront naviguer à travers les considérations éthiques entourant l’IA, telles que les biais, l’équité et la transparence. Les pratiques Agile pourraient devoir évoluer pour assurer un développement et un déploiement responsables de l’IA.

Recalibrage

(D’accord, c’est moi l’humain qui écris à nouveau)
Mon ami Kent Beck a tweeté ceci :

Je pense que Kent saisit l’essence de ce à quoi nous sommes confrontés maintenant, dans tous les rôles et professions. Nous devons recalibrer ce sur quoi nous passons notre temps. Qu’est-ce que cela signifie d’être un Ingénieur, un Scrum Master, un Product Owner, un Directeur technique, etc. ?

Il en va de même pour l’Agile : nous devons recalibrer nos pratiques agiles. Cela commence par l’auto-réflexion. Sur quoi passons-nous du temps ? Quels sont nos rituels, rôles, artefacts ? Qu’est-ce qui doit être remis en question, changé ou réévalué alors que nous entrons dans l’Ère de l’IA ?

Partagez le post avec vos pensées !

Pour aller plus loin

• Are developers needed in the age of AI?
• Generative AI in a Nutshell – how to survive and thrive in the age of AI