Parce que l’agilité à l’échelle est l’un des enjeux cruciaux des grandes organisations, nous avons interrogé quatre experts afin de constituer un ebook, permettant de comprendre les apports de l’agilité à l’échelle et SAFe. L’article suivant est un extrait de cet ebook et nous permet de comprendre en quoi l’agilité à l’échelle est différente d’un cycle en V avec un feedback utilisateur.
Le cycle en V est une série d’étape d’un projet
On peut difficilement comparer un cycle en V qui est “orienté projet” et l’agilité à l’échelle qui est “organisationnelle”. Je vais comparer le cycle en V avec une pratique Agile, comme Scrum par exemple. Le cycle en V est une série d’étape d’un projet dont chaque étape est validé en mode FILO (First In Last Out), qui est finalement une séquence d’étape.
L’intégration des équipes organisées en cycle en V dans les jalons de synchronisation est toujours délicate
Un cycle en V reste une organisation basée sur la prédictibilité des solutions, dans laquelle le feedback utilisateur trouvera difficilement sa place sans risquer de remettre en cause les prévisions, ou alors seulement à la marge. L’agilité à l’échelle intègre le client pour guider les objectifs fonctionnels et respecter l’autre valeur importante : permettre d’adapter le produit au fur et à mesure de son développement.
Il est possible d’envisager des organisations à l’échelle avec, à la marge, quelques équipes organisées en cycle en V, mais leur intégration dans les jalons de synchronisation est toujours délicate, même en se calant sur des mini-cycles en V.
Cette organisation des sprints en mini cycles en V est une perversion de l’agilité, notamment quand elle est majoritaire, dans la mesure où elle organise les développements en séquences (spécifications- développement-tests-mise en production) sans que les équipes soient polyvalentes ; cette organisation est assez vite démasquée par le management visuel (Kanban), obligé de tracer les étapes.
On devrait voir une réelle différence et rester dans une vraie agilité si on est passé à l’échelle intelligemment
Ha ha, bonne question, ça sent le vécu ! Evidemment, cela devrait être très différent comme l’ont écrit mes co-auteurs.
En réalité, et spécialement dans les grandes échelles et les approches top- down, cela n’est pas si évident à distinguer.
Par exemple, on se retrouve à faire du SAFe avec un PI (Program Increment) de spécifications, un PI de développement et un PI de validation. Et au vu de l’ampleur de la tâche et au risque de me faire huer par toute la communauté agile, cela peut être un début. Privilégier la collaboration entre équipes avant la livraison fréquente et incrémentale est un chemin possible. Travailler sur un portfolio priorisé, en lien avec les stratégies d’offres et de solutions, en intégrant des retours clients peut être le pas suivant. Puis investir sur les flux d’intégration, vérification, validation, déploiement continus pour livrer fréquemment des incréments en est un autre.
Sur une approche bottom-up, on devrait voir une réelle différence et rester dans une vraie agilité si on est passé à l’échelle intelligemment.
Appliquer des approches reposant sur des postulats s’apparente souvent à construire un château de cartes
Gardons en tête que le cycle en V ou Waterfall (cascade) est une approche qui cherche à systématiser la réalisation du projet compte tenu de l’expérience méthodologique acquise au cours du temps, et en particulier avec deux postulats forts ; on sait ce que l’on veut faire ; et on sait comment on va le faire.
Or, dans notre monde numérique, où les technologies évoluent très vite, et où les besoins ne sont pas ou mal définis et évoluent encore plus vite, appliquer des approches reposant sur les postulats ci dessus s’apparente souvent à construire un château de cartes. On ne peut tout simplement pas définir avant quelque chose qu’on ne connaît pas. Ou plutôt, pour pouvoir définir avant, il faut faire le choix de travailler avec des technologies obsolètes et de ne pas trop innover. Pas sûr que cela soit un choix gagnant.