Intermédiaire

Scrum s’incrémente : Scrum 3.0

Aujourd’hui, tout le monde connaît Scrum. Le framework s’est répandu pour devenir l’une des méthodes les plus appliquées dans le monde du développement. Et comme tout sujet devenant mainstream, les individus et les organisations se l’accaparent, le transforment, l’adaptent, au gré de leurs besoins.

Parfois, ces adaptations sont un succès, parfois elles sont un échec, souvent un mystère pour l’œil extérieur. Mais dans tous les cas de figure, qu’elles soient pertinentes ou non, efficaces ou non, elles correspondent à une image de la réalité, une incapacité à suivre les règles by the book, une envie d’injecter dans une méthode, aussi éprouvée soit-elle, une part de la personnalité de l’entreprise et des personnes qui la composent.
Mais lorsque l’on prend un peu de recul, que l’on compare le Scrum d’une équipe avec celui d’une autre, on reconnaît des patterns, des adaptations qui se répètent, des problèmes communs et des entorses jugées nécessaires que l’on retrouve étrangement dans plusieurs contextes.
C’est le constat de Dan Rawsthorne et Douglas Shimp (tous deux coachs chez 3Back, dont Douglas Shimp est d’ailleurs fondateur, ainsi qu’auteurs du livre Exploring Scrum: The Fundamentals), et le fruit de leurs réflexions se concrétise sous la forme de ce qu’ils appellent Scrum 3.0.

Le principe est simple : il s’agit de conserver l’esprit et le mouvement de Scrum, tout en y intégrant des patterns ayant pour objectif d’apporter souplesse et productivité à l’équipe. Les changements sont, au final, peu nombreux mais ils sont importants et modifient subtilement la dynamique de l’équipe Scrum.

 

Les Product Owners manquent de temps

Le premier changement et celui qui est le plus mis en avant est la scission du Product Owner en deux rôles, ce qui correspond à l’acceptation d’une rustine que l’on retrouve souvent : le PO proxy. Plus ou moins décrié dans l’ensemble de la communauté agile, il se révèle souvent nécessaire car les PO se retrouvent aisément submergés, et en particulier lorsque l’on va les chercher côté métier. L’intérêt d’un PO faisant partie du métier concerné par son produit est indéniable, mais le fait qu’il ait – justement – un métier, en plus d’être PO, l’enferme dans un cycle douloureux de manque de disponibilité pour ses deux rôles.

Scrum 3.0 propose donc de remplacer notre PO débordé par :
– Un Business Owner (BO), redevable auprès des sponsors de la maximisation de la valeur à livrer (concrètement il produit des epics et les priorise) et des délais qu’il souhaite communiquer (il possède donc le plan de release et remet les dates communiquées à jour au fil des sprints).
– Un Team Captain (TC), totalement intégré à l’équipe Scrum et redevable auprès du Business Owner de la maximisation de la valeur produite dans chaque sprint.
Le BO et le TC travaillent conjointement afin de fragmenter les epics en stories sur lesquelles l’équipe de développement pourra travailler, et ils affinent ces stories avec les développeurs pour qu’elle soient jugées prêtes.
Cette répartition des tâches du PO est la brique principale apportée par Scrum 3.0, mais deux autres ajustements majeurs sont présentés.

Flux continu

Tout d’abord l’intégration d’une notion de flux continu. Les sprints ne sont plus considérés comme des incréments quasi-indépendants dont l’objectif est de produire une version potentiellement livrable du produit, mais comme le morcellement d’un flux continu de développement, interrompu par les rituels de fin et de début de sprint : review, rétro et sprint planning. On se rapproche d’un Kanban saupoudré de Scrum, et encore plus avec la notion de WIP Limit (limiter le travail en cours).

Le backlog est alimenté par toute l’équipe et comprend à la fois les tâches techniques nécessaires à la vie du produit et les stories fonctionnelles provenant des travaux du BO et du TC. Il n’y a plus de remplissage lors du sprint planning, dont la dynamique et l’objectif sont totalement modifiés, car toutes les stories prêtes entrent dans le backlog de sprint à n’importe quel moment. Le sprint planning est conservé pour donner une nouvelle orientation à chaque itération, en lui définissant des objectifs à court terme et en s’engageant formellement sur la brique d’amélioration continue (Kaizen) qui sera mise en pratique. On s’y assure également que le stock de stories ou tâches prêtes est suffisant pour alimenter l’équipe durant le sprint à venir.
Enfin, au sein d’un Sprint, c’est au TC de prioriser les travaux de l’équipe pour en maximiser la production de valeur, et il doit prendre en compte à la fois les priorités métier et techniques pour orchestrer le travail réalisé. Le TC doit donc se trouver au cœur de l’équipe, toujours disponible pour la guider et la réorienter quand cela s’avère nécessaire.

Que devient le Scrum Master ?

Dernier ajustement notable, le Scrum Master disparait et, à l’instar du PO, son rôle est scindé en deux :
– Un Facilitateur/Coach (F/C), à ne pas confondre avec un coach agile. Ce rôle a un périmètre d’intervention restreint à l’équipe, qu’il aide à s’auto-organiser, à lever ses blocages et à faire le meilleur usage possible de Scrum.
– Un Change Agent (CA), intervenant au niveau de l’organisation pour assurer la bonne compréhension de l’agilité et garantir l’efficience de la collaboration avec l’équipe Scrum.
Là où la scission du PO correspond à une acceptation du rôle de PO Proxy, on peut voir dans celle du Scrum Master une généralisation du rôle de coach agile, les redevabilités du CA étant très proches de celle qu’un coach pourrait être amené à assumer, libérant ainsi le F/C pour lui permettre de se consacrer exclusivement à l’équipe Scrum.

Et ensuite ?

D’autres subtilités émaillent le travail de Dan Rawsthorne et Douglas Shimp sur Scrum 3.0, et je conseille vivement la lecture de leur whitepaper, au moins pour avoir une idée des mutations à l’œuvre dans le monde des équipes Scrum. Un guide de Scrum 3.0 est en cours de rédaction et devrait bientôt voir le jour avec plus de détails.
Cette approche empirique de l’évolution de Scrum me semble très intéressante, d’autant qu’elle se fait totalement à l’image de la naissance du Manifeste Agile, né de l’observation de dérives bien réelles. Reste maintenant à confronter cette nouvelle vision de Scrum à … la réalité dont elle s’inspire.

Source : scrum30.org
Scrum 3.0 et illustrations sous copyright ©3Back LLC

© SOAT
Toute reproduction interdite sans autorisation de l’auteur

Nombre de vue : 678

COMMENTAIRES 2 commentaires

  1. Eirian dit :

    Ce qui me chagrine dans ce post c’est d’imaginer qu’on fasse évoluer un cadre (ou une méthode) en se basant sur des constats fait par des entreprises qui n’ont pas utilisé le cadre de la bonne manière.

    On utilise plus ou moins de concepts de Scrum en fonction de ce qu’on comprend et/ou de ce qu’on a envie de comprendre.

    Il faut se souvenir également que Scrum aide à bien faire le produit mais qu’il est encore plus efficace quand il s’accompagne de méthodes d’expression de besoin et de conception (XP)

    Le PO

    Le rôle de PO a toujours posé beaucoup de questions. Principalement sur sa disponibilité.
    Mais pas seulement …
    Comment a-t-il été désigné ? A-t-il été accompagné ? A-t-il une vraie connaissance de Scrum ?
    Avait-il un rôle opérationnel avant d’être désigné PO ou a-t-on embauché quelqu’un pour ce rôle ?
    A-t-il bien compris son rôle ???

    Ici, le BO reprend quasiment le rôle du PO mais il n’intervient pas pendant le SPRINT …
    Concrètement, sa mission semble s’arrêter à l’alimentation du backlog en stories “prêtes” …
    A mon sens, cela représente déjà 80% des activités du PO.
    On est donc pas dans un partage réel …
    Comment être certain que la vision du TC est alignée avec celle du BO quand l’équipe a des questions ?
    Ne sommes-nous pas de nouveau dans le schéma PO / Proxy PO qui pose problème ?

    Flux continu

    Selon moi, le SPRINT est déjà un “morcellement d’un flux continu de développement, interrompu par les rituels de fin et de début de sprint”
    Il ne faut pas le voir comme autre chose.
    Les dérives du TC me font un peu tousser … Dans l’idée pourquoi pas ? Dans les faits … Attention à ne pas perdre en “auto-gestion” et ne pas se retrouver avec un donneur d’ordre qui impose le “quoi” et le “comment”.
    La hiérarchie est de retour au sein de l’équipe !

    Encore une fois, quand Scrum est “bien respecté”, on veille déjà à :
    – Convier l’équipe à affiner les stories
    – Donner l’opportunité à l’équipe de défendre des stories techniques
    – Ce que le stock de stories prêtes soit toujours suffisant

    Le rôle du Scrum Master

    Pourquoi vouloir limiter le champ d’action du Scrum master à l’équipe ???
    Le constat qui est souvent fait est que le rôle du Scrum Master n’est pas un rôle à temps plein.
    Là, on souhaite qu’il se focalise sur l’équipe en prenant le rôle de “facilitateur”.
    J’ai bien peur que les rôles et les égos ne se frottent entre Facilitateur et Team Captain, que les visions ne soient pas partagées entre le Facilitateur et le Change Agent …

    Il était déjà compliqué de “former” un PO et un Scrum Master.
    Il faudrait maintenant former un BO, un TC, un Facilitateur, un Change Agent et espérer que l’équipe de développement et les parties prenantes s’y retrouvent dans toute cette organisation complexe.

    Accompagnons déjà les PO et les Scrum Master en entreprise.
    Respectons le cadre avant de le modifier.
    Donnons les moyens au PO de se former sur les méthodes d’expression de besoin.
    Donnons les moyens aux équipes de développement de faire de la veille et de se former à l’XP.

    Et faisons le constat après avoir réellement mis toutes les chances de notre côté 🙂 non ?

  2. Grégoire QUENTIN dit :

    @Eirian : Attention à ne pas confondre “rôle” et personne… considérer que 4 rôles impliquent de disposer de 4 personnes est erroné. Sous l’idée de séparer les 2 rôles en 4, on peut y voir l’idée de pallier aux faits que :
    -> le rôle de PO est trop souvent donné à un expert métier qui sait comment marche actuellement le métier, alors qu’un PO doit avoir la capacité de dessiner le futur en se reposant sur des ressources variés
    -> le rôle de Scrum master n’a généralement pas le mandat pour intervenir hors de l’équipe…

    Cela permet selon le contexte d’avoir une personne endossant les rôles de BO & TC (bref de PO) et une autre les rôle de FC & CA (bref SM) ; ou de mixer, ce qui dans des posture d’agilité à l’échelle peut être d’autant plus intéressant…

    En soit, on pourrait même imaginer un cadre où : le rôle de BO soit porté par des experts métier, et où celui de TC soit porté par la team sur la base de points d’intelligence collective 🙂

AJOUTER UN COMMENTAIRE