Vous entendez beaucoup parler d’Agile ces derniers temps ? C’est normal ! Dans la gestion de projets, et notamment dans l’IT, ces méthodes ont le vent en poupe. Hé bien voici un petit article pour vous aider à comprendre Scrum en quelques minutes !
Quelle est la réalité derrière cet intérêt ? Afin de ramener un peu de concret, penchons-nous donc de plus près sur Scrum.
Pour comprendre SCRUM, d’abord, son histoire…
Hirotaka Takeuchi et Ikujiro Nonaka, deux universitaires japonais, inventent le terme Scrum en 1986 lorsqu’ils publient leur article « The New New Product Development Game« . Ils utilisent alors le vocabulaire du rugby en reprenant le terme anglais de “Scrum” (la mêlée) pour décrire une nouvelle méthode de développement de produits.
Ken Schwaber, l’un des fondateurs de Scrum.org a, en 1996, transposé l’idée et la méthode en théorisant les principes du cadre Scrum tel qu’on le connaît aujourd’hui. Il ajoute alors sa conviction que dans un environnement imparfait et difficilement prévisible, on ne peut pas planifier l’ensemble des tâches menant à la réalisation d’un projet complexe. Dans ce contexte, la « mêlée » devient alors une équipe de multidisciplinaires impliquée dans un même projet qui doit réagir aux imprévus.
Scrum est un cadre de travail avant tout!
Ce n’est pas une méthode Agile ! Et non !
Même si quand on parle d’Agile, « Scrum » fait partie des termes les plus associés, il ne faut pas tout confondre ! C’est une étiquette erronée que l’on colle à Scrum. Rassurez vous ! Tout ce que vous avez appris n’est pas faux ! Scrum est bien agile, mais ce n’est pas une méthode.
Scrum est bien plus pour moi, un cadre de travail. Il définit en effet un ensemble de cérémonials (si si!… le pluriel de cérémonial c’est ça!), de rituels et de pratique. Tout cela va permettre de rythmer le projet, et en particulier les phases de développement logiciel.
Comme vu plus haut, Scrum vise à répondre à la complexité des projets. Pour cela, il propose une approche empirique qui s’appuie sur trois piliers :
- transparence : chacun connait les problèmes de l’équipe. Ils sont alors plus faciles à traiter et des idées out-of-the-box peuvent être proposées par les collègues. On ne cherche surtout pas à cacher l’information !
- inspection : on prend le temps ensemble et individuellement d’analyser ce qui est produit (la rétrospective) et d’identifier les voies d’amélioration possibles
- adaptation : une fois les axes d’amélioration identifiés, il faut les mettre en place. L’équipe est donc ouverte au changement et dispose de la liberté et de la légitimité d’adapter son fonctionnement
S’approprier les rituels pour comprendre Scrum
Cela peut sembler anecdotique, mais en réalité pour comprendre Scrum, il faut comprendre l’importance de ces rituels. En effet, les trois piliers, cités plus haut, sont incarnés en cérémonials. Ces pratiques rythment les sprints, c’est à dire des itérations de 2 à 3 semaines (c’est en tout cas ce que je conseille, mais on peut adapter la durée à chaque situation).
Durant les sprints, les rituels les plus pratiqués sont :
- le daily-meeting : tous les matins, pendant 15 minutes, tout le monde se retrouve et partage son actualité. On décrit tour à tour les tâches réalisées la veille, les difficultés rencontrées et ce qui doit être traité dans la journée. Chacun doit être clair et transparent sur les problèmes. Ceci permet de les résoudre ensemble. En général, j’essaie de faire mes daily meetings debout (on parle de stand-up meeting) pour éviter que l’équipe ne soit trop bavarde. Ça incite à être concis !
- le sprint planning : au début de l’itération, l’équipe (composée notamment du Scrum Master, du Product Owner et des développeurs) définit les objectifs du Sprint. On liste alors les tâches à réaliser durant le sprint. C’est ce qu’on appelle le « Sprint backlog ». Les tâches y sont alors bien décrites et le plus souvent priorisées. On aura ainsi des tâches qui doivent absolument être exécutées (on parle parfois de Minimum Viable Product ou MVP).
- la revue : à la fin du sprint, l’équipe examine ensemble ce qui a été réalisé (c’est ce qu’on appelle l’incrément). Cette revue, souvent avec une démo, permet de récolter un maximum de feedbacks. Tout cela, alimentera le backlog pour les prochaines itérations. Pour bien comprendre Scrum, on peut dire que la revue s’intéresse au “quoi” : ce qui a été fait et ce qui reste à faire.
- la rétrospective : la rétrospective quant à elle, s’intéresse au “comment”. Comment on a fait, comment ça s’est passé et que doit-on faire différemment. Chacun s’exprime et l’équipe recense ainsi les problèmes rencontrés durant le sprint. On discute et on capitalise pour améliorer l’organisation et atteindre plus d’efficience. La rétrospective est clé en Scrum. Il participe à l’amélioration continue et à la quête du “zéro-déchet”.
Une histoire de cycles…
Ainsi, Scrum donne un cadre de travail qui vise à rythmer le développement et à le rendre plus efficace.
A chaque itération, tout au long du projet, Scrum définit les réunions à mettre en oeuvre. Les rituels de cadrage (sprint planning) et de clôture (revue et rétrospective) encadrent le travail et favorisent l’atteinte des objectifs définis. On garantit ainsi que les tâches soient claires, comprises et partagées. A partir de là, on s’y tient pendant tout le sprint !
Sauf urgence bien sûr ! Dans la vraie vie, il peut toujours y avoir, un incident de production ou un imprévu (on parle parfois de « spike »). Cela peut remettre en cause les tâches du sprint. Mais là encore, le cadre Scrum permet de réagir au mieux. Tous les jours, revoir l’avancement, l’en-cours et les points de blocage permet de réagir aux priorités. On ré-alloue alors si besoin la capacité de l’équipe.
Ce que j’adore avec le cadre Scrum, c’est que l’équipe devient meilleure au fil des itérations. La vélocité (c’est à dire le nombre de points de complexité de l’ensemble des tâches terminées) augmente. Sans jamais négliger la qualité ! On produit, on apprend, on s’améliore. Et c’est reparti pour un cycle !
Si vous souhaitez en savoir plus sur les bénéfices de la mise en place de la méthode Agile, découvrez le témoignage de Jérémy Amourous, DSI de Colissimo.
(merci à Jordan qui a co-écrit cet article!)
Tout simplement « Agile Fan » !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Nidhal
