Utiliser Scrum dans un projet d’avant-projet

Dans un article que j’ai écrit récemment sur le “Sprint Zéro”, j’ai pu démontrer que dans les rares occasions où le sprint zéro pourrait être une bonne idée, les équipes Scrum feraient mieux de l’envisager comme un “projet avant le projet”. Les projets ne viennent pas au monde opérationnels à 100% - c’est-à-dire avec le personnel qu’il faut et prêt à se mettre au travail du jour au lendemain. La grande majorité des projets peuvent, néanmoins, commencer immédiatement et des choses comme les environnements techniques et un premier backlog produit peuvent être mis en place pendant le premier sprint - un bon vieux sprint numéro un.

Mais pour certains projets un effort tout particulier devrait être fourni en amont pour décider ce que devrait impliquer tel ou tel projet et même s’il devrait y avoir ou pas du tout un tel projet. C’est ce genre de travail d’analyse que beaucoup d’équipe mettent dans un sprint spécial dit sprint zéro. Bien qu’un sprint soit généralement suffisant pour ce type de travail, il n’est pas inimaginable qu’un projet d’une certaine taille soit amener à bénéficier de deux sprints (même si leur durée est plus courte, avec des sprints d’une semaine par exemple). Bien que je pense que ce cas se rencontre rarement, j’aimerais donner quelques conseils dans la conduite d’un tel “projet-avant-le-projet”.

Un projet-avant-le-projet peut être envisagé plus simplement comme un projet d’étude préalable. Il peut permettre de répondre à des questions comme :

Quelles sont les fonctionnalités qui devraient être développées ?
Combien de temps cela devrait-il prendre ?
Quel est l’investissement qui sera nécessaire ?
Est-ce que le projet devrait être entrepris ?

Sur ce genre de projet, il n’y a pas d “incrément de produit potentiellement livrable” au sens habituel d’un logiciel opérationnel livré à la fin d’un sprint. Alors qu’est-ce qu’un projet tel que celui-là peut-il bien produire ?

Pour répondre à des questions comme quoi faire lorsque l’on applique Scrum en dehors de son terrain de prédilection du développement des produits, je pense qu’il est judicieux d’examiner les raisons expliquant pourquoi les règles Scrum sont ainsi. L’exigence de livrer un incrément de produit potentiellement livrable existe pour aider les équipes scrum à éviter la paralysie de l’analyse et à ressentir un sentiment d’urgence à produire quelque chose pendant la durée d’un sprint. Une juste dose d’urgence peut être à la source d’une créativité plus grande. La règle existe aussi pour aider les équipes scrum à rester honnêtes - c’est-à-dire de faire en sorte qu’elle ne puisse pas proclamer une quelconque avancée alors qu’aucune avancée n’a vraiment été faite.

Pour voir comment ces règles peuvent s’appliquer sur un projet d’étude préalable, prenons comme hypothèse une équipe développant un nouveau système pour des hôpitaux avec des sprints d’une semaine pour répondre à des questions comme celles évoquées précédemment. À la fin du sprint, l’équipe doit vraiment avoir terminé quelque chose. Elle ne peut pas vraiment terminer une fonctionnalité étant donné qu’elle ne fait qu’étudier le système. Mais d’une certaine façon, l’équipe pourrait terminer quelque chose, par exemple en ayant discuté avec tous les pharmaciens qui sont parties prenantes sur le projet. L’équipe saurait maintenant tout ce dont les pharmaciens auront besoin y compris les nouvelles fonctionnalités en rapport avec les prescriptions de médicaments, la recherche d’informations sur les patients, etc. L’équipe n’aura pas besoin d’évoquer à nouveau avec les pharmaciens leurs besoins de base. Ils peuvent être déclarés comme traités lors des entretiens avec les pharmaciens.

À la place, l’équipe aurait pu parler avec l’ensemble des parties prenantes de la partie du système en rapport avec les prescriptions médicales. Dans ce cas, l’équipe passe tout le sprint à interviewer non seulement les pharmaciens mais aussi les médecins, les infirmières, etc. Le seul sujet qui sera abordé lors de ces entretiens sera celui des prescriptions. L’équipe reviendra auprès des parties prenantes pour aborder les autres fonctionnalités lors des entretiens qui viendront après. Pour le moment, néanmoins, on peut dire de cette équipe qu’elle a terminé d’étudier les besoins de toutes les parties prenantes sur les prescriptions

Ces exemples illustrent comment appliquer les principes qui sous-tendent les règles scrum et dont le résultat peut être soit un petit morceau de logiciel - soit un élément spécifique du développement produit. Bien qu’ils permettent à une équipe d’appliquer Scrum en dehors de son terrain de prédilection, je voudrais réitérer mon avertissement que j’aimerais mieux qu’un tel effort ne soit pas du tout entrepris. La plupart des projets peuvent commencer immédiatement et ces problèmes résolus au fur et à mesure du démarrage du projet.

Auteur : Mike Cohn
Source : Using Scrum on an Analysis Project
Date de parution originale : 05 Mars 2013

Traducteur : Nicolas Mereaux
Date de traduction : 13/02/2017