Comprendre Scrum : une non-méthode Agile !

comprendre scrum

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 !

(merci à Jordan qui a co-écrit cet article!)


organisation-performante-qui-sommes-nous-nidhalTout 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

Partager sur twitter
Partager sur linkedin

Vous aimerez aussi ...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Recevez nos articles

La protection des données nous tient à cœur. Vous pouvez vous désinscrire de ce type de communications à tout moment. Pour plus d'informations, consultez notre politique de confidentialité.

Livre blanc

les problématiques du manager dans un livre blanc
La protection des données nous tient à cœur. Vous pouvez vous désinscrire de ce type de communications à tout moment. Pour plus d'informations, consultez notre politique de confidentialité.

Partagez nos articles

Partager sur linkedin
Partager sur twitter
Partager sur email

Rechercher

une organisation rayonnante

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considérerons que vous acceptez l’utilisation des cookies. Voir notre Politique de confidentialité.