Que signifie être agile?

Nous avons un projet que tout le monde dit que nous ferons de manière agile, mais je doute que nous ayons clairement compris ce qu'est l'agilité.

Dans les projets précédents, nous avions organisé des réunions, puis défini le backlog du produit et alloué le travail aux développeurs en 2 à 3 semaines de sprints. Chaque matin, nous avions des réunions de mêlée (qui semblaient durer une demi-heure à chaque fois) et chaque développeur a continué avec cela. Presque personne n'a écrit de test jusqu'à la fin du sprint et le travail non terminé a été ajouté au sprint suivant.

Les développeurs se parlaient à peine et aucun TDD n'était impliqué dans le développement. En fait, la plupart des développeurs avaient une spécification au début et venaient de la suivre pendant les 2 ou 3 semaines pour lesquelles le sprint était organisé. Il n'y a eu pratiquement aucune communication avec le client / intervenant.

L'assurance qualité s'est impliquée généralement quelques mois plus tard et à ce moment-là, nous avons trouvé des exigences manquantes, ce qui a encore augmenté la quantité de travail que nous devions faire. De toute évidence, il n'y avait pas de boucle de rétroaction.

Ma question est donc de savoir où nous nous sommes trompés et comment puis-je empêcher l'équipe de faire les mêmes erreurs.

Ce que vous décrivez n'est pas Agile par définition (Manifeste Agile), c'est Waterfall avec des réunions de statut quotidiennes. Agile signifie s'adapter facilement au changement, s'il n'y a pas de boucle de rétroaction interactive avec le propriétaire du produit et donc les clients, alors quel changement se produit?

Agile est synonyme d'échecs rapides, grâce à une communication constante avec le propriétaire du produit / les clients. Il vaut mieux échouer plus tôt que tard, moins de travail est fait et moins est "perdu". Et vous n'êtes pas coincé avec l'argument selon lequel "nous n'avons pas le temps de le faire correctement, puisque nous avons passé tellement de temps à le faire mal, nous avons juste besoin de continuer sur cette même voie, même si cela conduit à l'échec ".

On dirait que votre direction fait "SCRUM, mais ..." où le "mais" est là où ils jettent tous les trucs SCRUM qu'ils ne comprennent pas ou avec lesquels ils sont d'accord et font juste les choses de la même manière au hasard comme toujours, mais avec de nouveaux noms de mots à la mode brillants.

Dans SCRUM, le stand up quotidien ne consiste PAS à fournir un statut à la direction, c'est à forcer l'interaction des développeurs, afin que vous sachiez ce que font vos collègues et que vous pouvez vous entraider et ne pas dupliquer le travail. Si cela prend plus de 45 secondes par personne, vous vous trompez. Il s'agit de transparence pour l'équipe, si une personne donne le même statut plusieurs jours sur quelque chose qui devrait représenter une journée de travail, l' équipe peut résoudre le problème des personnes le plus tôt possible.

Si vous ne testez pas le code les uns des autres tel qu'il est écrit, alors vous ne le faites pas correctement non plus. Les tests doivent être intégrés dans le processus et non après coup. L'AQ doit être incluse dans les séances de planification et donner des estimations sur la durée des tests.

Si vous ne respectez pas les engagements Sprint et ne faites pas rouler les choses, vous ne le faites pas correctement. Les sprints concernent les engagements si vous vous engagez à trop de travail, arrêtez de le faire, il n'y a aucun moyen d'introduire une prévisibilité ou une répétabilité si vous ne pouvez pas vous engager avec précision dans les livrables.

Jarrod a fourni une bonne réponse (+1 à cela) et je voudrais m'étendre un peu là-dessus.

Agile ne se résume pas aux échecs rapides et aux retours d'informations entre le propriétaire du produit (client) et l'équipe; il s'agit d'un retour rapide entre toutes les parties prenantes impliquées. Être vraiment agile (et cela vient directement du manifeste ), c'est reconnaître que le processus n'existe que pour aider les développeurs à fournir un meilleur produit. Les personnes au-dessus du processus signifient que dès que l'équipe reconnaît que votre processus existant ne fonctionne pas, vous le changez et le faites fonctionner.

"Scrum mais ..." est également un problème, mais cette pièce a ses deux côtés. Si vous regardez le manifeste, vous verrez qu'il s'agit de l'équipe et du fonctionnement des outils / processus pour vous. Il n'y a pas deux équipes identiques et donc chacune fonctionnera légèrement différemment et c'est ok. Vous pouvez certainement prendre toute la méthodologie Scrum et essayer de la suivre à la lettre et voir si cela fonctionne pour votre équipe.

Une autre alternative est au lieu de pousser un autre processus dans l'équipe et de faire suivre à tout le monde ce que Scrum vous dit de faire, essayez l'approche agile : Communiquez avec l'équipe et voyez si ensemble vous pouvez identifier les problèmes et les solutions pour chacun. Introduisez ensuite progressivement des changements dans votre façon de travailler afin de résoudre les problèmes.

Cela peut prendre un peu de temps, mais ...

1. Vous réglerez d'abord les problèmes les plus importants qui auront le plus grand impact sur la capacité de vos équipes à livrer le produit
2. En identifiant les problèmes immédiats et en participant à la recherche de solutions, les membres de votre équipe comprendront pourquoi certaines pratiques sont importantes et ne les feront pas simplement parce qu'on leur dit de les faire.

Si nous établissons une analogie entre Scrum et un modèle de conception, travailler comme je l'ai proposé serait similaire au codage dans un modèle, où vous gardez le code aussi simple que possible et ne convergez sur un modèle de conception qu'en cas de besoin. Au lieu de simplement choisir un modèle de conception et de rouler avec lui (c'est-à-dire sélectionner aveuglément Scrum et tous ses processus en un seul ensemble), ce qui rend parfois le code plus complexe et plus difficile à maintenir qu'il n'aurait pu l'être autrement.

La clé pour comprendre est que l'agilité ne consiste pas à trouver un nouveau processus pour faire les choses; il s'agit d'un changement continu et d'un ajustement constant aux processus / pratiques existants.

si l'équipe (et sa direction) veulent vraiment "être agiles", ils devraient commencer par lire et discuter en équipe du Manifeste Agile et de ses principaux. Ensuite, choisissez l'une des méthodologies agiles qui ont été créées ( Scrum , par exemple), obtenez une formation à ce sujet et commencez par suivre. Je recommanderais de le suivre de près pendant un certain temps avant de le modifier, mais c'est juste moi.

Ils devraient également examiner en profondeur les pratiques d'ingénierie qui sont utilisées pour soutenir la méthodologie de projet agile particulière choisie.