c'est bien ce que Ryu2000 a indiqué
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
Version imprimable
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.
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.