Discussion :

[shenron666]

Page 14 du scrum guide 2020 :
Note de fin
Scrum est gratuit et offert dans ce guide. Le cadre de travail Scrum, tel que décrit ici, est immuable. Bien
que la mise en œuvre uniquement de certaines parties de Scrum soit possible, le résultat ne sera pas du
Scrum. Scrum n'existe que dans sa totalité et peut fonctionner comme un conteneur pour d'autres
techniques, méthodologies et pratiques.

c'est bien ce que Ryu2000 a indiqué

Nous ne sommes pas obligé de suivre SCRUM à la lettre.
Il est possible de faire son propre système de gestion de projet agile.

en ce qui me concerne, le problème n'est pas la méthode
c'est son application
tantôt soi-disant "à la lettre"
tantôt adaptée à la sauce de tout un chacun
jamais respectée comme il faut

[ddoumeche]

je suis assez d'accord avec l'article.
scrum en tant que tel est une bonne méthodologie, mais comme chaque méthodologie c'est à elle de s'adapter à l'entreprise et non pas à l'entreprise de s'adapter à la méthodologie.
dans ma boite actuelle, toutes les semaines, on a :
- le daily (possiblement 3 par jour)
- une matinée complète de réunion à 35 personnes pour revoir le backlog (4 personnes max qui ont qqch à dire).
- lors des pocker planning, on doit estimer en story point, c'est tellement facile de comparer la création d'une table et la création d'un écran.
- pas de retrospective

Scrum n'est pas adapté aux grosses équipes, pas plus que les projets informatiques en général. Au delà de 8-10 personnes, le temps perdu en interactions croit géométriquement, et le meilleur moyen de couler un énorme projet est de rajouter des développeurs.
Réorganisez-vous en plusieurs équipes de 5 à 10, ou en binômes.
Utilisez le planning poker pour discuter des problèmes techniques entre développeurs, mais si chacun est un spécialiste de sa partie du programme uniquement, cela ne sert à rien. Décorrélez les services des IHMs pour augmenter la granularité et obtenir une meilleur estimation.

tous les 15 jours, une journée complète de réunion (démo, planning, ..).

Quand j'ose dire que ce n'est pas efficace, on me renvoie vers certains articles scrum disant que c'est la bonne manière de faire.

Pour moi, scrum, c'est le daily à max 2 minutes par personne
la démo, qui doit être bien préparée, avec un agenda du jour clair et précis.

4 équipes de 9 personnes faisant un daily meeting = (9-1)*2 = 16 minutes de "perdues" par personne et par jour

35 personnes faisant un daily meeting = (35-1)*2 ~= 1h10 de perdues par personnes et par jour.
35 personnes regardant le/la démo du collègue = 1/2 journée de perdue par personne par semaine.
Exercice : Faites le calcul du nombre de postes de travail que représentent ces 1h10 perdus par personne et par jour.

Voila ce que c'est que d'avoir des experts juniors envoyés par la SSII du coin. J'en ai connu, c'était des marchant de tapis.

Ici, on n'a jamais rien adopté de manière puriste, que ce soit ISO 9126, ou Scrum qui a des qualités mais beaucoup de défauts. On a toujours eu des équipes en compétition les unes avec les autres mais capable d'apporter des solutions à des problèmes, et se partager.
Et quand quelque chose n'allait pas, il y avait toujours un ingénieur pour la ramener et faire un scandale.