Absence du P.O., qui remplace? + arguments planning récurrent des cérémonies?

Bonjour,

Pour moi, en Scrum, nous tenons des ROLES.
Ainsi, si un rôle est manquant (absence de la P.O., par exemple), quelqu’un d’autre doit prendre le rôle.

De plus, les cérémonies doivent être fixées à des moments identiques d’un Sprint à l’autre, pour éviter la complexité de leur organisation.

Il faut savoir que ça fait des mois (depuis que je suis dans cette équipe), que je joue la carte de la souplesse, de l’adaptation, de l’intelligence collective et du « servantship », et que ce n’est que depuis quelques jours que j’ai annoncé à l’équipe, qu’au vu des mauvais résultats de cette posture, j’avais décidé de me positionner davantage comme « leader », de les guider, leur dire ce qu’est Scrum et ses règles, et je les ai priés de me faire confiance, en tant que pro (en substance).

Je voudrais, notamment, cesser de déplacer les cérémonies, à chaque Sprint, en fonction des indisponibilités de la P.O. (qui sont fréquentes)
Ce faisant (si j’arrive à convaincre l’équipe que c’est la bonne chose à faire!) je vais avoir des cérémonies où la P.O. ne sera pas présente.

De mon point de vue, et surtout si l’absence est prévue de longue date, dans ce cas, elle doit être remplacée par la personne de son choix. C’est elle qui peut déléguer son rôle, puisqu’elle reste « accountable » de sa mission et de son Product Backlog.

Qu’en pensez-vous?
Comment ça se passe chez vous?

Question subsidiaire : le seul argument que je sache avancer sur l’importance d’avoir les cérémonies toujours au même moment, c’est de réduire la complexité de leur organisation.
Et connaissant certains membres de mon équipe, ça ne suffira pas à justifier qu’on se passe de la P.O. en titre. Selon vous, y a-t-il d’autres arguments ?

Merci !

Je suis totalement en phase avec toi
Le scrum guide indique clairement que le PO est accountable de la valeur, mais qu’il peut déléguer son rôle
En tant que PO, parce que j’étais en vacances, il m’est arrivé de déléguer mon rôle pour un sprint planning au scrum master et à une partie prenante. C’était pas perfait parfait mais ça l’a fait.

Par rapport à tes questions. Pourquoi mettre les événements SCRUM à des moments réguliers ? :

Réduire la complexité organisationnelle induit réduire la charge mentale induit se concentrer sur l’essentiel = se concentrer sur le produit et non l’organisation autour du produit

2 « J'aime »

Si le PO est absent lors de la sprint review ou du sprint planning, il me donne les informations qu’il souhaite faire passer pour que je le « remplace » auprès de l’équipe (je suis Scrum Master). Il va être absent sur une durée plus longue cette été, il délègue donc une grande partie de son rôle au product manager. Pour le reste, il va s’avancer au maximum.

Pour la régularité des événements, en effet je ne vois que la simplification de l’organisation : si on bouge la sprint review ça veut dire s’assurer que les parties prenantes sont dispos, vérifier si une salle est libre, décaler la rétro et le sprint planning… Et il se passe quoi si c’est un dev qui est absent et pas la PO ? C’est moins important ? Et si la PO n’est pas dispo plusieurs jours de suite ? On modifie la taille du sprint ?
Etre régulier permet de bloquer le créneau longtemps à l’avance et tout le monde peut s’organiser en fonction (et donc refuser des réunions si besoin :wink: )

2 « J'aime »

Pourquoi tu dis que cette première posture à des mauvais résultats ? C’était quoi ton l’objectif avec cette posture ?

Changer de PO, est-ce une option ? Parce que s’il est régulièrement pas en mesure d’assurer ses responsabilités (peut importe pour quelles raisons) ça pose vraiment problème. Le produit et maximiser la valeur produite par l’équipe, devrait être son focus principal. Comment fait il s’il n’est pas en review pour les feedback, en rétro pour l’amélioration continue de l’équipe et en planning pour répondre aux questions de l’équipe et collaborer pour définir l’objectif, par exemple ?

Les événements au même moment, ça permet d’avoir des repères. Des adaptations pourquoi pas, mais ça devrait probablement être l’exception, ou à minima prévu dès le planning pour pouvoir faire un plan en tenant compte du temps imparti.

Après, tout dépend de l’amplitude des changements. Si c’est dans la même après midi, à une heure près, ça va encore, si c’est un changement de demi journée, mouais mouais, si c’est une journée ça commence à faire (sur un sprint de 2 semaine par exemple, mais, sur un sprint d’une semaine c’est encore plus impactant, car l’amplitude représente une plus grande part du sprint). En deux heures on en fait des choses en plus ou en moins, ça a donc des impacts sur le done et donc sur l’engagement et sur l’atteinte de l’objectif. L’adaptation en daily c’est quand même beaucoup plus pour s’adapter autour de ce qu’on apprend sur le produit que de s’adapter aux contraintes liées à l’organisation de l’équipe, cette organisation est censé être un cadre clair, qu’il n’y ai pas de question à se poser, ça permet de garder le focus au bon endroit.

Ces absences à répétition, ça dit quoi sur l’engagement du PO dans l’équipe ? Pour le produit ? Quel exemple ça donne et qu’est ce que ça autorise aux autres membres de l’équipe ? Est ce que la charte d’équipe autorise ce désengagement ?

De quels événements tu parles ? La review, le planning, la rétro, les trois :scream: ?

Chez nous, quand le PO n’est pas là (c’est à dire quand il est en vacances ou malade, parce que le reste du temps, les évènements sont prioritaires sauf très rare exception) - en planning le reste de l’équipe s’organise (on a une direction, on travaille les items en équipe, l’équipe prend des décisions éclairées par le sens donné et par les échanges que l’équipe a avec les parties prenantes) - en review c’est plutôt moi (SM) qui vais animer, mais en fait ça pourrait être n’importe quel membre de l’équipe - en rétro, s’il a pu laisser des choses à remonter on les prend en compte, sinon, ben on fait sans et il pourra consulter le mural de notre atelier de travail et le(s) action(s) dans le backlog produit et échanger avec l’équipe.

Voilà ce que j’en pense :blush:

4 « J'aime »

Merci Sophie,

Pour répondre à ta question, je replace le contexte :
Je suis arrivée dans cette entreprise et cette équipe il y a 6 mois, seulement, et c’est mon 1er poste comme S.M.

Je dirais qu’au début, il n’y avait pas d’objectif calculé. Ma posture était un mélange entre de la circonspection (j’observe d’abord), une grosse cuillérée de manque d’assurance et une immense foi dans l’intelligence collective et l’autogestion. Mais, après tout ce temps avec des progrès dérisoires vers le Scrum, et même un reproche qui m’a été directement adressé, j’ai réalisé que parfois, ce n’est pas d’autonomie, ni d’intelligence collective dont les gens ont besoin ou envie, mais d’un CADRE clair et rassurant. Comme les enfants.

Maintenant, je suis plus affirmative, et je trouve déjà que ça va mieux! :slight_smile:

En fait la P.O. nous a « avoué » tout récemment qu’elle avait beaucoup d’autres tâches très éloignées de ses tâches de P.O., et à moi, elle a carrément dit que ça l’arrangeait ainsi, que ses autres tâches l’intéressent beaucoup, et qu’elle n’avait pas l’intention de les sacrifier.

On sent qu’elle est en train d’organiser sa bascule sur un autre poste chez le client, pour se faire remplacer par une autre consultante qui vient de la même ESN qu’elle…
Bref.

Je ne connaissais pas la « Charte d’équipe ». Intéressant.Tu pourrais en dire plus?

Comme tu le soulignes, le PO est dans l’équipe mais avec un rôle précis.
Les absences sont naturelles et l’équipe doit en tenir compte.
En tant que SM, j’ai demandé aux membres d’identifier qui parmi eux, pouvait assurer le backup ; leur réponse unanime : celui qui maîtrise les tests. Il a pris le rôle avec beaucoup d’intérêt car dans les faits, il parle énormément avec le PO lors des séances des 3 amigos (PO+QA+Real).
Par la suite, il a tout fait pour se diriger vers le rôle de PO car cela lui plaisait beaucoup.

Concernant la partie des moments pour les cérémonies : idem, en tant que SM, l’un des concepts intangible que j’avançais était : – le rythme – car tout ce qui nous entoure est rythmé ;

  • les releases
  • les sprints
  • les minutes dans une heure
  • la terre autour du soleil
  • les nuits
  • le coeur …
    C’est sympa mais c’est pas encore suffisant comme argument.
    Non, le plus important à mon sens c’est de ne pas avoir à consulter son agenda :
    Les cérémonies tombent toujours aux mêmes moments suivant un rythme, une règle facile à retenir.
    J’avais placardé une feuille A3 pour représenter les moments des cérémonies visible de tous ceux qui passaient par là => transparence, communication, …
    Et, … AUCUNE dérogation ! Cela m’a valu une grosse remontrance des managers qui voulaient décaler une review parce qu’un Directeur n’était pas dispo. Que néni ! les parties prenantes aussi doivent s’organiser et assurer les backup ! (d’autant plus que le dit Directeur voulait venir en spectateur)
1 « J'aime »

Le Po est celui qui prend le lead sur le produit.
Il concentre les retours de toute part pour faire évoluer le PB.

Il est bienvenu aux cérémonies.
S’il est absent, en planning, ou de manière annoncée ou régulièrement, quelqu’un prend sa place.

Si le remplaçant n’a pas toutes les compétences, bienvenue au club de la formation continue. De toute façon, celui qui prétend avoir toutes les compétences est probablement un menteur.

Le côté cérémonial des cérémonies vise aussi à créer une habitude qui fait que l’on peut se concentrer sur quelques chose de plus important : l’objet de la cérémonie.

Ah ben je vois que @nicobiot le dit mieux que moi

Et @MarieMathivet aussi

1 « J'aime »

De son choix… ce n’est que le product owner ce n’est pas dieu. Si une équipe est dédiée au produit, l’équipe a son mot à dire, chacun au même poids que le P.O. en démission. L’équipe n’est pas un ensemble de pions.

Bien qu’on puisse faire pire, demander au manager de s’occuper de faire ce choix.

Oui, le travail de toute une équipe et les attentes de toute une flopée d’utilisateurs ne doit pas être tributaire de la disponibilité d’une personne.
Si la personne veut garder la main sur son produit, c’est à elle à se bouger pour se rendre disponible au rythme du reste.

Et, ça peut être très riche d’apprentissage, surtout si l’on n’oublie pas que le PO n’est pas celui qui sait, mais celui qui choisit.

Le tout c’est de garder le P.O. (impliqué) durant tout le sprint.

Ne pas oublier que tout changement dans l’équipe (PO, Dev ou SM) devrait justifier de refaire un team canevas pour valider ce nouvel esprit (et oui ça prend du temps, mais c’est pour ça que l’on veut une équipe stable.

Une équipe stable est plus importante qu’un projet stable.

C’est l’équipe qui fait le produit.

Deleguer ==> penser au delegation poker.

Changement dans l’équipe => penser à relire la matrice RACI ( dans la matrice d’une structure active, il faut mettre le nom et pas les étiquettes, parce que souvent le plus important n’est pas que tous les livrables du RACI soit réellement pris en charge et pas « celui qui devrait le faire de part son étiquette »

Nicolas, déléguer au SM me semble dangereux dans le sens où il ne maitrise que l’agilité et rien d’autre … il aide l’équipe à produire de la valeur ; c’est un servant leader dans l’organisation.
Je suis donc surpris qu’il ait accepté ce rôle.
Perso, en tant que SM, je dis toujours que je n’y connais rien ni au métier ni à la techno mais que l’agilité, ça, je connais ; les pros c’est l’équipe ! Je m’arrange toujours pour que ce soit l’équipe qui trouve les solutions à leurs problèmes.

1 « J'aime »

@Moosh, as-tu une ressource que tu recommandes sur le Team Canvas ?

Il me semble qu’il y a carrement une video sL sur le sujet

Team Canvas | Scrum.org

1 « J'aime »

Merci Frédéric pour ton témoignage.
Petite remarque : l’équipe et la P.O. elle-même ne souhaitent pas que qui que ce soit d’autre qu’elle, fasse les tests finaux, arguant du fait que si jamais c’était mal fait, ça nous retomberait dessus, qu’elle représente le client et que c’est donc à elle (ou à quelqu’un de chez le client) d’assumer cette partie-là…

Dans la mesure où la P.O. est « accountable » de son Product Backlog et de son rôle, il me semble normal qu’elle ait le dernier mot sur le choix de la personne à qui elle souhaite le déléguer.
Même si l’équipe peut en discuter.

2 « J'aime »

C’est quoi un « team canevas » stp?

C’est ça :

A remplir en équipe !

1 « J'aime »