Scrum est-il diabolique ?

Question

Au dernier CITCON Europe, nous avons eu une excellente session sur le thème " Scrum est-il diabolique ? " Lecture de l'article du blog de James Shore sur " Le déclin et la chute de l'agile "a ramené cette session à l'esprit.

Ce sont des doutes sérieux soulevés par des personnes profondément impliquées dans la méthode agile. Pour les personnes extérieures, les jugements peuvent être encore plus sévères, comme dans ce billet de blog " La maladie agile ".

Quelle est votre opinion actuelle sur Scrum et/ou Agile et son influence actuelle sur le développement de logiciels ?

(Il ne s'agit pas de savoir ce qu'agile signifiait il y a plus de 5 ans, mais plutôt de son influence aujourd'hui. Il ne s'agit donc pas tant de Scrum contre RUP que de savoir si Scrum est le nouveau RUP).

Answer 1

Personnellement... Je pense que Scrum est plus facile à accepter pour le style de gestion vieux-scientifique que n'importe quelle méthode agile. Les Scrums qui devraient prendre 30 minutes ou moins se transforment en de longues mises à jour de statut d'antan... (maintenant quotidiennes et permanentes !)

Comme avec la plupart des choses agiles Je pense que la faute est dans

• ne pas comprendre les principes qui sous-tendent la méthodologie... ce qui conduit à suivre les pratiques énumérées sur une foi aveugle... et à être impuissant lorsqu'elles ne fonctionnent pas
• ne pas adapter la méthodologie au problème à résoudre. La standardisation est tellement tentante courir après des solutions standardisées pour tous les problèmes. C'est notre nouveau processus. Tout le monde doit s'y conformer".
• ne pas s'adapter aux réalités du terrain et aux rétrospectives.
• Régler les symptômes plutôt que la maladie.

Les bonnes personnes feront de bons logiciels (même sans agile, SCRUM, ou autre)... les personnes médiocres et inférieures produiront des logiciels similaires même avec leur propre variété d'agile. Cependant, les gens qui font de l'agile comme il était prévu... auront de meilleurs produits.

Mise à jour : JFYI..Je viens de trouver un catalogue de ' Les odeurs de Scrum sur le site de Mike Cohn . Court, bien écrit et venant de l'homme lui-même.

Answer 2

Je ne connais pas grand-chose de Scrum, et certainement pas assez pour dire si c'est "mauvais" (je pense aussi que "mauvais" est un terme surutilisé et trompeur de toute façon, mais c'est probablement une autre discussion). Mais comme pour presque tout, je pense que le fanatisme et le fondamentalisme sont mauvais, même lorsque l'intention est bonne.

Je connais un peu l'XP et d'autres méthodologies "agiles", et il y a beaucoup de bonnes idées dans beaucoup d'entre elles, mais j'ai toujours considéré cela comme des suggestions et non comme une formule à suivre méthodiquement. Ma principale préoccupation concernant tous les modèles de développement, est qu'ils nécessitent des développeurs compétents, intelligents et motivés pour fonctionner parfaitement, et comme beaucoup des meilleures idées relèvent vraiment du bon sens pour des personnes intelligentes, cela semble un peu exagéré. Il est même possible que le style cow-boy, "codez et réparez", fonctionne si tous les développeurs sont bons et disciplinés. Mais toute méthodologie échouera avec une équipe majoritairement incompétente, et suivre aveuglément un "manifeste" sans bon sens n'améliorera pas les choses.

L'opposé d'"agile" ; les systèmes bureaucratiques lourds ; peuvent en fait fonctionner mieux pour les développeurs médiocres, qu'un système qui exige des participants autonomes ; bien que cela puisse éloigner de nombreux développeurs créatifs et intelligents. Le principal problème est de trouver de bonnes personnes, pas tant de savoir comment gérer le projet...

BTW : Personnellement, j'aime les idées agiles, et j'utilise celles qui me conviennent, mais je vois aussi que cela ne fonctionnerait pas si moi et mes collègues n'étions pas capables de nous gérer.

Answer 3

Quelques observations sur les aspects négatifs de SCRUM dans mon expérience :

Un sens du détail trompeur.

Il y a tellement de détails de processus spécifiques dans SCRUM qu'il est très facile de s'enliser dans le processus tout en perdant de vue les objectifs de haut niveau (et cela devient alors un simple processus de culte du cargo). De plus, SCRUM génère beaucoup d'artefacts, il est facile de se tromper en croyant que cette pléthore de données vous donne plus de visibilité sur le processus de développement qu'elle ne le fait en réalité, et la simple quantité de données décourage probablement les gens de se demander s'ils obtiennent les bonnes informations.

Sur l'application.

SCRUM est souvent appliqué à tort comme un processus polyvalent adapté à toutes les situations, alors que, comme tout processus, il n'est utile que dans un ensemble assez restreint de circonstances.

Pression pour la myopie

SCRUM encourage le travail à court terme sur des tâches concrètement définies. Les travaux moins bien définis (en particulier ceux dont les artefacts n'existent pas déjà dans le système), comme la recherche ou la planification stratégique, sont désavantagés pour obtenir du temps de développement.

Crédit mal placé

SCRUM est l'un des processus de développement les plus visibles, et son nom/marque accrocheuse l'aide, ce qui signifie que souvent, un projet réussi qui utilise SCRUM a plus de chances de voir SCRUM recevoir une bonne partie du crédit qu'un projet réussi qui utilise un processus de développement moins visible et qui n'a pas un nom aussi accrocheur.

FUD

Les personnes les plus formées à SCRUM semblent être celles qui le défendent le plus aveuglément, allant jusqu'à essayer de faire peur aux gens en leur faisant croire que le moindre écart par rapport à la voie unique de SCRUM conduit au processus redouté de la "cascade". Compte tenu de l'énorme multiplicité des différents processus de développement, dont beaucoup ont leurs propres qualités, cette tendance est plutôt ridicule. Il y a aussi cette idée que la seule façon d'être agile est d'utiliser SCRUM(TM) ou TDD(TM) ou XP(TM), alors qu'en réalité il existe de nombreuses façons de parvenir à l'agilité du développement sans aucune de ces méthodologies spécifiques. La vérité est qu'aucun processus de développement n'est une solution miracle, et que les meilleurs processus de développement ne sont vraiment que progressivement meilleurs que les 2e, 3e, etc. meilleurs processus.

Answer 4

Il est intéressant de noter que j'ai récemment écouté le discours d'une conférence de Tim Bray, dont le sujet était "comment survivre à la crise du crédit" (plus ou moins) et son point de vue était qu'agile est non seulement loin d'être mort, mais qu'il sera le seul acteur pendant un certain temps et que c'est la cascade qui est morte.

Son raisonnement à ce sujet semble parfaitement clair et évident pour moi que lorsque l'argent est serré aucune entreprise ou client va s'engager à d'énormes coûts initiaux où l'échec est presque terminal pour un projet quand ils ont l'option de petits coûts itératifs où l'échec exige juste une autre itération. Vous pouvez discuter toute la journée du risque relatif, mais je sais par expérience que seule la méthode agile procure au client un sentiment de sécurité et de contrôle.

Il est certain que le balayage du terme "agile" en fait une arme chargée dans les mains d'une mauvaise équipe de gestion, et j'ai moins de temps pour des choses comme XP et des sessions de scrum d'une heure, mais ce n'est pas un échec du principe du développement agile. Il est certain que le post de SGS fait un bon point que les méthodologies plus rigides peuvent être mieux adaptées aux développeurs médiocres et aux logiciels d'usine, mais je suis sûr que cela ne s'applique pas à l'OP ;)

Au cours de ma carrière, je peux dire que chaque projet en cascade s'est finalement transformé en projet agile bâclé lorsque le foo a atteint le bar, et seuls les projets agiles (pleinement adoptés) ont bénéficié du soutien de toutes les parties à la fin du projet. Est-ce un parti pris de favoriser ce qui a toujours été meilleur ?

Résumé : Je ne suis pas du tout d'accord. Agile est l'avenir.

Answer 5

Scrum ne remplace PAS une véritable gestion de l'ingénierie logicielle. Quelqu'un doit toujours s'assurer que le code est bon, que le projet progresse conformément aux besoins de l'entreprise et que l'expérience utilisateur est bonne. Scrum fait en sorte que toutes les choses sans importance semblent plus importantes. Il s'agit de regarder les arbres sans voir la forêt.

L'autre chose que je déteste à propos de la mêlée, c'est que les mêlées ont tendance à être des réunions extrêmement pénibles au cours desquelles les choses intéressantes ne sont pas discutées - et l'équipe en a tellement marre les uns des autres que les choses intéressantes ne sont plus discutées nulle part. Cela permet de s'assurer que l'innovation et le plaisir sont éliminés du processus de développement. Cela conduit à des logiciels ennuyeux et de mauvaise qualité.

J'ai vécu avec "Agile" et "Scrum" pendant un an, et j'ai vu de nombreuses autres entreprises les utiliser. Je suis convaincu que "nous faisons de l'agile" signifie simplement "nous n'avons pas d'instinct ou de sagesse en matière de développement de logiciels, alors nous nous contentons de nous écouter parler pendant 30 minutes par jour et de prétendre que nous sommes bons dans ce domaine."

Ok, oui, d'après mon expérience, la mêlée est diabolique. "Agile" est un grand mot de marketing, mais une méthodologie terrible.