Pourquoi tant d’entreprises font du cycle en V avec Scrum ?

Scrum ne nous impose pas :
👉 d’utiliser la complexité pour estimer une durée
👉 de faire du Daily Scrum un simple reporting de l’avancement prévu
👉 de sécuriser toutes les adhérences d’une équipe avant le démarrage d’un sprint
👉 d’attendre qu’une User Story soit complète avant de l’attaquer
👉 d’avoir différentes phases de validation et de tests qui viennent alourdir (voir bloquer) le processus de livraison
👉 de passer par un système de release et déployer en fin de sprint, voir après…

Toutes ces contraintes ne viennent pas de Scrum !

Elles ont été rajoutées en grande partie pour réduire les risques et l’on y arrive d’une certaine manière… sauf que :
👉 on perd en adaptabilité, en flexibilité et en communication
👉 on livre difficilement et tardivement de la valeur
👉 on n’arrive pas à suivre les changements et gérer les imprévus
👉 on fait des suppositions sur des informations manquantes
👉 et l’on finit avec potentiellement de l’over-engineering et des fonctionnalités bancales qui ne répondent pas entièrement aux attentes des utilisateurs finaux

En bref, on pense faire de l’agilité, mais on garde nos vielles habitudes qui ne sont pas agiles !
Que cela soit la durée d’un sprint ou d’une US, un waterfall itératif reste un waterfall.

La solution ?

💡 Lever les barrières et favoriser la collaboration au lieu du contrôle !

Les évènements Scrum sont là pour faciliter la communication, recueillir des feedbacks et trouver des solutions à des problématiques du terrain.
Et, qui de plus qualifiés pour gérer tout ça que les acteurs qui sont directement impactés et qui détiennent la connaissance du projet ?

➖ L’équipe aura de contraintes.
➕ Elle arrivera à avancer et livrer rapidement.
➕ Elle diminuera les risques.
Et
➕ Elle sera réactive afin de gérer efficacement ce qu’elle rencontrera sur son chemin.

---