Trouver un poste de P.O. ou S.M. sans background technique ? Freelance ou full remote -

Communauté Scrum Life
,
1

Hello les collègues !

Je suis la preuve qu’on peut se faire recruter comme S.M. sans background technique, puisque j’ai eu la chance d’être embauchée comme telle, et, en plus, en full-remote (qui n’est finalement pas un cadeau, comme on a pu en parler sur un autre fil, mais c’est ce que je voulais à la base = je m’estime chanceuse).

Mes employeurs actuels refusent de me laisser partir m’installer à l’étranger : ça leur créé des responsabilités légales à mon égard dont ils ne veulent pas, d’une part, et d’autre part, ils s’étaient engagés auprès du client, pour avoir un-e S.M. française et en France.

Pour des raisons personnelles, j’ai vraiment besoin de pouvoir m’expatrier hors U.E. (l’an prochain, par exemple).

Je commence à regarder les petites annonces d’offres d’emploi comme S.M. ou P.O. (je vais bientôt passer ma certif PSPO 1, et je suis -presque- sûre que ce job là me conviendra mieux : analyser, reformuler, traduire, transmettre, réfléchir, chercher, j’aime et je sais faire).

Et, comme d’habitude, je vois que les boîtes cherchent des P.O. ou des S.M. avec des backgrounds techniques…

J’ai bientôt 1 an d’expé en tant que S.M., je suis certifiée PSM 1, bientôt PSPO 1, plein d’expériences dans des domaines divers (hotellerie, tourimse, administration, animation, éducation).

Pensez-vous que j’ai mes chances de trouver un job en tant que Freelance (même s’il faut casser mon prix) comme SM ou PO ?
Freelance, parce que ça semble un moyen de pouvoir m’installer où je veux sans avoir de compte à rendre…

Vos avis?
Vos témoignages ?

Merci d’avance !

1 « J'aime »
2

En fait, il existe bien plus de SM sans background technique que le reste, de mon expérience. Dans ma nouvelle boite, on a recruté une SM qui n’a aucune xp technique (jamais codé). Par contre, des POs non techniques, j’en vois de moins en moins.

Côté freelancing, sûrement que tu peux. Mais à 1 an d’xp, ce sera faisable mais difficile. J’ai commencé en freelance SM avec 0 xp, juste mes connaissances en gestion de projet et mon envie de faire du produit il y a maintenant 9 ans de cela, et ça a marché ! Faut surtout montrer ton xp dans les divers domaines.

Et j’encourage tous les SM personnellement à au moins apprendre à coder, ne serait-ce que pour augmenter facilement son empathie / se mettre à la place des devs. Apprendre les bases, au moins. The Odin Project est un bon moyen en open source de l’apprendre. J’ai appris le dev après être passé SM, personnellement, et c’était un de mes meilleurs investissements :wink: (même si j’étais algorithmicien avant…)

1 « J'aime »
3

C’est vital dans ma vision des choses. Notamment parce qu’une personne ayant pour focus l’amélioration du processus d’une équipe sans savoir ce que l’équipe fait/pourrait faire, ça me paraît sous efficient en l’occurrence.

1 « J'aime »
4

Bonjour @BenjaminF, merci pour avoir mentionné et donné l’information du projet Odin pour les scrum master qui veulent mieux comprendre les développeurs. Je vais commencer une mission de scrum master en janvier ;).

2 « J'aime »
5

Pour le SM seulement : Je pense (et j’en suis sûr) que le SM ne doit pas avoir de connaissance technique afin de ne pas être pollué par ses connaissances. Quand j’arrive dans une équipe, je dis clairement que je ne veux connaitre ni le métier ni la technique. J’explique en revanche que je suis là pour les aider et leur fournir tous les outils et tous les moyens nécessaires à la recherche des causes des pb, la recherches des solutions possibles et la mise en place du plan d’action ; jamais je propose une solution technique ; je leur dis simplement s’ils ont fait le tour de toutes les possibilité… (outil 5M, 5 pourquoi, Muda, …) En effet, dans l’équipe il y a des experts techniques, des experts fonctionnels, des experts DevOps, des experts en sécurité, des experts réseau, des experts UX ; moi, dans tout ça, je ne suis qu’un petit expert du framework Agile ; que ce soit scrum, kanban, à l’échelle ; et mon objectif, c’est de leur transmettre tout ça pour que l’équipe devienne autonome.
Et en fait, c’est bien mieux comme cela car aux SM de changer facilement de client, d’équipe, de pays, de techno, … la liberté en fait :wink: idéal pour un freelance.
Pour le PO, c’est différent, il doit connaitre le contexte métier et pas de technique car il exprime un besoin et l’équipe apporte les solutions ; le PO doit connaitre l’agilité, comme chacun des membres et c’est là l’un des rôles du SM.
Je ne développe pas ici la notion de remote qui est un sujet à part entière qui concerne chaque memebre d’une équipe ; comment travailler ensemble. Juste, je fais référence à la matrice de Grudin pour bien montrer le domaine des possibles entre l’espace et le temps.
Désolé de la longueur du texte mais c’est un vaste sujet !

1 « J'aime »
6

Je n’ai absolument pas la même croyance que toi. Ce n’est pas toujours le cas ! Un SM peut ou ne pas savoir coder, ça dépend énormément du contexte. J’ai accompagné avant une équipe qui a souffert du manque de connaissance technique du précédent SM, qui n’arrivait juste pas à parler le langage des devs, et la confiance s’est effritée. Pourtant, il est « excellent » en tant que SM, de mon point de vue.
Connaitre la technique, de mon expérience, te permet d’aller un cran encore plus loin dans l’amélioration continue. Je rappelle qu’à l’époque, c’est le manager technique à Toyota qui est responsable de coacher dans le PDCA… Dans XP, c’est le coach qui est aussi technique… Je continue ? :wink:

Ce n’est donc qu’un débat de croyance, mais de mon expérience qui façonne mes croyances : tu peux aller encore plus loin en connaissant la tech. Faut juste rester en posture basse le plus possible. Les meilleurs coachs agiles que j’ai vu sont un peu techniques et sont experts en posture basse, clairement !!

Par exemple, je fais quelque chose d’unique en général quand j’arrive dans des équipes : je leur fais se faire un diagnostique ET je leur propose un audit de ma part. Pour moi, les deux sont deux facettes importantes, pour limiter les biais de groupe. Et pourtant, sans connaissance technique minimes, courage pour faire un audit des techniques de codes de l’équipe (l’excellence technique renforce l’agilité).

7

Heureux de voir ton point de vue très intéressant qui parle davantage de coach tandis que d’autres parlent de Lead Tech, Lead QA, Lead XXX que tu peux solliciter ponctuellement pour aider l’équipe. J’aime bien le lean surtout la partie qui dit que la connaissance est chez ceux qui font et que ce sont eux qui peuvent apporter les solutions pragmatiques ; j’aime bien aussi l’histoire de Jean-François Zobrist qu’il raconte dans son livre « L’entreprise libérée ».
En revanche, je te rejoins sur le fait d’augmenter la compétence de l’équipe en leur apprenant comment.
J’ai beaucoup aimé également l’expérience de Jean-Christophe qui a aidé des équipes à développer un magasin en Scrum et là on n’était pas dans du code …
Débat très instructif en tout cas, merci Benjamin.
J’espère toutefois que l’on n’embrouille pas trop Charlotte pour trouver son poste :wink:

2 « J'aime »
8

J’ai vu un scrum master (un peu technique) qui n’identifiait pas certains problèmes car il ne comprenait pas ce qu’on se disait, car pas assez technique. A ce moment comment est-ce qu’il peut aider l’équipe si il n’identifie même pas les problèmes?

Comment avoir une posture de facilitateur si tu ne comprend pas les tenants et aboutissants d’un sujet?

Comment est-ce que tu peux être un exemple une inspiration si tu n’arrives mêmes pas à imaginer des solutions pertinentes? Je ne dis pas trouver la solution à implémenter mais juste montrer l’exemple en montrant qu’il y a surement plein de solution différentes. Car très souvent les développeurs sont jeunes et inexpérimenté, même si ils trouvent des solutions par eux-mêmes il se peut que ca soit loin d’une solution pérenne et optimal.

Combien de conception fonctionnelle ont planté un projet car réalisé par des PO qui ne comprenne le concept d’architecture microservice?

Etc…

Un Scrum Master technique n’est pas un handicap si tu reste en posture basse. Un Scrum Master non technique est un handicap si tu n’arrives pas à identifier les problèmes, comprendre le contexte, communiquer avec l’équipe.
Les 2 profils sont envisageables, mais dire qu’il faut être incompétent dans un domaine pour être compétent dans l’autre est totalement absurde à mes yeux.

2 « J'aime »
9

De mon point de vue, un SM qui connaît la technique risque d’être « pollué » par cette connaissance. Ce n’est pas son job de donner des idées techniques, encore moins de trouver des solutions techniques. Or justement, s’il s’y connaît, il sera tenté de prendre position, pousser une solution ou même juste d’exprimer un avis. Dès que ça arrive, il perd son efficacité en tant que Scrum master. En effet, le codage est un sujet très prenant, comme un gouffre presque et quand on commence à y mettre le nez, on ne sait pas où ça va finir. J’ai vu plein de SM qui ont juste voulu « aider un peu » et qui se sont retrouvés tellement impliqués qu’ils n’avaient plus le temps de faire leur job se SM.
Le SM a plein de ressources pour aider l’équipe, y compris sur les sujets les plus techniques, sans s’y connaître lui même, en posant les bonnes questions. Il peut aussi identifier avec l’équipe des compétences manquantes éventuelles et les aider à trouver l’expert qui peut les aider.

2 « J'aime »
10

Merci à tous·tes pour vos avis! :pray:t4: :heart_eyes:

Ca a parfois un peu dérivé du sujet initial, mais c’est pas grave ! :grin:

De toutes façons, ces derniers temps, le doute sur mon intérêt pour le poste de S.M. a augmenté.
Par conséquent, la question du background technique indispensable, ou non, m’importe surtout pour le poste de P.O.

Attention, ci-dessous paragraphe pleurnichard : besoin de m’épancher! :stuck_out_tongue_closed_eyes:

Je m’étais fait des illusions sur le job de SM, je crois…
Je n’y trouve pas mon compte. Je me sens inutile.

Même en regardant mes « succès », je suis totalement frustrée : j’arrive à faire avancer les choses, mais à un rythme incompatible avec ma nature proactive, dynamique, impatiente (impression de pédaler très fort pour faire 50 m / mois), sans compter qu’aucun mérite ne m’est jamais reconnu : les changements arrivent tellement longtemps après que je les ai suggérés, qu’il n’y a que moi pour me souvenir que c’est moi qui ai semé la graine de cette idée.
Idée qui avait tout d’abord été décriée, critiquée, avec des remarques blessantes en prime! (« on perd notre temps! » « on a déjà discuté de tout cela », « à quoi bon? », « cette idée est nulle », etc. etc.)

Je ne me sens clairement pas respectée. Raisons exogènes et endogènes :

  • Mon équipe a perdu un très bon dév (lead tech) très LEADER + un Scrum master/développeur/manager (un des boss de la boîte), et a hérité de moi, S.M. débutante, sans background technique. Ca, c’est pas de ma faute.

  • Là où je suis « responsable », c’est que je n’ai pas su cacher mon manque de confiance en moi. Je crois que l’équipe aurait souhaité enchaîner avec une Scrum Master « leader », qui donne des instructions, qui affirme avec aplomb, etc.
    Non seulement, j’en suis pas capable (je doute de tout), mais c’est pas non plus dans mes valeurs et aspirations : j’ai envie de faire du collaboratif, de participatif, du brainstorming, stimuler la pensée divergente du groupe, etc.
    Mais j’ai l’impression que les dév ont juste envie de rester « peinards » derrière leur écran, à coder, enquêter pour résoudre les bugs, coder, encore coder.
    Le reste des process, ils n’en ont que faire. Et j’ai très certainement une grosse part de responsabilité dans mon incapacité à les y intéresser.

Et je me noie dans un cercle vicieux : sentir qu’on ne me fait pas confiance me déstabilise, je deviens plus maladroite, moins convaincante et donc on me fait encore moins confiance, etc. :anguished:

Heureusement qu’il y a ce forum! Perso, c’est ma bouée de secours quand je suis envahie par le doute et la déprime.
Donc, encore une fois, MERCI à celles-ceux qui ont répondu! :pray:t4: :purple_heart: :blue_heart: :green_heart: :orange_heart: :blush:

11

Bonjour,
Pour moi, les connaissances pour être un bon PO sont plutôt celles ci :

  • maitriser les ficelles de ce rôle (formation scrum pour PO obligatoire)
  • un plus : connaitre déjà le métier / le fonctionnel du produit (ou bien tu les découvres au fur et à mesure)
    Je n’ai pas de background technique et je pense jouer le rôle de PO convenablement, je connais en revanche pas mal de vocabulaire utilisé par les dev et m’en fais préciser si besoin (si tu ne comprends rien du tout au vocabulaire technique et ne souhaites rien comprendre je pense que tu risquerais d’être larguée sur les enjeux de planification).
2 « J'aime »
12

C’est vrai @Charlotte que cela a dérivé et par ma faute en plus, j’en suis désolé. En revanche je trouve très bien que tu ressentes plus une âme de PO avec un vernis Scrum c’est super ! J’espère que tu partageras cette expérience avec un super SM et une super équipe pluridisciplinaire ! C’est dans ce contexte où les rôles sont bien identifiés et bien répartis que l’on s’éclate le plus.
Au plaisir !

1 « J'aime »
13

Non, non, pas ta faute, et puis de toutes façons, ça reste très intéressant ! :smiley:
Merci pour les encouragements! :pray:t4:

14

:+1:t4:
Mon expérience actuelle m’a beaucoup appris de ce point de vue là, je pense (vocabulaire). Sans compter l’anglais pro sur lequel j’ai beaucoup progressé aussi.

J’espère trouver le temps de passer une certification Devops Foundation, et peut-être faire comme un-e des collègues qui s’est exprimé-e ci-dessus : me former au dév, au moins les bases !

2 « J'aime »