Scrum

Des conseils dans la mise en œuvre de Scrum.

Fil des billets - Fil des commentaires

Scrum éparpillé façon puzzle

En 2014, j'avais essayé un jeu de simulation de Scrum, avec un puzzle ; il mettait l'accent sur l'affinage et la présentation du backlog en bacs[1], c'était donc le jeu des bacs.

Début 2015, j'avais expérimenté une variante pour simuler du Scrum à plusieurs équipes.

Cette variante a reçu un très bon accueil, ce qui fait que je l'ai animée de nombreuses fois. J'ai eu du mal à lui trouver un nom. Cela a d'abord été "Astérix et la grande échelle de Scrum" parce que j'utilisais le puzzle "Le village gaulois".

Finalement c'est "Puzzle grand Scrum".

Un atelier que j'ai animé une quinzaine de fois :

  • au cours des jeux agiles de l'IPI à Blagnac,
  • à Agile Games France 2015 à Bazas,
  • au ScrumDay 2015,
  • à Agile tour Montpellier,
  • à Agile tour Toulouse,
  • au cours des 4 derniers Raids Agiles (animation avec Pablo aux manettes pour les rétros),
  • dans 5-6 autres formations Scrum.

À raison de plus de 2 heures par session, cela m'a permis de collecter plein de comportements intéressants sur, par exemple, la notion d'équipe feature, le rôle de Product Owner, l'auto-organisation et le ScrumMaster, l'affinage multi-équipes, les démos et les rétrospectives, la définition de fini. Je vais en restituer quelques-uns, en commençant par la façon de prioriser.

Mais avant, et en rappelant que l'objectif de l'atelier est de simuler la réalisation d'un seul produit avec 3 équipes, une réaction émerge parfois, et c'était en particulier le cas lors du dernier Raid, qui est : "ce serait plus facile avec une seule équipe". C'est probablement vrai pour le puzzle, mais c'est aussi une question légitime pour du développement de logiciel. Le passage à l'échelle complique les choses et il vaut mieux l'éviter chaque fois que c'est possible.

Ceci étant dit, voyons ce que donne le jeu avec 3 équipes, sur la question : par quoi commencer le puzzle ?

Par le cadre

L'envie de commencer le puzzle par le cadre arrive fréquemment, c'est comme cela que cela se fait d'habitude pour un puzzle. L'exercice pousse à changer cette habitude (le cadre n'a pas de valeur métier, on ne fera pas tout le puzzle et j'insiste sur cela) et certains ont du mal. Cela provoque des discussions avec le PO sur la priorité à donner. Parfois les partisans du cadre l'emportent (pas bien loin, car le cadre ne survit pas à la première démo).

Je rappelle que je fournis au début du jeu une liste de 20 stories (ou features, peu importe ici) et pour chacune la valeur métier que je lui donne. Dans cette liste, il n'y a pas de cadre, qui nécessiterait pour être réalisé plusieurs stories, toutes de faible valeur.

Par le tri

Il est arrivé que le backlog soit enrichi de nouvelles cartes genre tri des pièces. C'est assez rare ; en général, cela vient dans la conversation mais n'est pas accepté par les partisans de la valeur métier.

Une story "tri" n'apporte pas de valeur métier, mais on peut considérer qu'elle apporte de la valeur à l'équipe. Cela correspond à une story technique.

Il est probable que si je ne fournissais pas une liste prédéfinie, il y aurait plusieurs stories techniques de ce genre dans le premier sprint.

Par un personnage

La logique utilitariste voudrait que ce soit Astérix qui soit fait en premier, puisque c'est le personnage qui a le plus de valeur. Dans l'atelier, on ne fait pas d'estimation de la taille des personnages (ni de l'effort pour les réaliser), mais c'est assez facile à imaginer avec la surface que prend ce personnage dans l'image du puzzle. Même en utilisant le ratio valeur / taille, c'est toujours Astérix qui semble prioritaire. La différence avec Obélix est flagrante, qui rapporte moins de valeur et qui est plus gros enveloppé.

Pourtant, ce n'est pas toujours Astérix qui est choisi en premier. Par exemple, lors du Raid Agile #5, Richard, qui était le PO, a demandé Bonnemine en premier. Pour lui, c'était mieux de commencer comme ça. Richard n'est pas utilitariste, il a fait parler son cœur (à la démo du premier sprint, il a un feedback rude des parties prenantes).

tableau du puzzle au début

Pendant le jeu, tout cela provoque des conversations et c'est le but. La façon dont est prise la décision sur la priorité, dépend finalement du ou des PO (j'ai essayé le jeu avec différentes configurations), c'est un sujet sur lequel je reviendrai.

Dans un prochain article, je parlerai aussi de la définition de fini. Astérix fini, est-ce bien clair pour tout le monde ce que cela signifie ?

Note

[1] notion qui est présentée en détail dans mon livre, chapitres 7 et 8

Scrum, si populaire et si méconnu

À propos de Scrum, cela fait un bout de temps que je ne consulte pas les annonces pour savoir si et comment on en parle. Je ne regarde même plus les enquêtes pour savoir ce qu'on en pense. Scrum est maintenant si populaire que je n'éprouve plus le besoin de commenter une annonce ou une enquête de plus.

D'autres le font pour moi. Et parfois cela attire mon attention sur Twitter, quand c'est fait avec brio. Allan Kelly et Dave Nicolette, qui ne sont pas des aficionados de Scrum, ont publié des analyses au scalpel :

En résumé, pour le premier, l'annonce, Chef de projet agile/ ScrumMaster comme on dirait en France, est aberrante. Et pour le second, l'enquête sur le problème avec Scrum montre d'abord un gros problème de compréhension de ce qu'est Scrum par les enquêteurs (et les enquêtés).

Pourquoi cette ignorance ? Aurions-nous mal communiqué sur Scrum ? Parfois je m'interroge. En tant qu'auteur d'un livre dont le titre est Scrum mais qui parle plus que de Scrum, est-ce que je contribue à la confusion ? J'ai pris un soin méticuleux à organiser le livre en deux parties, la première avec le Scrum de base, la seconde avec les compléments à Scrum, le chapitre 13 "Contextualiser Scrum" articulant les deux. Dans l'édition 4, j'ai repoussé le chapitre "Planifier la release" qui présente les estimations et le Planning Poker dans la deuxième partie, car cela ne fait pas partie du core Scrum.

En ce qui concerne le rôle de ScrumMaster, je fais l'hypothèse que, plus que de l'ignorance du rôle, il y a une minimisation, voire une négation, de l'essence de Scrum. En accolant des mots qui ne vont pas bien ensemble, on se raccroche à l'ancien monde, on veut se rassurer. Le problème en faisant cela, c'est qu'on dénature Scrum.

Je vous conseille la lecture de ces deux billets d'Allan Kelly et Dave Nicolette.

Pour garder à l'esprit le côté radical de Scrum, relisez aussi la préface de Pablo. Ça tombe bien, dans l'extrait proposé par Dunod, avec la préface, il y a aussi le chapitre sur le rôle de ScrumMaster, si souvent incompris.

Une journée de Product Owner

Dans l'édition 4 de mon livre, j'ai ajouté des descriptifs d'une journée typique d'un ScrumMaster et d'un Product Owner.

Après Nicolas, le ScrumMaster chez Peetic, c'est le tour de Céline, la productoneuse.

Lire la suite...

Une après-midi révélatrice de ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

Voici la deuxième partie avec un extrait tiré du chapitre 5 Le rôle du ScrumMaster.

Lire la suite...

Une matinée typique d'un ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

On commence par la matinée de Nicolas, le ScrumMaster chez Peetic.

Lire la suite...

Bon Scrum 2016

Un détournement de la couverture de l'édition 4 pour ma carte de vœux :

2016.jpg

Ça a bien marché pour moi, grâce à Scrum je suis devenu plus populaire. À vous de jouer.

Glossaire T-V

Voici la dernière partie du glossaire que j'ai ajouté à l'édition 4 de mon livre Scrum :

  • Tâche : travail contribuant à une story, n’apporte pas de valeur par lui-même.
  • Taille (de story ou feature) : attribut estimé (en points) indiquant quelle part de backlog sera réalisée.
  • User story : story qui apporte de la valeur à une ou plusieurs parties prenantes qui utilisent le produit.
  • Tableau de sprint : sert à montrer l’avancement des travaux pendant le sprint, c’est une représentation physique du plan de sprint.
  • Tableau de features : représentation des features dans leur état courant.
  • Test d’acceptation : test permettant d’accepter une user story du point de vue de son comportement.
  • Valeur métier : attribut estimé mesurant ce que combien quelque chose (story, feature, produit) apporte aux parties prenantes.
  • Vélocité : utilisée pour prévoir la capacité, mesure de la partie du backlog réalisée par l’équipe pendant un sprint.
  • Vision : expression d’une volonté collective de développer un excellent produit ou service.

Rien en W, X, Y et Z.

WIP, Xanpan, YAGNI et Zappa, ce sera pour la prochaine fois. Z comme zéro figure dans sprint zéro.

Glossaire R-S

couverture Scrum éd.4

Dans l'édition 4 de mon livre, j'ai ajouté un glossaire. C'est une des nombreuses nouveautés.

Lire la suite...

Glossaire O-P

Les mots et le langage sont importants dans Scrum et l'Agilité. Vendredi dernier, lors du forum ouvert d'Agile tour Toulouse, le sujet "Jargon et buzzword" a attiré du monde. Nous étions une dizaine à la table et je crois que tout le monde est resté jusqu'au bout.

Lire la suite...

Glossaire G-M

Suite du glossaire que j'ai ajouté à la 4e édition de mon livre Scrum, avec les lettres G à M.

Lire la suite...

- page 2 de 7 -