Je suis sur un projet de refonte d’une application avec 2 sites FO (qui ciblent 2 types d’utilisateurs) et un back-office d’administration (pour un autre type d’utilisateurs).
Je vais aller droit au but : j’ai l’impression que Scrum s’adapte mal pour ce type de projet.
Globalement, on connait toutes les fonctionnalités du nouveau système qu’on met en place (à quelques exceptions près)
La direction s’est évidemment engagée sur une date de livraison auprès du boss, et on est confronté à ce genre de commentaire « A quoi bon un sprint goal ?? De toute manière, on n’ouvrira pas le système en prod, tant qu’il sera pas iso (fonctionnellement) avec le système actuel : donc il faut sortir tout le sprint backlog »
Je vous passe les joyeusetés contractuelles (plusieurs sociétés prestas avec des enjeux différents compliquant la transparence et la communication, des engagements en JH définis par avance etc.)
Normalement Scrum est plutôt adapté pour des projets « complexes » ?
Cette refonte implique des difficultés techniques car on met en place de nouveaux outils logiciels. Et bien évidemment, on besoin du feedback des utilisateurs car l’interface change.
Est-ce que pour autant ce projet est complexe ? Peut-être que la problématique se porte au niveau du contrat et de l’engagement contractuel, et que Scrum pourrait très bien s’adapter (même si effectivement, il faut que le périmètre fonctionnelle soit iso avec l’existant)
Avez-vous déjà travaillé dans ce type de contexte ? Quel est votre regard sur cette situation ?
Pour une refonte d’un produit, bien sûr que ça s’adapte bien. Même très bien ! C’est juste un peu complexe, donc parfait pour un cadre comme Scrum (qui n’aime pas trop la complexité forte… Scrum c’est vraiment bien quand c’est un peu complexe, justement).
Par contre, que Scrum ne soit pas adapté à un environnement qui s’en fiche, ça, oui. Et c’est l’impression que j’ai ici. Un contrat fort, un waterfall d’entrée, t’empêchera de faire ça. Et la volonté que ce soit ISO, pareil, ça casse toute l’idée de Scrum.
Prenons un exemple : un projet de refonte où les parties prenantes réfléchissent réellement à refaire presque à 0, en prenant juste une partie du périmètre vraiment critique du produit, d’aller voir les utilisateurs et de l’améliorer petit à petit… Ben oui, d’un coup, ça marche très bien non ?
EDIT : pour info j’ai travaillé dans ce contexte. Le premier truc que je challenge, c’est à dire « la croyance qui doit changer », c’est que « ça doit être ISO ». C’est faux. C’est jamais ISO, déjà. Et si c’est ISO d’y à 20 ans ça fait longtemps qu’il faut le changer réellement !
J’ai fait des projets de refonte et j’ai toujours combattu cette croyance. Elle tue les projets de refonte.
A force de réfléchir à la question, je commençais à tendre vers cette conclusion. Comme je le disais, étant donné qu’on se base sur de nouvelles briques logicielles, les parcours clients évoluent et on a besoin d’avoir de l’interaction pour savoir si ça répond bien aux besoins.
Hélas, les utilisateurs finaux arrivent tard dans la boucle de feedback, car la direction côté client veut optimiser l’activité de ses salariés et pas les « interrompre » dans leurs activités habituelles.
Et même la direction elle-même se rend très peu disponible, car ils ont « très peu le temps » (réunion sur le temps du déjeuner, ou très tôt le matin ou tard le soir)
C’est compliqué, ce n’est pas l’éclate et beaucoup de remise en cause personnel sur ma capacité à faire évoluer les choses …
Oui, clairement, si on mesure l’avancement au fait d’être ISO ça ne peut pas marcher.
J’ai mon lot d’exemples de projets de migrations de ce type qui ont bien foiré en Scrum.
Une des approches possible c’est de challenger la stratégie, pour passer d’un projet ISO solution à ISO besoin, et surtout le mode de mise en production, pour passer d’une approche que j’imagine aisément être big bang vers un déploiement incrémental via une strangler app par exemple.
Tant que le management verrouille l’approche en mode ISO solution tu ne peux rien faire directement. Il va falloir interroger les objectifs de la direction et tenter de faire évoluer leurs croyances, en espérant que tu aies un mandat approprié pour ça.
Je n’ai pas été clair dans mon message. En fait, on refait tout de A à Z, les produits (actuel vs nouveau) sont totalement indépendants techniquement : aucune adhérence entre les 2 systèmes.
Effectivement, je connaissais cette stratégie de déploiement incrémental mais pas l’expression de Strangler App, qui évite l’effet big bang avec une mise en prod progressive. C’est pratique, et ça peut être combiné à un système de feature flipping également, pourquoi pas.
Tu parles du management, et c’est bien là ma difficulté. Je n’ai pas de « sponsor », de personnes sur lesquelles m’appuyer… Je me sens un peu seul face à un mur, me renvoyant parfois à mes capacités de déclencher quelque chose en face
Le sponsor, c’est pour actionner le management, donc c’est plutôt pour la phase d’après.
La première étape c’est de comprendre le contexte, les croyances, et surtout les objectifs.
Pour ça il va falloir beaucoup d’écoute et de patience.
Et peut-être qu’au final ce dont l’organisation a vraiment besoin c’est de faire une migration en waterfall.
L’idée n’était pas d’opposer de manière binaire scrum et waterfall, mais plutôt de dire que quand y’a une incohérence entre les objectifs et la méthode, ce n’est pas forcément les objectifs qui sont en tort.
Elle file direct dans mes favoris.