P.O. a besoin d'arguments pour convaincre dévs de rester en Scrum -

J’arrive après la bataille et j’imagine que tu as pu avancer sur ta problématique.
Merci @Charlotte pour tes retours d’expérience qui permettent à chacun ici de phosphorer sur la réalité, et pas des cas stéréotypés « by the book ».
Ce qui me surprend, c’est alors que la première des 4 valeurs du manifeste agile est d’accorder de l’importance « aux individus et leurs interactions plutôt qu’aux processus et aux outils », dans la plupart des RETEX qu’on peut lire sur ce forum et d’autres, on y parle d’abord des processus et des outils.
Ne le prends pas mal, mais, j’ai pourtant pris la peine de lire tous les messages de cette discussion, et au final, nous n’en savons toujours pas beaucoup plus sur les entités désignées sous le terme de « devs ». C’est pourtant par là qu’à mon avis tu aurais dû commencer. Leur parcours, leur historique avec la société, leurs attentes. As-tu fait une ébauche de profil DISC avec ces personnes ? Avant de trouver des arguments, encore faut-il les comprendre, à mon humble avis (et expérience).

1 « J'aime »

Convaincre et pas imposer, c’est déjà un très beau verbe…
Mais attention, c’est donner le droit à l’autre de refuser.

Selon moi, le défi, c’est qu’ils arrivent à s’en convaincre eux-mêmes.
Et donc ce qu’il faut, c’est leur apporter ces moments de doute, d’inspection qui vont les faire sortir d’eux-mêmes ce qu’il est nécessaire de changer.

Mes réactions à chaud quand je vois ça c’'est

PO et SM en même temps, bof
Ah mais vous n’êtes que 4. Ok Scrum est peut-être overkill.
Si ce sont des « devs » au sens « programmeurs » qui n’ont pas envie de s’occupe de l’aspet market, passer par l’étape « fondation » de scrum => l’excellence technique. Scrum n’en parle pas parce que c’est un prérequis.

Une approche telle que eXtrême Programming pourrait probablement plus les embarquer.
Extreme programming — Wikipédia.

Une autre activité pour provoquer la discussion c’est de faire un team canvas. Normalement ca se fait avant de se lancer, mais ça n’est pas grave, ça peut-être bénéfique de le relire pendant l’aventure, quitte à ce que ce soit d’enfin le formaliser.

Une activité qui peut être chouette c’est Combattez l’Agile Bashing : optez pour le serious game Agile Smells !!

Pour ces temps de discussion, j’ai l’impression que l’utilisation des 6 chapeaux pourraient être facilitatrice : A un instant T, tout le monde parle avec le même chapeau.

Et encore un autre outil pour discuter avec eux :
Le Health Checks for Agile Teams

« Tenter de visualiser le niveau »
=> On ne juge pas le niveau, on veut juste le constater
=> Face aux indicateurs, ils vont s’interroger sur la raison d’être de ces indicateurs et ouvrir l’esprit sur d’autres angles de vision.


Est-ce qu’ils savent mesurer ce gain annoncé ?
Note, l’important étant de finir les tickets (réellement finir), la découpe en tâche leur appartient.

1 « J'aime »

Il faut faire comme en Belgique. La pression, on ne la subit pas, on la boit.

1 « J'aime »

Salut Maxime,

Oui, ça a avancé : on est beaucoup plus coordonné-es et organisé-es, merci pour ton intérêt! :slight_smile:
Mais, il me faudrait du temps que je n’ai pas, là, pour analyser les causes de ces progrès…
Tout de même, j’aurais tendance à penser que la « deadline de fou » a été une des causes du bazar du début.

Je retiens le profil DISC, merci! :pray:t4:

Merci pour toutes ces pistes!
Cependant, je ne sais pas comment/quand je serai en mesure de les utiliser. Depuis le début de ce projet, (3 mois, maintenant), je croule sous les tâches diverses et je fais des dizaines d’heures supp’ pour éviter la noyade… :roll_eyes:

Je les garde de côté, merci encore :slight_smile: