"On a arrêté Scrum non pas parce qu'on ne délivrait pas bien, mais pour délivrer encore mieux" Qu'en pensez-vous?

Bonjour à tous et à toutes,

Il y a quelques jours, j’ai un de mes collègues qui sait que je m’intéresse à Scrum, qui m’a envoyé ce post sur LinkedIn rédigé par par David Beck, coach agile.
Dans l’un des commentaires au post, il y a celui de Rudy Onfroy (CTO chez CapCar) que je trouve très intéressant et qui écrit ceci :

Scrum est très bien mais il ne faut pas non plus le voir comme le cadre « ultime ».

On a arrêté Scrum chez nous.

Non pas parce qu’on ne délivrait pas bien, mais pour délivrer encore mieux.

On a voulu être encore plus itératif.

On a arrêté de penser à la maille de l’objectif du sprint pour penser à la maille de chaque problématique.

On en fait rentrer de nouvelles en continu.

On conçoit développe et délivre en 2-3 jours maximum chacune d’elles.

On mesure, on analyse et on rajoute une pièce dans la machine si besoin.

Je te rejoint totalement sur les pratiques.

C’est impossible d’être agile sans les bonnes pratiques d’ingénierie par contre c’est totalement possible d’être agile sans Scrum :slightly_smiling_face:

(Loin de moi l’envie de « troller », mais) Qu’en pensez-vous ? Est-ce une bonne ou une mauvaise idée ? Est-ce que c’est parce que CapCar n’a pas (bien) compris Scrum et réussi à l’appliquer pour que ça (leur) soit bénéfique ? Ou est-ce que, au contraire, ils ont bien compris Scrum et (justement) compris que ça ne pouvait pas s’appliquer à leur(s) façon(s) de travailler, à leur vision, à leur entreprise, à leur organisation pour mieux produire ?
Est-ce que « penser à la maille de l’objectif du sprint » au lieu de « penser à la maille de chaque problématique » n’est pas un problème pour scrum ? Est-ce que, selon vous, ce changement de perspective aide (ou peut aider) à délivrer encore mieux comme le suggère Rudy Onfroy ?

Par ailleurs, le fait de faire rentrer des problématiques en continu, est-ce que c’est pas du Kanban du coup (en regard de cette vidéo sur la chaine Scrum life) ?

Merci pour votre avis :wink:

Bonne journée :wink:

Lors d’une formation avec un des plus anciens coach agile de France, qui était coach XP dans les années 2000+, on avait discuté d’un truc qui m’a beaucoup plu :
« Très souvent, le rôle même du Scrum Master est un blocage à l’auto-organisation d’une équipe, et que déléguer d’une autre manière ce rôle pourrait être une solution adaptée ». S’ensuivit une discussion sur d’autres modèles de gouvernances niveau leadership (« élections sans candidats » que j’ai proposé récemment dans une entreprise, par exemple) plutôt que d’avoir une seule personne qui a toujours cette responsabilité. Ca m’a fait beaucoup questionner le cadre, et j’en ai vu des choses qui ne me plaisent plus trop maintenant.

C’est top d’aller au delà de Scrum. C’est même sain de challenger des cadres ! J’ai aucune idée de comment fonctionne CapCar, mais j’aime beaucoup : ayons l’humilité nécessaire pour garder un esprit critique.

Y a des équipes où clairement, le fonctionnement de Scrum ne fonctionne pas. Rien de mal à ça, le problème c’est plutôt de s’entêter à continuer quelque chose qui ne fonctionne pas… Ce n’est qu’une manière de faire. Il en existe d’autres à découvrir !

1 « J'aime »

J’ai envie de dire qu’on s’en fout et que c’est un peu stérile. Si ielles ont testé et que ça marche, preuve à l’appui, tant mieux pour l’organisation. Ca en fait pas pour autant une généralité donc je ne saurais pas en tirer plus de conclusion que ça. Maintenant, si on me montre que 100 autres entreprises arrivent au même résultat avec la même approche, c’est plus la même crèmerie…

Alors là, à part avec un exemple, ça tiens de l’interprétation, donc je ne suis même pas sûr de comprendre ce que ça veux dire.

Bonjour,

C’est compliqué de juger avec si peu de détail.

Avec les informations qu’il donne, j’ai envie de dire que son objectif de sprint peu très bien être de répondre aux problématiques 1, 2 et 3 ce qui du coup reviens exactement au même.

La ou je n’ai pas de conviction mais plutôt des interrogations, c’est sur le fait de faire de très petites itérations 2-3jours. Est-ce qu’il n’y a pas une perte de temps à refaire les mêmes étapes si fréquemment?

Pour moi le fait d’avoir des sprints d’au moins 2 semaines, c’est pour optimiser certaines réunions et ça permet aux gens de développer sereinement sans être arrêté tous les 2 jours, ce qui peut clairement casser le rythme. Quand je développe une API en java, je pense a le faire en bulk et non pas en unitaire c’est bien pour optimiser. La ça revient au même pourquoi faire que 2-3jours? Ne peuvent-il pas charger plus pour optimiser leur temps de réunion? Des petits pas ces bien, mais trop petit n’est-ce pas contre productif?

As tu déjà tenté le sprint de 1 jours ? C’est très intéressant comme expérience :slight_smile:

Qu’est ce que « optimiser des réunions » veux dire ? Et pour ce qui est des développement, il me semble que tu t’arrêtes toutes les fins de journée non ? (sauf si tu es ChatGPT déguisé en internaute ? :astonished:)

Ah non jamais tenté, je garde ça en tête pour tester ça :slight_smile: !

Optimiser dans le sens :

  • Trouver un créneau qui correspond aux agendas de tout le monde, pour avoir les bons interlocuteurs et donc pouvoir atteindre l’objectif de réunion
  • Prévoir un créneau ou les gens se mettent dans l’état d’esprit adapté au point, par ex le refinement demande beaucoup de concentration et de remise en cause pour challenger ce qui est présenté. Si ce point n’est par ex que de 30 minutes, peut être qu’il peut être profitable de continuer sur d’autres sujet pour profiter que tous le monde soit chaud. Peut être même qu’en 30 minutes les personnes n’auront pas eu le temps de se chauffer et n’auraient alors que gratté la surface des sujets et loupé des dépendances a fort impact.

Pour les développements, personnellement quand je finis ma journée j’anticipe le lendemain. « Demain je pourrais enchaîner sur tel sujet, du coup si je prend ce sujet il faut que je vois telle chose avec untel, etc… ». Je vois les sprints comme un flow si on repart de 0 sur une nouvelle problématique le lendemain, je ne sais donc pas a quoi m’attendre je ne peux rien anticiper, je deviens donc passif ce qui est le contraire du but rechercher ou on veut que les gens se responsabilise et soit donc proactif.
Aussi certains développeurs n’aiment pas trop les réunions donc autant optimiser pour pouvoir leur laisser du temps au développement, c’est ça qu’il recherche, c’est la ou ils « s’éclatent »

Bonjour,

De mon expérience, je n’utilise pas une méthode ou un cadre, mais plusieurs. Cela dépend du besoin, et des problèmes à servir.

J’ai utilisé du lean management sur des processus PRINCE 2, du scrum avec des équipes produits, du kanban dans des équipes support, et peut-être d’autres choses demain …

Je ne sais pas ce que je vais apprendre, je ne sais pas ce qui est le mieux mais ce sera toujours celle que nous pensons être la plus efficace ensemble.

Par contre, je ne change pas de méthode ou de cadre sur un coup de tête !

C’est transcender Scrum.

Et si il n’y avait plus de réunion et que 100% du temps été consacré à agir ?

Ne plus penser au futur, mais plutôt au présent. Plus besoin d’anticiper ou prédire le futur.

Le moment présent.


Dans cette interview Rudy Onfroy nous livre les secrets de fonctionnement de son équipe de 10 développeurs.

Tu n’as pas besoin de sprint pour être agile - Rudy Onfroy, CTPO CapCar

Un jour SCRUM ne sera qu’un souvenir des dinosaures de l’informatique comme l’a été le cycle en V.

On parlera de la nouvelle méthode révolutionnaire ! Mais pour que cette methode voit le jour faut expérimenter c’est comme ca que je le vois.

ça ne veux littéralement rien dire :confused: Je suis sûr qu’on sera heureux d’apprendre qu’on peut bosser dans l’aérospatial sans « penser au futur ». Pas besoin de faire d’études, on découvrira tout sur le « moment présent ».

Toute équipe qui dit qu’elle ne fait pas de réunion ment. Même dans la vidéo que tu proposes, on parle de réunions utiles. Les formes que peuvent prendre les réunions sont diverses et variées, allant d’une discussion informelle, à un rituel de communication comme une sprint review ou un backlog refinement, en passant par du software-teaming. Mais elles sont impossibles à éviter, ou alors bonjour l’inefficacité et les hand-offs.

1 « J'aime »

C’est ça la méthode frug’agile :smile: ?

Je dirais plus le ultimate-waterfall, mais je saisis la blague :wink: