Il y a quelques semaines (mois), je publiais un article à propos de la méthode ShapeUp de BaseCamp. Si vous ne connaissez pas cette méthode, je vous invite à aller le lire avant de continuer.

Si dans cet article, je me suis efforcé de présenter la méthode de manière très objective, j’ai néanmoins émis quelques réserves dont l’une d’entre elles qui est l’objet de ce présent billet : l’identification des risques en amont de la phase de réalisation.

Un cas concret de risque à identifier

Un peu de contexte. Cet exemple est directement tiré du livre de Ryan Singer. Le produit développé par Basecamp comporte une fonctionnalité de todo list. L’idée émerge d’introduire des groupes dans cette todo list. Pour matérialiser ces groupes, il est envisagé d’introduire des diviseurs. Dans le fonctionnement initial de la liste, lorsque des éléments sont cochés, ils sont automatiquement envoyés en bas de liste. Mais avec l’introduction de ces groupes, où ces éléments doivent-ils donc être envoyés ? En bas de liste ? En bas de son propre groupe ? Les items ne doivent plus être déplacés lorsqu’ils sont cochés ? Encore une autre solution ?

La réponse donnée par le livre

Pour avoir le contexte dont je vais parler ici, vous pouvez vous référer au chapitre Case study: Patching a hole, p.38 du livre Shape Up.

Image par Anemone123 de Pixabay

Le livre indique qu’il a été essentiel pour les Shapers d’identifier le risque concernant « où vont aller les items d’un groupe, une fois cochés ». Et que ça aurait été catastrophique si on n’avait pas éclairci ce point-là avant de donner le sujet à l’équipe.

Mon point de vue : dans une approche typiquement Scrum, le backlog refinement devrait pouvoir permettre d’identifier ce genre de risque. Lors d’un affinage, on dépile la demande, l’équipe devrait assez naturellement se rendre compte du travail à accomplir. Lors de cet affinage, si l’équipe a la chance d’avoir un UX designer, il devrait se poser les bonnes questions, notamment : « que se passe-t’il une fois l’élément coché ? ». Si toutefois la question ne vient pas de l’UX, durant cet affinage, la question à se poser serait quand même de chercher à connaitre le scénario utilisateur (sinon, cela veut dire que l’équipe de réalisation serait réduite à produire des fonctionnalités plutôt que de répondre à un besoin). Assez naturellement, le réflexe d’un développeur, (en tout cas, c’est le réflexe que j’aurais moi-même), serait de penser en premier lieu en CRUD :

L’ajout d’un élément dans la todolist
La modification d’un élément dans la todolist
La suppression d’un élément dans la todolist
L’ajout d’un groupe dans la todolist
La modification d’un groupe
La suppression d’un groupe
Et bien sûr, la lecture des éléments et des groupes

Si l’on parlait de considérations métiers plutôt que techniques, la question à se poser serait : A quoi sert la todolist ? Ce à quoi on pourrait répondre : avoir une liste d’éléments a faire et facilement savoir quand ces éléments sont faits. Comment répond-on à ce besoin ?

Quand on coche un élément, il est redirigé en bas de todolist. Ok, c’est une story supplémentaire. Et là devrait alors venir la question : « Oui mais, comment on fait quand il est dans un groupe ? ».

Est-ce grave si l’on n’est pas capable de répondre a cette question ? Non.

Ce n’est que l’affinage, donc le travail n’a même pas encore commencé. A partir de là, on peut envisager tout un tas de scénarios possibles :

On n’implémente que l’ajout et la suppression dans un premier temps. Cela répond déjà au besoin primaire de la todolist : On peut ajouter des éléments pour savoir qu’ils sont à faire, et on peut supprimer ces éléments lorsqu’ils sont terminés. Cela est peut-être suffisant pour l’utilisateur final.
Avant même d’entamer le travail sur cette todolist, on peut avoir un nouvel affinage, d’ici-là, le PO peut avoir retravaillé le besoin et être en mesure de donner la direction à prendre
Cette question n’a pas encore de réponse alors que le travail a commencé. Ce n’est pas grave, cela ne pourra de toute façon pas être pris en compte avant le sprint suivant. C’est même un point qui pourra être soumis en revue de sprint pour solliciter le feedback des parties prenantes
Finalement, lors de la revue, les parties prenantes disent qu’elles n’ont même pas besoin que les éléments cochés continuent d’apparaitre dans la liste : gain de temps sur la réalisation
Les parties prenantes indiquent qu’ils préféreraient voir les éléments cochés dans un autre onglet > on peut réagir au plus tôt et reprioriser la suite, plutôt que d’attendre la fin des 6 semaines et présenter un travail qui paraissait borné au départ puis n’est pas convaincant à la fin
Finalement, en découvrant les contraintes soulevées par cette fonctionnalité et en les présentant aux parties prenantes, celles-ci estiment que la valeur est trop faible face à l’énergie nécessaire à dépenser pour avoir quelque chose de convenable, et décident donc qu’elles ne veulent plus de cette fonctionnalité : on économise alors le temps supplémentaire qui aurait été dépensé.

Comparaison de timelines

Essayons de poser un scénario nominal en comparant le déroulé entre une approche Basecamp et une approche Scrum.

L’approche Basecamp

Ce que l’on peut constater au premier regard sur cette timeline, c’est qu’il peut y avoir un temps mort assez conséquent entre le moment où la fonctionnalité à été imaginée, formalisée, et le moment où son développement va effectivement démarrer. Toutefois, les intervenants ne sont pas les mêmes lors de ces 2 phases. Donc durant ces premières semaines, en réalité, d’autres fonctionnalités seront développées en parallèle.

Autre point important à souligner : quand bien même les risques auraient été écartés en amont, des échanges sont encore possibles durant la phase de réalisation (à partir de la semaine 9). La fonctionnalité n’est donc pas figée, et s’il y a des incertitudes, elle peut être présentée, même partiellement.

L’approche Scrum

Qu’apprend-on ici ? On voit que le délai de livraison de la fonctionnalité est bien plus court. Attention, cela ne veut toutefois pas dire que le temps total passé est moins important. L’avantage que l’on en tire ici est la capacité à être plus réactif face à une nouvelle demande qui arrive.

Ensuite, contrairement à Basecamp, le sujet est appréhendé par l’ensemble de l’équipe dès la première semaine. On permet donc une forte implication des développeurs alors même que rien n’est encore concret. Dès le départ, on permet également de faire intervenir un ensemble de personnes ayant tout le contexte nécessaire (métier, technique, UX, ….).

Les risques peuvent être identifiés à chaque étape et il n’est pas forcément nécessaire d’attendre d’avoir analysé le sujet en profondeur pour démarrer.

Conclusion

A la lecture du livre sur la méthode Shape Up, j’ai ressenti que l’identification du risque en amont était un point essentiel pour Ryan Singer et qu’il était important selon lui de ne pas laisser l’équipe de développement avec des « rabbit holes » au démarrage. Cette idée est défendable. Mais selon moi, cela enlève une part de responsabilité à l’équipe de réalisation, sur cet aspect-là. Qui plus est, lorsque l’on compare avec un développement agile, typiquement Scrum, le démarrage avec un risque non identifié n’est pas forcément très impactant sur le délai de livraison (et voire même au contraire), quand bien même l’intégralité de l’incrément produit serait remis en cause (fail fast, fail often).

Pour reprendre la question posée dans le titre de cet article : mon expérience m’a démontré que quand bien même on tenterait de pousser des phases d’analyses complètes en amont d’un projet, voire d’une simple fonctionnalité, il subsiste tout de même des zones d’ombre invisibles au départ, qui ne sont révélées que lorsque le développement est en cours.

Avec une équipe impliquée, consciente de son contexte métier et technique, et la possibilité qui lui est offerte d’intervenir en amont du démarrage du dév, la présence de risques n’est plus un problème, puisque l’équipe devient autonome sur leur détection et les solutions à y apporter.

Vous connaissez aujourd’hui un fonctionnement similaire, avec des phases d’avant projet longues et couteuses, qui finalement n’ont pas permis de lever toutes les incertitudes ? Ou au contraire, vous pensez que celles-ci sont absolument indispensables ? N’hésitez pas à en parler en commentaires.