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’elles 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 : 1734

COMMENTAIRES 7 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 🙂

  3. Nilo dit :

    Je suis assez d’accord avec @Eirian. Je ne comprends pas pourquoi il faudrait découper les rôles du ProductOwner et ScrumMaster.
    Même si ce sont des rôles, dans certaines entreprises il y aura bien des personnes différentes.
    -> 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 -> on peut soit mieux choisir, soit former
    -> le rôle de Scrum master n’a généralement pas le mandat pour intervenir hors de l’équipe -> on lui donne le mandat, on travaille sur l’organisation pour qu’elle devienne agile.

    Si les autres arguments c’est dire : le PO n’est pas disponible, il faudrait plutôt comprendre pourquoi ? Multi-casquettes ? pourquoi ? Structure non agile peut être. Une seule personne sinon vive le ping-pong. Au final en découpant les rôles, on ne sait plus qui écouter. Ce découpage génère des problèmes de communication (téléphone arabe), n’est-il pas fait pour partager des responsabilités, voire donner encore des faux titres ? ça sent un peu la hiérarchie qui veut devenir agile sans perdre ses titres. Je trouvais que Scrum était la méthode agile la moins agile (à cause de ses “process”), pourtant nous la pratiquons tous les jours à échelle humaine, et je reconnais ses bienfaits.

    Avec ces frameworks pour passer à la grande échelle, ça devient franchement n’importe quoi : on avait SaFE et maintenant Scrum 3.0. Je suis sûr qu’on va me sortir bientôt des certifications.

  4. Guillaume dit :

    Exactement le même constant que Eirian. A la lecture du papier, on légitime une situation sous-optimale (en clair, le manque de dispo du PO et du Scrum Master) en en faisant un nouveau standard. Comment peut-on espérer transformer une organisation en étant totalement démissionnaire devant ce qui cause une grosse partie de ses problèmes ?

    Ah oui, et énorme contresens dans les affirmations du genre :

    *This requires the Team to be interrupted frequently
    to resolve time-sensitive issues related to bugs, building, testing or deployment that
    come up in Operations. The Team needs to know: “Which is more important, the new
    functionality we’re already working on, or the new work that just came up?” — and
    this is a decision the Product Owner needs to make right now*

    Et, plus loin,

    *we may need two Product Owners: one with the
    Stakeholders to prioritize the new functionality, and one with the Team to prioritize
    the Work.*

    Non ! Le PO n’organise/priorise pas le travail de l’équipe, et surtout pas les tâches techniques, sous peine de devenir un chef de projet traditionnel, ce qu’on cherche justement à éviter. Il priorise seulement les fonctionnalités. La deuxième partie de la phrase est contraire aux fondamentaux de l’agilité.

    Quand à la prise en otage du nom “Scrum 3.0” par une boîte qui n’a a priori rien à voir avec la Scrum Alliance mais tire un profit évident de cette numérotation (conférences, training…), je la trouve assez gonflée. Je n’ai pas trouvé de réactions des créateurs de Scrum à ce sujet mais s’ils n’ont pas été consultés, c’est assez malhonnête.

  5. Marcelo Lopez dit :

    Hello everyone,

    I’m Marcelo Lopez, and I appreciate this conversation. And an interesting conversation it is.

    What I’m hearing is that folks are afraid of a few things, and while I will speak to some of what I’m hearing; realize this subject is so complex, a brief conversation here alone will not touch all the endpoints that will present themselves in such a context.

    1. That the SM is going away. Not at ALL. What Scrum 3.0 is calling out is the fact the ScrumMaster-ING (the active ScrumMaster) is doing these things. Remember, the ScrumMaster Teaches, Coaches and Facilitates the understanding, adoption, and usage of Scrum itself and the Development is them empowered to use it to adapts it’s own (CURRENT processes) to make them better and more enjoyable (especially when it’s current processes are impeding the team from delivering quality results). What are calling out in Scrum 3.0 is that Teaching, Coaching and Facilitation are facets of ScrumMastering, and that in reality these are aspects that not only a single person, but ALL members of a team should be aspiring and pursuing to learn and apply for themselves. Now, outside of the Team, the ScrumMaster is an organizational change agent helping the organization recognize that to empower the Team’s success, not all change is from within the Team itself. These interconnected parts of being a ScrumMaster, could indeed be embodied by one person. That is great! Often, it will require different humans to undertake those facets of ScrumMaster-ING. That is not to say any given Team will not have a ScrumMaster, but even the best ScrumMaster within a Team may be so involved with that Team that Organizational Change Agency will be beyond the PHYSICAL capacities of that one human being. SO where would that leave the “Organizational Change Agent” aspect of ScrumMasterING? Left in the wind? Of course not, that would be silly.

    2. As for Product Owner-SHIP (the act of being a Product Owner) is indeed complex. I would know, I’ve been one for an over 150+ person product development group. The model described in Scrum 3.0 is stated as Scale-Ready, because when a PO encounters the situation where the number of customers/stakeholders/people who want things, reaches a certain point, the abilities of that one mind must….SCALE. No surprise there. Or at least, to anyone who’s applied Scrum and been a PO for any length of time would recognize that as a fact. The emergence of calling out a “Business Owner” as a role, that to faciliate the abilities of the Team-level PO (or Team Captain) to call “Function(Next)” for the Team from it’s backlog. In other words, to allow the PO to “BE A PO”. The Business Owner thereby faciliates and strategizes business intent, and works with the PO/TC to make sense of it before the Team can begin to at their level, refine it further and make it READY to be worked on.

    Another matter, someone made the comment “mainly on its availability. “. Exactly!! The PO/TC being a FULL SCRUM TEAM member would not be called out on “availability”. That’s their job. They are not a proxy, because they retain “Function(Next)” at the Team level. In other words, the Teams Backlog has one and only one owner. No change from Scrum there.

    The fact is that SCALING Product Owner-SHIP requires the separation between Strategic Backlog and Tactical (Development Scrum Team) Backlog. By “Development Scrum Team” I mean those at the base level performing software development, integration and evaluation testing (Nexus Integration Team, anyone?? Yes, because that is that the Nexus Integration effectively is.), for example. The Strategic Backlog would also require another Team….a Product Owner Team. This Product Owner Team would be populated by the BO as IT’S PO/TC, and the PO/TC from the Development Team as a virtual member to inform the Product Owner Team on decisions, helping clarify intent, ordering and valuing things before they transition into the Scrum Development Teams’ Backlog.

    3. If you read the white paper itself, you would recognize that Scrum 3.0 does indeed respect the framework. If anything, it respects Scrum moreso than LeSS, SAFe or even Nexus itself. Have a look at http://leanpub.com/PPSAD (The Patterns that make Scrum work) and http://ExploringScrum.com, before deciding if Scrum’s model isn’t being respected. I would say that not only does Scrum 3.0 respect Scrum as defined in the Scrum Guide, it also respects the good work defined by Dr. Jeff Sutherland (you know, one of the CREATORS of Scrum) in his discussion about what he called “Scrum Type C” in a talk have gave in 2005 for a more continuous flow model of Scrum in action.

    Perhaps some more study of Scrum, and it’s model would be useful. The two gentleman who defined Scrum 3.0 are Dr. Dan Rawsthorne (Certified Scrum Trainer #8, as in the 8th person designed by Ken Schwaber as a Scrum Trainer) and Doug Shimp (also a CST in the United States and who has run 3Back for over 13 years). Between them training over 45,000 CSM’s and 15,000+ CSPO’s. Maybe folks haven’t heard of 3Back, but that’s alright. No one knew about something, until someone had an interesting conversation with them about it.

    If any of you want to know more….I encourage you to reach out to me DIRECTLY, my email is at the end of this posting.

    Also keep in mind, we have a Scrum 3.0 conference coming up in Washington, D.C. coming up at the end of this month, October.

    My email is: marcelo.lopezjr@3back.com

  6. Guillaume dit :

    Je rejoins l’avis des commentaires ci-dessus. Ca se rapproche de SAFe. On pourrait extraire de la dev team un system architect 😉

  7. Je ne suis guère convaincu par ce que je vois en première approche. Déjà cela semble bien compliqué, ne serait-ce qu’au niveau des rôles !
    Déjà dans “Exploring Scrum” certaines choses m’avaient questionnées et j’étais en opposition sur d’autres :
    – La multiplicité (bien inutile) de différents type de stories
    – Le PO, définit comme “celui qui a une cible au milieu de la poitrine” … dois-je en dire plus.
    Ce n’est pas le lieu pour faire une liste exhaustive du livre. Ici, j’entends parler de “team captain” et j’entends “chef de projet” (prioriser les travaux, rendre compte). A ce stade l’emprunt du terme Scrum doit beaucoup au marketing et peu au respect du framework.
    Le flux rythmé par les cérémonies ? Je pense que Corey Laddas l’a fait avant et en fait nombre d’équipes le font déjà sans ressentir le besoin d’y apposer un nom (à part “Scrumban, mais qui en fait ne parle pas tout à fait de ça). D’ailleurs au passage, la superposition flux et planning meeting m’apparait un peu incohérente. Mais peut-être devrais-je lire le whitepaper ?
    Bref, j’ai l’impression que l’on n’en a pas terminé avec les frameworks d’agilité à l’échelle. Ce doit être le nouvel eldorado, j’imagine…

AJOUTER UN COMMENTAIRE