En 2017, une étude contrôlée de Saltz et Shamshurin a produit un résultat qui a mis mal à l’aise une partie de la communauté agile: parmi quatre approches testées sur des projets data science, Scrum a obtenu les performances les plus faibles. Kanban arrivait en tête, suivi de CRISP-DM, puis de l’absence de méthode, et enfin Scrum. Pour les organisations qui appliquent Scrum à tous leurs projets par défaut, le constat mérite un examen attentif.
Pourquoi les sprints posent problème
Le timeboxing (découpage du travail en intervalles de temps fixes) est au coeur de Scrum: l’équipe s’engage sur un ensemble de tâches à livrer dans un sprint de durée fixe. Ce mécanisme fonctionne lorsque l’effort est estimable avec une précision raisonnable, ce qui suppose que l’équipe comprenne la nature du travail à réaliser.
En data science, cette condition est rarement remplie lors des phases exploratoires. Nettoyer un jeu de données peut prendre deux jours ou trois semaines selon ce qu’on découvre en l’examinant. Entraîner un modèle satisfaisant peut nécessiter une itération ou vingt. Forcer ces activités dans des sprints de deux semaines crée une tension artificielle: l’équipe doit soit découper le travail en morceaux qui ne correspondent à rien de significatif, soit accepter de ne pas tenir ses engagements de sprint, ce qui érode la confiance dans le processus.
L’enquête de Saltz et al. confirme cette friction à travers les scores de satisfaction: les équipes utilisant Scrum rapportent une satisfaction de 3,9 sur 5, contre 4,3 à 4,4 pour les équipes travaillant avec Kanban ou CRISP-DM. Le cadre méthodologique censé améliorer la collaboration génère en réalité de la frustration.
CRISP-DM: le cadre que les data scientists utilisent déjà
Avant de chercher des solutions nouvelles, il est utile de constater que le domaine dispose depuis plus de vingt ans d’un framework dédié. CRISP-DM (Cross-Industry Standard Process for Data Mining) découpe le travail en six phases: compréhension métier, compréhension des données, préparation des données, modélisation, évaluation et déploiement. Selon les enquêtes compilées par datascience-pm.com, il reste le framework dominant dans la profession.
CRISP-DM a un mérite fondamental: il oblige à formuler le problème métier avant de toucher aux données. Cette discipline semble évidente, mais son absence est responsable d’un nombre considérable de projets data qui produisent des modèles techniquement corrects mais opérationnellement inutiles. L’alignement métier dès la première phase impose une rigueur que beaucoup d’équipes techniques négligent lorsqu’elles disposent de données intéressantes et d’outils puissants.
Le framework a toutefois un angle mort que les chefs de projet identifient vite: il ne dit rien sur l’organisation du travail collectif. CRISP-DM décrit les phases d’un projet, pas la façon dont une équipe de cinq personnes coordonne ses tâches au quotidien. Pour un chef de projet, c’est précisément la pièce manquante.
Kanban comme réponse à l’incertitude
Si Scrum échoue à cause du timeboxing et que CRISP-DM ne couvre pas la coordination d’équipe, Kanban offre une solution intermédiaire. Le système repose sur trois principes qui s’accordent bien avec le travail exploratoire: la visualisation du flux (chaque tâche est visible sur le tableau), les limites de travail en cours (WIP, pour Work In Progress) qui empêchent la dispersion, et l’absence de cadence imposée.
La préparation des données, qui représente environ 80% de l’effort dans un projet data science typique, illustre bien l’avantage de Kanban. Cette phase génère des tâches de durée imprévisible qui s’enchaînent de façon non linéaire: le nettoyage d’une variable peut révéler un problème de qualité qui impose de revenir à la source. Un tableau Kanban absorbe ces variations de flux naturellement, là où un sprint Scrum les subit.
La combinaison qui gagne du terrain
La littérature récente, synthétisée dans une revue systématique de 2022, converge vers une approche hybride: utiliser CRISP-DM pour structurer les phases du projet et une méthode agile pour organiser le travail quotidien. Sept propositions distinctes ont été identifiées par les chercheurs, sans consensus sur un modèle unique.
Le principe commun est pragmatique: CRISP-DM fournit le cadre intellectuel, la séquence logique qui garantit qu’on part du besoin métier pour arriver au déploiement, tandis que Kanban (ou dans certains cas Scrum) fournit le cadre opérationnel permettant de savoir qui fait quoi, dans quel ordre et avec quelle visibilité sur l’ensemble du travail en cours.
Microsoft a formalisé cette idée avec son Team Data Science Process (TDSP), qui superpose les phases de CRISP-DM avec des pratiques Scrum et DevOps. La recommandation pratique qui émerge des études est plus nuancée: Kanban pour les phases à forte incertitude (exploration des données, modélisation itérative), Scrum uniquement pour les phases où le travail est suffisamment prévisible (déploiement, mise en production, monitoring).
Adapter le pilotage à la réalité du terrain
Pour le chef de projet qui gère une équipe data science, la première adaptation est de reconnaître que la mesure d’avancement classique ne fonctionne pas pendant les phases exploratoires. Le livrable intermédiaire d’un data scientist n’est pas un incrément de produit: c’est une information sur ce que les données permettent ou ne permettent pas. “Ce modèle ne fonctionne pas avec ces variables” est un résultat légitime, pas un échec.
Les revues de projet doivent inclure des dimensions spécifiques: la qualité des données sources, la pertinence des hypothèses de modélisation, l’écart entre les performances du modèle et les seuils d’acceptation métier. Un projet peut respecter son calendrier tout en s’engageant dans une impasse technique si ces dimensions ne sont pas examinées régulièrement.
L’enjeu le plus délicat reste la communication avec les parties prenantes. Dans un projet classique, on rend compte en termes de pourcentage d’avancement et de livrables produits. Dans un projet data science, le chef de projet doit expliquer pourquoi l’équipe a passé trois semaines à tester des hypothèses qui n’ont rien donné, et pourquoi ce travail a de la valeur. Les travaux de Viaene et Van den Bunder, publiés par le MIT Sloan, insistent sur cette compétence de traduction: le manager de projets analytics doit savoir reformuler les résultats techniques en termes de décisions métier, y compris lorsque le résultat consiste à invalider une piste. Sécuriser l’engagement des parties prenantes dans un contexte où les résultats sont incertains demande de valoriser ce que l’équipe a appris autant que ce qu’elle a produit.
Ce rééquilibrage entre livraison et apprentissage ne signifie pas abandonner toute rigueur. Les limites WIP de Kanban, les revues de phase de CRISP-DM et un suivi régulier des hypothèses testées fournissent un cadre suffisamment structuré pour maintenir la direction du projet sans étouffer l’exploration nécessaire.