Quelle méthode utilisez-vous pour tranche/prendre des décisions quand l'équipe n'arrive pas à s'accorder?

Communauté Scrum Life
, ,
1

Bonjour,

Sur certains sujets, le Scrum guide n’indique pas d’accountability et certaines décisions sont censées se prendre en équipe, sans qu’aucun des rôles/team members n’ait de voix prépondérante.

Quelles méthodes utilisez-vous, vous, pour départager des opinions divergentes dans l’équipe? Quand, après une réunion dédiée, aucun accord n’est trouvé?

Un exemple : la durée du Sprint

Spontanément, par paresse, j’ai d’abord été tentée d’utiliser la bonne vieille méthode « démocratique » de la majorité qui l’emporte, mais je sens bien qu’on peut mieux faire. :stuck_out_tongue_closed_eyes:

Je me suis dit qu’on pourrait se baser sur les notions de « why/what/how » qu’on utilise en Sprint planning meeting : le Why étant une compétence de la P.O., les What & How étant du ressort des Devs.
Et dans ce cas, pour l’exemple donné (durée du Sprint), ce serait plutôt les Devs qui devraient avoir le dernier mot.

Qu’en pensez-vous, et comment faites-vous, vous?

Merci! :slight_smile:

2

Besoin de contexte: on parle de quelle décision dans quel scope ?

Ma réponse à chaud serait : pourquoi pas tenté toutes les solutions en même temps, s’arrêter à mi-chemin, voir laquelle est la plus susceptible d’aboutir, et continuer sur ce chemin là ?

3

Selon moi les prises de décisions sont essentiellement dépendantes du contexte et de leur importance

A ta place je me tournerai vers un delegation poker pour que vous puissiez sereinement vous positionner sur les prises de décision et définir ensemble qui peut / doit décider de quoi.

Dans le cas de la durée du sprint, je te suggère dans un premier temps d’évaluer la fréquence des changements à apporter à ton produit. Plus souvent il faudra pivoter et plus courts seront tes sprints.

Si vous n’arrivez pas à trancher, commencez avec un rythme « moyen » de 2 semaines, et à la première rétrospective discutez-en :slight_smile:

Dans tous les cas il faut d’abord essayer quelque chose et en tirer des conclusions par la suite

4

Déjà fait!

Dans l’exemple que j’ai donné, c’est la durée du Sprint qui est sujet à discussions.

Quand je suis arrivée dans l’équipe, on était sur du 2 semaines.
A la demande de la P.O. qui se sentait débordée, on a rallongé à 3 semaines, pour voir.
On doit bientôt faire le bilan de cet essai, mais j’ai déjà pris la température : c’est très partagé : on arrivera difficilement à un accord.

Contexte : on est dans une phase plutôt « run » d’une appli pour laquelle on développe très peu de nouvelles fonctionnalités (on paye la dette technique, on améliore les aspects sécurité et juridiques (RGPD), etc.)

5

C’est la deuxième fois que je lis ce terme de « delegation poker ».
Ca a l’air très intéressant, je vais aller googler ça.
Mais, bien sûr, si tu as le courage de développer, je suis preneuse! :slight_smile:

6

Première question : Est ce que Scrum est le plus adapté ?

Deuxième question : Est ce que cet allongement du Sprint répond à la bonne question vis à vis de vos problèmes ?

Troisième question : Comment avez vous mesuré que la mesure prise était la bonne factuellement autrement que par du ressenti ?

7

L’essai des 2 semaines, puis 3 est déjà fait. Comme répondu plus haut à Samuel, le bilan fait par chacun/chacune de ces essais est très différent d’une personne à l’autre, et on aura du mal à s’accorder.

D’où ma demande de témoignages sur les stratégies/méthodes que vous employez, les unes et les autres, dans des cas similaires.

Faute de mieux, ou en attendant de dégotter la super méthode qui va bien :smile:, je pense que je vais me baser sur le Why/What/How.

8

  1. ça, je n’en suis pas sûre en effet… Mais c’est une décision prise conjointement par mon management et le client. Et j’ai été recrutée comme Scrum Master. Je viens à peine d’arriver, je ne vais pas, déjà, scier la branche sur laquelle je suis assise. J’attends encore un peu :wink:

  2. Le problème de la P.O. (qui a demandé cet essai de rallongement) était de fournir les tickets, de raffiner son Backlog, etc. Elle était très débordée, et ne parvenait pas à remplir son rôle de pourvoyeuses de PBI. Ca m’a arrangée aussi : le Scrum n’était pas du tout installé, et la moindre planification de réunion était très compliquée = j’étais « pour » aussi.

  3. Je ne suis pas sûre de comprendre la question, mais en tout cas, mon intention est d’exposer à l’équipe les raisons pour lesquelles on choisit généralement un Sprint plus ou moins long (besoin de livrer plus souvent, risques de fausses routes à éviter, besoin de feedback fréquent, etc.).
    Selon moi, dans notre cas (appli pluss en « maintenance » qu’en développement), on n’a pas besoin d’avoir des Sprints si courts, et si ça arrange la P.O. qu’ils fassent 3 semaines, ça me va.

L’argument « contre » principal que j’ai entendu jusqu’ici, c’est que malgré ce rallongement, la PO ne fournit pas beaucoup de tickets quand même et surtout que la testeuse est obligée d’attendre plus longtemps pour travailler
(Pour pallier ça, j’ai une idée -découverte ici-même- : le Swarming!! :smiley:)

Bref. Ma question n’était pas tant sur la durée du Sprint, qui n’était qu’un exemple, mais plutôt sur la philosophie qui sous-tend les prises de décisions, quand on n’arrive pas à tomber d’accord en équipe.

9

J’ai malheureusement une mauvaise nouvelle: les prises de décisions sont contextuelles et n’obéissent que très difficilement à des « philosophies ». Même des trucs aussi reconnus que l’empirisme doivent se plier à l’intuition dans certains cas. Mais pour ce qui est de ton cas, j’ai bien l’impression qu’il y a clairement un manque de moyen du côté du ou de la PO. Allonger ou réduire le sprint n’y changera pas grand chose.

10

A mon avis, c’est justement parce que c’est « contextuel » qu’on devrait pouvoir se reposer sur une « philosophie » générale ou des « principes » (on appelle ça comme on veut) pour sortir d’une impasse.

Ca pourrait être : la majorité l’emporte (chacun expose ses arguments, et à la fin on vote)
Ca pourrait être : regarder à quelle question (Why/What/How) on peut assimiler la thématique discutée, pour donner une voix prépondérante à un rôle de l’équipe. (C’est ce que je compte faire, pour l’instant, pour la question de la durée du Sprint, si on n’arrive pas à tomber d’accord)
Ca pourrait être : on doit avant tout considérer l’impact sur la valeur du produit livré, pour prendre une décision,
etc.

J’ai bien pensé à faire discuter le sujet lui-même par l’équipe (« comment prend-on les décisions quand il n’y a pas d’accountability claire, et qu’on n’arrive pas à se mettre d’accord? »), mais j’aimerais mieux pouvoir les guider, et les soulager de ces « brainstormings » qui ne les passionnent clairement pas…

11

Là, tu mets le doigt sur quelque chose.

Les soulager des brainstorming, ce n’est pas le but justement. Le mieux que tu puisses faire, c’est leur faire comprendre que l’action doit venir de l’équipe, pas d’instaurer quelque chose à leur place. Laisse les apprendre.

Un truc assez dur en tant que SM c’est d’accepter de ne pas se placer en tant que sauveur ou sauveuse justement.

1 « J'aime »
12

Bonjour Charlotte,
Alors ton histoire m’inspire plusieurs réflexions :

  1. Pour obtenir une décision rapidement, cherche aussi du côté des techniques de « décision par consentement » (et sa version « adaptée » dans Holacratie qui est pas mal).

L’idée est non pas d’obtenir l’adhésion de toute le monde a une proposition, mais de s’assurer qu’il n’y a pas d’objection radicale ou valable. On entend par objection valable : une objection qui montrerait que la décision est infaisable ou serait un retour en arrière rédhibitoire pour le fonctionnement de l’equipe/orga.

En gros : qlqun formule une proposition, on a une phase de questions (factuelles, pas de jugement de valeur !), une phase de formulation des objections, on discute de savoir si l’objection est valide, puis, la personne qui a formulé la proposition initiale soit abandonne l’idée, soit elle reformule en tenant compte des objections et on refait un tour. S’il n’y a pas d’objection valable : on adopte!

  1. On ne doit pas oublier de poser un cadre a cette réunion : il DEVRA y avoir une prise de décision a la fin. Sinon c’est du tps de perdu…

  2. Sans formuler de solutions (j’en ai pas), il me semble que tu as déjà en partie lever le « vrai » obstacle à la question de la durée du sprint : la PO qui a trop de boulot.
    La réflexion pourrait aussi porter sur comment l’aider lors de chaque sprint ? L’équipe est-elle assez autonome ? La PO subit elle des contraintes venant de l’extérieur de la team ? Etc…

Bon courage a toi en tous cas!

1 « J'aime »
13

Par contre, jette un œil du côté de la vidéo sur les core protocoles, il y a peut être des trucs qui peuvent t’aider

1 « J'aime »
14

Oui, je sais bien, et c’est plutôt mon penchant naturel (l’intelligence collective, etc.) mais j’ai récemment changé mon fusil d’épaule, en voyant que cette posture frustrait beaucoup l’équipe, qui avait besoin de plus de cadre.
En une phrase : j’étais beaucoup plus « servant » que « leader » et ce n’était pas ce dont l’équipe avait besoin.
L’équipe se plaint d’avoir à réfléchir sur tous les sujets, de devoir se réunir trop souvent, et on a convenu, ensemble, que je serai plus leader, plus guidante.

Pour l’instant, c’est de ça dont l’équipe a besoin. J’espère qu’en avançant dans l’application du cadre Scrum, ça évoluera, mais actuellement c’est trop tôt (recul de 6 mois d’expérience).

15

Effectivement, les Core protocols decider abordent comment prendre des décisions (cf l’explication de Bloculus, très bien faite comme d’hab) : Core Protocols (5/9) : Le "Decider", pour prendre des décisions rapides en collectif - BLOCULUS

En général les équipes pigent vite et s’y habituent rapidement.
Pas sûr que ça fonctionne pour ta durée de sprint car vous n’êtes à mon avis pas alignés sur la/les causes racines des problèmes que vous rencontrez.

3 « J'aime »
16

C’est ce qui me chagrine aussi.

17

Suis tout à fait en phase avec ça et tu peux l’appliquer pour tout de manière plus large : Principe du Consensus Systémique. N’oublie pas d’ajouter dans les différents choix possibles proposés également le « Ne rien faire » car parfois les propositions peuvent ne pas remporter d’adhésion de l’équipe et il faut trouver autre chose. L’essentiel étant que tous se sentent concernés et participent à la décision finale. Penser plutôt dans les propositions à voter pour ce qu’on ne veut surtout pas et prendre la décision qui a le moins de votes… c’est plus rapide et souvent sujet à moins d’erreurs.

3 « J'aime »
18

Je ne comprends pas quel est le pb avec la durée du sprint au travers de tes messages. Par contre je vois que le PO galère à fournir du travail et que la testeuse attend pour travailler. Ça me fait réagir !

Cela me fait penser que l’équipe n’agit pas en équipe et ne fait pas son possible pour apporter de la valeur.

Je travaillerai ces points là :blush:
La durée du sprint n’est peut être bien qu’une jolie excuse pour tout le monde (conscient ou non), j’irai creuser derrière.

Aussi, plus la durée du sprint est longue plus il y a de capacité à faire donc plus il y a de travail réalisable et plus on a envie d’en pourvoyer aux exécutants heu… aux devs pardon (:grin::wink:). Réduire la durée du sprint me semble être plus adéquat : les dev (dont la testeuse qui n’attend pas hein :scream:…) Peuvent prendre des problématiques plus petites, et avoir du feedback plus vite. Les risques sont plus faibles. Le PO a donc moins de sujet à ‹ préparer ›… Cela nécessite de bien découper les problématiques, sinon le PO se trouvera toujours débordé s’il essaye de spécifier des solutions et c’est peut être sur ce point qu’il faut accompagner le PO, l’équipe entière peut l’aider à réduire le problème au plus petit possible pour qu’on puisse y trouver une solution dans un sprint. C’est une des hypothèses que vous avez testé ?

3 « J'aime »
19

+1 avec Sophie (sprints plus courts => moins de complexité, plus facile de s’engager, piloter l’avancement etc…).
Je pense également qu’au delà de la dispo/fourniture d’US du PO, il faut se poser la question de pourquoi la testeuse doit attendre avant d’avoir des sujets à tester ? Normalement elle devrait en voir dès le deuxième jour du sprint, non ?
Ton fonctionnement ressemble plus à du cycle en V avec le PO qui doit fournir une spec, les dev développent à leur rythme puis passent la main à une testeuse.

Pour aider le PO, pourquoi ne pas essayer de travailler à 6 mains (PO, testeuse et 1 dev) afin d’arriver à converger rapidement vers des PBI ready ?

2 « J'aime »
20

Je ne sus pas sûre de bien comprendre la description du workflow que tu indiques…

La taille des PBI dont les dév s’emparent ne change pas en fonction de la durée du Sprint. En revanche, effectivement, les dév sont censés pouvoir en faire plus, en nombre, si on a 3 semaines de Sprint contre deux.

Nous avons très peu de feedback du métier (ou alors ça se passe dans mon dos? Sachant qu’on est tous en full-remote = on ne voit pas ce que les autres font, quelles réunions ont potentiellement lieu entre telle et telle personne en déhors des réunions d’équipe organisées par moi).
Je travaille pour ça, en douceur, mais c’est pas facile.

Et je crois avoir identifié que la plupart des freins et des fonctionnements « non-Scrum » sont liés à une certaine réticence de la P.O. à jouer le jeu… Manifestement, dans son esprit, elle est une cheffe d’équipe. Comme tu dis, elle va distribuer du travail, et les autres exécutent.
De plus, elle a ouvertement admis que ses autres rôles lui plaisaient et qu’elle n’avait pas l’intention de les sacrifier pour être plus disponible pour l’équipe (elle est consultante externe et s’est vu confier d’autres tâches que celles de P.O. par le client).

Nous ne développons pas une solution, nous sommes plutôt dans un contexte de « maintenance » et de paiement de la dette technique, avec quelques petites évolutions.
J’aurais donc tendance à dire qu’on ne prend pas de risque à avoir un Sprint de 3 semaines.
Globalement, le client souhaite qu’on sécurise l’appli, et n’a pas de nouveaux besoins pour le moment.

Bref, c’est un peu long à expliquer, pour resituer le contexte, mais je suis d’accord sur ce qui a été dit ici et là, que je traduirais par : on est dans du Scrum washing… Et je dois convaincre, pour espérer que ça change! (d’où mes diverses questions sur ce forum).

@Sophie, je n’ai pas compris : " l’équipe entière peut l’aider à réduire le problème au plus petit possible pour qu’on puisse y trouver une solution dans un sprint"
Sachant que le problème majeur de la P.O., selon moi, c’est son indisponibilité, qu’elle-même ne souhaite pas résoudre…

Merci! :slight_smile: