Je travaille dans un magasin similaire. Comme d'autres l'ont noté ici, ce que vous décrivez peut être agile mais pas mêlé de mêlée. J'ajouterais également que le fait de sauvegarder ou non les journaux et les sprints dépend du fait qu'il s'agisse d'un nouveau travail ou d'une maintenance et d'un support continu. Si le premier, alors une approche en cascade aurait plus de sens pour une équipe d'une personne. Sinon, d'un point de vue PM, ce qu'ils font semble être une bonne approche s'ils ont plusieurs projets dans leur portefeuille.
Pour les amateurs d'Agile, la simple mention de l'utilisation de la cascade est un sacrilège. Mais les gens doivent faire preuve de bon sens.
Permettez-moi de donner un exemple d'un de mes projets récents. Je dirigeais une équipe de 3 développeurs sur un calendrier agressif de 5 mois pour repenser deux sites Web majeurs. Nous avions des réunions de stand-up quotidiennes. Mais c'était un projet en cascade car c'était une petite équipe, un cycle de vie limité, et les développeurs étaient tous des entrepreneurs à court terme engagés dans le projet uniquement jusqu'au lancement. Le projet a suivi un cycle de vie en cascade très traditionnel. Absolument rien de mal à cela. Sauf que nous avons travaillé de manière «agile», nous avons maintenu les réunions debout et nous avons conservé les meilleures pratiques de développement agile. Notre petite équipe a été exemptée des réunions hebdomadaires de planification de sprint de la grande équipe. Pourquoi? Parce que nous n'avions pas de déploiements hebdomadaires. Et notre équipe ne dépendait ni n'influençait le travail effectué par aucune autre équipe. En fait, nous avons travaillé de façon presque autonome. Après le lancement des sites Web, nous sommes ensuite passés à un processus agile de maintenance et d'assistance continues. Les autres développeurs travaillent maintenant ailleurs. Toutes les améliorations sont planifiées en fonction des déploiements périodiques.
Le fait est qu'il est préférable d'utiliser les processus qui conviennent le mieux à la taille, à la complexité et à la maturité de chaque projet. Si vous faites beaucoup de recherches, il est difficile de faire une estimation pour les cinq prochains mois, donc l'agilité est probablement une meilleure approche que la cascade.
Une partie du problème est que certaines personnes semblent penser que vous pouvez planifier à l'avance les cinq prochains sprints. Cela a été le cas avec moi auparavant. Vous ne devez pas planifier plus de deux sprints, car si vous l'êtes, vous allez à l'encontre de l'objectif des sprints. Un sprint est censé être un engagement à fournir une quantité réaliste d'améliorations dans un délai défini. Vous ne devez pas vous engager dans quelque chose dont vous n'êtes pas sûr. La planification de sprint est par nature une planification à court terme, mais c'est un peu le point. Si vous avez un calendrier à long terme, pensez à diviser les choses en livrables plus petits. Ou mettre en place des réunions de point de contrôle en fonction de l'endroit où vous vous trouvez dans le SDLC.
La planification du sprint est censée être un engagement réaliste sur ce qui est garanti d'être accompli dans un certain délai. Si vous constatez que la planification ne tient pas compte de variables inconnues, vous devriez peut-être commencer à donner des fourchettes ou des estimations pessimistes. Ou, comme d'autres l'ont suggéré, utilisez des points d'histoire. Les sprints ne doivent pas non plus être réservés complètement pour permettre le glissement et d'autres tâches importantes qui surviennent.