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

Communauté Scrum Life
,
1

Bonjour ! :wave:t4:

J’ai changé de projet (ouf!) et de fonctions, et suis devenue P.O./S.M. * pour une petite équipe de 4 personnes (moi incluse) qui doit développer from scratch un outil logiciel pour un client.

Ce client, bien qu’il ait accepté/souhaité l’agilité, nous demande de livrer une V1 (leur MVP) à une date précise dans 3 mois. Le client a des impératifs liés au marché (hémorragie de clientèle, part s à prendre sur le marché rapidement, etc.) qui expliquent cette date limite, et ce besoin de pouvoir anticiper sur le moment de la mise sur le marché.

J’essaie de maintenir un semblant de Scrum dans notre fonctionnement, mais les 2 dév de l’équipe ont tendance à faire leur vie…
Par exemple, sans consulter personne, ils prennent des tickets qui étaient prévus pour le Sprint à venir, parce qu’ils sont bloqués sur les tickets du Sprint en cours; ils changent les titres des tickets; ils refusent de diviser en sous-tâches les tickets, disant qu’on gagnera du temps au moment de ‹ merger ›, s’il n’y a qu’une branche, etc.
Bref, ils font leur petite vie, avec, je sais, l’argument qu’on est pressé, et qu’il faut livrer cette V1 dans les temps. On fera du vrai Scrum plus tard…

Ca me prend assez la tête pour que j’aie réfléchi jusqu’à réaliser que je suis la seule de l’équipe à bien connaître Scrum. Il se peut que, notamment, il y ait un problème de connaissance de Scrum tout simplement.
Donc, OK, je vais leur montrer une petite vidéo pédago (à trouver sur Internet) qui expliquera non seulement le fonctionnement concret d’un Sprint Scrum, mais aussi les valeurs et piliers sous-jacents, le fait qu’on doive travailler ensemble en se respectant, en se consultant, en se coordonnant.

J’ai aussi une petite liste d’arguments pour défendre ma vision des choses :

  • Diviser les tickets en sous-tickets fait peut-être perdre du temps au moment de merger, mais permet, en cas de bug, de n’avoir à intervenir que sur une partie du code = pour la maintenance ultérieure, ça semble mieux.
  • Diviser les tickets en sous-tickets permet aussi au business et à moi (je ne suis pas technique) de comprendre ce qu’on fait et où on en est.
  • Se consulter avant de rebaptiser un ticket permet de se mettre tous-tes d’accord sur son nom, afin qu’on sache tous-tes de quoi on parle.
  • Fonctionner dès maintenant comme en Scrum, alors qu’on a une deadline comme en waterfall, permet de prendre de bonnes habitudes de travail (on ne fera probablement pas de Sprint review et on ne livrera probablement pas d’incrément à chaque fin de Sprint, avant la date de livraison espérée de la V1, mais on peut planifier les Sprints, se voir en Dailys, et … collaborer!)

Avez-vous d’autres billes à partager avec moi pour m’aider à convaincre les dév qu’il est préférable qu’on prenne un peu de temps pour se coordonner, pour raffiner les tickets pour qu’on y voie clair?

Merci d’avance à tous-tes! :pray:t4: :slightly_smiling_face:

*Oui, on m’a collé les deux casquettes. Je suis laissée en dehors des tractations contractualo-financières entre ma boîte et le client, mais j’imagine que c’est plus facile de vendre une ressource polyvalente :wink: Et il est vrai que l’équipe est petite pour l’instant.

2

C’est compliqué de te répondre, car sans connaitre les tenants et aboutissants, et juste avec ta version, si je te donne un conseil je ne sais pas ce que ça peut donner. Je vais quand même essayer plutôt avec des hypothèses à tester.

A ta place, ce que je ferais, c’est plutôt que de parler de Scrum et d’Agile, j’essaierai de faire du Product Management de mon côté, d’abord :

  • Vérifier et revoir le périmètre souvent avec le client. Il y a sûrement un travail à faire là dessus, et si j’étais toi je mettrais aussi mon énergie dessus.
  • Et ce qui en découle, découper fonctionnellement, sur de plus petites livraisons. Pourquoi pas faire un Story Mapping, si ça n’est pas déjà fait, avec toute l’équipe et le client ? Avec dans l’idée de rendre tout ça plus clair pour tout le monde ?

Sur la partie orga :

  • Sans connaitre les devs, juste attention à un possible passif. Beaucoup de devs ont vécu du Scrum bullshit, donc vérifier leur avis dessus.
  • Comme tu n’es pas technique, les devs risquent tout de même de faire ce qu’ils veulent sans contrainte, même en découpant en sous tâche (car ils peuvent découper d’une manière où tu ne comprendrais quand même rien :confused: )… Aurais-tu au moins un allié dans l’équipe ? Si non, comment en avoir au moins un ?
  • Faire une retro sur les règles de fonctionnement dans l’équipe, et clarifier au moins un peu plus qui fait quoi, en mettant aussi tes problématiques en avant.
  • Pour que les devs te suivent, outre mettre en place des contraintes, il faudrait qu’ils y voient un intérêt. Donc quel intérêt auraient-ils à être embarqué là dedans ? Faire attention à la perte de pouvoir et de contrôle des devs, qui ont l’air bien planqué dans leur façon de faire, (perte d’autonomie / de liberté en passant en Scrum ?) de ce que je lis.
2 « J'aime »
3

Merci pour tes conseils @BenjaminF :pray:t4:

J’ai oublié d’indiquer que le client sait précisément ce qu’il veut dans sa V1. Nous avons déjà une liste de User Stories qu’il nous a fournie.
Autrement dit, nous avons déjà un objectif, des fonctionnalités précises, une date précise de livraison.
(Je pense quand même demander aux stakeholders si ce choix de cette V1 est une décision mûrement réfléchie, ou si c’est une décision prise dans l’urgence pour stopper l’hémorragie de clients de leur outil actuel vieillissant et dépassé par la concurrence. Mais même dans le cas n°2 -décision « panique »-, je crains qu’on ne puisse partir sur de l’Agilité qu’à partir d’après la livraison de cette V1).

J’ai fait un story mapping pour prioriser les US que le client nous a demandé de développer pour sa V1. Seule, parce que dans un premier temps, le client nous imposait une deadline ahurissante * (nous avions 2 mois pour livrer, en partant de quasi rien). Tout devait donc être fait très très vite!

*Deadline que j’ai réussi à négocier pour avoir 2 mois de plus.

Important : nous sommes tous-tes en full-remote. Rien ne peut être éclairci hors des visio-conférences.

Je pense réunir l’équipe au plus tôt pour parler de ce problème de manque d’alignement entre nous. Mais tu as raison, la rétro serait le moment idéal théoriquement pour en parler.

Effectivement, il faut que je puisse justifier de mon besoin de coordination et de collaboration auprès des dév. Et c’est le sujet/motif de ma publication.
Mon problème principal, c’est la crainte de notre désorganisation, qui rendra les choses peu claires pour moi et pour les stakeholders, et qui risque si elle s’installe, de devenir irrémédiable.
En bonus, il y a le fait que je ne serve à rien en tant que PO si chacun fait sa vie, mais ça, je conçois que ça ne soit pas un argument assez solide, puisque l’objectif c’est de fournir au client un produit qui lui apporte de la valeur, et que mon utilité, tout le monde s’en fout (sauf moi) :wink:

Merci encore pour ta contribution, ça m’aide bien à réfléchir ! :pray:t4:

4

Quelques petites remarques ; comme Benjamin c’est basé uniquement sur ton point de vue et uniquement sur les aspects que tu présentes, donc ça vaudra jamais un vrai accompagnement.

Le fait d’avoir une deadline n’est pas du tout un aspect de waterfall.

La base de Scrum c’est de cadrer une démarche agile (c’est-à-dire dans laquelle on bascule entre des tâches marketing, de conception, d’implémentation et de déploiement de manière désordonnée - par opposition à un waterfall où ces activités sont séquentielles) par un cadre temporel, le sprint : « on travail sur la feature F12 pendant 1 semaine ».

La deadline peut être un support plus qu’une gêne. Ce qui pose fondamentalement problème c’est l’absence de feedback pendant ces 3 mois. C’est beaucoup trop long. Et surtout, vous risquez d’avoir des mauvaises surprises au bout de 3 mois si vous vous rendez compte que - par exemple - vous avez oublié d’implémenter les fonctionnalités nécessaires pour faire payer des licenses à vos utilisateurs …

Donc il est au contraire super important de bien faire du Scrum dès le départ, et de considérer que tout sprint doit pouvoir partir en production. Quitte à utiliser des proxy-client dans vos review.

Cela dénote un problème d’autonomie de l’équipe. Il faut en parler en urgence avec le sponsor du projet, tu ne peux pas engager ta responsabilité sur un fonctionnement avec autant d’enjeux et des délais aussi courts si la réalisation du travail dépend de tiers qui peuvent vous bloquer. Au vu de la situation globale que tu semble décrire, ça devrait se dénouer rapidement, sinon c’est que l’organisation pour laquelle tu travailles ne veut pas vraiment se sortir de l’ornière et elle n’aura que ce qu’elle mérite.

A moins d’utiliser un flow complexe et coûteux - ce qui ne serait pas cohérent avec la taille de l’équipe, du produit, et de son cycle de vie - cette affirmation est plutôt erronée. Les branches permettent un découpage temporel du code. Ca permet de comprendre comment et pourquoi on a écrit une ligne de code plutôt qu’une autre, et de travailler en équipe de manière asynchrone plutôt que synchrone.

Mais pour la résolution de bug, ce qui compte c’est le découpage logique (éviter de mettre une fonctionnalité dans plusieurs fichiers ou de mettre plusieurs fonctionnalités dans un même fichier). Là-dessus, j’ai une mauvaise nouvelle : les meilleurs pratiques de développement ne sont pas toujours les plus répandues :frowning:

Et là, c’est pas ton boulot de pouvoir critiquer et les guider (de toutes façons si tu n’es pas technique tu n’as pas les compétences pour le faire). Par contre avec ta casquette de SM, il est important de voir comment ils se positionnent en terme d’ouverture d’esprit, et l’effort qu’ils font pour s’améliorer, aller cherches des nouvelles pratiques, rencontrer des experts, se former, etc … Cependant, c’est là aussi que ta casquette de PO peut venir gêner leur croissance, parce qu’il faut livrer, livrer, liver … C’est pour ça que Scrum recommande un non-cumul mais tu le sais déjà :slight_smile:

Quel est ton avis critique sur le nommage et la rédaction des tickets / PBI ? Sont-ils bien exprimés dans l’espace du problème et non celui de la solution ? Ce qui est important et souvent mal fait dans du scrum bullshit c’est ce cloisonnement entre :

  • les PBI du product backlog, décrits dans l’espace du problème. Ils sont la chose du PO, donc pas renommé/modifié sans son accord ;
  • les tâches du sprint backlog, décrits dans l’espace de la solution. Elles sont la chose des devs, et ne servent pas à mesurer un avancement mais à se répartir le travail en équipe.

Normalement, on prend un PBI du PB et ça devient le sprint goal du sprint. De là l’équipe constitue son sprint backlog initial, avec une série de tâches à accomplir. En suite, chaque jour en mêlée quotidienne, on discute de l’opportunité de modifier le sprint backlog, c’est-à-dire ajouter, modifier ou supprimer des tâches, et non pas seulement suivre un avancement.

En pratique, beaucoup d’organisation font une conception technique sans s’en rendre compte, et expriment les « besoins » sous forme d’une solution. C’est le classique cahier des charges. Donc on a au final des gens pas techniques qui font une conception technique et qui demandent à des ingénieurs d’implémenter leur solution, et sur qui on tape si le problème n’est pas résolu, même si l’implémentation est conforme à la spécification qu’on leur a imposée.

Mode cynisme on : franchement, qu’est-ce qui pourrait mal se passer ? et pourquoi les développeurs font leur susceptibles et démissionnent pour un oui ou pour un non ?

Plus sérieusement, si tu parles de sous-découpage, est-ce que ton organisation n’est pas tombée dans ce travers ? C’est en général parce que le PBI est exprimé dans l’espace de solution qu’on ressent le besoin de le détailler (au sens culinaire du terme). La solution décrite dans le PBI devient un fin en soi au lieu d’être un moyen pour résoudre un problème, et c’est là qu’on retombe dans un waterfall, à l’issue du quel vous aurez une implémentation du produit conçu initialement et non une implémentation qui rend service aux utilisateurs.

1 « J'aime »
5

Je ne suis pas favorable à l’objectif que tu te donnes. Je te conseille d’être plutôt dans une démarche de découverte de pourquoi les gens font ce qu’ils font tout en acceptant qu’on ne peut probablement pas tout identifier ni tout comprendre. Dans un système complexe, il faut éviter d’imposer une cible.

Je te propose deux clés de lecture. La première et les 3 A :

  • agentivité : Qui peut faire quoi ? Qui peut imposer quelle contrainte ?
  • affordances : Quelles actions sont suggérées ou facilitées par l’environnement ?
  • agencements : Que disent les gens ? Quels sont les schémas narratifs qui s’installent ?

Notamment, quelle est ton agentivité ? Il n’est pas question de convaincre, si tu peux leur imposer de ne pas travailler sur les tickets du sprint d’après. Quelle est l’agentivité des devs ? J’ai un peu l’impression que votre manager n’a pas pris la peine de bien établir vos rôles respectifs dans l’équipe. A toi de signaler les dysfonctionnements, les risques et le manque de moyens pour y faire face.

La deuxième clé de lecture est l’atelier Futur à l’envers (exemple de facilitation), à ne pas confondre avec Remember the Future. Dans l’atelier Futur à l’envers, on décrit le présent, on explore les événements antérieurs qui ont contribué à construire le présent, puis on imagine deux futurs impossibles (et j’insiste sur impossible) : l’un utopique, l’autre dystopique. On peut éventuellement finir par imaginer les événements qui auraient pu produire cette utopie et cette dystopie si l’on avait fait d’autres choix dans le passé, des sortes de timelines alternatifs du multivers. A la fin, cela peut aider une équipe ou plusieurs à mieux percevoir les risques, les appétences et les craintes. Si tu arrives à mieux comprendre les craintes des devs, cela te donnerait peut-être des idées qui leur seront plus utiles.

2 « J'aime »
6

Bonjour Charlotte, je me permets d’intervenir entre deux réponses que je trouvent très constructives, il me reste à lire celles de Adrien.

Mais, en réalité, au delà du sujet initial et en cours, ton paragraphe ci après m’interpelle ou m’alerte dans mon projet en discussion.
Dixit :
"Mon problème principal, c’est la crainte de notre désorganisation, qui rendra les choses peu claires pour moi et pour les stakeholders, et qui risque si elle s’installe, de devenir irrémédiable.
En bonus, il y a le fait que je ne serve à rien en tant que PO si chacun fait sa vie, mais ça, je conçois que ça ne soit pas un argument assez solide, puisque l’objectif c’est de fournir au client un produit qui lui apporte de la valeur, et que mon utilité, tout le monde s’en fout (sauf moi).

Le role PO n’est pas de se charger plus de la vision produit plus que de la gestion équipe ?

Je parle franco ne connaissant pas encore le métier à 100% et te laisse libre de réponse.

Merci à vous tous pour vos échanges et courage à toi Charlotte.

J’ai hâte de lire ton témoignage de réussite projet. :smiling_face:

1 « J'aime »
7

Au passage je découvre deux ateliers très proche de ce que je fais déjà, mais ça met des mots dessus, le 3A et surtout le Futur à L’envers très proche d’un réflexe professionnel que j’ai déjà sur la peur en accompagnement.

Donc merci beaucoup, je les mets dans mon KM perso !

8

@ArwynFr

D’accord. Effectivement, le dév’ c’est bien trop obscur pour moi pour pouvoir me positionner, mais je pensais qu’il y avait une étape dans le dév’ où le code n’est pas encore mergé dans une seule branche, et pendant laquelle, du coup, il était encore temps de fixer des problèmes, par petits morceaux, sur chaque petite branche. Bref. Effectivement, je vais faire confiance aux dév’ pour choisir la meilleure façon de faire.

Concernant le mode de fonctionnement dans lequel on est, merci de m’avoir aidée à ouvrir les yeux : je crains que ce soit mon manque d’expérience et d’expertise qui parle… :roll_eyes:
Spontanément, une liste de fonctionnalités imposée et une deadline imposée, étaient pour moi le signe qu’on n’est pas en mode Agile. J’associais Scrum et l’agilité à la créativité/recherche de solutions.
Alors qu’en effet, on peut fonctionner en Scrum même avec une liste toute prête de features et avec une deadline (l’essentiel étant de pouvoir réagir vite si on s’aperçoit qu’on fait fausse route).

Merci aussi pour ces notions de problème et de solutions! (dont je ne me servais pas jusqu’ici!) Ca m’aide à envisager des méthodes pour qu’on s’y retrouve tous-tes : les dév et moi, la PO, notamment dans la gestion de nos tickets dans notre Gitlab.

Par contre, je n’ai pas bien compris ce passage : « La solution décrite dans le PBI devient un fin en soi au lieu d’être un moyen pour résoudre un problème, et c’est là qu’on retombe dans un waterfall, à l’issue du quel vous aurez une implémentation du produit conçu initialement et non une implémentation qui rend service aux utilisateurs. » …

9

Eh bien, dans mon contexte, j’ai deux casquettes (mauvaise pratique, mais on est une petite équipe, et j’imagine que c’était difficile pour mon management de justifier que le client paye pour 1 SM et 1 PO, pour seulement 3 dév - 2 tech & 1 designer…).

Donc, je suis concernée un peu par tout, y compris la gestion/coordination de l’équipe.

Je suis censée prioriser le travail, en tant que PO. Si les dév se servent à volonté dans le Product Backlog, au motif de l’urgence à agir, je craignais que ça mette le bazar dans notre organisation. Mais, grâce à cet espace d’échange ici, et notamment aux conseils de @ArwynFr , je me rends compte que les dév’ se contentent de manipuler des tickets qui les concernent = ceux qui sont les « enfants » des miens. Donc, des items « solutions » par opposition aux miens qui sont les items « problèmes ».

10

Je suis d’accord avec toi et avec @BenjaminF : plutôt que flipper sur ce qui m’évoque un début d’ « anarchie », je vais essayer de comprendre comment les dév appréhendent Scrum et l’Agilité, et … leur faire confiance! (c’était le cas 100% au début - on a commencé il y a 1 mois seulement- mais je sens une réticence à l’égard de … mes fonctions? moi? le travail non-dév en général?).

Merci pour tes conseils! :pray:t4:

11

Je comprends tout à fait. Étant donné que tu as le rôle interface stake holder et dev team. Néanmoins, je 'e considère pas que le rôle de coach soit de ton ressort.

C’est aussi à ton organisation de convenir avec le client vis à vis des ressources à prendre compte pour épauler l’équipe Scrum.

Ceci dit, d’après ce que je comprends, ce n’est pas forcément le cas, et l’équipe peut être pluridisciplinaire n’est pas encore disposée à se projeter dans ce sens.

Essaye de voir avec ton organisation je pense.

Comme tu as la casquette Scrum Master et que tu as le devoir d’éloigner les obstacles. Ça devient alors un bon exemple n’est ce pas ?

12

Le client râle depuis le début et nous met la pression. Il semble considérer qu’on n’est pas assez rapides (et j’imagine qu’on est trop chers, même si notre management cloisonne et m’exclut des tractations financières).
Autant te dire que malgré ma nature optimiste, je ne crois pas beaucoup dans la possibilité qu’on nous ajoute une ressource à ce stade…
Mais tu as raison, je garde ça en tête pour après la livraison de la V1, si l’équipe s’agrandit par exemple… :crossed_fingers:t4:

13

C’est une possibilité offerte par l’outil de faire des branches par fonctionnalités. Mais il y a deux limites à cela :

  • Individuellement ou en sous-équipe, chacun travaille sur sa feature. On ne joue plus au rugby mais au golf. C’est une technique qui a du sens si on a un contexte dans lequel on a plusieurs scrums sur le même produit et chaque équipe sa branche ;

  • C’est vrai tant qu’on n’a pas mergé, mais les bugs ne se trouvent pas dans cette phase. Car tant qu’on n’a pas mergé, ce n’est pas vraiment le code du produit, juste un brouillon en attente d’intégration. Si on peut s’y retrouver après la fusion, alors on peut s’y retrouver avant. L’inverse n’est pas vrai.

Je te donne un exemple : pour les fêtes, ma famille organise - comme beaucoup d’autres - des festivités auxquelles je suis convié, et pour lesquelles je me déplace généralement avec une voiture de location.

Si le PBI est rédigé sous la forme « louer une Peugeot 208 », ça devient l’objectif. Du coup, si je me présente à l’agence de location et qu’ils n’ont plus ce modèle, mais qu’on me surclasse avec une Mercédès ou une Lexus, et bien l’objectif n’est pas atteint. Je devrais être très mécontent. De même, si on me donne une Peugeot 208, mais avec des problèmes de freins, le réservoir vide, le chauffage cassé, et une carrosserie douteuse, je devrais être content parce que l’agence de location a mis tout en oeuvre pour me fournir le modèle que j’ai demandé.

Ca c’est parce l’agence de location a considéré que l’objectif à atteindre c’était le modèle demandé (solution), au lieu des conditions de confort et de sécurité de mon trajet (problème). Au final je vais juger la prestation très durement, ce qui va provoquer une réaction de dégoût chez le prestataire, qui a pourtant réalisé des efforts surhumains pour me fournir exactement le modèle demandé malgré tous les obstacles qui se sont dressés sur sa route.

Quand le sage désigne la lune, l’idiot regarde le doigt.

14

C’est le passage « et c’est là qu’on retombe dans un waterfall » que je n’avais pas compris. (Mais merci pour ton exemple, très parlant, qui pourrait m’être utile).
Le travers que tu décris serait typique de Waterfall, si je te suis bien.

15

De rien, mais le but n’est pas forcément de faire confiance, plutôt d’accepter que tu ne connais pas tous les tenants et aboutissants de la situation et d’éviter de tomber dans une erreur fondamentale d’attribution. Ca se trouve les devs ont tort de faire comme ils font actuellement. Egalement, ça se trouve que tu as tort de proposer Scrum. Evitons le manichéisme.

2 « J'aime »
16

Je trouve cette citation horriblement condescendante.

3 « J'aime »
17

Et on ne sait pas bien qui elle vise, mais j’avoue l’avoir prise pour moi… :no_mouth:

18

Hello

Je parle en tant que dev

A force de vouloir « gérer le projet » tu vas juste les perdre, il vont en avoir marre et vous demander a changer de projet

Le rôle du Pô et de donner des tâches/de dire voilà ce qu il y a a faire et tenez moi au courant

Si tu veux faire du scrum : participe au daily et faire en sorte de voir où ça avance

Le po/scrum n est pas là pour diriger … Mais plus pour cadrer ( bien comprendre la différence :slight_smile:

En te lisant je comprends que tu veux diriger : laisse faire … Ils y arriverons très bien et savent comment faire

Vois toi comme l interface entre le client/dev : c’est déjà assez compliqué :slight_smile: faire en plus du management de tâches, c’est le rôle entre les dev qui se mettent d accord

Voilà voilà

19

Si seulement c’était aussi simple, on ferait du cycle en V.

Ce n’est pas toujours vrai.

2 « J'aime »
20

Je ne sais pas ce que j’ai dit qui laisse à penser que je veux diriger… :thinking: Total malentendu…
Je crois dur comme fer dans l’intelligence collective et la collaboration.
J’adhère 100% à l’esprit Scrum d’horizontalité, où on travaille tous-tes ensemble, avec chacun-e des « redevabilités » mais aucune hiérarchie.
Et je pêche plutôt par excès de démocratie que l’inverse : j’ai tendance à inciter tout le monde à se mêler de tout, et c’est là qu’en effet, je te rejoins, il y a un risque de démotiver les dév : la plupart préfèreraient qu’on leur dise quoi faire, et qu’ils s’en débrouillent… C’est là-dessus que je dois être vigilante, et je te remercie de ta remarque qui m’y fait réfléchir.

Cependant, le souci de laisser s’installer un fonctionnement incontrôlé, où chaque dév modifie les tickets à sa guise, c’est que je risque de ne plus rien y comprendre, et le business non plus.
Cet argument-là suffit.

D’ailleurs, depuis que j’ai publié ce post, j’ai pu m’en expliquer avec l’équipe qui semble avoir bien compris : on a repris les tickets qui avaient été rebaptisés pour en rendre la description cohérente et compréhensible par tout le monde.

Merci pour ta contribution, en tout cas! :pray:t4:

1 « J'aime »