Discussion :

[Victor Vincent]

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

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

[transgohan]

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.

[Madmac]

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.

[Mimoza]

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é.

[fpignalet]

"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

[fpignalet]

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.

[JCD_31]

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.

[Bono_BX]

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) !

[captaindidou]

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.

[Saverok]

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é...

[Bono_BX]

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.

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.

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.

[Ryu2000]

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

En tout cas c'est mieux que le cycle en V

Si on applique la méthodologie à la lettre, ok c'est peut être pas top.
Mais si on est moins strict on peut faire quelque chose de géniale avec SCRUM.

Il y a beaucoup de retour du client, on comprend bien son besoin, il y a des objectifs à court terme, c'est plus motivant qu'une gestion pas agile, la pire gestion de projet ce serait "Tiens voilà le cahier des charges, je reviens dans 2 ans chercher le produit fini" et le client se rend compte qu'il a demandé des choses qu'il ne veut pas et qu'il a oublié des choses dont il a besoin, et de toute façon le besoin a changé en 2 ans.

L'important c'est d'être un peu agile dans sa gestion de projet, après on est pas obligé d'être ultra strict dans l'application de la méthode.

Essayez de respecter ça à fond :
Extreme programming

[JCD_31]

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é...

C'est aussi quelque chose que j'ai remarqué. La présence de confirmés dans une équipe SCRUM fait que la méthode fonctionne mieux, contrairement à KANBAN, par exemple.
Il y a aussi en amont de la réalisation : SCRUM nécessite que chaque tache soit estimée pour pouvoir faire la vélocité de sprint. Je peux vois assurer qu'un Sprint Planning avec des juniors ne sachant pas estimer engendre des débats sans fin. Je ne compte plus le nombre de fois où j'ai lâché l'affaire là dessus pour que ça aille plus vite...

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.

ça marche aussi dans d'autres domaines mais pas officiellement. J'ai testé les principes des méthodes agiles dans le domaine de l'artisanat et ça a plutôt bien fonctionné

[micka132]

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.

C'est pas vraiment vrai. Peut etre le terme "agile" est directement associé à l'informatique, mais la philosophie derrière existe dans d'autre domaine et depuis des dizaines d'années. Un exemple parfait est l'utilisation du Kanban. Mais ca va etre dur d'évangiliser en présentant un "vieux" truc de 70 ans comme une méthode révolutionnaire .

[jyves69]

Les méthodes de gestion de projet, pour moi, c'est comme les couverts :
On doit utiliser celui qui est le plus adapté ! (sinon, on sait ce que ça donne de ne pas en utiliser ....)
Critiquer une fourchette parce que c'est une fourchette n'a aucun sens.
Maintenant, connaître plusieurs méthodes permet de choisir la meilleure, adaptée à l'équipe, au client, au projet, au contexte... Car si on n'a qu'un marteau, on voit tous ses problèmes en forme de clou !

captainedidou => Pourquoi l'agilité n'est pas utilisé en dehors de l'IT ? => FAUX, j'ai mis en place avec succès l'agilité dans plusieurs autre domaines (Electronique, Marketing, ...). A votre disposition pour vous apporter tous complément.
Le fait est, qu'aujourd'hui, l'IT est de domaine qui utilise le plus de méthodes. Tant mieux ! A vous de jouer pour utiliser la meilleur méthode.

[JCD_31]

Les méthodes de gestion de projet, pour moi, c'est comme les couverts :
On doit utiliser celui qui est le plus adapté ! (sinon, on sait ce que ça donne de ne pas en utiliser ....)

C'est bien là le problème. C'est qu'on a pas forcément le choix. La plupart du temps, les méthodes et technologies sont imposées par des gens qui n'y comprennent rien...

[el_slapper]

C'est bien là le problème. C'est qu'on a pas forcément le choix. La plupart du temps, les méthodes et technologies sont imposées par des gens qui n'y comprennent rien...

à commencer par l'auteur de l'article. Je ne suis pas un fan de SCRUM(euphémisme), mais certaines circonstances peuvent en faire une méthode efficace. Le gars, il a essayé dans un contexte précis, ça s'est planté pour des raisons pas forcément claires, et il en déduit que c'est toujours de la merde. C'est comme si un entraineur de football disait que le 4-4-2 c'est de la merde parce-que le Brésil en 98 a perdu 3-0 contre la France en jouant en 4-4-2.

Donc, j'insiste, l'auteur de l'article n'y connait rien. On ne détermine pas la valeur d'une méthode largement utilisée par des expériences purement personnelles, ou par de beaux raisonnements. On le fait en faisant des statistiques, ce qui manque cruellement à l'article. Je suis à peu près sur que les projets SCRUM se plantent aussi souvent(mais pas plus souvent) que les autres, mais j'adorerais avoir des chiffres pour confirmer - ou infirmer - mon intuition.

[Ryu2000]

On ne détermine pas la valeur d'une méthode largement utilisée par des expériences purement personnelles, ou par de beaux raisonnements.

C'est un truc qu'on retrouve dans tous les topics de ce genre, en même temps c'est précisé dans le titre :

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

C'est juste l'avis d'un type random qui a écrit un message sur son blog...
Il ne faut pas y accorder trop d'importance, ce n'est que son point de vue personnel, ce n'est pas la vérité absolue.
Il y a des points qu'il n'aime pas dans SCRUM et il en fait part.

[micka132]

Je suis à peu près sur que les projets SCRUM se plantent aussi souvent(mais pas plus souvent) que les autres, mais j'adorerais avoir des chiffres pour confirmer - ou infirmer - mon intuition.

C'est surement vrai, on pourait meme se poser la question de l'utilité d'une méthodologie. N'est-ce pas juste un moyen d'avoir une cohérence dans une équipe, cohérence qui impacte forcément sur le bon déroulement du projet?

[Saverok]

On le fait en faisant des statistiques, ce qui manque cruellement à l'article. Je suis à peu près sur que les projets SCRUM se plantent aussi souvent(mais pas plus souvent) que les autres, mais j'adorerais avoir des chiffres pour confirmer - ou infirmer - mon intuition.

De part mon expérience personnelle, les risques d'échec avec les méthodes Agile (SCRUM ou autres) sont plus importants qu'avec les méthodes classiques du genre cycle en V.
Pour commencer, je précise que pour moi, les critères de réussite d'un projet tiennent en 3 points : satisfaction des utilisateurs (et non des donneurs d'ordres), le planning et le budget (dans cet ordre de priorité).
Si l'un des 3 points n'est pas au moins partiellement atteint, je considère, à titre personnel, que le projet est un échec.

Avec les méthodes Agile, on définit les spécificités détaillées au fur et à mesure du développement.
On ne démarre qu'avec une trame générale que l'on spécifie à chaque itération.
Cela implique de bien définir le contenu des sprints et d'avoir un product owner qui maîtrise parfaitement son sujet et déjà là, ce n'est pas gagné.
Idem côté développeurs / concepteurs, ils doivent avoir en permanence en tête que les fonctionnalités qu'ils développent peuvent être remises en cause à tout moment et ils doivent veiller à mettre en oeuvre le code le plus générique possible pour éviter de devoir tout réécrire à chaque fois et là encore, ce n'est pas si simple.
Lorsque l'on combine ces 2 points, on constate bien que les risques de dérives sont nombreux et qu'on peut se retrouver à la fin du nombre de sprint définit en ayant consommé 100% du budget avec une application inutilisable car avec les fonctions principales non totalement développées car le poduct owner aura passé trop de temps à peaufiner une fonction en délaissant les autres ou encore que les temps de dev s'allongent au fil des sprints car le code mis en place lors des premières itérations étaient trop spécialisés...
Le scrum master doit alors être particulièrement vigilant à garder toujours le cap et ce n'est pas évident car cela implique de cadrer le product owner qui est, le plus souvent, le client et ce dernier refuse / accepte mal, le plus souvent, qu'un prestataire lui donne des directives / le rappel à l'ordre / lui fixe des objectifs / ...