Parmi les objectifs principaux à réaliser durant la phase de cadrage lors d'une transformation agile, c'est le choix du cadre méthodologique à appliquer selon le contexte et l’environnement du projet en question. Or ce n'est pas toujours possible de choisir le cadre de travail "Scrum" même si c'est la méthode la plus populaire et plus fréquemment utilisée.
Le Framework agile "Scrum" est constitué de plusieurs pratiques adaptables en fonction du contexte et environnement du travail de chaque équipe ou projet, mais il reste quand même une méthode agile basée sur la gestion du flux continu (Gestion du Product Backlog), bien structurée, qui exige des rôles et des cérémonies, et des normes à appliquer sur le terrain (Normes du "Scrum Guide"), ce qui n'est pas toujours possible dans certains contextes, en conséquent et comme étant un Coach agile je ne recommande pas parfois l'utilisation de ce cadre vu que les conditions préalables ne sont pas applicables.
La première condition à aborder dans cet article, et qui est la clé principale de la réussite quelque soit la méthode agile choisie est bien évidement la culture, ainsi que d'être ouvert d'esprit pour tout changement même si parfois radical. D'autres conditions préalables sont requises, en occurrence :
L'autonomie en expertise technique de l'équipe de développement sans faire appel à quelqu'un de l'extérieur (Pas forcément que des experts, mais plutôt une équipe équilibrée) .
La taille de l'équipe de développement qui ne doit pas être moins de 3 personnes.
La fréquence du changement du besoin, car s'elle est importante alors il faut penser à la méthode "Kanban".
Activité de Build pour développer un logiciel ou produit, et pas une activité de RUN ou de maintenance se basant sur le flux tiré en travaillant au fil de l'eau (Kanban).
La disponibilité et l'implication du client, de ses parties prenantes, et ses utilisateurs finaux (Affinage, Sprint Review, et maîtrise du domaine fonctionnel) afin de collecter des Feedbacks rapidement et alimenter le "Product Backlog".
Un flux de demandes continu permettant d'alimenter le "Product Backlog" au fur et à mesure, ainsi que d'occuper l’équipe de développement à 100% durant les Sprints.
La présence d'un "Product Owner" et un "Scrum Master" au sein de l'équipe Scrum.
Pas de cahier de charge initial figé à traduire à la lettre en User Stories dans le Backlog.
Une cadence des Sprints fixe (de 1 à 4 semaine selon le choix à faire) et pas variable d'un Sprint à l'autre.
Il existe bien évidemment d'autres critères et conditions, mais l'essentiel c'est de garantir un cadre de travail correct, respectant les règles du jeu de Scrum, et permettant de tirer tous les bénéfices de l'agilité et de "Scrum".
Conclusion :
En monde agile, et avec le cadre "Scrum", nous pouvons livrer rapidement plus de valeur métier réelle, en appliquant les deux approches incrémentale et itératif, mais pour cela on doit être capable de garantir un environnement et contexte de travail convivial et respectant les normes et les valeurs de ce cadre méthodologique agile.
Parmi les objectifs d'un Coach agile c'est de bien orienter l'équipe vers les bonnes pratiques et s'assurer que le cadre méthodologique agile choisi lors de la phase de cadre est adéquat avec le contexte en question.
En fait, le Scrum reste un cadre de travail agile flexible et adaptable, mais en parallèle il faut garantir à minima le respect des normes standards pré-requises.
Comments