Quand Agile tourne mal [fermé]

J'écris un cours Agile pour certains des nouveaux gars que nous intégrons récemment, et je veux ajouter un récit édifiant pour qu'ils comprennent qu'Agile n'est pas destiné à tous les projets.

Mon problème est que, en raison de la nature des projets dans lesquels je travaille avec Agile, cela a plutôt bien fonctionné jusqu'à présent, je ne peux pas honnêtement souligner ce qui peut mal tourner et pourquoi lorsque vous l'utilisez dans le mauvais type de projet.

Quelles sont les choses à surveiller lorsqu'un projet Agile tourne mal?

Le plus gros échec avec les équipes "Agiles" est le résultat de ce qu'on appelle le Cargo Culting . Essentiellement, les équipes veulent les effets d'équipes agiles performantes afin d'imiter les actions visibiles

• Standups quotidiens (qui durent environ une heure)
• Diviser le travail en sprints
• Histoires d'utilisateurs (qui sont généralement un peu plus qu'une phrase mais une estimation est attendue)

Ce sont les trois que vous verrez constamment "appliqués" dans ces environnements, mais très peu d'engagement à être réellement agile. En fait, vous entendrez la direction dire que nous "agissons". (Fuyez ces deux mots, c'est un mauvais signe.)

Vous entendrez également beaucoup parler de la dette technique, mais leur définition de la dette technique est «faites-le rapidement et sale et nous pourrons peut - être l' améliorer plus tard». (Traduction: nous allons donner l'impression que nous nous soucions de la maintenabilité, mais en réalité, nous garderons la même mentalité de chaufferie parce que c'est ce qui a fonctionné pour nous dans le passé).

Autres phrases clés: "Je sais que ces histoires ne sont pas entièrement définies mais nous faisons de l'agile afin que nous puissions les corriger au fur et à mesure."

"Nous faisons du développement agile, vous devriez donc être en mesure de répondre à mes besoins dans le sprint au fur et à mesure que je l'identifie."

"Nous ne sommes pas en mesure de verrouiller nos histoires engagées au début du sprint car les besoins changent constamment au milieu du sprint."

L'indicateur clé pour savoir si un projet Agile réussira est si le chef de projet (Scrum Master ou n'importe quel rôle) a eu une expérience ou une formation formelle sur la conduite d'un projet Agile. Trop souvent, j'ai vu des gens lire sur Agile dans un livre ou suivre un cours de deux jours sur le fait d'être un maître de mêlée et je pense qu'ils ont les côtelettes pour réussir à le mettre en œuvre. Désolé, ça n'arrive pas capitaine.

Les personnes qui ne comprenaient pas ce qu'est l'agile (était?) Et l'appliquaient à:

• les clients qui ne sont pas disponibles pour commenter jusqu'à la date limite
  ... et menacent de poursuites judiciaires par la suite;

• les gestionnaires qui éloignent les développeurs du client (probablement parce qu'ils sont légèrement sous-payés et pourraient sauter des navires, aller travailler pour ledit client) et jouer au " téléphone cassé " dans une tentative désespérée (souvent réussie, cependant) à regarder occupé et utile,

  Voir aussi: la gestion des champignons , alias "gardé obscur, nourri de fumier" et les patrons aux cheveux pointus . :)

• des équipes trop grandes pour aller n'importe où;

• les entreprises qui gardent sur leur liste de paie des concepteurs d'architecture de système autrefois renommés qui détournent désespérément l'attention du fait qu'ils ont complètement perdu de vue le métier de codage réel, en surproduisant de magnifiques, impraticables, difficiles à réaliser, UML sagrada familias .

Agile n'est pas adapté aux contrats à durée déterminée ou à prix fixe. Une fois que vous vous êtes inscrit pour une telle bête, vous devez livrer. Agile est très doué pour poursuivre le développement pour toujours, car les clients changent d'avis et «clarifient» leurs besoins. Cela ne vous aide pas le jour où l'argent est épuisé, mais vous devez quand même terminer le travail.

Cependant, Agile est très bon pour la phase post-projet lorsque vous effectuez des mises à jour incrémentielles et des corrections de bogues.

L'autre aspect où Agile échoue n'est pas une faute d'Agile, c'est une faute de personnes qui insistent sur tous les vieux trucs comme la documentation de projet complète, les conceptions initiales et les mauvaises lignes de communication. (Le manifeste agile semi-arsed ).

Voici quelques questions qui peuvent être utiles pour chercher une réponse en termes de recherche d'un exemple où une tentative d'Agile peut mal se passer:

• Agile est-il la nouvelle microgestion?
• Le processus Agile: comment et quoi documenter?
• Bonne combinaison de planification et de programmation sur un nouveau projet

Avez-vous déjà entendu parler de "pseudo Agile"? Voici quelques entrées de blog à ce sujet:

• De la pseudo-agile à la cascade - le chemin d'une petite et nouvelle entreprise de logiciels
• Pseudo Agile!

Il y a quelque chose à dire pour les entreprises qui peuvent avoir leur propre point de vue sur ce qui est Agile et le transformer en autre chose.

J'ai travaillé sur une équipe Agile très performante, ainsi que sur quelques-unes qui ont tenté Agile, mais je n'ai pas pu le faire fonctionner.

Celui qui a réussi avait les éléments suivants:

• Exigences vraiment «agiles». Il y avait des histoires d'utilisateurs, et nous les avons codées.
• Propriétaire du produit disponible. Si une user story à partir de laquelle je codais était incomplète, je pouvais facilement aller voir le propriétaire du produit, lui demander ce qui devait être là, l'ajouter et compléter le code.
• Engagement envers le processus et réalisation qu'il s'agissait d'une courbe d'apprentissage.
• Équipe ciblée.
• Des managers qui connaissaient et comprenaient la manière agile de faire les choses et qui étaient déterminés à la faire fonctionner.

L'équipe couronnée de succès a fait Agile et l'a très bien fait. Je pense que si vous n'avez aucun de ces points ci-dessus, vous pourriez échouer assez facilement. Les première et deuxième choses vont de pair, et si vous ne l'avez pas, Agile ne fonctionnera pas.

L'équipe dans laquelle je ne faisais pas bien Agile avait aussi quelques éléments:

• Manque d'engagement de la part de la direction. La direction ne croyait pas à la philosophie et hésitait à s'engager en conséquence.
• Exigences documentées ailleurs que dans les user stories. Voir ci-dessus l'engagement de la direction. De plus, nous avions des analystes des exigences très bien payés et de gros outils d'exigences coûteux dont quelqu'un avait besoin pour justifier l'utilisation.

J'ajouterai aux excellentes réponses déjà publiées que, par mon expérience, Agile et spécifiquement Scrum ne fonctionneront que si la direction ET l'équipe sont disposées à mettre beaucoup de visibilité sur ce qui se passe.

Cela signifie que dans les entreprises publiques (les gouvernements par exemple), il sera très difficile de le faire fonctionner correctement.

Je ne sais pas cela par expérience personnelle, mais hypothétiquement, il existe de nombreuses circonstances où l'agilité n'est pas la meilleure option.

• Projets dont le produit est essentiel à la vie ou à la propriété - Par exemple, vous ne voulez pas utiliser Agile pour développer le logiciel qui exécute votre stimulateur cardiaque. Pourquoi? Parce que votre tolérance aux erreurs est proche de zéro. Prenons un exemple classique d'erreur de programmation en médecine en ce qui concerne le Therac 25 . Certes, il n'a pas été construit avec agile, mais le point est le suivant: développer la vie ou la propriété critique n'est pas un endroit pour dire, "nous allons nettoyer cela au prochain sprint" ou "nous n'avons pas besoin de grand, juste bon assez."

• Projets avec trop de développeurs juniors - Agile attend une certaine autonomie au sein du groupe participant. S'il n'y a pas assez d'expérience dans l'équipe, alors cette autonomie peut jouer contre vous.

• Projets qui nécessitent un degré de contrôle ou de planification supérieur à ce qui est traditionnellement offert avec Agile.

Je suppose que quelqu'un d'autre va intervenir et m'aider avec de meilleurs exemples, ou dévaloriser ce morceau de tripes que j'ai écrit ;-).

N'oubliez pas que lorsque le seul outil dont vous disposez est un marteau, chaque problème ressemble à un clou. Tous les projets ne sont pas des clous.

Agile à mon avis, c'est la culture de l'équipe qui pratique. Si la culture craint, les membres de l'équipe ne s'entendent pas et les gens ne collaborent pas pour respecter les engagements de sprint, alors la culture ou l'équipe est déficiente.

Je ne dirais pas nécessairement cependant que Waterfall fonctionnera nécessairement dans un tel environnement, ce n'est pas une situation en noir et blanc, très peu est vraiment en noir et blanc.

Une bonne équipe Agile est communautaire. Ils ont un esprit tribal de communauté où tous les membres travaillent vers les mêmes objectifs. L'équipe réussit ou échoue ensemble. Ils travaillent ensemble pour résoudre des problèmes. Un membre de l'équipe arrêtera ce qu'il fait avec ses tâches pour aider un membre de l'équipe en difficulté. Tout va couler ou nager.

Lorsque ce n'est pas le cas, il devient rapidement évident ce qui ne va pas. Si les membres de l'équipe sont assis, tapent sur leurs ordinateurs portables ou envoient des SMS, ou zonent pendant le standup quotidien, alors vous n'avez pas une bonne équipe Agile. Si vos chefs de projet appliquent toutes les procédures, définitions et terminologies Scrum mais que tout le monde garde juste la cadence et rend hommage, alors ce n'est qu'une farce assez flagrante de ce qu'est vraiment Agile, et cela à bien des égards conduit à un dysfonctionnement de l'équipe, à l'inefficacité , les délais manqués et les projets échoués.

Échouer Agile est à bien des égards moins bien loti qu'une équipe Waterfall modérément réussie et a probablement des taux de réussite de projet plus faibles.