Publié par
Il y a 11 mois · 8 minutes · Agile

Scrum pour la Recherche

J’ai récemment coaché une équipe de R&D sur un projet impliquant beaucoup de travaux de recherche. L’équipe devait trouver des solutions innovantes à des problématiques complexes liées au traitement de l’image. Cela passait par la lecture de papiers scientifiques, l’étude de « l’état de l’art », le test de diverses solutions, parfois en creusant profondément une piste pour finalement se rendre compte qu’elle n’était pas viable, etc.

Ces solutions étaient alors implémentées et livrées par l’équipe dans un moteur de traitement d’image pouvant être utilisé tel quel par certains clients, ou intégré par d’autres, dans des applications grand public.

Les membres de cette équipe connaissaient vaguement Scrum, mais avaient du mal à voir comment cela pouvait fonctionner sur leur projet. La littérature Agile ne les aidait pas non plus beaucoup – comme s’ils étaient parmi les premiers à vouloir utiliser Scrum pour la Recherche.

Voici donc comment nous nous y sommes pris pour implémenter Scrum sur ce projet, et les 5 clés de notre succès.

1. Accepter l’incertitude

Lorsqu’une équipe Scrum doit déterminer si elle peut implémenter directement une User Story, ou si elle ferait mieux de passer par un « Spike » afin d’acquérir d’abord de la connaissance et de lever certains risques, elle évalue le niveau d’incertitude. Si celui-ci est au-delà d’un certain seuil – appelons le « Seuil de Spike »  que l’équipe a inconsciemment défini comme étant le maximum d’incertitude qu’ils étaient prêts à accepter dans leur Sprint, alors, il commencent par un Spike.

Même si tout ceci est très abstrait, dans l’ensemble, j’ai le sentiment que ce « Seuil de Spike » est à peu près le même dans toutes les équipes que j’ai coaché auparavant. Ce seuil est tel qu’environ 10% des User Stories doivent être précédées d’un Spike afin de gagner en certitude.
Scrum pour la Recherche

Sur ce projet-là, définir un « Seuil de Spike » équivalent nous aurait amené à avoir un Spike pour plus de la moitié de nos User Stories. Ce que nous ne voulions pas car cela aurait réduit notre capacité à livrer de la valeur à nos utilisateurs rapidement. Nous avons donc convenu d’accepter d’avantage d’incertitude dans nos Sprints en augmentant notre « Seuil de Spike » afin de garder un nombre relativement faible de Spikes dans nos Sprints et d’avoir une chance de livrer plus rapidement de la valeur.

scrum pour la recherche

Nous avons donc dû apprendre à chiffrer des User Stories alors qu’une part non négligeable du travail restait à découvrir. Nous avons limité les dégâts en nous dotant d’une bonne baseline pour l’estimation en Story Points, et en l’améliorant régulièrement.

Notez que malgré tout ça, nous avions plus de Spikes dans nos Sprints que la plupart des équipes Scrum.

2. Accepter d’échouer

En acceptant cette incertitude dans nos Sprints, ce que l’on accepte aussi – en plus d’un grand écart-type sur la Vélocité – c’est l’échec pur et simple ! Nous avons accepté que parfois, une User Story serait abandonnée après quelques jours de travail et que nous aurions alors à trouver quoi faire à la place, en plein milieu du Sprint.

Accepter d’échouer, ce n’est facile pour personne, mais je crois que c’était encore plus difficile pour certaines personnes de cette équipe. Les chercheurs et les docteurs n’aimant vraiment pas échouer ! Ils aiment penser qu’ils ont « réfléchi à tout » avant de se lancer dans l’implémentation. Et lorsque l’implémentation commence, ils aiment que ce soit fluide.

3. Le Buffer d’Interruption

L’autre ajustement clé que nous avons mis en place s’inspire d’un classique des « Patterns » listés sur ScrumPlop, et un des favoris de Jeff Sutherland himself : Illegitimus Non Interruptus. Avec les spécificités suivantes :

  • Ce buffer représentait parfois jusqu’à 40% de la vélocité de l’équipe. C’était assez nouveau pour moi, pour autant, je crois savoir que certaines équipes (celles qui font beaucoup de support ou de maintenance notamment) utilisent un buffer encore plus gros, donc ce n’est pas si exotique que cela.
  • Nous utilisions ce buffer, non pas seulement pour gérer des imprévus (support, bugs et autres urgences), mais principalement pour ajouter des User Stories au Sprint à mesure que l’équipe avançait dans le Sprint, en fonction de ce qu’elle découvrait.
    Par exemple, si notre vélocité était de 30, notre backlog de Sprint, d’une durée de 3 semaines, pouvait ressembler à ceci :
    – Une User Story à 5 points
    – Une User Story à 3 points
    – Un Spike à 5 points
    – Une User Story à 2 points
    – Un Spike à 3 points
    – Un buffer de 12 pointsA la fin des Spikes, nous nous posions alors la question de quoi rajouter au Sprint, au vu des nouvelles connaissances acquises par l’équipe et sachant que nous ne pouvions pas ajouter plus de 12 points. Bien que cette approche ne soit pas recommandable partout, elle nous a clairement semblé une meilleure approche que de s’obliger à attendre le prochain Sprint Planning pour continuer sur un sujet.

Je dois dire que ce Buffer fut un élément clé de la réussite de Scrum sur ce projet, et d’une certaine adhésion de l’équipe à Scrum. Avant cela, l’équipe voyait Scrum comme une « méthode consistant à définir 100% du travail à faire toutes les trois semaines, et interdisant de se tromper, de changer d’avis, ou de découvrir de nouvelles informations entre deux Sprint Plannings ».

4. Devenir des champions du découpage des User Stories

Découper des User Stories n’est jamais simple au tout début. Mais ici, ce l’était encore moins. Il nous a fallu être parfois très ingénieux pour trouver l’ultime découpage qui rendrait notre User Story suffisamment « petite » (voir plus loin) pour rentrer dans un Sprint. Il nous a aussi fallu apprendre à faire des compromis – mais les bons – sur nos User Stories ; à renoncer à une des lettres de « INVEST » parfois… Pour cela, je me suis tourné vers les meilleurs : Craig Larman et Bas Vodde, qui, dans leurs livres Scaling Lean and Agile Development et Practices for Scaling Lean and Agile Development présentent une série de techniques de découpage avec lesquelles nous nous sommes familiarisés.

J’ai organisé un atelier dans lequel, par petits groupes et sur des User Stories réelles de l’équipe, nous avons expérimenté différentes manières de découper, et comparé les avantages et les inconvénients de chacune. Notre façon de découper le travail était par ailleurs un sujet récurrent de nos Sprint Retrospectives. Au final, nos techniques de découpage favorites étaient :

  • le découpage par « Stub » (implémentation d’un « faux » pour une partie non-disponible du système, de l’algorithme, afin d’être en mesure de travailler sur d’autres parties)
  • le découpage par taux de succès (l’algorithme doit donner un taux satisfaisant sur 50% de la base, puis 70%, 90%, etc.)
  • le découpage par performance (la fonctionnalité peut d’abord s’exécuter sans contrainte de temps, puis en moins d’une minute, de 500 millisecondes, etc.)
  • le découpage par type de données (images RGB, images RAW)

5. Redéfinir « Small »

Jusqu’à mon intervention sur ce projet, j’avais tendance à définir une User Story « petite » comme représentant « jusqu’à 50 heures de travail ». C’est ce que je disais aux équipes que je coachais, et cela ne fonctionnait pas trop mal. Ici, cela n’était tout simplement pas possible. L’incertitude était trop grande, le domaine, et le code, trop complexe. A titre d’illustration, nous avons une fois réalisé le simple « squelette » d’une fonctionnalité. Une implémentation parfaite d’une fonctionnalité ne faisant concrètement rien, mais respectant notre « Definition of Done ». Cela nous a pris 30 heures. Donc si 50 est le maximum autorisé, cela ne nous laisse pas grand-chose pour trouver une solution à un quelconque problème, l’implémenter, encore moins pour essayer, se tromper, et recommencer.

A la place, nous sommes convenus d’une autre définition de « Small » : « un binôme pendant un demi Sprint ». C’est-à-dire 120 heures de travail. C’est ce que nous visions comme taille maximale lors des découpages. Et cela restait encore parfois compliqué…

Et voilà, c’est tout ! Nous avons donc démontré que Scrum pouvait tout à fait fonctionner sur ce type de projet à l’incertitude forte. Bien sûr, nous aurions pu aussi adopter une approche Kanban qui facilite une gestion au fil de l’eau, mais nous apprécions la cadence imposée par Scrum, ses objectifs de Sprint atteignables à court terme et le temps dédié pour prendre du recul sur le produit et le process entre les Sprints. Au delà du cadre choisi, je dirais que le plus important reste de s’adapter aux préférences de l’équipe et aux éléments avec lesquels elle se sent le plus à l’aise. Ainsi, même en R&D Scrum fonctionne. Il faut simplement se rappeler que Scrum est un Framework définissant peu de choses au final, et dans le cadre duquel il revient à chaque équipe d’essayer des choses, d’inspecter, de s’adapter, et de recommencer.

Ce billet a été initialement posté en anglais sur le site de la Scrum Alliance : Scrum for Research.

Grégory FONTAINE
Grégory a 10 ans d'expérience au cours desquels il a été Chef de Projet puis Responsable Qualité avant de se trouver une passion pour l'agilité et de devenir Scrum Master et Coach. Développeur sur son temps libre, Grégory aime aussi bien accompagner des équipes de développement dans l'implémentation de pratiques d'ingénierie que travailler sur des transformations organisationnelles à grande échelle.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *