Hello à tous, je me pose la question Où commence et s’arrête la suppression d’obstacles ?
Je m’explique : nous sommes en migration de plateforme, les développeurs de mes équipes sont régulièrement freinés dans la résolution de leurs problèmes techniques car ils doivent attendre que la personne responsable des droits (DevOps) fasse le travail avec les droits appropriés.
Ils insistent pour demander l’ouverture momentanée de droits qui a déjà été refusée par le SRE, avec explications à la clé.
Est-ce que c’est mon travail en tant que Scrum Master d’aller porter leur parole pour essayer de supprimer cet obstacle, ou bien est-ce qu’ils doivent le faire eux-mêmes?
Merci
Si j’étais toi, en cas de doute, je demanderais à l’équipe : « voulez-vous aller porter cette parole encore une fois, ou préférez vous que j’essaie de le faire ? »
Donc la réponse Où commence et s’arrête la suppression d’obstacle : là où commence et s’arrête tes croyances sur où elles s’arrêtent 
Sinon, j’ai oublié de répondre quand même directement : j’irai essayer de régler le problème vu qu’ils ont déjà essayé et que ça n’a pas marché. Ca peut être d’intégrer le DevOps dans l’équipe de dev, réussir à ouvrir les droits en escaladant le problème, ou bien accepter que ce sera lent et le dire au leadership.
Merci pour ta réponse Benjamin. Elle est claire, je vais voir quel chemin emprunter
La réponse à ta question dépend, à mon avis, de la valeur relative que tu accordes à leur progression d’équipe sur ce sujet par rapport aux enjeux produit. Ca dépend aussi de l’accessibilité des solutions proposées, car tous les membres de l’équipe n’ont pas la même influence, en particulier sur la sphère managériale :
- Si l’enjeu produit est faible (problème rare et produit peu critique), que la relation entre équipes est un sujet fort du moment, que les solutions sont gérables par des dev, il vaut certainement mieux les laisser gérer, quitte à les orienter si ça patauge ;
- Si y’a le feu côté produit, que y’a des sujets plus urgents à aborder dans leur fonctionnement d’équipe, et que les solutions nécessitent d’impliquer des personnes qui te sont plus accessibles qu’à eux, il vaut certainement mieux leur proposer de gérer toi-même ;
- Entre les deux, c’est moins évident ; tu peux essayer d’arbitrer avec eux.
Tu peux aussi avoir une approche hybride : les aider à trouver une solution (ou au moins une meilleure approche) et les soutenir dans la suppression de l’obstacle par eux-mêmes ensuite.
Ayant reçu une fin de non-recevoir justifiée de la part du SRE, si l’intention c’est d’y retourner comme en 40, ça ne donnera rien à part une bonne dose de frustration, quelle que soit la personne qui s’y colle. Deux approches possibles qui me viennent :
- Réfléchir avec le SRE aux conditions qui pourraient rendre cette élévation de privilèges acceptable (formation ? signature d’un NDA ? participation régulière à des workshop ?)
- Si ça n’est pas possible, faire évoluer la relation entre les 2 équipes d’un mode de collaboration à un mode X-as-a-service. Expliquez ce dont vous avez besoin et voyez sur quels SLA l’équipe tierce peut s’engager. Avec le PO voyez qu’est-ce que ça représente en impact business. Reprenez les inquiétudes et arguments du SRE et mettez-les en balance avec ces impacts et discutez-en avec votre « PPCM » managérial.
Merci, c’est très complet.
Le sujet des droits aux devs pour trouver des solutions eux mêmes et régler les problèmes qui freinent la migration est un sujet produit SI crucial, pas de marche arrière possible car c’est un choix stratégique de sécurité des données, mais est en fait transparent pour les millions d’utilisateurs… Pourtant je comprends partiellement le SRE qui avance que c’est un principe de base pour protéger les devs en cas de fuite de données, ils seront éliminés d’office et le nombre de personnes potentielles sources de fuite se réduit alors à 5. Donc pas d’élévation de droits. Respect de la matrice, passage par les DevOps/ SRE. C’est un produit très sécurisé, avec des bases de plusieurs millions d’utilisateurs. Je ne suis là que depuis 3 mois, l’autre ScrumMaster, 15 ans d’expérience est ma tutrice, dit que ce n’est pas à moi de porter les actions, que j’ai déjà remonté les demandes une fois, que les devs doivent établir leurs suggestions de procédures de droits momentanés et faire eux mêmes les demandes, que je leur ai permis de l’exprimer une seconde fois en rétro, d’envisager des solutions non envisagées auparavant, ça s’arrête là pour moi.
Personnellement je ne veux pas ajouter cette charge sur les devs déjà retardés par la limitation des droits, je suis prête à porter la demande même si ce ne sera pas dans mon intérêt, tant pis… Ce serait mieux pour les équipes.
Et nous avons tous le même accès direct aux managers, on est tous en openspace… Mais ils ont besoin de sécurité et donc préfèrent la voix du SRE.
Je crois donc avoir essayé les options hybrides, actives, arbitrales, équipe et produit, et je crois comprendre l’option x as a service car c’est en fait la position de l’équipe DevOps/SRE au sein/service des équipes.
Mais j’ai posé cette question pour savoir jusqu’à quel point je suis ScrumMaster ou j’outrepasse mes propres « droits » en me créant des devoirs qui n’en sont pas.
Je lis dans vos réponses qu’il y a toujours plusieurs options, plus ou moins actives ou serviables selon l’environnement, et que s’il n’y a pas de solution ben… C’est comme ça, on fait avec, on perd en agilité, on perd en bien être psychologique des équipes, ça coûte… On gagne en sécurité
Merci pour le temps passé à me répondre.