Est-ce que quelqu'un d'autre pense que Scrum n'est pas agile?
Je suis un grand fan du 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érative, l'écriture de code autour d'un test, la programmation en binôme, avoir un client sur place pour gérer les choses. C'était un environnement de travail très productif et je n'ai jamais eu l'impression d'être sous pression.
Cependant, les derniers endroits où j'ai travaillé utilisent/ont utilisé Scrum. Je sais que c'est l'enfant de l'affiche pour le développement agile de nos jours, mais je ne suis pas convaincu à 100% qu'il est agile. Voici les deux principales raisons pour lesquelles cela ne me semble pas agile.
Les chefs de projet adorent ça
Les chefs de projet, qui de par leur nature sont obsédés par les délais, semblent tous aimer Scrum. D'après mon expérience, ils semblent utiliser le Sprint Backlog comme un moyen de suivre les exigences de temps et de garder une trace du temps passé sur 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 à estimer la durée d'une tâche alors que je peux simplement poursuivre la tâche elle-même. Ou de la même manière, pourquoi perdrais-je du temps à documenter la durée d'une tâche lorsque je peux passer à la tâche suivante.
Réunions standup
Les réunions de stand-up à l'endroit 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 donnerait un coup de tête et référencerait le Sprint Backlog comme un moyen de montrer que vous êtes incompétent pour ne pas respecter le calendrier.
Je comprends maintenant le besoin de communication, mais le ton des réunions quotidiennes devrait sûrement être léger et se concentrer sur le partage des connaissances. Je ne pense pas que cela devrait se transformer en une où est votre charade de style de devoirs. De plus, le point troublé de l'agilité est que les délais changent, ils ne doivent pas être gravés dans le marbre.
Conclusion
L'idée de l'agilité est d'améliorer le logiciel en facilitant la vie des développeurs. Par conséquent, à mon avis, tout processus agile utilisé par une équipe doit être dirigé par un développeur. Je ne pense pas qu'un gestionnaire de projet utilise un processus qu'il a étiqueté "agile" pour suivre un projet n'a rien à voir avec le développement agile.
Vous pensez à quelqu'un?
Oui. Même l'un des "pères" de l'agile n'est pas d'accord pour dire 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 regardé, Oncle Bob donne un bref historique de Scrum et dit essentiellement que Scrum n'est pas un processus de développement Agile parce que Scrum a évolué au fil du temps pour devenir un processus de gestion . Les raisons derrière cela semblent être parce que ce sont les chefs de projet, et non les développeurs, qui suivaient les cours Scrum.
Il y a certains éléments dans Scrum qui sont plus sujets à la perversion, mais pour être franc, ce que vous décrivez est le résultat d'essayer d'amener une organisation à adopter Scrum sans éduquer toutes les parties prenantes sur ce dont il s'agit, comment cela fonctionne et pourquoi cela fonctionne. Vous avez besoin de l'adhésion dans toute l'entreprise pour obtenir des résultats.
Toute transformation agile va exposer tout ce qui se passe dans votre organisation, y compris, mais sans s'y limiter, les microgestionnaires, les personnes assoiffées de pouvoir avec leurs propres programmes, les développeurs insuffisamment formés, les silos de communication, etc. S'il n'y a pas de volonté collective pour résoudre ces problèmes et vous venez de "faire des standups" et juste "travailler en sprints", l'implémentation Scrum va tomber à plat sur son visage.
Je ne saurais trop insister sur ce point: si vous voulez faire du Scrum, vous avez besoin d'entraîneurs compétents qui peuvent vous montrer le chemin. Il ne suffit pas de lire Essential Scrum et de voir ensuite où cela vous mène ...
Ce que vous décrivez est ce que nous, formateurs de Scrum professionnels, voyons beaucoup dans les organisations qui ont "implémenté Scrum". Souvent, ils "font XP dans l'équipe de développement" aussi, ce qui signifie qu'il y a quelques tests unitaires en cours d'exécution sur un serveur de build quelque part. Ce n'est pas de la mêlée.
Oui, les chefs de projet peuvent utiliser un backlog de produit, en particulier celui qui a été numérisé, pour abuser de l'enfer des mesures que ces systèmes rassemblent. Mais l'équipe de développement et le Scrum Master ne devraient pas le laisser faire. Que fait un chef de projet de toute façon? Cela ne devrait-il pas être un Product Owner?!
Tout comme XP peut être mal fait, et certains processus plus rigoureux peuvent sembler très fluides (avec une intégration, un déploiement continus, mais toujours très pilotés par le plan), Scrum est juste un framework. Il faut de bonnes personnes qui comprend les valeurs et le processus pour bien l'exécuter. Il faut Apprentissage continu une amélioration pour y arriver.
Vous vous attendiez probablement à celui-là, mais ce n'est pas parce que certaines (beaucoup?) Abusent de Scrum de manière non agile que Scrum n'est pas Agile.
Chef de projet : il n'y a pas un tel rôle dans une équipe Scrum. Le Scrum Master n'est pas responsable du budget ou du respect des délais. Il est responsable d'aider l'équipe et de supprimer tous les obstacles qui se dressent sur le chemin vers l'objectif auquel elle s'est engagée. D'après ce que vous décrivez, il semble que votre PM détourné Scrum pour prendre pour lui-même les prérogatives qui vont normalement à l'équipe et au Product Owner, perpétuant 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 de sprint, pas de point à temps = dépensé 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 orientée sur les objectifs.
Depuis le Scrum Guide :
Suivi des progrès du sprint
À tout moment dans un Sprint, le travail total restant dans le Backlog Sprint peut être additionné. L'équipe de développement suit ce travail total restant au moins pour chaque mêlée quotidienne pour projeter la probabilité d'atteindre l'objectif de sprint. En suivant le travail restant tout au long du Sprint, l'équipe de développement peut gérer sa progression.
scrum est une méthodologie gestion de projet
agile est une développement logiciel méthodologie (-ish)
scrum + agile fonctionne très bien
mêlée sans agilité ... pas tellement
Je vais énoncer des faits évidents, mais restez avec moi.
L'article de Takeuchi Nonaka dans HBR parle d'un processus de développement de nouveaux produits, ne parle pas de développement de logiciel agile, ne parle pas de Scrum tel qu'il est défini par Ken & Jeff:
Scrum (n): Un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive et créative des produits de la plus haute valeur possible. Scrum est: Léger, Simple à comprendre, Difficile à maîtriser.
Scrum est un cadre de processus qui a été utilisé pour gérer le travail sur des produits complexes depuis le début des années 1990. Scrum n'est pas un processus, une technique ou une méthode définitive. Il s'agit plutôt d'un cadre dans lequel vous pouvez utiliser divers processus et techniques. Scrum met en évidence l'efficacité relative de la gestion de vos produits et de vos techniques de travail afin que vous puissiez continuellement améliorer le produit, l'équipe et l'environnement de travail.
Le Manifeste Agile parle de développement logiciel Agile - c'est un manifeste - pas un framework, pas un processus.
Si vous évaluez Scrum par rapport aux valeurs et principes du Manifeste Agile, vous verrez qu'il convient.
Le Product Owner est propriétaire du Product Backlog. L'équipe de développement interfonctionnelle est propriétaire du backlog Sprint & Sprint. Il n'y a pas de gestionnaire de projet - comme répondu précédemment - c'est une mauvaise utilisation de Scrum et de son intention (Agile).
La transparence, l'inspection et l'adaptation sont les piliers de Scrum, qui se transforment en actions d'apprentissage et d'amélioration pour arriver à "Terminé".
Cela facilitera la vie des équipes de développement interfonctionnelles, mais non sans engagement, confiance, apprentissage et amélioration.
Donc ma réponse:
Un chef de projet n'est pas un propriétaire de produit - un propriétaire de produit connaît son produit et les besoins et priorités de l'entreprise/des clients. Il n'y a pas un seul projet qui gère le "processus" Scrum.
Pour moi, les choses signalées comme négatives et ce qui semblait être positif avec Extreme Programming (XP) sont deux choses différentes. XP pour moi, c'est plus sur les pratiques de développement logiciel bien que chevauchant quelque peu avec Scrum. Les cinq valeurs de XP sont communication, simplicité, feedback, courage et respect) ils fonctionneront donc évidemment avec Scrum. Scrum ne prescrit pas de pratiques de développement logiciel.
Scrum bien fait est agile - et dirigé par l'équipe de développement -, dans son incrément - Sprints.
Le stand-up quotidien (la mêlée quotidienne) est pour l'équipe de planifier les prochaines 24 heures et en ce que nous partageons tous ce que nous avons appris au cours des dernières 24 heures. Si cela ne prend pas plus de 15 minutes, il est évident que nous, l'équipe, devons également devenir grands dans cette communication - et cela ne nous interdit pas de soulever des problèmes avec les personnes concernées entre les deux - c'est ainsi que nous apprenons et nous améliorons. .
L'estimation et la documentation font également partie du processus d'apprentissage - qu'est-ce qui s'est passé qui a changé la chronologie, qu'est-ce que nous avons fait, c'était génial, qui a amélioré la chronologie - comment pouvons-nous continuer à le faire ou l'élever dans le prochain sprint, pourrions-nous avoir fait quoi que ce soit sur les choses qui ont eu un impact négatif sur la chronologie - quoi et comment, sinon nous l'avons intensifié - quoi, comment - pour continuer à apprendre et à s'améliorer. Logiciel de travail sur une documentation complète - bien qu'il y ait de la valeur dans les articles à droite, nous apprécions davantage les articles à gauche.
Donc, si vous avez un état d'esprit Agile et votre équipe aussi, alors c'est à vous de remettre les pendules à l'heure. Si l'organisation ne veut pas être agile et se transformer en une culture agile, il est préférable de passer à autre chose. Il existe de meilleures organisations sur le chemin vers une culture Agile qui a besoin et valorise vos compétences et votre état d'esprit Agile.