Est-ce que quelqu'un d'autre pense que Scrum n'est pas agile?

41

Je suis un grand fan de développement agile et j'ai utilisé XP sur un projet très réussi il y a quelques années. J'ai tout aimé, l'approche de développement itératif, l'écriture de code autour d'un test, la programmation en binôme, la présence d'un client sur site. C'était un environnement de travail très productif et je ne me suis jamais senti sous pression.

Cependant, les derniers endroits où j'ai travaillé ont utilisé / utilisé Scrum. Je sais que c'est aujourd'hui le modèle de développement agile, mais je ne suis pas convaincu à 100% que c'est agile. Vous trouverez ci-dessous les deux principales raisons pour lesquelles cela ne me semble pas agile.

Les gestionnaires de projet l'adorent

Les gestionnaires de projet, qui sont par nature obsédés par les échéances, semblent tous aimer Scrum. D'après mon expérience, ils semblent utiliser le backlog de Sprint comme moyen de suivre les exigences de temps et de consigner le temps consacré à une tâche donnée. Au lieu d'utiliser un tableau blanc, ils utilisent tous une feuille Excel que chaque développeur est tenu de remplir religieusement.

À mon avis, c'est beaucoup trop de documentation / de suivi du temps pour un processus agile. Pourquoi devrais-je perdre du temps à évaluer combien de temps une tâche va me prendre alors que je peux simplement m'occuper de la tâche elle-même. Ou de la même manière, pourquoi perdrais-je du temps à documenter le temps que prend une tâche pour pouvoir passer à la tâche suivante?

Standup Réunions

Les réunions à la place précédente où je travaillais étaient un cauchemar. Chaque jour, nous devions expliquer ce que nous avions fait hier et ce que nous allions faire ce jour-là. Si nous dépassions notre "estimation" de temps pour une tâche, le chef de projet créerait une odeur nauséabonde et ferait référence au Backlog de Sprint comme moyen de démontrer qu’il était incompétent de ne pas respecter la chronologie.

Maintenant, je comprends le besoin de communication, mais le ton des réunions quotidiennes devrait être léger et se concentrer sur le partage des connaissances. Je ne pense pas que cela devrait se transformer en une charade de style de devoirs. Aussi, le point le plus troublant de l'agilité est que les délais changent, ils ne devraient pas être figés.

Conclusion

L'idée de l'agile est d'améliorer le logiciel en simplifiant la vie des développeurs. Par conséquent, à mon avis, tout processus agile utilisé par une équipe devrait être dirigé par un développeur. Je ne pense pas qu'un chef de projet utilise un processus étiqueté "agile" pour suivre un projet n'a rien à voir avec le développement agile.

Pensées quelqu'un?

agile scrum

— Winarama
source

6

En mêlée, les équipes doivent être autogérées. L’objectif du chef de projet est d’éliminer en fin de compte son rôle afin que l’équipe organise et assiste seule aux réunions quotidiennes. Le rôle de gestionnaire de projet devrait idéalement être éliminé pour pouvoir assister à des réunions de planification et rétrospectives et gérer tout le travail organisationnel.

— SuperM

7

Oui. Même l' un des « pères » de agile ne pense pas que Scrum est vraiment agile: youtube.com/watch?v=hG4LH6P8Syk

— Euphoric

18

Donc, ce que vous dites, c'est que vous ne faites pas Scrum, et vous en êtes conscient, mais vous êtes étonné que Notscrum soit aussi Notagile?

— pdr le

2

Je n'ai jamais passé plus de temps dans les réunions à parler de processus que chaque équipe "agile" à laquelle j'ai participé. Mais je l’aime toujours beaucoup mieux que l’alternative.

— Rob

11

D'après mon expérience, Scrum est essentiellement une tentative visant à donner à Waterfall un aspect agile en la divisant en unités plus petites. En fait, les sprints devraient être appelés de manière plus réaliste "cascades".

— Berislav Lopac

25

Dans Scrum, certains éléments sont plus enclins à la perversion, mais pour être franc, ce que vous décrivez est le résultat de la tentative visant à amener Scrum à adopter une organisation sans informer toutes les parties prenantes de son fonctionnement. et pourquoi ça marche. Pour obtenir des résultats, vous devez obtenir l'adhésion de l'ensemble de l'entreprise.

Toute transformation agile va exposer tout ce qui ne va pas dans votre organisation, y compris, sans toutefois s'y limiter, les microgestionnaires, les personnes pimpantes qui ont leur propre agenda, des développeurs insuffisamment formés, des silos de communication, etc. S'il n'y a pas de volonté collective de résoudre ces problèmes et vous ne faites que "faire des redressements" et juste "travailler dans des sprints", l'implémentation de Scrum va tomber à plat.

Je ne saurais trop insister là-dessus: si vous voulez faire Scrum, vous avez besoin d’entraîneurs compétents qui peuvent vous montrer le chemin. Il ne suffit pas de lire Essential Scrum pour voir ensuite où cela vous mène ...

— Stefan Billiet
source

16

En quoi les relevés quotidiens sont-ils différents de la microgestion?

— Giorgio

10

Les tâches incombent à l'équipe pour organiser son temps de manière à ne pas se gêner. Il est tout à fait inapproprié de parler d’estimations, du temps écoulé pour des tâches antérieures, etc.

— Julia Hayward

10

@ Georgio: cela dépend de ce que vous entendez par microgestion. L’objectif d’un stand-up quotidien dans SCRUM est de tenir tout le monde au courant de ce que font les autres, et non de donner l’occasion à un chef de projet de châtier des personnes qui ne respectent pas les estimations. En fait, il n’existe aucun chef de projet dans SCRUM, le suivi et l’ajustement des estimations incombent à l’équipe. Si la question n’est pas remplie, la question à poser est "quelle en est la cause et comment pouvons-nous l’éviter ou le permettre à l’avenir? ", pas" à qui la faute et à quel point pouvons-nous le faire sentir? "

— Michael Borgwardt

3

@ErikReppen, comme il est à peu près tout, vous avez un petit groupe de personnes qui propose une amélioration digne de ce nom, puis vous obtenez un groupe beaucoup plus grand qui veut le monétiser et le pervertit complètement :-p je crois en Scrum, mais je me démarque complètement de Scrum Alliance et de son entreprise de certification.

— Stefan Billiet

8

@ jessehouwing: Oui, mais imposer des réunions à une équipe mature, c'est comme si on s'approchait de quelqu'un qui sait parfaitement marcher et lui dire: regarde, tu as un problème, tu ne peux pas marcher, je vais t'apprendre à marcher correctement. Ces gens vont vous regarder et se demander: Hé, qu'est-ce que ce gars veut de moi? Bien sur que je peux marcher. Ainsi, imposer des réunions quotidiennes à une équipe mature et auto-organisée ne perturbe que leur travail: il ne s'agit que de gaspillage. Une telle décision peut être expliquée par une direction incompétente ou par la volonté d’observer / de contrôler le fonctionnement de l’équipe.

— Giorgio

20

Oui. Même l'un des "pères" de l'agile ne convient pas que Scrum est vraiment agile: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

Je pense que ce lien de l'un des commentaires ci-dessus dit vraiment tout. Cela vaut la peine d'être surveillé, Oncle Bob donne un bref historique de Scrum et indique que Scrum n'est pas un processus de développement agile , car Scrum a évolué avec le temps pour devenir un processus de gestion . Les raisons derrière cela semblent être que ce sont les chefs de projet, et non les développeurs, qui suivaient les cours Scrum.

— Winarama
source

2

Ceci (ce que vous avez écrit, pas ce que dit oncle bob) est un non séquentiel. Le simple fait que quelque chose soit un processus de gestion ne le rend pas intrinsèquement non-agile.

— Dave Hillier

9

Vous pouvez avoir des chats bruns et des chiens bruns, mais un chat brun ne peut jamais être un chien brun. Ce n'est pas parce que ce n'est pas brun, c'est parce que ce n'est pas un chien. De même, un processus de gestion Agile ne peut pas être un processus de développement logiciel Agile, non pas parce qu'il n'est pas agile, mais parce qu'il ne s'agit pas d'un processus de développement logiciel, c'est ce dont nous parlons.

— Winarama

1

Ensuite, vous voudrez peut-être mettre à jour votre question intitulée "Est-ce que quelqu'un d'autre pense que Scrum n'est pas agile?"

— Dave Hillier

Merci de partager la vidéo. J'ai trouvé cela très instructif.

— MickJ

Bien, les gestionnaires comme agiles en abusent même. Donc, ils peuvent blâmer les développeurs. Donc, en utilisant agile, que ce soit faux ou pas, c'est un problème de rectitude politique.

— Amour

13

Ce que vous décrivez, c’est ce que nous, formateurs Scrum professionnels, voyons beaucoup dans les organisations qui ont "implémenté scrum". Souvent, ils font aussi "XP dans l'équipe de développement", ce qui signifie qu'il y a quelques tests unitaires en cours d'exécution sur un serveur de construction quelque part. Ce n'est pas scrum .

Oui, les chefs de projet peuvent utiliser un carnet de produit, en particulier un fichier numérisé, pour exploiter de manière démesurée les métriques recueillies par de tels systèmes. Mais l'équipe de développement et le Scrum Master ne devraient pas le laisser faire. Qu'est-ce qu'un chef de projet y fait de toute façon? Cela ne devrait-il pas être un propriétaire de produit ?!

Tout comme XP peut être mal géré et que certains processus plus rigoureux peuvent sembler très fluides (intégration continue, déploiement, mais toujours très planifiés), Scrum n’est qu’un framework. Il faut de bonnes personnes qui comprennent les valeurs et le processus pour bien l’exécuter. Il faut l' apprentissage continu une amélioration pour y arriver.

— jessehouwing
source

12

Vous vous attendiez probablement à cela, mais ce n'est pas parce que certaines personnes (nombreuses?) Abusent de Scrum d'une manière agile que Scrum n'est pas agile.

Chef de projet : ce rôle n'existe pas dans une équipe Scrum. Le Scrum Master n’est pas responsable du budget ni du respect des délais. Il est responsable d'aider l'équipe et de supprimer tous les obstacles qui les empêchent d'atteindre l'objectif pour lequel ils se sont engagés. D'après ce que vous décrivez, il semble que votre Premier ministre ait détourné Scrum pour qu'il prenne pour lui-même des prérogatives qui vont normalement à l'équipe et au Product Owner, perpétuant ainsi les anciennes habitudes de commande et de contrôle.

Suivi du temps : Scrum recommande de suivre le temps restant et de le résumer pour déterminer le statut du sprint, et non pas le temps passé par les membres individuels de l'équipe. Cela peut sembler un détail, mais fait toute la différence entre une culture axée sur le blâme et une approche axée sur les objectifs.

Du guide Scrum :

Suivi de la progression du sprint

À tout moment dans un sprint, le travail total restant dans le backlog de sprint peut être additionné. L'équipe de développement suit le travail total restant au moins pour chaque Daily Scrum afin de projeter la probabilité d'atteindre l'objectif Sprint . En suivant les travaux restants tout au long du sprint, l’équipe de développement peut gérer ses progrès.

— guillaume31
source

Il est inévitable de devenir une culture axée sur le blâme même Scrum est 100% politiquement correct en théorie.

— Amour

2

Scrum est une méthodologie de gestion de projet

agile est une méthodologie de développement logiciel (-ish)

Scrum + Agile fonctionne très bien

scrum sans agile ... pas tellement

— Steven A. Lowe
source

3

Il est intéressant de noter que Scrum était une méthodologie de développement de logiciels, mais que, avec le temps, il a évolué pour devenir une méthodologie de gestion de projet.

— winarama

2

Je pense que c'est un peu inévitable. Les développeurs n'ont tout simplement pas autant de sens de propriété dans le processus (ne le veulent pas). Récemment, dans une revue de sprint, j’ai remis en question l’objectif de l’équipe: écrire un logiciel ou faire en sorte que le graphique de burndown soit beau. Je me suis fait comprendre, mais tous les membres du PM présents dans la salle ont dû faire de leur mieux pour souligner l’importance de bla bla bla. lol!

— Rob

2

@ T-Pane: Encore plus intéressant que Scrum ait été proposé à l'origine comme méthodologie de développement de nouveaux produits - hbr.org/1986/01/the-new-new-product-development-game/ar/1

— Steven A. Lowe

2

@ StevenA.Lowe Ah Scrum, c'est un voyage de découverte de soi.

— winarama

1

Je sais que c'est vieux mais cette réponse est complètement fausse. Scrum est un cadre dans lequel les motifs doivent s’intégrer. Agile est un ensemble de valeurs et de principes.

— Venture2099