Nouveau poster Scrum

Depuis novembre 2020 que le nouveau Scrum guide est sorti, je voulais mettre à jour mon poster Scrum… il fallait juste que je prenne le temps de le faire 🙂

Il y a déjà des tas d’articles, de vidéos etc. sur les différences de cette nouvelle version, mais ça me paraît quand même important de pointer celles qui m’ont marquées et que j’ai essayé d’intégrer dans cette représentation graphique :

Premier changement que j’applaudis des deux mains : il n’y a plus qu’une seule équipe, la Scrum Team, qui partage le même seul objectif : l’objectif produit. Plus de « development team ». Vraiment pour moi que c’est une très bonne chose, car je trouve que cette notion de « dev team » apportait à la fois de la confusion et une distance entre le PO et les autres membres de l’équipe. Voilà, maintenant c’est clair, tout le monde est sur le même terrain avec les mêmes règles et un objectif commun.

Il n’est plus question de « rôles ». Ce mot « rôle » est tout simplement absent du Scrum Guide (si on exclue la partie remerciements à la fin 😉 ). L’équipe (unique donc) est collectivement « responsable de toutes les activités liées au produit ». Au sein de cette équipe il y a un Product Owner, un Scrum Master et des Developers qui ont des redevabilités différentes, mais l’ensemble des responsabilités sont portées collectivement.
Je me suis posée beaucoup de questions sur la différence entre ces notions de « redevabilités » et « responsabilité ». En creusant les définitions, il me semble que la redevabilité est ce que je dois faire (le PO est redevable de la priorisation du backlog par exemple), et la responsabilité est ce sur quoi je doit rendre des comptes (l’équipe est collectivement responsable de l’objectif produit). Cette subtilité me semble importante à pointer car elle met en évidence qu’il n’est pas possible de dire « on n’a pas atteins l’objectif mais c’est la faute de XXX qui n’a pas fait son boulot » (je caricature à peine). Même si chacun a des redevabilités qui peuvent lui être propres (fixées par le cadre Scrum ou en interne de l’équipe auto-gérée), tous les membres de l’équipe sont collectivement responsables. L’équipe perd ou gagne ensemble. Il ‘y a pas de sens à débriefer en disant que le match est perdu mais que les défenseurs on atteint leur objectif… c’était déjà l’esprit de l’ancien Scrum Guide, mais il me semble que le cette nouvelle version enfonce le clou 🙂

On retrouve les 3 mêmes artefacts : « product backlog », « sprint backlog » et « incrément produit », mais ils sont maintenant associés à 3 engagements respectifs :

• L’objectif produit fait partie intégrante du product backlog et décrit un état futur du produit (les autres éléments émergent pour définir ce qui permettra d’atteindre cet objectif). C’est le seul objectif à long terme de l’équipe, on peut le rapprocher de la notion de « vision » mais le mot objectif induit, de ma compréhension, quelque-chose de plus concret et atteignable. A noter que la valeur focus me semble particulièrement mise en avant par ces deux phrases : « L’Objectif de Produit est l’objectif à long terme de la Scrum Team. Ils doivent atteindre (ou abandonner) un objectif avant de s’attaquer au suivant. » J’y retrouve les principes Lean/Kanban de limitation du WIP, terminer avant de commencer etc.
• L’objectif de sprint fait partie intégrante sur sprint backlog et est l’unique but du sprint. Le plan de sprint sert cet objectif et peut tout à fait être modifié en cours de sprint si besoin, tant que ça reste au service de l’objectif de sprint.
• La définition of done est un engagement associé à l’incrément produit.

Ces trois engagements servent la transparence et doivent permettre de mesurer l’avancement de l’équipe Scrum (ils doivent donc pouvoir être communicables à tout moment).

Pour résumer, on a donc une seule équipe, concentrée sur un seul objectif : l’objectif produit, et qui s’engage sur cet l’objectif produit (engagement long terme), l’objectif de sprint (engagement court terme) et sur la définition of done (objectif de qualité).

On ne parle plus d’équipe « auto-organisée » mais d’équipe « auto-gérée ». Ca peut sembler un détail… mais pour moi c’est important (comme chaque mot du Scrum Guide :)). Une équipe auto-organisée est autonome sur le comment, sur son organisation interne pour atteindre un objectif, mais cet objectif peut lui être imposé. Une équipe auto-gérée est autonome sur le comment, mais aussi sur le quoi, se définit ses propres objectifs, décide sur ce quoi elle travaille.

Il y a aussi d’autres changements qui ne se voient pas forcément dans le poster :

• Globalement cette nouvelle version va vers la simplification et très concrètement on passe de 20 pages à 15 pages (il n’y a vraiment aucune excuse pour le lire, le relire et le re-relire 😉 )
• Cette version s’adapte à la démocratisation de l’agilité qui sort largement aujourd’hui du domaine du développement logiciel, il n’y a plus de références qui spécialisent Scrum sur un domaine d’intervention particulier.

Et voilà mon petit poster 🙂