De quoi avez-vous besoin pour réussir avec Agile?

L'adoption Agile peut échouer dans certaines organisations, j'ai même travaillé pour une entreprise où la cascade était le seul (vrai) moyen mais uniquement parce qu'ils avaient essayé Agile sur un projet et avaient échoué.

Quand j'ai demandé aux gens qui se souvenaient encore que (j'étais un junior) j'étais fermé dur, comme si je leur rappelais un mauvais cauchemar qui s'était vraiment passé.

Je ne sais pas pourquoi le projet a échoué. Il existe des ressources trouvées sur le Web pour lesquelles Agile échoue dans certaines entreprises, mais la raison est principalement économique. J'ai donc pensé demander ici quelques commentaires.

Quelles sont les raisons de l'échec de l'adoption Agile dans certaines organisations? Ou, une autre façon de le dire. De quoi avez-vous besoin pour réussir avec Agile?

Vous avez besoin de la direction, des clients et des développeurs chacun pour comprendre et soutenir la façon de penser Agile et les méthodes Agile. Plus en détail:

• La direction doit être à l'aise pour entendre la vérité, contrairement à ce qu'elle attend traditionnellement (c'est-à-dire "oui, le projet est sur la bonne voie" pendant 11 mois ... puis soudain "oups, nous devons retarder le délai de quelques semaines ... euh, mois ... euh ... "à la fin). Ils doivent également être à l'aise de laisser chaque partie faire (et assumer la responsabilité) son travail. Plus important encore, que les développeurs doivent prendre des décisions techniques et des estimations. Donc pas de contrôle serré et de micro-gestion.
• Les clients doivent comprendre qu'Agile requiert leur implication profonde et continue dans le processus de développement, pas seulement "passer la commande", puis ramasser la livraison quelques mois plus tard. Ils doivent également être à l'aise en raison de l'absence d'une spécification de grande exigence fixe et du manque apparent d'engagement de l'équipe de développement pour livrer ce pour quoi ils avaient été initialement demandés.
• Les développeurs doivent être à l'aise pour prendre des responsabilités, prendre des décisions, communiquer ouvertement et travailler en équipe. C'est-à-dire pas de "propriété du code", pas de "cowboys solitaires" et pas de blâme infructueux des autres pour les problèmes qui peuvent être résolus par l'équipe elle-même.

D'après mon expérience, c'est le premier point qui se cache le plus souvent derrière les projets Agile qui ont échoué, mais les deux autres peuvent également causer des problèmes.

Mise à jour

Par «gestion», je veux dire non seulement le chef de projet direct, mais aussi les niveaux supérieurs. Comme @Michael l'a noté à juste titre, certaines parties plus ou moins externes (par exemple, QA ou un attribut de tâche externe) peuvent également affecter le succès / l'échec des projets Agile, mais je suppose que cela ne peut être possible que si leur leader respectif le permet, et / ou si les responsabilités et les lignes de commandement ne sont pas claires au sein de l'organisation.

Vous avez besoin:

• Des gens qui veulent être très ouverts et honnêtes . La visibilité est primordiale car vous avez besoin de confiance à travers toutes sortes de limites de couches.
• Des clients et des managers qui veulent vraiment entendre la vérité.
• Des personnes désireuses et capables de redéfinir leurs rôles en fonction des besoins actuels .
• Liberté de changer les processus qui ne fonctionnent pas actuellement .
• Les gens qui sont prêts à admettre leurs erreurs et à les inverser .
• La capacité de combiner des environnements de construction et de test à volonté . (C'est plus important et plus cher que les gens ne le reconnaissent.)
• Autant de tableaux blancs que vous pouvez remplir vos murs.

Cela semble si simple, mais beaucoup de ces demandes sont importantes dans cette industrie.

Un projet agile échouera le plus souvent lorsqu'un acteur clé refuse d'être agile, ou (pire) lorsque quelqu'un n'est pas honnêtement intéressé par le succès du projet ou le sabote carrément. Ce dernier peut tuer n'importe quel projet (comme un certain nombre d'autres choses), mais les processus agiles donnent aux gens plus de flexibilité, et cela inclut la flexibilité de jouer une politique destructrice.

Exemples:

• Le contrôle qualité insiste sur le fait que les clients ne peuvent pas voir le logiciel à moins qu'il ait passé un cycle de test manuel d'un mois
• La direction impose des délais irréalistes
• Le client refuse de prioriser les exigences ("ils ont tous la priorité la plus élevée!")
• Quelqu'un qui n'est pas un intervenant immédiat mais qui a un poids politique continue d'assigner des tâches longues et sans rapport à un membre clé de l'équipe, et le chef de projet ne peut pas empêcher cela.

Je ne peux que donner mes conseils à partir de ma propre expérience personnelle.

Un employeur que j'avais totalement échoué chez Agile. Le travail a été effectué de façon ponctuelle, les tests étaient inexistants et les exigences étaient documentées dans des courriels et des procès-verbaux de réunion. La seule méthode de développement utilisée était l'anarchie, ou le «codage à tirer et oublier». La mise en œuvre d'une sorte de méthode d'ingénierie logicielle aurait été impossible car les développeurs étaient trop surchargés pour mettre en place une sorte de logiciel de gestion de projet de suivi des histoires.

Chez un autre employeur, notre équipe avait un membre héroïque qui tentait désespérément d'établir quelques bonnes pratiques Agile - nous avions un tableau Kanban, un suivi des problèmes, nous utilisions TDD et BDD (bien que n'étant pas agiles en eux-mêmes, ils ont tendance à être présents dans les groupes Agiles) . Malheureusement, il nous manquait des éléments tels que des récits, des sessions d'estimation, la planification de la capacité, des tableaux de gravure, des graphiques de vitesse - le genre de trucs utiles de gestion de projet Agile qui permettent au travail de se dérouler en douceur. Comme un symptôme classique de l'agilité qui va mal, lorsque notre tableau Kanban est devenu trop plein, nous avons acheté un tableau plus grand: /

L'endroit où je suis actuellement utilise des points d'histoire comme moyen de planifier la capacité avec des itérations de deux semaines, TDD, des standups quotidiens, des rétrospectives temporelles itération par itération et une programmation en binôme sur la plupart des choses. Ceci est le résultat de l'adhésion totale de la direction et de l'éducation des clients.

Il pense que pour que Agile réussisse dans une entreprise, vous avez besoin des choses suivantes:

• Des chefs de projet qui comprennent Agile et qui utiliseront les outils de manière appropriée.
• Les développeurs qui comprennent Agile, qui sont ouverts et honnêtes, avec la discipline qu'Agile requiert
• Adhésion du client. Ils doivent reconnaître les avantages d'Agile et être disposés à écouter les conseils de leurs développeurs concernant ce qui peut être développé dans un laps de temps donné.

EDIT: Il est également essentiel de vous assurer que vous avez une bonne compréhension de -pourquoi- des choses comme les stand-ups quotidiens et les courtes itérations sont utiles.

Mes expériences avec l'échec Agile n'ont rien à voir avec l'économie mais avec la politique d'entreprise / départementale / personnelle.

Sur le plan personnel, il y a simplement des gens dont les personnalités s'affronteront. Les forcer à devenir une équipe Agile, ou pire encore une équipe de programmation en binôme, fera monter leur aversion les uns envers les autres jusqu'à un point d'ébullition. Cela peut devenir très méchant, très rapidement et entraîner des actes de sabotage dignes d'une émission de téléréalité, transformant les réunions de mêlée en un peloton de tir circulaire ou pire encore.

Au-dessus de cela, il y a la gestion du développement. J'ai vu cela mal tourner de deux manières différentes.

Le premier est `` cargo cult Agile '' où le gestionnaire insiste pour suivre le manifeste et quelle que soit la classe / le livre / le site Web qu'ils lisent exactement sans comprendre la raison, le moment de les utiliser et le moment d'improviser. C'est comme si le manager Agile attend que la magie se produise parce qu'il suit exactement le sort. Cette implémentation procrustean d'Agile peut entraîner un certain nombre de problèmes qui conduiront à l'échec du projet.

L'autre est `` Agile In Name Only '' où la terminologie comme les sprints et la mêlée est utilisée mais n'est en réalité que des étiquettes sur les anciennes pratiques comme la micro-gestion, la malhonnêteté qui monte et descend la chaîne de commandement, de longues réunions de statut inutiles et d'autres trucs du genre . Les projets échouent comme auparavant, mais maintenant Agile peut être blâmé pour cela plutôt que pour une mauvaise gestion.

Au-dessus, il y a un manque d'adhésion du client / client du projet. Ces personnes auront leurs propres priorités ministérielles et peuvent être réticentes à travailler avec une équipe de développement à moins qu'il ne soit clairement indiqué que leur gestion fait partie intégrante de leur travail. Cela peut être aggravé par la politique ministérielle ou les politiques d'entreprise. Par exemple, les opérations et le marketing contribuent à un projet et votre équipe finit par faire tourner ses roues car les deux parties ne peuvent s'entendre sur rien. Un autre exemple est lorsque la politique d'entreprise sur la gestion du temps et la facturation provoque des conflits. J'ai en fait constaté que les clients externes étaient plus faciles à traiter que les clients internes. Ils ont aimé l'attention qu'ils ont obtenue du processus et savaient qu'ils en avaient pour leur argent.

L'OMI "Agile" échoue lorsqu'il n'y a pas d'adhésion en gros des pratiques. Ce que je veux dire, c'est qu'Agile s'appuie sur le "client" (généralement un autre département ou gestionnaire) qui comprend que:

1. Ils ne savent pas à 100% ce qu'ils veulent que le logiciel fasse, même s'ils pensent qu'ils le font
2. Ils n'ont aucune idée du temps qu'il faudra pour terminer, même s'ils pensent qu'ils le font
3. On leur dira combien de temps cela prendra et ils devront l'accepter ou réduire les fonctionnalités pour respecter un délai
4. Ils devront choisir les fonctionnalités à chaque itération et ne recevront pas l'application complète à 100% en une seule fois.

Toutes ces choses sont très difficiles à avaler pour la plupart des gestionnaires, et l'OMI est la raison n ° 1 pour laquelle il est difficile de faire de l'Agile - les gestionnaires ont l'habitude de dire "Cela sera fait avant le x date" et de le faire "Magiquement" avant cette date. (après que les développeurs aient mis 80 heures par semaine) et c'est un 180 pour réaliser que l'équipe de développement va vous dire que ce projet se fera en 3 mois, et le seul choix que vous avez est de l'accepter ou de réduire les exigences pour obtenir c'est fait plus tôt.

Deuxièmement, il faut faire confiance à l'équipe de développement. En allant de pair avec le n ° 1 ci-dessus, très peu de managers semblent réellement faire confiance à l'opinion des personnes engagées en tant qu'experts; si un développeur dit qu'un projet prendra x quantité de temps, et x est plus que ce que la direction pense qu'il faudra, ce n'est jamais un cas de "je ne sais pas comment écrire un logiciel, donc le développeur a probablement raison" c'est plus " Ces développeurs bons à rien veulent se gâter au travail, alors ils ont dit que cela prendrait 3 mois ".

Troisièmement, votre équipe de développement doit être derrière Agile; cela signifie ne pas couper les coins ronds et ne pas ignorer les retours constants et les questions de "Est-ce vrai? Quand x se produit, que doit faire Y?". Même si vous ne suivez pas TDD ou la programmation par paires, votre équipe de développement doit être suffisamment compétente pour suivre les processus agiles (par exemple les sprints, les itérations). Cela implique d'avoir un lead / manager qui peut correctement estimer les tâches et comprend que vous n'avez pas besoin de faire de chaque fonctionnalité une priorité, il est OK d'avoir un arriéré de travail et vous ne devriez pas surcharger les gens.