Quelle est ta PIRE expérience?

Allez, marrons-nous un peu, même si c’est en riant jaune : quelle est ta PIRE expérience professionnelle ? Et par extension, certainement la plus anti-agile…


Moi c’était dans une boîte où on interdisait aux développeurs de parler aux clients et utilisateurs. Surtout pas ! Tout devait passer par le « PO » et l’architecte, qui entretenaient la politique des patrons de tout contrôler et d’essayer d’enfumer tout le monde.

Un jour – j’étais développeur – alors que l’architecte était absent, j’ai été finalement en contact direct avec le client. Ô malheur ! J’ai été honnête, transparent, j’ai répondu aux questions du client, en lui expliquant ce qui était possible, ce qui ne l’était pas, et les contraintes qui venaient avec chaque solution envisagée. Le client semblait soulagé d’avoir enfin un véritable interlocuteur. Juste après cet échange, mon client de messagerie clignotte et je vois des messages de collègues qui m’applaudissent virtuellement. Sacré satisfaction ce jour-là.

Evidemment, dans ce type d’environnement, les anecdotes ne manquent pas mais je vais m’arrêter à celle-ci pour le moment.

Bref. Ils étaient fous – au sens littéral du terme.


Et toi ? Quelle est ta pire expérience ?

6 « J'aime »

J’ai envie de dire celle de RTE parce qu’elle m’a mené à l’épuisement professionnel.

Et avant de déclencher le SAFe Bashing, mon problème ce n’était pas le framework, mais une organisation silotée avec des implications et adhésions top-down décalées entre les différents silos.

Bref, je n’avais pas le « mandat » d’une partie de l’organisation.

Et donc le problème de l’agilité à l’échelle, c’est d’avoir les problèmes à l’échelle, et quand on construit collaborativement, c’est toujours beaucoup plus lent que de construire « arbitrairement » et « autoritairement ».

3 « J'aime »

@jplambert, quelle a été la réaction de l’architecte
à son retour ?
Embrouille ou finalement cela a permis d’aller dans la bonne direction ?

Je ne sais plus. Rien de positif n’en est sorti pour moi côté hiérarchie (à titre personnel ou niveau feedback des collègues c’est une autre histoire). Mais je pense bien qu’à l’époque j’avais déjà posé ma démission, ou pas loin ; donc bon…

Pour la petite histoire on n’a pas réussi à se mettre d’accord sur la durée du préavis : je voulais partir plus tôt que les 3 mois réglementaires lors d’une démission ; on m’a dit oui à l’oral, puis non en reniant les notes que j’avais prises et envoyé par mail, puis sollicité les RH de la maison mère qu’on ne voit jamais d’habitude pour me mettre la pression… J’ai fini par faire un abandon de poste (je les ai quand même prévenu par courrier recommandé, hein) alors qu’on me menaçait de procès si je faisais ça. C’est dire l’ambiance.

1 « J'aime »

Mission d’AMO au forfait, la première et la seule.

Je ne connais ni l’entreprise, ni le métier. J’ai le droit à 3 à 4 ateliers max pour comprendre le besoin et définir la solution. Entre 10 et 20 jours par projet pour tout faire y compris pour rédiger trois documents dont une specs détaillées.

Puis le client choisis une boîte pour le dev, avec laquelle je n’ai pas le droit de communiquer. Éventuellement, la boîte peut envoyer une fois une liste de questions.

La boîte fait le dev à partir de la specs. Ensuite elle envoi ça à ma boîte pour qu’une autre personne fasse la rct. Cette personne peut me poser des questions mais ne parle pas aux devs.

Cette organisation est tellement folle. Elle repose sur l’hypothèse que le client connaît ses besoins et la solution qui va y répondre, que je ne suis qu’un scribe, que les devs ont seulement besoins d’une specs et le testeur également.

Voilà pourquoi j’ai une phobie du forfait en AMO.

3 « J'aime »

Mission à l’échelle qui se passe bien, un super sponsor, exigeant mais qui se bat dans l’orga pour laisser de la place aux équipes, aux datas, aux besoins réels des utilisateurs, etc.

Super relation, team performante et félicitée.

Suite à une réorg, il est remercié et remplacé par un manager tour d’ivoire qu’on a jamais vu dans l’année qui a suivi.

Premier contact avec l’équipe : sans m’en parler, il fait une invitation teams avec tout le monde, pour leur dire que maintenant, ils devront traquer leur activité au 1/4 d’heure près pour chaque mois passé. « ça va prendre 3, 4 minutes par jour, ça va »
J’ai eu beau lever des alertes à droite à gauche sur les impactes, c’était le début de l’écroulement.

En 1 an, on est passé de « équipe de 13 membres faisant des mises en prod sans bug pour 400 000 users en rigolant » à "2 membres soulagés de refiler le projet devenu patate chaude à une équipe zombie scrum qui implosait niveau relationnel …

En tant que SM sur le projet, le gachis et la déchéance de cette histoire me rends encore triste.

7 « J'aime »

On dirait le début d’un atelier Artiste et spécifieur, avec des règles semblant absurdes pour mettr en avant de façon caricaturales des travers des entreprises.

Mais en fait, ça existe dans la vrai vie !? :exploding_head:

1 « J'aime »

Mon pire mandat est dans une entreprise ou l’architecte en chef se disait qu’il est aussi le PO!! et ou tout doit passer par la «Table d’architecture» avant de passer au équipes! et on on disait qu’on était TOP agile!!
je ne sais pas si vous voyez l’image mais c’etait lourd!

Ma pire expérience… je crois que je suis en train de la vivre en ce moment. Je la raconterai quand la question reviendra.

@Valerie_Criton la question est revenue ! :slight_smile:

2 « J'aime »

Hello à tous,
Je viens de terminer une période d’essai en tant que Scrum Master Junior dans une start up et j’'espère que ce sera la moins bonne expérience de ma vie pro :sweat_smile:
J’arrivais sur une création de poste ou l’hypothèse de l’équipe People était qu’un scrum master Junior par équipe « pouvais marcher ». Sauf que l’équipe de dev sénior en question n’était pas du tout convaincue par l’agilité et encore moins par la méthode Scrum. Résultat : remise en question quotidienne du cadre (why not me diriez-vous ? mais pas pour la Scrum Master débutante que je suis ^^) PO anti-agilité que je ne souhaite à personne et bien d’autres choses.

Bref… je viens sur ce forum pour apprendre et trouver des réponses à mes nombreuses questions mais aussi et surtout pour détecter un peu mieux en amont les missions « impossibles » pour mon profil.
En route pour de nouvelle aventure :rocket:
Fady

Ou bien, une première expérience où tu as appris beaucoup.

Oui il est vrai que j’y ai beaucoup appris, sur moi-même, les autres et biensûr sur l’agilité.

J’apporte un peu d’eau au moulin des situations compliquées! Je comprends la frustration de ne pouvoir contacter les clients directement. Cependant je t’apporte l’éclairage d’un PO qui a évolué dans une organisation bancale : dans mon cas, le fait que les dév contactent le client sans me prévenir a créé une crise politique interne entre les directions avec l’agitation de tous les grands chefs à plumes. Moment désagréable pour un truc pas si grave en vrai… La politique interne plus que les personnes explique bien des verrouillages.

:grinning:
En effet !

C’était ma première mission en tant que PO et j’étais très heureuse d’entrer dans cette entreprise dite « AGILE » avec mon diplôme sous le bras et ce, malgré quelques petits signaux d’alerte que j’ai ignorés dans les débuts dont : « on fait du Scrum parce que c’est populaire » lors de mon entretien et « Agile, c’est de la m… » dit le Directeur aux alternants nouvellement arrivés dans notre welcome meeting.

On m’a demandé de prendre en charge la TMA et j’avais avec moi une équipe de dev mais on était pas vraiment une équipe, plus un pôle « ressources » puisque les devs pouvaient partir à la demande sur d’autres projets si besoin (moi y compris). Pas de Scrum Master. On changeait plusieurs fois de suite de projets ou produits dans la semaine ou même dans la journée. Fallait se remettre dans le contexte ensuite. Pas simple. On nous a appelé ensuite l’équipe « multi-projets ».

On a quand même mis en place Kanban pour le process « RUN » de la TMA et ça a bien fonctionné, l’équipe et les clients étaient contents. On était réactifs par rapport aux remontées d’anomalies, on arrivait à fonctionner selon les allers-venus et à bon rythme mais ça n’était jamais suffisant pour la chargée relation-client/Directrice commerciale/Manager/Future directrice de l’entreprise. Fallait qu’on dépile un max pour faire rentrer du CA. Fallait qu’on soit rentable. Comme elle avait accès à jira, elle prenait des tickets dans le backlog et les rajoutait assignés dans le board (ou demandait à un admin de le faire) avec un petit mail : "j’ai alimenté les devs parce qu’ils n’avaient pas grand chose à faire"ou « j’ai donné ça à intel parce qu’il n’avait que la fonctionnalité « bidule » à faire, c’est un peu lège, non ? ». On le découvrait le lendemain.

Je pourrais raconter pas mal d’autres anecdotes, du style : commencer les devs sans attendre le go du client, dailys obligatoires, les règlements de compte dans les rétros des autres équipes, une QA complètement débordée, specs hyper détaillées, process lourd avec flicage des salariés et gonflage des factures.

Le jour ou je me suis vraiment décidée à partir, c’est lorsque la direction m’a demandé de remplir un excel journalier en ligne qu’elle pouvait consulter à toute heure de la journée. Un excel de tout ce qu’on faisait dans la journée avec l’équipe en détaillant les réunions et les conversations pour « nous aider à nous organiser et trouver des axes d’amélioration ».

Est-ce nous qui avions un problème ? Je ne pense pas.

J’aurai quand même appris beaucoup de choses et heureusement, entre nous, dans l’équipe, on s’entendait très bien. Maintenant je suis ailleurs mais j’ai bien l’impression d’être retombée dans un Water Scrum Fall again.

2 « J'aime »

C’est fou ce qu’une seule personne peut arriver à faire comme dégâts dans une orga qui fonctionne. Est-ce que tu as su pourquoi votre super sponsor a été remercié ?

2 « J'aime »

Pire expérience ? Contexte agence sans notion d’agilité du tout… Le commercial prend le brief oral du client, consulte un dev senior pour le chiffrage, établit un devis. Le client négocie à la baisse. Le commercial baisse le prix en calculant qu’on produira offshore (et pas avec le dev qui a chiffré donc) sans changer le périmètre. J’arrive sur le projet pour la réunion de kickoff seulement. Je pose toute une série de question qui me permettent d’identifier que ca ne passera pas (la complexité du projet ayant été sous évaluée faute de poser ces questions avant). J’alerte le commercial qui ignore mes warnings. Mon erreur à ce stade : ne pas avoir escaladé immédiatement. Je rédige les specs. après de longs ateliers avec le client qui doit m’expliquer son métier… Et ne comprends pas à quoi servent ces ateliers puisqu’il a déjà « tout » expliqué. J’envoie ma spec (en francais) à l’autre bout de la planète à un responsable de prod français junior qui les explique en anglais (approximatif) à des dev junior non anglophones. Je vous laisse deviner la suite. Cerise sur le gâteau : au moment de la mise en prod le client refuse de payer l’achat d’art (hors devis puisque le design est conçu pendant le projet). J’ai ensuite exigé et obtenu qu’il y ait toujours quelqu’un de la prod en binôme avec les commerciaux pour analyser les cahiers des charges (souvent les rédiger…) et les chiffrer.

1 « J'aime »

Bonjour,
Je vis en ce moment ma pire expérience.
Je travaille avec un PO anti scrum. Il ne voit aucunement l’intérêt d’avoir un scrum et demande à l’équipe dev de ne pas passer par moi. Quand j’essaie d’en discuter avec lui pour découvrir pourquoi il ne veut pas de scrum et de lui expliquer que je peux être utile, le PO ne m’adresse plus la parole pendant plusieurs jours. Il s’est plaint de la présence d’un scrum dans l’équipe à notre responsable de service , qui du coup m’a demandé , pour ne plus avoir de problème avec le PO, de ne plus venir aux dailys, et de ne plus intervenir entre les devs et le PO, il me resterait bien assez de travail pour m’occuper et vu que j’avais bien mis en place les process de travail, tout fonctionnait correctement sans le scrum. Mais il m’a rassuré, le PO allait de mieux en mieux et recommençait à discuter :slight_smile: Et tout cela grâce au scrum qui a bien travaillé :frowning:
Le PO vient et ne parle pas non plus quand nous faisons les retro. D’après lui, les retro sont inutiles et les problèmes ne sont jamais réglés à ce moment-là, inutile d’en parler (alors qu’il a râlé pendant tout le sprint sur les mêmes sujets). Et oui, on pourrait trouver une solution en équipe, mais il a peur que cette solution ne lui convienne pas.
Je mets en place des icebreakers, il ne participe pas. C’est sympa, ça met l’ambiance mais ce n’est pas pour lui.
Quand je lui demande ce qui pourrait être amélioré, il me dit « tout devrait être amélioré, les réunions devraient être plus dynamiques, et les devs ne travaillent pas comme je veux » et quand je lui demande ce qu’il propose, il me répond « rien, je ne suis pas scrum, c’est le boulot du scrum non ? »
Je fais des sondages dans l’équipe avec des questions sur ce qui fonctionne, ne fonctionne pas, ce que l’on pourrait améliorer, comment… et j’ai des retours constructifs. Cela donne un peu de baume au cœur et me dis que je dois continuer et ne rien lâcher, que c’est une expérience enrichissante mais ce n’est pas toujours facile
Par contre j’en viens à ne plus avoir de bienveillance pour le PO…

4 « J'aime »