IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas,
Selon Gene Bond, directeur exécutif chez iiSM.ORG

Le , par Bill Fassinou

1.6KPARTAGES

27  1 
Scrum est une méthode Agile dédiée à la « gestion de projet ». Cette méthode de gestion est également appelée framework de management de projet. L’objectif de Scrum est d’améliorer la productivité d’une équipe. Elle est utilisée par plusieurs organisations à travers le monde, dont certaines ont témoigné de son efficacité. Cependant, d’après Gene Bond, directeur exécutif chez iiSM.ORG, une organisation dont la mission est de faire progresser la carrière des leaders du logiciel à tous les stades, la méthode Agile Scrum ne marche pas. Elle fonctionnerait dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas. Voici un aperçu de son argumentation.

Scrum est une méthode connue pour organiser le développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Scrum est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile. Toutefois, s’agit-il d’une méthode adaptée à tous les types d’entreprises ? Ou plutôt, Scrum fonctionne-t-il dans tous les cas d’utilisation ?


Gene Bond, directeur exécutif chez iiSM.ORG

Bond pense que non. « Oui, je comprends qu'Agile Scrum fonctionne bien pour 15 % des équipes qui le pratiquent. Mais comment appelle-t-on une chose quand elle échoue 85 % du temps ? Je crois que c'est ce qu'on appelle un échec », a-t-il déclaré. Selon lui, les créateurs de cette méthode l’ont fait dans un objectif précis, sans vraiment penser à toutes les sortes d’organisations qui étaient là ou qui ont vu le jour plus tard. Il estime que la taille unique ne correspond pas à toutes les équipes. Ce qui, dès le départ, aurait été clairement démontré par les créateurs de Scrum.

« Agile Scrum n'a jamais été conçu comme une solution unique. C'est pourquoi le mouvement a été fondé par des programmeurs pratiques, des codeurs propres, des programmeurs extrêmes, des partisans du RAD et du RUP, eh oui, des défenseurs de Scrum. Dernièrement, nous avons ajouté au panthéon Agile la programmation allégée, qui est un ajout très apprécié », a-t-il déclaré. Selon Bond, aucune de ces solutions n’a malheureusement pas été conçue pour être universelle. Pour Bond, Scrum échoue, car la plupart des organisations le perçoivent comme la solution idéale quand leurs équipes commencent à rencontrer des problèmes d'efficacité.

En d’autres termes, certaines organisations espèrent y trouver une solution magique pour la gestion du développement : des flux de création de logiciels qui peuvent être facilement mis à l’échelle, mais aussi des flux qui facilitent l'adaptation aux exigences changeantes tout en garantissant la responsabilité. De ce fait, les gens vendent Agile comme un concept (ce qui n'est pas souhaité), et ensuite livrent un type de Scrum contraint par le rôle. « En fait, Agile Scrum est si facile à conditionner et à consommer que presque tout le monde peut le vendre et le livrer », a déclaré Bond.


Et selon lui, quelque chose qui est facile à vendre et à livrer et qui est très demandé ne peut être qu’un échec. En outre, il a aussi ajouté qu’il échoue, car de nombreuses entreprises croient qu’il suffit de copier ce que font les autres et qui marche et le tout est joué. Selon lui, cela ne marchera pas parce que les fondateurs d'Agile avaient raison : « il n'y a pas de taille unique ». Selon Bond, ce que ces derniers n’ont pas prévu ou sur lequel ils n’ont pas pu se mettre d’accord, c'est que pour que les gens adoptent sans peine Scrum, il devait être présenté sous forme de pratiques concrètes.

Il ne devait pas se montrer sous forme de classes abstraites avec des méthodes virtuelles à définir selon le contexte. Toutefois, les partisans d’Agile ont trouvé le moyen de le rendre concret. Ils ont packagé et livré Agile Scrum. Mais selon Bond, il reste encore beaucoup à faire pour réaliser la promesse d'Agile qui est : la réalisation d'une utilisation judicieuse de pratiques de développement légères et de flux de travail qui s'adaptent avec souplesse aux besoins changeants et évolutifs des clients. Par ailleurs, Bond reconnaît qu’il existe bien des situations où Scrum marche bien.

D’après son argumentation, Agile Scrum fonctionne étonnamment bien lorsqu'une équipe de développement itère directement avec un client via une série de courts sprints et dans certaines conditions. En premier, lorsque le client est engagé dans des revues de sprint et dans le processus d'apprentissage plus large consistant à découvrir quel est son besoin réel par rapport à son besoin perçu. Deuxièmement, en apprenant à connaître ses besoins, le client donne la priorité à la prochaine chose qui doit être construite ou résolue.

Pour Bond, c’est à ce moment-là qu'Agile Scrum brille : avoir des clients qui sont engagés, et des équipes qui sont activées. Il n’est pas le seul qui croit que Scrum ne fonctionne pas. Pour ceux qui argumentent dans le même sens que lui, le véritable problème vient de la perception du besoin réel du client. Pour certains internautes, la plupart des clients ont toujours cru que toute la charge de travail incombe entièrement aux personnes qui créent le logiciel.

En fait, ils estiment que lorsque les gens veulent des logiciels qui sont entièrement conçus pour eux, ils fournissent très peu d'effort ou ne fournissent pas du tout d'effort pendant les phases de planification et de développement. Il n'y a pas de magie dans le développement de logiciels où les développeurs connaissent soudainement vos processus/workflows/exigences exacts. D'après eux, c'est la principale raison de l’échec des méthodes de travail. Par contre, d’autres pensent que Scrum et d’autres méthodes agiles fonctionnent très bien.

Selon eux, il suffirait de rester bien attentif dès que le processus de développement démarre. En plus de cela, il faut introduire dans ce processus de très petites équipes, mais pas beaucoup, des frais généraux bureaucratiques réduits, etc. Par ailleurs, ils estiment qu’il faut recommencer à zéro chaque fois que possible.

Source : Billet de blog

Et vous ?

Quel est votre avis sur le sujet ?
Êtes-vous ou pas du même avis que Gene Bond ? Que pensez-vous de ses arguments ?
Quelle méthode Agile utilisez-vous et quelles sont les difficultés que vous rencontrez souvent ?

Voir aussi

Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative

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

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

« Agile est un cancer », pour Erik Meijer qui estime qu'il doit être banni une fois pour toutes

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de JackIsJack
Membre éclairé https://www.developpez.com
Le 20/05/2020 à 14:56
Cette méthode Agile est la combinaison savante de 'management à la mode' et de 'technique d'animation pour CE1/CE2'. Le best-of c'est vraiment le chiffrage par 'point d'effort', c'est un canular de qualité.

Ce qui fait le succès des projets ce sont des individus qui le compose, à la fois ceux qui réalisent, ceux qui mènent et ceux qui exigent. Mélanger de la terre dans un sens ou dans un autre, ca aura toujours le goût de terre !
30  1 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 22/05/2020 à 19:58
On a toujours fait du cycle en V mais pour autant on a toujours pris en compte les changements des clients meme en cours de route. J'ai jamais vu une boite qui faisait du cycle en V pur et dur (ou on remet en cause des choses a la fin). Depuis quelques années on fait du scrum, nos projets ne sont pas de meilleures qualités, on repousse les sprints et les sujets non finis donc au final on explose les budgets de manière phenomenale.
Je n'ai jamais eu l'effet tunnel sur projet cycle en V car on attend jamais la fin pour identifier/remonter/rectifier les problèmes ou si les besoins semblent pas nets.
Avec Scrum par contre on a tendance a ne pas finir les sprints, c'est pas grave on prolonge dans le suivant.
Beaucoup de temps passé en stand up meeting (les 15 min c'est toujours plus proche des 45 min); on a des salles remplies de post it. En debut de projet tout le monde est content on se fait plaisir a faire des tableaux a gogo. Au fur et a mesure de l'avancement, comme les personnes travaillent sur plusieurs sujets (cad le projet en cours mais doivent aussi assurer le SAV de leurs autres logiciels) ben les SUM sont de moins en moins populaires, les gens delaissent au profit des urgences des autres projets.
Bref le scrum est un echec sur tous nos projets. Pourtant on en a vu passer des scrum master (a un moment le critere de selection c'était recruter des gens qui bossent sur projets open source). On a multiplié les outils, plus les formations associées, les plannings poker qui sont une farce, velocité etc. tout ce langage inutile pour mesurer l'efficacité des gens. Les gens sont bons quand ils savent exactement ce qu'ils doivent faire.
Personnellement je n'y crois pas; la seule methode qui fonctionne c'est le bon sens. Derouler des process parce que c'est ecrit dans la methode, ca coute.
21  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 20/05/2020 à 10:12
Résumé de l'article et façon internationale s'il vous plaît : "there is no silver bullet".

Bien que je respecte et que je suis d'accord sur ce qui est dis, ça fait des années qu'on le crie et que (presque) personne, n'écoute.
19  2 
Avatar de brulain
Membre habitué https://www.developpez.com
Le 20/05/2020 à 19:27
Demander de l'agilité dans une organisation et avec des individus rigides, des procédures et des normes dans tous les sens, un nombre de projets obscène et j'en passe, c'est peut-être un tout petit peu normal que ça merde. Mais bon, on aime tellement les baguettes magiques.
15  1 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 21/05/2020 à 4:13
Je fais partie des 85%
J’ai du intervenir sur 4-5 projets où on «*appliquait*» cette méthode à chaque fois c’est pas respecté, des daily de 45min, des tâches ajoutées en court de sprint.
L’estimation des tâches en point est souvent une aberration aussi, etc ...
14  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 25/05/2020 à 8:56
Vouloir appliquer 1 méthode absolument n'est juste pas possible pour la majorité. Chaque équipe est unique et donc chaque équipe fonctionne différemment. Il faut savoir piocher dans chaque méthode pour en extraire ce qui nous convient.

Scrum c'est pas mal de masturbation, avec du vocabulaire qui fait cool mais au final on brasse aussi pas mal de vent j'ai l'impression. Perso j'ai autre chose à foutre tous les jours que de passer 15 à 30 min en réunion (parce que les SU meeting ca ne tiens jamais dans le délai impartit) pour finalement ne rien apprendre de nouveau. Une bonne équipe elle saura communiquer au bon moment sans avoir a se forcer.
13  0 
Avatar de herdans
Membre actif https://www.developpez.com
Le 22/05/2020 à 16:23
Bâti autour d'un noble idéal, cet outil de pilotage / planification est transformé en indicateur de productivité. Dans un monde ultra concurrentiel, où la performance de chacun est individuelle, tout comme la prime, cela ne pouvait pas en être autrement. Tout est question de rendement, à celui qui réussit le plus de sprints, termine premier.

Cela rassure de pouvoir mettre des deadline, même si ces dates de fin sont scientifiquement inventées avec la méthode du doigt mouillé.

Cette méthode branchouille à la mode, vendue à toute les sauces, devenue l'alpha et l'omega, restera comme ses ancêtres, toujours dépendante du management, critère prépondérant dans le bon déroulement du projet.

Les hommes > la méthode
9  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 20/05/2020 à 15:45
Citation Envoyé par JackIsJack Voir le message
Cette méthode Agile est la combinaison savante de 'management à la mode' et de 'technique d'animation pour CE1/CE2'. Le best-of c'est vraiment le chiffrage par 'point d'effort', c'est un canular de qualité.
C'est surtout qu'elle est vendue comme ça et souvent qu'elle est utilisée comme ça en entreprise...

Citation Envoyé par JackIsJack Voir le message
Ce qui fait le succès des projets ce sont des individus qui le compose, à la fois ceux qui réalisent, ceux qui mènent et ceux qui exigent. Mélanger de la terre dans un sens ou dans un autre, ça aura toujours le goût de terre !
Oui mais là, quand on commence à travailler avec des gens compétents, on n'est plus dans le management !!! Que vont devenir tous les scrum master et compagnie ? Déjà que le chômage va remonter, faut pas déconner non plus !
8  0 
Avatar de Antjac
Membre chevronné https://www.developpez.com
Le 30/08/2023 à 7:41
Pour ma part, j'essaie d'adapter la méthode en fonction du contexte (entreprise, collaborateurs, nature du projet). Actuellement dans mon entreprise on va faire en fonction de la situation.
Par exemple, Dans le cas d'une période où l'essentiel des tickets va être des bugs isolés, on va travailler en Kanban. Pas de planification, juste une priorisation des tickets faite par les PO et les devs piochent dedans. Daily meetings classiques et on livre régulièrement des releases. Ça s'arrête là

Dans un cas où il y a plutôt des nouveaux développements, on fonctionne sur un sprint backlog préparé à l'avance par les PM et PO avec une priorisation au sein de celui-ci. Lors du premier jour du sprint, on va faire une estimation (en temps) et déjà une affectation à un développeur qui aura une capacité en temps déterminé (en fonction de son contrat, de ses congés sur la periode et de ses potentielles autres activités, typiquement un dev au 35h sans rien de particulier, ça va être 4h30 ou 5h par jour environ).
Quand plus aucun développeur n'a de capacité, le sprint est considéré comme rempli et toutes les autres tâches non affectées sont reléguées dans le backlog.

Chaque jour, on fait le daily meeting assez classiquement, ce qui permet de réajuster, de communiquer sur les difficultés ou au contraire d'aider les autres si l'un est plus en peine et à la fin du sprint, démonstration faite par un membre de l'équipe à l'équipe (devs, testeurs, po, PM, direction et toutes personnes intéressées) et échange rétrospectif après. Je trouve que dans mon contexte, cette méthode (pas forcément scrum) fonctionne assez bien.
8  0 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 31/08/2023 à 7:07
Citation Envoyé par foetus Voir le message
Après, tu as l'effet tunnel : l'équipe de développeur passe tout son temps jusqu'à la livraison seule sur le projet.
C'est caricatural : le cycle en V n'interdit pas les validations intermédiaires lors de la recette avec avenants au cahier des charges qui permettent d'ajuster les développements. Fort heureusement, on n'attend pas d'être en production pour corriger certains défauts !
8  0