Je suis confronté à la situation suivante et aimerais vos avis/conseils :
L’entreprise a déjà un service numérique bien en place, desservi par plusieurs logiciels à disposition des utilisateurs. La phase « Discovery » n’existe donc pas vraiment, ou du moins, moins qu’un nouveau soft à construire de A à Z.
L’équipe enchaine régulièrement entre des phases de projets « moyens » : de 2 à 6 mois pour sortir une ou plusieurs nouvelles features sur un des softs existants et des phases de maintenance applicative et évolutive.
Est-ce qu’une alternance entre une orga Scrum durant les phases de projet et une orga Kanban dans les phases de maintenance est envisageable pour la même équipe ? Avez-vous déjà rencontré ce genre d’orga ?
Quand l’un commence, quand l’un termine ? Le support s’arrête pendant la phase d’évolution du produit ?
Pourrais-tu tout gérer en Kanban ? Qu’est-ce qui t’empêche de continuer en scrum ?
N’as-tu pas 2 produits : un produit logiciel et un produit de support ? Quelle est la taille de l’équipe ?
Peut-elle être divisée en 2 ?
Est-ce le syndrome du « On envoi de la feature pendant 6 mois et ensuite 3 mois de bugfix avant la release parce y’a rien qui marche », Ou bien sont-ce des phases imposées par une norme/contrainte quelconque ? (aéro, industriel, médical, …)
J’ai eut une fois le cas d’un projet géré en Kanban au début puis migré en Scrum. Il s’agissait d’un projet de recherche, avec une phase d’état de l’art et une phase d’industrialisation. On avait commencé en Scrum, mais les story était très artificiel : « As a scientist, I want to read this paper in order to decide if method is interesting ». Bref, impossible de définir des incréments produit. On est passé sur une approche Kanban timeboxé, avec Go/NoGo en fin de ticket.
Lorsqu’on a eut un proto à peu près viable, on est repassé en Scrum avec des story plus orienté feature.
@Samuel_Abiassi c’est généralement le PO qui check l’impact des nouvelles features
@MDO Yes, on va justement tester une scission de l’équipe en 2 flux de travail distincts, on va voir ce que ça dit Les itérations sont plus devenues une contrainte administrative qu’une vraie valeur : on reprend toujours les tâches entre sprint, y’a pas de vision produit, du stock s’empile, des tâches en recette ne sont jamais livrées …Donc l’idée de Kanban serait de retirer cette pression des sprints pour les PO le temps de « souffler » et d’avoir le temps d’établir une vraie stratégie produit
@Tan Nope, pas de contrainte particulier, c’est surtout que la PO n’a pas le temps de faire la Discovery/Build car elle est beaucoup trop prise.
C’est pas vraiment le propos. Ce que je voulais souligner, c’est surtout que l’output d’une User Story, elle provient de l’User, pas de l’équipe. Une US écrite sans jamais avoir rencontré un User n’est qu’un mensonge sur lequel on a mis une étiquette pour faire bien.
