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

Raid Agile de printemps

La magie du Raid Agile a encore frappé. Comme les quatre précédents, ce rassemblement a engendré des émotions partagées, a fait souffler des bouffées d’agilité positive, a déclenché des élans de fraternité, a abouti à des réflexions profondes.

Des moments de plaisir, dans le but, atteint me semble t-il, d'un apprentissage partagé.

Lire la suite...

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...

Le blog Scrum, Agilité & rock'n roll a 10 ans

10 ans, plus de 1200 billets publiés, des pages statiques, des présentations, des séries. Des tranches de vie ou plutôt de Brie, comme disait Frank Margerin, le plus rock'n roll des auteurs de BD (c'était avant Lucien).

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...

Club de jeu spécial Agile Games France

Mes goodies d'AGF16Comme #AGfR16 s'est déroulé à Nailloux dans le Lauragais, il y avait de nombreux toulousains. Nous étions plusieurs habitués du club de jeu Agile Toulouse. Mais pas tous. C'est pourquoi nous organisons ce soir un klub de jeu (le kjeub) spécial.

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...

Jours tranquilloux à Nailloux

Le lac de la Thésauque

  • Jeudi : Fédération Agile, 12e réunion
  • Vendredi et samedi : 5e Agile Games France

Lire la suite...

We're gonna groove

Un billet sous la forme d'une conversation avec Pablo Pernot.

Led Zeppelin au Royal Albert Hall 1970

Lire la suite...

Agile Games France, en 2016 à Naillloux

Le bandeau pour AGF16

Merci à l'excellent @ramuncho pour ce dessin bien dans l'esprit de cette 5e édition !

Lire la suite...

Les experts, des parties prenantes qui aident l'équipe Scrum

Le besoin d'un expert

Lire la suite...

Taille et stabilité d'une équipe Scrum

On a vaincu la loi de Brooks.

Lire la suite...

Indépendant depuis 22 ans

C'est le 22 février 1994 que je suis devenu officiellement consultant indépendant.

Extrait de la déclaration INSEE

Lire la suite...

La vie d'une story

Les 5C +1

Après les 6D, les 6C.

Lire la suite...

Visions

Le Raid #4 tirait à sa fin. Luigi s’est approché de moi et m’a fait part d'une légère frustration : il pensait que nous parlerions plus de vision en ce 3e jour.

Vision ?

Cartes vision de MysteriumD'abord pris au dépourvu, j'eus un réflexe habile en lui faisant remarquer que, dans le jeu auquel il avait participé la veille au soir, le fameux Mysterium, j’avais fait part de mes nombreuses visions.
En tant que fantôme, c'est par mes visions que je communiquais avec les médiums chargés de l'enquête.

Des visions floues il faut bien le dire, presque des hallucinations.

Luigi se souvint des difficultés à interpréter mes visions. Il sourit mais il attendait que je lui parle de vision partagée du produit. Dans le cadre de l’agilité.

Lire la suite...

Conception de logiciel, évolutions

Le club de lecture Agile Toulouse de lundi dernier portait sur de la conception de logiciel, avec le livre de Corey Haines.

Voici le dessin réalisé en séance par Cyrille (un très grand merci) :

klub4rules.jpg

Avant qu'on se lance dans la discussion sur cet ouvrage, j'ai souhaité parler d'un événement récent, avec un autre livre que j'avais apporté.

Lire la suite...

L’alchimie du Raid Agile

Une nouvelle fois, l’alchimie a opéré pour le quatrième Raid Agile. Comme les précédentes, cette rencontre de Pablo et moi (les deux animateurs) avec les raiders (les participants) dans un lieu propice (les Cévennes) a suscité des émotions partagées, des bouffées d’agilité positive, des harmonies collectives, des introspections bienveillantes.

Des moments de régal.

Lire la suite...

Décider qu'une story est prête

6D1.png

Lire la suite...

Conception simple, 4 règles

Le livre choisi pour le 18e klub de lecture d'Agile Toulouse est :

Lire la suite...

Butinage plutôt qu'essaimage

abeilles.jpgDans mon livre, je parle d’essaimage, en particulier dans le chapitre 9, pour nommer la façon dont l’équipe s’organise collectivement pour faire le travail du sprint. Le terme est d’ailleurs dans le glossaire de l’édition 4.

Lire la suite...

Changes

J'avais regardé mercredi dernier le documentaire Bowie, l'homme 100 visages ou le fantôme d'Hérouville sur France4 et cela avait réveillé en moi l'envie de réécouter du Bowie.

À vrai dire, je n'en écoutais plus beaucoup et quand c'était le cas, surtout des titres datant de plus de 40 ans. Mais comme on annonçait la sortie d'un nouvel album, je me suis laissé tenter. J'ai pris beaucoup de plaisir ce week-end en écoutant plusieurs fois Black Star. En plus c'était son anniversaire vendredi, on en parlait. Bref, c'était un peu ma semaine Bowie, le retour.

Lire la suite...

Au commencement avec Scrum, soyez shu

Je commence avec cet article une nouvelle série, qui sera constituée des compléments à mon livre pour l’édition 4 (pour les compléments à l’édition 3, voir cette série). Cette fois, les compléments vont porter sur des notions apparues dans cette nouvelle édition.

Le premier article concerne le Shu Ha Ri.

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.

Accompagnement Scrum

Il y a des coachs agiles qui sont à plein temps chez leur client. Parfois même, ce sont des armées de coachs à plein temps qui restent pendant une longue période au sein d'une organisation.
Je suppose que c’est pour des transformations agiles aussi massives que délicates.

Ce n’est pas la forme d’accompagnement que je pratique. En général, j’accompagne mes clients de façon discontinue et sur une période limitée.

Un bon exemple de ce que je fais, bien que ce ne soit jamais pareil, a été montré dans le retour d’expérience d’Intel à Agile tour Toulouse (il avait aussi été présenté au ScrumDay à Paris en avril).

Chronologie accompagnement Intel

Voici la chronologie du Scrum chez Intel Toulouse, service Telephony, dans la bonne humeur, telle que présentée par Christophe et Cyril.

Dans cette histoire de transformation du service, j’étais le « coach agile », voici les faits saillants de mon intervention.

Cadrage

Une question essentielle est comment démarrer. Dans ce cas d’organisation par silo d'activités, il s’agissait de se mettre d’accord entre le sponsor et ses managers sur l’opportunité de constituer une équipe pluridisciplinaire, en connaissant les implications de Scrum. Comme le contexte est plutôt difficile, un pilote a été lancé assez longtemps après la séance de cadrage que j’ai prodiguée.

Formation initiale

J’ai d’abord donné une formation (on the job training) qui consiste à prendre l’équipe Scrum juste constituée à cette occasion et son vrai projet et à appliquer Scrum dessus. On démarre le sprint zéro ensemble lors de cette formation (4 jours). On pratique sur l’essentiel. On constitue le backlog initial, on prépare le premier sprint. Ensuite ils continuent tout seuls.

Accompagnement d’équipes

Ensuite, j’ai accompagné cette équipe, plutôt légèrement, en participant à des événements de leur sprint : affinage (ils disaient grooming), mêlée, revue, rétro. Légèrement mais suffisamment, parce que l’équipe se débrouillait bien toute seule. Quelques mois plus tard, une deuxième équipe a démarré. Une équipe que j’ai formée de la même façon. Mais une plus difficile à faire adhérer au cadre Scrum. J’aurais dû, je pense, les accompagner plus que ce que je n’ai fait.

Évaluation

Finalement je suis revenu pour une évaluation de ces 2 équipes. J’ai fait cela en interviewant individuellement des membres des équipes, ainsi qu’en animant une rétrospective pour chaque équipe. Le résultat de mon évaluation a permis de mieux aligner les 2 équipes et le management. Un exemple qui me revient est sur l’usage de la vélocité : les équipes avaient le sentiment que le management mettait la pression sur la vélocité, alors que le management voulait juste avoir de la visibilité. Ma restitution les a orientés vers un engagement sur l'objectif de sprint.

Accompagnement de l’organisation

Finalement, un déploiement plus général, de type scrum de scrums, s’est opéré mais sans que j’intervienne pour lancer l’initiative.

J'ai peut-être eu un impact quand même, car l’envoi de 5 personnes du service au premier Raid Agile a sûrement contribué à renforcer le mouvement.

Je suis revenu pour accompagner cette transformation incluant tout le service, avec des actions ciblées sur : la mise en place de Kanban avec l’équipe pour laquelle c’était adapté, des compléments avancés pour les PO, des séances de travail avec le staff sur des sujets comme la planification de release et l’impact mapping et la consolidation de l’approche globale.

En tout, cela a représenté un peu plus d’une vingtaine de jours sur presque 2 ans.

- page 1 de 123