Dès le 2è jour du Sprint?
Ca voudrait dire que les dév terminent leur 1er PBI en 1 jour?
En tout cas, j’ai appris ici même ce qu’est le Swarming (enfin, j’en ai une idée théorique pour l’instant!), et ça m’a l’air super. Je vais essayer de convaincre l’équipe d’adopter cette méthode.
Souvent la durée du sprint raccourcie s’accorde avec l’intégration continue bien en place sinon certaines tâches pour livrer le master sont lourdes et deviennent trop coûteuses, c’est d’ailleurs la raison des sprints qui courent sur 3 semaines le plus souvent.
PO qui ne fournit pas assez, QA qui attend…, c’est bien, au moins déjà, les devs ne sont pas critiqués ici 
j’ai envie de rappeler que les rôles c’est bien, mais que l’équipe c’est mieux… le PO peut aider, les devs peuvent aider, si la QA est à la bourre, on aide à faire passer les tickets à DONE le plus vite possible avant d’en balancer d’autres… on peut améliorer la qualité du dev si le PO ne fournit pas assez en entrée… la QA peut préparer ses tests automatisés en amont, le temps que les tickets arrivent en test aussi, plutôt qu’attendre que les devs aient avancé…
Pour en revenir à la question : quelle méthode utilisez-vous pour trancher quand l’équipe n’arrive pas… pourquoi trancher ? pourquoi décider à la place de l’équipe ? Il faut guider l’équipe vers une solution qui permettra d’améliorer son organisation, en lui proposant des solutions, pourquoi pas, mais elles devraient émerger des problèmes qu’elle rencontre, donc les solutions devraient être découvertes au fil des sprints plutôt que d’avoir les réponses clé en main…
Lorsque tu ne sais pas dessiner, même si je sais dessiner, je sais tenir mon crayon et même si j’ai beau te dire comment tenir ton crayon, ce n’est pas pour autant que tu me feras un très beau cercle en regardant comment j’ai fait le mien. Tu essayeras, tourneras ton crayon, essayeras autrement… jusqu’à arriver à un cercle qui te semble te convenir… c’est pareil pour le fonctionnement de l’équipe… vous avez identifié que vous n’arrivez pas à vous accorder, c’est un très bon point de départ. Maintenant, dans vous, il y a plusieurs, donc tu ne régleras pas le problème de tout le monde en même temps… procède par exemple par étape en prenant un rôle après l’autre et en essayant des améliorations puis en les gardant si elles fonctionnent ou en en essayant une autre le sprint suivant si elles n’apportent rien et recommence.
Concernant la suggestion de @SophieB je suis tout à fait avec les sprints courts, même si ça peut stresser les équipes lorsqu’elles ne sont pas vraiment encore organisées en intégration continue.
Tu retrouveras souvent malheureusement des POs qui ont un historique et qui du coup oublient qu’ils n’ont plus la casquette de chef de projet et donc qui regardent de haut les gens de l’équipe et ont du mal à accepter qu’ils sont maintenant au même niveau que toute l’équipe… c’est un travail de longue haleine et ton cas d’une personne externe est encore plus compliqué étant donné que le PO se doit d’être disponible à tout moment pour l’équipe…
Pour moi, ce problème pourrait être réglé en remontant ça plus haut puisqu’on retrouve de toute façon partout une orga verticale… ou presque… il y a sûrement un manager au-dessus à qui parler de ce problème…
Mais qui a dit que je voulais décider à la place de l’équipe?
Qui a dit que je voulais des réponses clé en main? 
« Trancher » est effectivement maladroit, mais il faut synthétiser une question en qq mots dans le titre…
J’ai ré-expliqué mon contexte et mon mindset sur un autre fil, et c’est long, donc je ne vais pas m’y recoller, mais ce dont j’aurais besoin c’est de retours d’expérience, d’idées de méthodes (quelqu’un a partagé la méthode « Decider », qui est vraiment chouette, merci!). Pour le mindset « Scrum », ses valeurs, ses principes, je suis au point, je pense. J’ai choisi ce métier pour sa très proche ressemblance avec mes valeurs et les pratiques que j’aspire à voir appliquées en entreprise.
Pour la durée du Sprint, qui était un exemple : on a déjà testé les deux solutions. Il n’en ressort pas de consensus.
Je viens à la pêche aux expé, aux arguments, etc. Ainsi, si j’en tiens un ou plusieurs qui peuvent coller avec notre contexte, ça m’aidera à faciliter les réflexions et les prises collectives de décisions, tout en restant focus sur notre objectif : délivrer un incrément de valeur à ceux qui nous payent.
Sinon, je ne comprends pas ce que tu veux dire par prendre « un rôle après l’autre et en essayant des améliorations puis en les gardant si elles fonctionnent ou en en essayant une autre le sprint suivant si elles n’apportent rien et recommence ». Dans le cas de la longueur du Sprint, je ne vois pas comment ça pourrait être traité rôle par rôle…
Pour finir, oui, je te rejoins sur le fait de susciter le travail d’équipe autant que possible d’où cette idée de Swarming que j’aime beaucoup!
Et, après avoir tenté diverses choses pour aider la P.O. à se libérer du temps pour nous, j’ai dû jeter l’éponge et j’ai effectivement fait remonter le problème à mon propre management. Qui, lui aussi, doit marcher sur des oeufs… 
Note qu’on n’a pas de QA, on a une QC qui fait tous ses tests manuellement, et on n’a pas non plus de plan de release… On bricole pas mal, j’ai l’impression, dans cette équipe (sans en avoir testé d’autres, c’est difficile à dire, c’est mon ressenti).
Je plussoie et j’irais même plus loin: avoir le courage d’expérimenter, c’est également engager plusieurs (beaucoup de) Kaizen en même temps. Dans le TPS, certains ateliers s’engagent même sur des quotas de Kaizen. Autant dire que certaines équipes et leurs 2-3 actions de retros sont très loin du compte.
Besoin de traductions, svp :
Kaizen, kézako?
TPS ?
Merci.
Kaizen : amélioration continue. Par extension, « un » kaizen représente une amélioration.
TPS: Toyota Production System, qui est l’une des sources principales de Scrum.
Merci Guillaume pour ton post clair et constructif! 
(j’ai trouvé le schéma « Core protocol Decider » que quelqu’un d’autre m’avait conseillé. Ca rejoint ce que tu décris, sauf erreur, et ça m’a l’air super!)
Après que j’aie fait plusieurs types de propositions pour aider la P.O. à se libérer, elle a fini par admettre ouvertement qu’elle ne souhaitait pas renoncer à ses autres tâches (elle est externe d’une boûte d’outsourcing recrutée par le client, et le service auquel elle appartient chez le client lui confie d’autres tâches que celles de P.O.).
Par contre, elle a réussi à faire recruter une deuxième consultante par le client pour l’assister et alléger sa tâche de P.O…
Quand on sait que le client refuse de recruter un dév de plus pour l’équipe, qui est en sous-effectif, pour des raisons de budget, ça laisse un peu perplexe…
D’accord merci
Et en remettant ça en perspective avec le texte que tu as cité, ça donnerait quoi, concrètement, stp?
On avance pas nécessairement assez rapidement en faisant seulement des « petits pas ». Plus nombreuses sont les expérimentations en parallèles, plus elles ont de chance d’amener concrètement vers la destination attendue. Penser rôle par rôle dans un scope sprint par sprint, c’est lent, et ça ne répond pas en plus pas forcément au problème. Par contre, lancer un sprint dont l’objectif serait « Faire en sorte de créer un process qui nous amènerait à être satisfait pour faire X », là, tu as toute mon attention.
Personne ne dit que TU voulais décider à la place de l’équipe… maintenant, la tournure du sujet peut prêter à confusion vue la réaction. Donc tant mieux si ce n’est pas ce qui te passait par la tête c’est le plus important et désolé si ce que j’ai écrit a été interprété dans ce sens.
Je n’ai pas mis en rapport la durée du sprint avec le fait de chercher à régler les problèmes rencontrés avec chacun des membres de l’équipe… donc normal que tu ne voies pas de rapport.
En tout cas, lorsque je lis tes différents commentaires dans le fil de la discussion, je note un malaise de ton côté avec cette PO et ce qu’elle a fait ne semble pas te convenir… là où il y a conflit, c’est toujours un sujet chaud à régler. Est-ce qu’elle ressent les choses de la même manière que toi ? Comment pourriez-vous à nouveau vous accorder ensemble ? Sereinement ?
Tu as raison de t’intéresser aux Core Protocols, ce sont de très bons outils! 
L’autre intérêt c’est qu’ils sont accompagnés de « Core comittements », qui sont une sorte de charte a laquelle les gens doivent adhérer pour bien utiliser les protocoles.
Dans ta situation ça te fait une super opportunité a creuser :
1/ tu amènes le protocole « deciders » pour pouvoir rapidement mettre qlq chose en place et améliorer la prise de décision par une mécanique simple à comprendre
2/ ça te laisse le temps de creuser avec l’équipe quels « engagements » ils seraient près a prendre pour continuer à améliorer la situation. Sans forcément essayer de les faire adhérer à ceux des « Core », ça pourrait permettre a l’équipe de faire sa propre charte et a toi, d’introduire petit a petit d’autres Protocols … 
Ce qui te laisse après de la latitude pour … gérer ta PO 
Bon courage!
Et rappelle toi : traite les pbs les uns après les autres !
Bonjour Charlotte,
je viens de tout lire 
j’arrive après la bataille mais je vais tenter de rajouter un autre élément qui pourrait répondre à ta problématique.
Il est clair que tu veux faire bouger les choses, et dans une optique clairement positive, mais tu n’es pas suivie dans ta démarche par l’équipe. La PO qui s"isole, les devs en remote qui semblent un peu distants des prises de décisions, une testeuse qui doit s’ennuyer puis rusher en fin de sprint, toi qui t’essouffle… Chacun à ses motivations, tu as détecté les motivateurs externes (la mission de la PO, ta mission, etc.)
Du coup j’ai pensé à…
Roulement de tambours
Les moving motivators !
Cet atelier peut aider à ce que chacun exprime ses motivations intrinsèques et l’impact que peut avoir un contexte, un changement sur ses motivations personnelles. Ca peut t’éclairer, toi, mais surtout les membres de l’équipe, à pourquoi on décide certaines choses et pourquoi on ne décide pas.
Je te donne un lien vers un exemple d’atelier :
Je ne l’ai jamais pratiqué en environnement pro, mais je l’avais joué avec un collègue de formation Scrum Life dans le contexte d’un PO surbooké qui ne veut pas déléguer ou qui est pressé par sa hiérarchie, et ça avait été très enrichissant.
Avant de te lancer là dedans, et que chacun se mette en action de jouer le jeu, tu peux aussi mettre en place des Safety Check pour juger si l’équipe est prête ou pas à aborder des sujets sous le cadre de « l’intime »
Je te laisse analyser ces sujets
Nicolas
Hello Nicolas,
J’ai failli m’inscrire sur Klaxoon, mais ça demande un numéro de téléphone, et l’utilisation qui va en être faite n’est pas indiquée dans leurs CGU…
Les termes de leurs CGU et de leur politique de confidentialité sont contradictoires d’avec les données demandées au moment de la création du compte.
Bref, j’aime pô beaucoup ça…
Je vais voir si je trouve un équivalent sur une autre plateforme du coup.
Merci pour les tuyaux! 
J’arrive un peu après la bataille mais si je peux donner 2 centimes dans la réflexion, les voici :
La philosophie / le principe général de scrum c’est l’empirisme, c’est à dire :
Si on reprend ton exemple sur la durée du sprint, voilà ce que tu dis :
L’info qui manque ici, c’est pour voir … quoi ?
Pour quelle raison avez-vous fait cette expérience ?
Si je reformule : vous avez augmenté la durée du sprint en espérant que ça augmenterait la production de PBI. La question à vous poser à l’issue de l’expérience est donc « est-ce qu’on a augmenté la production de PBI ? »
Donc a priori, ça n’a pas amélioré la situation.
Il y a peut-être d’autres bonnes raisons de passer à 3 semaines, mais ce n’était pas en lien avec le problème de départ. Vous pouvez passer tout le temps et l’énergie que vous voulez à décider si vous passez à 3 semaines ou pas, ce n’est donc pas ce paramètre qui améliorera la production de PBI. Alors si c’est vraiment cette capacité de qui pose problème sur le produit, vous feriez mieux de lâcher l’affaire de la durée du sprint et rechercher une autre explication/expérience pour résoudre le problème.
C’est parce que vous n’avez pas de métrique que chacun y va de son avis et surtout de son ressenti. Du coup la décision devient émotionnelle au lieu d’être rationnelle. Regardez le nombre de PBI produit par semaine et comparez. Une fois là, la décision sera très facile à prendre :
Idem, réponse très tardive, mais comme mon camarade, je me permets d’ajouter mon petit grain de sel.
Il y a deux questions qui se cachent dans le post initial.
La première c’est comment prendre une « bonne » décision.
La seconde c’est comment aligner l’équipe sur cette décision.
Concernant le comment prendre une bonne décision, sujet qui me passionne, il faut d’abord une vision (sans doute le « why » évoqué par l’auteur du post initial), une boussole pour savoir dans quelle direction on veut aller.
Toute décision (pour un sujet un minimum complexe) doit aussi s’appuyer sur une évaluation de la situation, un diagnostic. Une décision ne peut pas être hors-sol et doit se baser sur un minimum d’éléments objectifs et factuels.
Enfin, une décision doit être implémentable. Sans doute le « how ». Il convient de s’assurer qu’elle peut être mise en oeuvre. Si ce n’est pas le cas, ce n’est qu’une bonne idée en théorie, mais pas en pratique.
Je vois souvent la décision comme le point d’articulation entre la vision et l’exécution. Ce n’est que du bon sens, mais cela m’a aider à plusieurs reprises dans ma la réflexion.
Sur la manière de faire en sorte que l’équipe soit alignée sur la décision, il faut d’abord qu’elle soit convaincante. C’est pour cela que du simple « brainstorming » en mode intelligence collective ne suffit pas. Il faut l’argumenter et expliciter en quoi cette décision est « logique ».
Sur les sujets complexes, tout le monde n’a pas le même niveau d’information ni de compréhension. C’est pour cela que je préconise souvent de réaliser un travail pédagogique en amont de la prise de décision, si celle-ci doit être collégiale (par exemple en comité de pilotage).
Une fois le sujet suffisamment clair pour tout le monde, alors il peut il y avoir un débat éclairé, pas avant.
Aligner les équipes sur une décision est aussi important que de prendre une « bonne » décision. Car, une décision en soit ne vaut rien tant qu’elle n’est pas mise en exécution.
J’en reviens toujours à mon triptyque : vision, décision, exécution.
Bonjour,
Claude Aubry a écrit une série d’articles intéressants sur les prises de décisions collectives : La prise de décision collective - Scrum, Agilité & rock'n roll