Des US qui ne sont pas rédigées de façon explicite « afficher le numéro de version » (ou, comment, en gros, en petit …)
Des US avec des conditions d’acceptation qui ne couvrent que un % infime du fonctionnel attendu
Des US qui « trainent » sur 4, 5, 6 sprints (donc 12, 15 voire 18 semaines)
Des US qui ressemblent à des expressions de besoin de cycle en V
Des sprints qui affichent 40 à 50 US …
Des rétros qui ne sont pas des rétros (on y parle de cookies, de vacances, de météo, … pas des vrais sujets)
Quand le PO répond au SM qui tente de d’améliorer tout ça « La méthode, j’en ai rien à foutre, moi je veux avancer » … on fait quoi ? On dissout l’équipe ? On satellise le PO ?
On pose la question sur le forum de Scrum-Life ← done
On répartit les problèmes.
Qu’il avance …
Mais le livrable, c’est la responsabilité de l’équipe, pas (que) la sienne.
Ou "au SM qui tente que tout ça s’améliore ?
L’amélioration, c’est la responsabilité de l’équipe (dont le SM et le PO font partie)
Qu’en dit l’équipe de la situation ?
Comment se fait-il que seul toi réagisse ?
L’équipe s’en convient de la situation ?
Voudrait-elle améliorer autre chose avant ?
Se sent-elle parfaite pour le contexte ?
Tout ceci pour dire "en tant que SM il faut driver, activer ces questionnements, mais bien les laisser choisir ce qu’ils veulent améliorer, et comment tenter d’y parvenir.
Si un membre de l’équipe fait un reproche à un autre (po->sm, sm->po,dev->dev,po->dev, sm->dev,dev->po,… tout est possible) on rappelle d’abord que dans tous les cas, c’est bien l’ensemble de l’équipe qui est perdante. Pas un de ses membres.
Why not ? Même symboliquement.
On dissout l’équipe et on en recrée une, éventuellement avec le même groupe d’individus.
Une équipe, ce n’est juste un groupe d’individus, mais un groupe d’individus qui s’est trouvé un tronc commun qui en fait l’essence de l’équipe. Le team canevas est parfait pour poser ça.
Une fois l’équipe recrée, ça me semble un des éléments vitaux de son fonctionnement autonome et autogéré.
Note on aura validé avec le contexte, le champs réel d’autonomie et d’auto-organisation.
Parfois on dit oui oui à l’équipe mais c’est "faites le boulot logistique, mais on garde le contrôle, passez par nous avant de …
L’équipe le sens très bien et se déresponsabilise : « De tout façon ca on ne l’a pas choisi, on nous l’impose quoi qu’on en pense, donc si on nous demande de ne pas penser, on exécute sans réfléchir, et on n’assume pas ce qu’il en ressort »
Il y a un coté delegation poker à clarifier « qu’est-ce que l’organisation délègue réellement à l’équipe pour qu’elle s’auto-organise et se sente réellement responsable de ce qu’elle délivre »
Quand ca est clarifié, alors on peut parler d’amélioration continue et donc de rétrospective.
Pour gagner du temps sur la rétro
— Bonjour, quels sont les points d’action de la rétro précédente ?
— Ah , on n’en a pas pris, ok ne cherchons pas de nouveaux points à améliorer, reprenons les précédents et choisissons une action"
— Ah on n’a pas de points à améliorer ? Vous voulez en proposer ? "
— Non ? ok alors allons bosser
— Ah on avait des points d’action ? Qu’avons-nous obtenu ? qu’avons nous réalisé ?
— Rien, bah pas besoin de réfléchir à d’autres, allons bosser en gardant ces points d’actions
— …
C’est ironique mais
Retro => choisir un nombre d’actions raisonnable que l’équipe VEUT mettre en œuvre et dont on peut observer l’effet. Donc ce qui n’est pas lié ==> allons bosser ou faire un foot
eXtreme programming => tout ce qui n’est pas fini à la fin du sprint est jeté.
Visions plus Scrum => tout ce qui n’est pas fini n’est pas comptabilisé dans la valeurs ajoutée par l’incrément.
Ce sont donc des Epic => si pas fini parce que trop gros revenir sur de la réduction de portée.
Poser la question « qu’allons-nous livrer à la fin du sprint » « Comment pourrons-nous vérifier que c’est une bonne piste ? »
Rappel : ni le PO ni l’équipe ne sont là pour « trouver la bonne solution » mais pour trouver « une solution réalisable assez rapidement pour valider que c’est la bonne ».
Et bien ça , ca ne me dérange pas.
Surtout en regard avec
Ce n’est pas grave si une US ne couvre qu’une infime partie du fonctionnel ou de la portée…
pour autant qu’on arrive à la finir sur cette infime partie en un sprint.
Note, « partie du fonctionnel » par contre ca doit être « un ensemble complet pour une livraison à l’utilisateur » (pas une livraison d’intention)
Il existe des équipes avec qui Scrum ne marchera pas. Ce n’est pas une méthode miracle.
Si les gens ne jouent pas le jeu…
Si j’étais le SM, et que ça fait quelques semaines que j’essaie d’aider et que je me tape ce genre de remarque, la meilleure chose à faire c’est « les laisser tomber ». Qu’ils se plantent. Qu’ils se fassent massacrer par le business. Ou pas, si le business s’en fiche d’ailleurs. Et je leur dis bien que c’est « leur responsabilité ». Mais j’arrêterais, car aider des gens qui ne veulent pas d’aide ne sert à RIEN.
C’est généralement quand on verbalise dans ce genre de situation le fait de ne plus aider, que d’un seul coup… On vient nous demander de l’aide ! Le paradoxe du sauveur, quoi. Arrêter d’aider pour qu’on nous demande réellement de l’aide. Mais pour ça il faut clairement le verbaliser et laisser tomber un temps, qu’ils se plantent.
Je pense que la personnalité de 2-3 membres de l’équipe a une grosse influence sur le groupe. Un PO bordélique mais qui a une capacité de travail incroyable. Mais il n’y a que lui qui sait se retrouver dans son bordel…
Quand une partie de l’équipe s’accommode du coté « approximatif » du fonctionnement et c’est difficile de trouver des relais pour le SM. Est-ce que c’est parce que cette partie de l’équipe fait beaucoup de choses en commun en dehors de la boite ?
Le pire, c’est que grosso-modo, les livrables sortent. On ne sait jamais vraiment quand à l’avance, mais ça sort.
C’est finalement assez difficile de décrire ce fonctionnement … une sorte de « best-effort » mâtiné de points d’étapes (les sprints) où l’on regarde où l’on en est … sans doute plus ScrumBan que Scrum si il fallait donner un nom.
Et avec un management qui se défausse fort à propos sur la méthode « Très bien, auto-organisez vous » ! Au final, des devs qui prennent leurs congés comme ils veulent, préviennent le vendredi soir pour la semaine suivante ou le lundi de la reprise qu’ils prolongent d’une semaine …
Les actions de rétro ? « Organiser une soirée la semaine prochaine » ou « fêter le retour de Untel ». Au mieux, « monter Spring Boot en version 3.0 »
A l’arrivée, un sentiment de déliquescence généralisé sur lequel les rappels théologiques (DoD, Invest, objectif de sprint, refinment …) n’ont pas de prise et son vus comme une contrainte.
Comme le SM, progressivement…
Le vrai problème de fond que je lis, c’est… Qu’il n’y a pas de problème.
Les livrables sortent, le management a l’air content, tout le monde est content en fait ! Les devs font ce qu’ils veulent, le PO fait ce qu’il veut et il est indispensable, et il n’y a aucune contrainte sur l’équipe.
Impossible que le SM puisse faire quoi que ce soit dans une situation sans contrainte. Il est mis par le système en position de bullshit job.
C’est une situation que j’ai vécu, que d’autres SM / Coach agiles / Coach d’équipes ont vécu, et comme j’avais vu en formation : en entreprise, sans contrainte, pas de changement.
j’ai volontairement découpé ma réponse.
Et c’est très « à chaud » sans connaitre tout le contexte.
Il faut vraiment prendre ca chaque fois comme des « avis » et des « idées à envisager » et pas des « conseils » ou « recommandations » de ma part.
C’est toujours facile de dire yaka quand on est pas soit même dans le truc.
Par contre ca m’intéresse d’entendre ton retour, ce que ca fait résonner en toi, et ultérieurement ce que tu auras et ce que vous aurez tenté
C’est bien pour ca que je pense en mode => si ca leur plait, ne rien forcer.
Et puis voir si tout leur plait.
Sans oublier que "le SM fait partie de l’équipe, il a son mot à dire, genre « c’est pas mon boulot de faire le secrétariat ». Et c’est à l’équipe à chercher des actions.
Et si l’équipe en a rien à faire du PO ou du SM ou des autres devs ou de ce fonctionnement … "refaire une nouvelle équipe " => réaligner les valeurs
Première question : Est ce un Problème pour l’équipe ,l’entreprise , nos clients ?
puis Avancer oui mais vers quel objectif ?
et pour le PO Avancer ca veut dire quoi pour toi ?
