Méthode ScrumBan

Scrum est un framework, ou cadre de travail, qui inclut la notion d’itérations courtes (sprints) pour réaliser un produit morceau par morceau. Ces itérations sont rythmées par des réunions appelées « cérémonies », comme les daily scrum qui sont des réunions quotidiennes que je conserve en ScrumBan, les revues de sprint qui se produisent à la fin d’une itération ou encore les rétrospectives pour améliorer la façon de travailler de l’équipe.

Dans la méthodologie Scrum, trois rôles sont proposés et je les conserve en ScrumBan : le Product owner (PO), le Scrum master (SM) et l’équipe de réalisation (Team). Le PO est identifié en tant que détenteur du besoin. Dans le domaine des infrastructures, il est fréquent de proposer que ce rôle appartienne au client. Le SM est le garant de la méthodologie, mais il est aussi celui qui va débloquer les situations. Il facilite et provoque les événements Scrum lorsqu’il le faut (daily meeting, revues de sprint, planification…). Enfin, l’équipe de réalisation est là pour implémenter le produit selon les User Stories présentes dans le backlog de sprint.

La Team prend la responsabilité partagée pour la réalisation du produit. La question qui revient souvent est « faut-il des spécialistes ou des généralistes » dans l’équipe. Avec l’expérience, on constate rapidement qu’il n’y a pas de solution idéale. Si les membres de l’équipe sont des experts dans un domaine particulier, il y aura des moments pendant lesquels ils ne seront pas occupés et s’ils sont des généralistes, ils risquent de manquer de compétence pour se sortir des situations difficiles. Le bon compromis est d’avoir des spécialistes prêt à apprendre un peu de la spécialité de chacun des autres membres sans pour autant devenir des généralistes. Les membres de l’équipe apprennent de multiples spécialités, mais probablement jamais toutes et si une expertise supplémentaire est nécessaire, il n’est pas rare que le Scrum Master fasse appel à un intervenant externe à l’équipe qui va, ponctuellement, débloquer la situation. Même en LeSS (Large-Scale Scrum), la question se pose également sous la forme « Feature Teams » vs « Component Teams ».

La méthode Kanban (« étiquette » en japonais), issue à l’origine de la méthode mise en place chez Toyota, est fondée sur l’idée qu’il ne sert à rien de commencer ce qu’on ne pourra pas terminer. On va faire en sorte que chaque activité maximise le temps passé à ajouter de la valeur au produit tout en diminuant ou supprimant les activités n’apportant pas de valeur. De Kanban, je garde la priorisation, la méthode de gestion à flux tirés et la visualisation sous forme de tableau.

Mixer Scrum et Kanban aboutit à une approche qui va garder des éléments des deux méthodes pour en créer une nouvelle plus adaptée à la réalité des projets d’infrastructures. Scrumban est une approche à géométrie variable qui peut tendre plutôt vers Scrum, plutôt vers Kanban ou vers un juste équilibre entre les deux méthodes.

En Agilité, il existe deux types d’appréciation d’une User Story : la complexité et la valeur. La complexité adresse la difficulté, le temps de réalisation et le risque liés à un scénario pour l’équipe. A risques égaux, un scénario très complexe, mais qui requiert peu de temps pour être effectué pourrait avoir le même nombre de points qu’un scénario simple, mais qui serait long à réaliser, car c’est l’effort total devant être déployé pour terminer le scénario qui est évalué et non un seul de ces aspects. La valeur métier d’une User Story peut être difficile à estimer. On peut considérer que sa valeur est proportionnelle aux nombre de parties prenantes ou « Stakeholders » qui la demandent. On peut également estimer sa valeur en termes de risque de ne pas faire. Cette dernière s’applique souvent pour les cas qui découlent d’obligations réglementaires, mais on peut l’étendre à n’importe quel type de User Story. La notion de valeur est souvent rapprochée de la notion de priorité lorsqu’on ne sait pas donner un chiffre à cette valeur. En ScrumBan, c’est plutôt sur la priorité que sur la complexité et la valeur qu’on fera le focus. Ceci étant, une estimation de charge approximative des User Stories permettra de vérifier que le « Product Backlog Items » respecte la charge totale attribuée pour la réalisation du produit.

La définition de la limite du travail en cours (Work In Progress) se déterminera et s’affinera en fonction de la taille de la Team, de son expérience et de sa montée en charge sur le produit. Il convient de s’inspirer du concept DevOps qui cherche à fusionner les équipes de développement et d’exploitation, ayant des objectifs différents pour ne pas dire antinomiques, au sein d’une même équipe. L’objectif est d’améliorer l’efficacité en faisant communiquer les équipes de conception et les équipes opérationnelles tout en mutualisant leurs compétences.

La méthode ScrumBan utilise les indicateurs proposés par Kanban, tels que le « Cycle Time » (temps nécessaire à la réalisation d’une tâche, de la phase d’initialisation à la phase de tests inclue) et le « Lead Time » (mesure du temps total de passage d’une tâche dans le « Board », de son entrée – « Backlog » – à sa sortie – « Done » -). Le « Lead Time » est un indicateur qui intéresse le client, alors que le « Cycle Time » intéresse le Scrum Master pour mettre en valeur les tâches et parfois les thématiques qui sont traitées rapidement et celles qui posent systématiquement un problème. Dans certains cas d’entrée continue dans le « Product Backlog », l’écart entre le « Lead Time » et le « Cycle Time » peut être révélateur du mode de fonctionnement de la Team.