Plusieurs projets et équipes agiles déploient le "Scrum" comme méthode agile s'inspirant des différents principes et valeurs de l'agilité comme le cas pour les différentes autres méthodes agiles à l'occurrence (Kanban, XP, FDD, RAD, DSDM, Crystal, ScrumBan, ...Etc.).
Chaque projet ou équipe a son propre écosystème, environnement, contexte, et cadre de travail, ce qui rendre impossible le déploiement de "Scrum" chez toutes les équipes de la même manière et sous les mêmes conditions.
En fait, le Scrum n'est pas qu'une méthode agile à vrai dire, mais plutôt un cadre de travail, un Framework de développement des produits et applications informatiques complexes, qui repose sur le développement Itératif et Incrémental en continu par le biais des cycles itératifs, ou plus précisément "Les Sprints", enrichi par un ensemble des rituels, des rôles, et des artéfacts à utiliser tout au long du projet.
Scrum est un cadre méthodologique, car une méthode explique explicitement et généralement comment procéder et faire les choses. Alors que Scrum ne dit pas comment réussir son développement logiciel, comment surmonter les obstacles, comment développer correctement en agile, comment spécifier et intervenir, ...Etc. Mai plutôt il se contente d’offrir un cadre de gestion de projet Agile (et c’est déjà beaucoup) : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (Product Backlog, sprint Backlog, graphique d’avancement) et des règles du jeu.
Si on regarde et on lit bien le "Scrum Guide", on va trouver que la base de ce cadre de travail, et pas assez de détail répondant à l'ensemble des problèmes qu'une équipe peut les confronter.
Pour bien réussir votre transformation, et récolter les fruits d'utilisation d'une méthode agile comme pour le Scrum, il est vivement recommandé de créer et personnaliser votre propre cadre de travail agile en s'inspirant de plusieurs Patterns, ou Bonnes pratique que chaque équipe voit l'utilité de les déployer.
Pour cela, appliquer le principe de "Inspecter", "Ajuster", et "Expérimenter" :
Inspecter : Détecter le problème ou la douleur persistance, et essayer de trouver la solution adéquate.
Ajuster : Si la solution proposée ne marche pas dès le premier coup, essayer de l'ajuster et de l'adapter selon le contexte du travail de l'équipe.
Expérimenter : Une fois on trouve la bonne solution efficace, on la maintient et on passe à autre problème dans l'équipe.
Conclusion :
Viser toujours l’amélioration continu, identifier bien vos obstacles et problèmes, chercher et déployer les bonnes pratiques et Patterns utiles pour vous selon le contexte de votre environnement de travail, sauf éviter le rythme Big Bang, et s’assurer bien de l’expérimentation d’une bonne pratique, ainsi que son maintien avant de penser à appliquer une autre.
Vous avez tout le droit de personnaliser votre cadre de travail en Scrum, sauf conserver et respecter la base comme les rituels, les rôles, et les artéfacts.
Commentaires