L'ingrédient méthodologique magique caché derrière le Scrum board

Photo by İrfan Simsar on Unsplash

Peut-être avez-vous déjà lu notre article "Qu'est qu'un Kanban?", qui vous présente ce tableau de suivi devenu emblématique de la gestion de projet moderne. Quelques colonnes qui correspondent à l'état d'avancée des tâches à faire, et on déplace les post-its de la gauche vers la droite. Voilà! A condition de bien choisir ce que veux dire "Done", vous êtes le roi ou la reine de la gestion de projet, et votre équipe fonctionne 10 fois mieux qu'avant!

Pas si vite... Si la méthodologie Kanban offre une vraie solution pour une équipe désordonnée ou désalignée, elle est souvent un peu trop simple quand le projet s'intensifie ou que l'équipe ou l'entreprise grandit:

1. Le nombre de tâches à faire grandit souvent plus vite que la capacité de l'équipe à les terminer. Elles s'accumulent dans la colonne "Todo"
2. Terminer plein de tâches et bouger plein de post-its ne garantissent pas la pertinence du travail effectué.

Pour ces deux raisons, le tableau de suivi Kanban n'est souvent qu'un des éléments de méthodologies plus complètes, dont la méthodologie Scrum. Après un rapide résumé dans la section suivante, nous regardons de plus près l'ingrédient méthodologique trop souvent passé sous silence et qui fait toute la différence (le fait que le travail est tourné sur l'extérieur). La dernière section vous donne quelques pistes, pour utiliser Scrum dans Klaro, au-delà de notre template de Scrum board lui-même.

Scrum en quelques mots

A l'origine, Scrum est une méthodologie de gestion de projets informatiques. C'est probablement la méthodologie agile la plus connue, même s'il en existe bien d'autres. Scrum est de plus en plus utilisé en dehors du développement logiciel, tant ses pratiques sont applicables de manière plus universelle.

La méthodologie insiste sur les pratiques suivantes:

• L'équipe s'organise en Sprints, c'est-à-dire découpe son travail en itérations successives de quelques semaines chacune,

• L'équipe se réunit tous les jours lors de sessions de 15 minutes (les fameux daily meetings), qui ont pour but de savoir qui a fait et fera quoi, et quels sont les blocages,

• L'équipe fait des rétrospectives en fin de sprint, pour démontrer le travail effectué d'une part, réfléchir et améliorer ses pratiques d'autre part.

L'ingrédient magique derrière le Scrum board

Si vous googlez "Scrum board" dans Google image votre première impression d'un Scrum board est d'être un Kanban classique, avec des tâches sur les post-its et des colonnes pour l'état d'avancement:

Pourtant le Scrum board présente une caractéristique essentielle: au sein de chaque sprint (observez le filtre sur la gauche de l'écran) on distingue les user stories (en vert, qui restent dans la première colonne) des tâches de l'équipe (dans les colonnes d'avancement).

Scrum, et l'agilité en général, effectuent une distinction essentielle entre:

• D'une part les user stories, qui décrivent ce que l'utilisateur ou l'utilisatrice souhaite. Les user stories bien rédigées sont donc orientées vers l'extérieur: elle décrivent le gain obtenu par ceux et celles qui sont les destinataires du travail de l'équipe.

• D'autre part les tâches, qui décrivent ce que l'équipe doit mettre en place en interne pour délivrer cette valeur.

Les descriptions habituelles de Scrum oublient souvent cet aspect pourtant primordial, au point qu'il n'est pas rare de rencontrer des équipes "agiles", organisées en sprints, daily meetings, et rétrospectives, mais dont le travail n'est en fait pas pertinent, car non orienté vers l'extérieur.

De la même manière qu'il ne vous viendrait pas à l'esprit de conduire votre voiture en regardant en permanence votre volant ou boite de vitesse, conduire un projet d'envergure nécessite de se tourner vers l'objectif, le client, la destination...

Klaro et Scrum

Klaro n'est pas un outil dédié Scrum, mais permet d'organiser une équipe autour de ses principes, en particulier cette distinction intérieur vs. extérieur. En pratique, nous observons deux grandes tendances se dégager.

Deux types de cartes liées: User stories et Tâches

La première technique, celle proposée dans notre template Scrum board, consiste à distinguer les user stories des tâches à l'aide de deux types de carte différentes et un lien entre elles, comme illustré ci-dessous. Un board de type Kanban permet alors d'afficher les deux types de cartes, mais de ne bouger que les tâches durant le sprint. Les user stories ne sont passées en "Done" qu'en fin de sprint, après vérification de l'utilisabilité par l'utilisateur final visé.

L'avantage de cette méthode est qu'elle correspond à la manière standard de faire du Scrum, et permet de clarifier les responsabilités. Les tâches sont en effet découpées de manière à n'être sous la responsabilité que d'un ou une membre de l'équipe, et ne change donc pas en cours de sprint. Le risque est de se retrouver avec trop de cartes, et de ne pas parvenir à transformer l'essai: il peut rester un gouffre entre les tâches effectuées et le fait d'offrir le gain espéré à l'utilisateur ou utilisatrice.

Seules les user stories sont des cartes

Une seconde utilisation de Klaro, qui a la préférence dans notre propre équipe, s'éloigne un peu de Scrum. Elle consiste à suivre les stories en Todo > Ongoing > Done, sans créer de cartes pour les tâches mais d'y préférer de simples notes dans les stories elles-mêmes:

Cette méthode a l'avantage d'éviter la création de dizaines de cartes tâches, et de diriger l'attention de l'équipe sur la valeur pour l'utilisateur ou utilisatrice finale. Elle ne fonctionne cependant bien qu'avec une équipe mature, globalement disponible pour le projet, et dont les résultats ne dépendent pas trop de facteurs ou personnes extérieures. Dans une telle configuration une dimension Assignee reste bien utile et permet de se passer la carte au fur et à mesure de l'avancement. Comme une équipe de sport ballon se dirige vers le but adverse, la personne qui a le ballon a la responsabilité d'avancer, ou de faire la passe stratégique suivante.

Dans les deux cas!

Quelle que soit la méthode que vous préférez la décomposition des objectifs de haut niveau en user stories de taille raisonnable et l'enchaînement en sprints qui démontrent l'avancement sont primordiaux à la réussite du projet.

Ces deux derniers sujets feront l'objet d'autres articles sur ce blog, restez bien connectés à l'aide de notre newsletter ou en nous suivant sur les réseaux sociaux.