La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui
Répond un professionnel du secteur

Le , par Victor Vincent, Chroniqueur Actualités
Scrum est une méthode de développement agile qui a été créé dans le but d’obtenir de meilleurs résultats dans les meilleurs délais. Elle se fonde sur plusieurs principes, des rôles fixes, des réunions officielles et des listes. Scrum permet de mener à bien des projets dont les besoins sont difficiles à quantifier dès le début. C’est l’une des principales forces qui ont contribué à sa popularité. Elle comporte cependant des inconvénients comme toute méthode. Scrum est adaptée aux équipes de petite taille, par conséquent des difficultés peuvent être rencontrées s’il s’agit de projets dont la taille de l’équipe est assez importante.


Scrum présente le risque de voir les fonctionnalités s’étendre indéfiniment ou « Scope Creep ». À moins qu’une date de fin soit définie de manière formelle, les parties prenantes peuvent être tentées de rajouter des fonctionnalités. Par ailleurs, si une tâche n'est pas bien définie, l'estimation des coûts et du temps du projet ne sera pas exacte. Dans ce cas, la tâche peut être répartie sur plusieurs sprints.

La méthodologie Scrum est étiquetée comme « carrée ». En effet, elle ne supporte pas des modifications dans son principe. On peut lire sur le guide officiel que « les rôles, les artefacts, les événements et les règles de Scrum sont immuables et bien que l'implémentation de certaines parties de Scrum soit possible, le résultat n'est pas Scrum. Scrum n'existe que dans son intégralité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques. »

Ce manque de flexibilité peut être constaté par exemple dans la définition du PBI « Product Backlog Item », qui est sous la responsabilité du Product Owner. En cas de manque de communication, les membres de l’équipe n’auront pas la possibilité d’apporter des améliorations à la définition des produits. Le guide de Scrum ne définit pas formellement une méthode de gestion des bogues, de réduction de la dette technique.

Le fait d’imposer un système de gestion de temps constitue également une contrainte. Tous les événements sont conditionnés dans le temps. Une fois qu'un Sprint commence, sa durée est fixe et ne peut être raccourcie ou allongée. Le Daily Scrum est fixé sur une durée de 15 min. Ce mode de fonctionnement ne favorise pas, une gestion de temps propre à chaque membre de l’équipe et par conséquent réduit les possibilités d’innovation et d’optimisation.

Enfin la méthode SCRUM s’adapte difficilement aux outils de gestions de tâches (JIRA, TFS,…) qui imposent des interprétations très bureaucratiques de Scrum. Ce qui induit une perte de temps pour les développeurs. Vis-à-vis des développeurs, le fait de splitter les tâches en petits éléments qui peuvent théoriquement être complétés par n’importe qui dans l’équipe réduit le sentiment de fierté et d’appropriation de la réalisation des tâches. Tous ces points faibles de la méthode ont poussé Adam Ard, un professionnel de la programmation, à affirmer que Scrum est une mauvaise méthode pour la gestion de projet agile.

Source : Billet de blog

Et vous ?

Pensez-vous que Scrum est une mauvaise méthode pour la gestion de projet agile ? Pourquoi ?

Voir aussi

Le département américain de la défense adopte agile et la méthode Scrum sous les conseils de Jeff Sutherland inventeur de Scrum

Project Open 4.0 disponible. La solution open source de gestion de projets s’intègre mieux avec SharePoint et introduit le support de Scrum


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 22/04/2018 à 19:33
Moi je dirai plutôt que cette méthode a ses défauts comme toute autre méthode.
S'il existe plusieurs méthodes c'est justement parce qu'aucune n'est parfaite.
Chaque méthode va s'appliquer plus facilement à un contexte et à un projet particulier. Voir à une équipe.

Donc génériquement je répondrai que non, elle n'est pas une mauvaise méthode de gestion de projet, car tout dépend du projet.
Elle apporte des avantages par rapport à d'autres méthodes, mais effectivement aussi des inconvénients.
Avatar de Madmac Madmac - Membre éclairé https://www.developpez.com
le 22/04/2018 à 20:35
La méthode est presque secondaire. Parce que les principales causes de délai et dépassement de coût sont:

- Les changements du cahier de charge, en cour de projet.
- Les deuxièmes cause est le cas où l'entreprise a sous-estimé le niveau de difficulté du projet.
- Enfin des projets qui sont tenté avec des technologies ou des versions qui ne sont pas mature.

En général, si on part le projet en partant des bases de données ont peut établir si le projet est réalisable, selon les critère du cahier de charge, très tôt.
Avatar de Mimoza Mimoza - Membre actif https://www.developpez.com
le 22/04/2018 à 21:10
L'avis de ce «professionnel» est tout personnel. Il a peu être eu une mauvaise expérience avec cette méthode mais la plus part (voir tous) les inconvénients qu'il décrit relève d'expériences très personnelles et qui AMHA l'ont été avec une mauvaise pratique de Scrum. On peut trouver des centaines/milliers d'autre «professionnel» qui diront exactement l'inverse.
Bref un avis parmi tant d'autre, a ne surtout pas prendre comme parole de vérité.
Avatar de fpignalet fpignalet - Candidat au Club https://www.developpez.com
le 23/04/2018 à 8:18
"le fait de splitter les tâches en petits éléments qui peuvent théoriquement être complétés par n’importe qui dans l’équipe réduit le sentiment de fierté et d’appropriation de la réalisation des tâches"
Oooooh, pauvres choux...
Nan mais sérieux, ce "sentiment de fierté" devrait venir UNIQUEMENT de la propreté du code realisé. L'"appropriation" d'une tâche signifie presque toujours un code dégueu et abscons compréhensible uniquement par son géniteur
Avatar de fpignalet fpignalet - Candidat au Club https://www.developpez.com
le 23/04/2018 à 8:19
Citation Envoyé par Mimoza Voir le message
L'avis de ce «professionnel» est tout personnel. Il a peu être eu une mauvaise expérience avec cette méthode mais la plus part (voir tous) les inconvénients qu'il décrit relève d'expériences très personnelles et qui AMHA l'ont été avec une mauvaise pratique de Scrum. On peut trouver des centaines/milliers d'autre «professionnel» qui diront exactement l'inverse.
Bref un avis parmi tant d'autre, a ne surtout pas prendre comme parole de vérité.
Ouais, tout pareil d'accord.
Avatar de JCD_31 JCD_31 - Membre régulier https://www.developpez.com
le 23/04/2018 à 8:48
Citation Envoyé par transgohan Voir le message
Moi je dirai plutôt que cette méthode a ses défauts comme toute autre méthode.
S'il existe plusieurs méthodes c'est justement parce qu'aucune n'est parfaite.
Chaque méthode va s'appliquer plus facilement à un contexte et à un projet particulier. Voir à une équipe.

Donc génériquement je répondrai que non, elle n'est pas une mauvaise méthode de gestion de projet, car tout dépend du projet.
Elle apporte des avantages par rapport à d'autres méthodes, mais effectivement aussi des inconvénients.
Entièrement d'accord. Cela dépend du contexte.

Cela fait 8 ans que je fais de l'agile. Les 6 première années, j'ai fonctionné en SCRUM et cela convenait parfaitement. Depuis 2 ans, je suis sur un projet aussi SCRUM mais dont la méthode ne fonctionne pas, où je tombe dans certains des travers cités par l'auteur. Du KANBAN aurait été mieux approprié, par exemple.
Ce n'est pas une généralité.
Je noterais aussi un très gros point à soulever qui fait que la méthode fonctionne ou non : la motivation et les objectifs des parties prenantes.
Avatar de Bono_BX Bono_BX - Membre confirmé https://www.developpez.com
le 23/04/2018 à 10:06
Hum, ce professionnel ne me semble pas très compétent dans le domaine de l'Agilité, pour donner ce genre d'opinion ...
La principale réponse à ses remarques est la compétence du chef de projet / Scrum Master et de son équipe.

Scrum présente le risque de voir les fonctionnalités s’étendre indéfiniment ou « Scope Creep ». À moins qu’une date de fin soit définie de manière formelle, les parties prenantes peuvent être tentées de rajouter des fonctionnalités.
Comme dans toute méthode, en fait. On ne fait pas de développement pour le plaisir, mais parce qu'il y a un besoin ; pourquoi ? Parce qu'un dev, ça a un coût. Donc tant qu'il y a un besoin et du budget, on fait le dev. C'est au métier de définir son besoin, et un bon chef de projet doit être capable de le challenger dessus.

Par ailleurs, si une tâche n'est pas bien définie, l'estimation des coûts et du temps du projet ne sera pas exacte. Dans ce cas, la tâche peut être répartie sur plusieurs sprints.
Même chose, cela se produit quelque soit la méthode. L'avantage de l'Agile, c'est que ça apparaît plus vite, justement parce que la tâche s'étale sur plusieurs sprints. C'est aussi un gros point fort, via la vélocité : si on déborde, que l'on a mal chiffré, ça va faire chuter la vélocité, représentant les événements imprévus et, grâce aux points de complexité, ce risque sera pris en compte lors des futurs chiffrages.

La méthodologie Scrum est étiquetée comme « carrée ». En effet, elle ne supporte pas des modifications dans son principe.
Dans "chef de projet", il y a "chef", et dans "Scrum Master", il y a "Master". Coco, c'est à toi de t'imposer et de changer ce qui ne te convient pas. Voir ma remarque du début.

Ce mode de fonctionnement ne favorise pas, une gestion de temps propre à chaque membre de l’équipe et par conséquent réduit les possibilités d’innovation et d’optimisation.
C'est quoi le rapport avec la choucroute ? Il faudra que je lise l'article original, la traduction est peut être ambigüe.

Enfin la méthode SCRUM s’adapte difficilement aux outils de gestions de tâches (JIRA, TFS,…) qui imposent des interprétations très bureaucratiques de Scrum.
Heu ... non, ce sont des outils paramétrables avec des templates de base. Encore un problème de compétence, pas de méthode.

Quand à l’orgueil des devs ... qu'ils grandissent un peu (et je précise que j'en suis un) !
Avatar de captaindidou captaindidou - Membre confirmé https://www.developpez.com
le 23/04/2018 à 11:31
Je n'ai jamais entendu autant de critiques à propos d'une méthode de développement que sur les méthodes agiles. Et cela ne date pas d'hier. Chaque année sur ce site, par exemple, des voix s'élèvent.

Pourquoi donc si elles sont si efficaces, elles ne sont pas reprises dans tous les secteurs de l'ingénierie ? Pourquoi seule l'informatique l'a adoptée ?

Je trouve aussi étrange les commentaires qui consistent à se borner à dire : "S'il critique la méthode, c'est parce qu'elle a été mal appliquée." Combien de fois, on l'a entendu. Faute de preuve, ce sont des propos gratuits. En tous cas qui n'ont pas beaucoup de valeur.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 23/04/2018 à 11:32
Je n'ai jamais rencontré aucun méthode parfaite que je puisse appliquer à la lettre du début à la fin d'un projet.
Comme dit par d'autre, chaque projet est différent de même pour les équipes métiers, le client, l'équipe de dev ainsi que du CP.
Ce qui compte avant tout, c'est que le CP soit à l'aise avec la méthode qu'il décide d'appliquer car c'est lui qui en sera le garant et animera l'ensemble des intervenant autour de cette méthode.

Personnellement, je pioche un peu dans toutes les méthodes et j'en garde ce qui m'intéresse.
Mieux encore, j'applique certaines choses à certains stades du projet et pas à d'autres et de même d'un projet à l'autre.
Bref, je m'adapte à la situation.

Concernant SCRUM spécifiquement, je lui trouve pas mal de qualité mais un défaut majeur : l'équipe doit être constituée principalement voir exclusivement de développeurs et concepteurs confirmés.
C'est trop complexe pour des juniors.
Avoir en tête que chaque fonctionnalité peut être constamment remise en question implique de développer un code particulièrement générique / adaptatif pour limiter au maximum les impact.
Ce type de gymnastique n'est pas aisé pour des débutants.
Et je ne sais pas pour vous, mais je n'ai pas eu ce luxe très souvent sur les projets auxquels j'ai participé...
Avatar de Bono_BX Bono_BX - Membre confirmé https://www.developpez.com
le 23/04/2018 à 11:48
Citation Envoyé par captaindidou Voir le message
Pourquoi donc si elles sont si efficaces, elles ne sont pas reprises dans tous les secteurs de l'ingénierie ? Pourquoi seule l'informatique l'a adoptée ?
Très bonne remarque ; précisément parce que les méthodes agiles ont été conçues pour l'informatique, et rien d'autre. A l'origine, le cycle en V vient des secteurs d'ingénierie "traditionnels" (BTP, génie civil), et l'agile est une tentative de combler les manques de ces méthodes aux spécificités de l'informatique.

Citation Envoyé par captaindidou Voir le message
Je trouve aussi étrange les commentaires qui consistent à se borner à dire : "S'il critique la méthode, c'est parce que ça l'a été mal appliqué." Combien de fois, on l'a entendu. Faute de preuve, ce sont des propos gratuits. En tous cas qui n'ont pas beaucoup de valeur.
L'inverse est aussi vrai : a-t-il des preuves que les méthodes agiles sont mauvaises ?

Traînant ma bosse dans le développement depuis pas mal de temps, j'ai vu des projets réussir et échouer avec les méthodes traditionnelles comme agile ; c'est pour cela que je pense que le première cause, c'est la compétence, pas la méthode.
Je ne suis pas un grand fan de Scrum (je lui préfère XP, que j'ai même tendance à adapter), mais je n'ai jamais vu non plus de bon argumentaire de ceux disant que c'est une mauvaise méthode. La vérité se trouve entre les deux, et l'agile étant par définition non rigide, il faut savoir l'adapter au besoin.

Citation Envoyé par Saverok
Concernant SCRUM spécifiquement, je lui trouve pas mal de qualité mais un défaut majeur : l'équipe doit être constituée principalement voir exclusivement de développeurs et concepteurs confirmés.
C'est trop complexe pour des juniors.
Avoir en tête que chaque fonctionnalité peut être constamment remise en question implique de développer un code particulièrement générique / adaptatif pour limiter au maximum les impact.
Ce type de gymnastique n'est pas aisé pour des débutants.
C'est pour cela que l'on préconise le pair-programming, l'idéal étant au moins un confirmé. Malheureusement, aujourd'hui on lui préfère les code review, ce qui est au final beaucoup moins productif, malgré les apparences.
Contacter le responsable de la rubrique Accueil