Voilà, le titre explique tout…
J’ai bientôt une nouvelle mission potentiellement mais j’aimerais aussi vérifier si ça m’irait, je me suis fait une liste de questions que je partage, mais si vous avez d’autres idées… ? Ca peut être cool de partager !
Qu’est ce qui est concrètement attendu d’un Scrum Master dans votre organisation ?
Comment est structuré l’organisation actuellement et quelle est l’organisation cible ?
Quels sont vos processus de delivery : CI/CD, qualité, flow actuel… ?
Si j’étais pris, quel est le mandat d’accompagnement que je pourrais réellement avoir, au niveau équipe, au niveau service, et au niveau organisation ?
De quelle manière pourrais-je contribuer à la mise en place d’une nouvelle organisation ?
Comment est actuellement mené votre transformation, et avez-vous une coalition mise en place ?
Je pense que tes questions peuvent être utiles mais sont trop directes. Comme dirait Dr House « le patient ment ». Il faut trouver des moyens détournés pour éliciter les informations qui t’intéressent, notamment les situations que tu aimerais éviter.
Par exemple :
Cette question risque fortement d’avoir une réponse déconnectée de la réalité. De toutes façons, à ce stade, à moins qu’un ethnographe te partage son étude, tu ne peux avoir aucune certitude sur les besoins de l’équipe que tu intègres.
Perso, je poserais des questions sur leurs références, leur histoire, les erreurs (anonymes) passées à éviter. J’essayerais de repérer les éléments de langage et demanderais des histoires qui illustrent les termes employés pour mieux cerner l’usage. Par exemple, si j’entends le terme « mindset », j’ai envie de savoir ce que ça veut dire concrètement pour eux. Mais je ne vais pas juste demander cash une définition du terme.
Je donnerais qq exemples de méthodes que j’aime bien employer pour voir les premières réactions. Est-ce que l’une les motive d’essayer ou pas ? Est-ce que j’arrive dans un milieu réfractaire, en vrai ?
Je demanderais tout d’abord une description des différentes personnes de l’équipe, leurs qualités, leurs faiblesses, leurs difficultés rencontrées, leurs succès passés, leurs échecs aussi (très important). Avoir une bonne vision de son cercle de travail immédiat, me semble la base.
Dans quel domaine certaines personnes doivent progresser et comment en tant que Scrum Master tu peux les aider ?
Existe-t-il des conflits ou des tensions entre les membres de l’équipe ?
Quel est le turnover dans l’équipe ?
Les membres de l’équipe (notamment les développeurs) sont-ils dédiés au produit ou bien partagés sur divers projets ?
J’essaierai d’en savoir un peu le ou les managers des membres de l’équipe (responsabilités, influence, personnalité). Indirectement, cela te donnera une idée de l’organisation réelle et pas théorique, notamment l’importance de la « politique » dans la boite. Ca te donnera aussi une idée des personnes avec qui tu devras « négocier ».
Qui sont les stakeholders ? Le product owner ? Le client final ?
Product
Demande à ce qu’on te présente la vision produit. Si c’est clair, net et précis (bon signe) ou bien flou, vague, peu spécifique (mauvais signe).
Est-ce une mission de refonte, de TMA, débarques-tu en période de crunch ? Demande-t-on à l’équipe d’innover ou bien de stabiliser une application bourrée de bugs et rendant fous les utilisateurs ?
Quel est l’environnement concurrentiel ? Réglementaire ?
Quels sont les objectifs à court et moyen terme ?
Process
Quels sont les processus de décision ? Existe-t-il un CAB ? Un comité d’architecture ? Un comité technique ? Combien d’escalades avant qu’une décision n’atterrisse au CODIR/COMEX ?
L’équipe est-elle autonome dans la priorisation de ses tâches ? Sinon, qui fixe les priorités et selon quelles modalités ?
Ce projet est-il englobé dans un programme plus large ? Si oui, qui est le Directeur de Programme ? Existe-t-il un PMO ?
…
Plus généralement, j’essaierai de puiser dans mes précédentes expériences ce qui m’a gêné et posé problème (cela peut varier selon les sensibilités des uns et des autres) pour lister et prioriser les différentes questions.
Merci pour ta réponse, effectivement ça risque d’être trop direct et de créer des biais.
Parler des « histoires », des références, effectivement ça me parle bien. Du style, l’histoire des équipes que je dois accompagner. Partager aussi quelques méthodes que j’utilise, pour voir un peu ce qui est réfractaire ou non, c’est quelque chose que j’avais fait auparavant et c’est vrai que ça donne un bon feedback, je vais utiliser ça ! Merci !
Pour le mandat, je n’ai pas le besoin des équipes, mais j’espère au moins connaitre le besoin du manager. Ca me donnera déjà quelques billes.
Eh bien encore merci, j’ai passé l’entretien et j’ai pu détecter des mensonges ainsi que les choses que je n’ai plus envie de revivre. Du genre « on met en place l’agilité pour mettre en place l’agilité ». Donc merci le forum ! Ca me donne des billes pour l’avenir et les prochains entretiens. #partage
C’est exactement ce qu’il faut arriver à détecter. Je n’arrive pas encore à lire entre les lignes pour ne pas me retrouver embarquer dans une transformation dénué de sens.
Ca me donne des billes pour l’avenir et les prochains entretiens.