Dans notre premier épisode « Scrum 3.0 L’origine, ou comment comprendre l’évolution de Scrum », nous vous parlions des caractéristiques et des différences entre Scrum 1.0, 2.0 et 3.0. Ce deuxième épisode, consacré à l’organisation de Scrum 3.0, a pour objectif de vous présenter de façon synthétique les nouveaux rôles et l’organisation de Scrum 3.0.
Les rôles
Commençons par définir les rôles et responsabilités d’une équipe « classique » Scrum. Pour avoir une équipe Scrum complète, il vous faut :
– Des parties prenantes qui vont jouer le rôle des clients, des utilisateurs finaux, des entités organisationnelles ou encore des experts,
– Un Product Owner qui va être le capitaine d’équipe et le garant de la vision produit,
– Un Scrum Master qui va être le facilitateur et le coach agile qui aidera l’organisation à s’améliorer en continue
– Une équipe de développement qui est composée de personnes dédiées au projet.
Dans Scrum 3.0 comme dans les autres Scrum, on peut scinder la méthode en 3 parties :
– La production qui développe des fonctionnalités dans le but de produire de la valeur pour les parties prenantes
– Le Product Ownership qui détermine le résultat à développer et quand le livrer
– Le Scrum Mastering qui aide l’équipe Scrum à utiliser au mieux les valeurs agiles et à avoir un environnement adéquat pour faire son travail.
Dans le Scrum 3.0, la production va être faite par l’équipe de développement, le Product Ownership va être partagé entre le Business Owner (BO) et le Team Captain (TC) et le Scrum Mastering entre le Team Facilitator/Coach (F/C) et le Change Agent (CA).
Voyons dans le détail les nouveaux rôles ajoutés.
Le Business Owner travaille avec les parties prenantes afin de maximiser la valeur des livrables : il construit alors le « Results Backlog », selon le plan stratégique des entités organisationnelles (nous verrons par la suite ce dont il s’agit).
Le Team Captain est le leader de l’équipe Scrum, il va travailler avec le BO pour aider l’équipe Scrum à maximiser la valeur de son travail, il va aider à la construction du « Work Backlog ».
Dans la partie Scrum Mastering, le Team Facilitator/Coach aide l’équipe à s’auto-organiser, à contourner les obstacles et à s’améliorer dans l’application de Scrum et de l’agilité. Le Change Agent quant à lui, va travailler avec les entités de l’entreprise pour les aider à comprendre comment aider une équipe Scrum et comment travailler avec.
Scrum 3.0 a donc quatre rôles qui permettent d’adapter au mieux le cadre Scrum aux organisations actuelles. En effet, les entreprises ont beaucoup de niveaux hiérarchiques et des équipes qui travaillent en silo. Il est donc compliqué d’appliquer du Scrum à 100%. C’est pourquoi avec les nouveaux rôles définis, le Scrum 3.0 est applicable, au mieux, en entreprise.
Les artéfacts
Dans Scrum 3.0, le Backlog est vu comme « une liste d’éléments qui représente tout ce qui est intéressant pour un client final que l’équipe Scrum a jugé nécessaire ». Le Backlog est une liste non exhaustive de travail à faire et de livrables. C’est pourquoi, pour Dan Rawsthorne et Doug Shimp, il n’y a pas de distinction entre le Product Backlog et le Sprint Backlog mais une liste continue de choses à faire, c’est pourquoi on parle de Backlog d’une façon générale. Néanmoins, ils vont découper le Backlog en différentes parties :
– Le Results Backlog dirigé par le Business Owner. Il représente la liste ordonnée des livrables qui apporteront de la valeur et qui devront être fournis aux clients.
– Le Work Backlog dont le Team Captain est responsable. Il est composé des éléments (User Stories) sur lesquelles l’équipe devra bientôt travailler. Les éléments du Work Backlog sont aussi bien des User Stories du Result Backlog que des User Stories de « corvée » comme nettoyer le code, former l’équipe, etc. Une particularité du Work Backlog est qu’il est continuellement affiné par l’équipe, par le TC et par le BO.
– Le Work In Progress est composé des stories sur lesquelles l’équipe travaille actuellement. L’équipe utilise alors le « WIP limits¹ » pour éviter l’effet goulet d’étranglement.
Le processus
Le processus Scrum 3.0, est le même que le processus « classique » Scrum. Néanmoins, on ne parle plus de Sprint mais de flux continu. On travaille alors au jour le jour, comme en méthodologie Kanban. Les Daily Scrum sont conservés pour permettre à l’équipe d’être synchronisée et de planifier la journée. Quant aux rétrospectives, elles sont gardées sur demande de l’équipe produit. Régulièrement, des démonstrations sont planifiées afin de recevoir les feedbacks des utilisateurs finaux. Les tests et la validation des fonctionnalités sont faits par le Team Captain au jour le jour.
¹ WIP : Work in Progress : Limitation du travail en cours. Pratique venant de la méthode Kanban qui permet de contrôler le nombre de tâches en parallèle pour une entité.
