Scrum

Des conseils dans la mise en œuvre de Scrum.

Fil des billets - Fil des commentaires

Bon Scrum 2017

Pour ma carte de vœux, j'ai repris et détourné la couverture de l'édition 4 de mon livre Scrum (qui a bien marché en 2016, merci à tous mes lecteurs) :

Bonne année 2017

Scrum ? mon scrotum ! version 3

Après la keynote d'Agile Pays Basque et la session à Agile tour Rennes, j'ai présenté une nouvelle version de Scrum ? mon scrotum ! jeudi dernier à Toulouse.

Ceux qui étaient présents sur place ont assisté à un bonus exceptionnel, le meilleur moment de la journée, avec la clownanalyse orientée scrotum absolument géniale des Bataclowns.

bataclowns.JPG

Voici les slides de cette présentation à Agile tour Toulouse 2016.

En discutant le soir et le lendemain à propos de ma présentation, je me suis aperçu que sur deux points, j'ai pu être mal compris.

Ultime session

Il s'agissait de ma dernière présentation de Scrum ? mon scrotum ! dans une conférence, mais je ne me priverai pas d'en parler dans des entreprises et il est possible que je développe ces idées sous une autre forme.

Néocons

Quand je parle des néocons, il ne s'agit pas des utilisateurs de l'agilité et Scrum, de ceux qui les pratiquent.

Je vise explicitement ceux qui influencent, les coachs, vendeurs d'outils, promoteurs de méthodes, etc.

Y compris, allez, les néococons :

  • ceux qui pensent que les certifications c'est pipeau mais qui en font passer quand même parce qu'il y a de la demande,
  • ceux qui considèrent que SAFe est un retour à un ancien paradigme mais qui le promeuvent quand même parce que ça rassure la direction.

La quintessence de la passe

La semaine dernière, à la fin de ma keynote Scrum ? mon scrotum ! pour Agile Pays Basque, j'ai fait deviner un mot.

J'ai donné 2 citations de Daniel Herrero, le chantre du rugby : Derrière une apparente simplicité, la passe cache le mystère des arts du lien.

et

…la passe est la quintessence du jeu collectif, un acte de vie.

Ces deux belles citations sont extraites du Dictionnaire Amoureux du Rugby, qu'un ami bienveillant m'a gentiment offert.

Si Scrum est bien évidemment associé au rugby, les exemples qu'on donne pour montrer l'analogie font généralement référence au pack qui pousse en mêlée.

Mais la passe est aussi un bel exemple de collaboration dans une équipe, comme le dit si bien Daniel Herrero. Dans sa première citation, on retrouve un peu ce qu'on dit de Scrum :

Scrum est facile à comprendre, mais difficile à appliquer.

Pour avoir joué trois-quarts pendant quelques années, je sais que réussir une passe en match n'est pas si facile. Même la simple passe en arrière. Dans le rugby moderne, on trouve de nouvelles formes de passe, notamment la fameuse passe après contact qu'on appelle offload.

Il fallait deviner ma forme de passe préférée, celle qui nécessite une belle technique du passeur mais surtout une grande confiance entre le passeur et le receveur :

Pour moi, la ……… est la quintessence de la passe.

Auriez-vous deviné ? Pas trop difficile, on était dans le Pays Basque. C'est un ancien rugbyman bordelais qui a répondu le premier et gagné le livre Scrum offert par les éditions Dunod.

J'espère en voir de belles, et réussies, par le Stade Toulousain ce soir contre Grenoble. Ce serait le signe d'une confiance retrouvée.

Nouveau guide Scrum

Pendant les vacances, j'ai participé à la traduction du nouveau guide de référence de Scrum, les règles du jeu. Dans cette version de juillet 2016, la nouveauté est l'ajout du paragraphe Les valeurs Scrum.

Les 5 valeurs dont il est question ne sont pas nouvelles. J'en parlais dans un billet de 2013, intitulé Les valeurs de Scrum et elles figurent dans mon livre Chapitre 3 §3.1.2 Valeurs partagées.

Mais c'est la première fois qu'elles apparaissent dans le guide de référence. Avec les traducteurs agiles, nous avons profité de cette nouvelle version pour revoir le texte en entier. La quinzaine de pages, disponible sur le site en différents formats, est maintenant beaucoup plus facile à lire.

Une bonne préparation pour ma keynote à Agile Pays Basque : Scrum mon scrotum !

Contextualiser Scrum

Pour utiliser le cadre Scrum, il faut d’abord y insérer des pratiques complémentaires, variables selon le domaine, et adapter le tout au contexte.

Lire la suite...

Équipes features façon puzzle

Je continue avec mes retours d'expérience sur l'atelier Puzzle grand Scrum que j'ai animé une quinzaine de fois.

Après des discussions sur par quoi commencer et sur la synchronisation des sprints, revenons sur l'organisation des équipes.

Pour réaliser le puzzle avec 3 équipes, on a besoin de définir sur quoi chacune va travailler.

Nous sommes dans le cas où il n'y a qu'un seul produit et je fournis au participant au jeu un seul backlog, sous la forme de 20 features (ou stories peu importe). Nous avons vu dans un épisode précédent comment ça se passait pour définir l'ordre dans ce backlog.

Les participants disposent également d'un tableau préparé, avec un colonne (ou une ligne) pour y mettre les features prêtes. Je leur dis simplement que pour y mettre un élément, il conviendrait de lui associer l'équipe ou les équipes qui vont le développer.

Le tableau de features est un outil de management visuel qui reste unique même quand le produit est gros et que plusieurs équipes y travaillent.

Dans le Scrum multi-équipes mono-produit, il y a donc une activité supplémentaire d'affinage, qui est de définir cette association entre une équipe ou plusieurs et une feature.

Dans le jeu, la plupart du temps, on a associé une feature à une seule équipe. C'est pour former ce qu'on appelle les "feature teams". À noter que je ne dis rien, quand j'anime le jeu, qui pousse les joueurs dans ce sens, ce qui laisse à penser que la notion est familière aux participants.

Il y a eu cependant quelques exceptions, en général au début et à la fin du jeu. Parfois, au début, comme lors du dernier Raid, il est d'abord prévu de mettre 2 équipes sur une feature. En général, cela ne dure pas et quand le sprint démarre, la feature est faite par une seule équipe.

Pourtant, en ayant suivi tous ces puzzles, je pense que le tri des pièces pose des problèmes aux équipes features. Sans un tri grossier, c'est difficile de savoir si on pourra assembler et intégrer un personnage dans un sprint. C'est un peu l'équivalent de l'infrastructure dans les gros projets, qui pousse parfois les organisations à choisir des structures hybrides, avec une component (ou infra) team à côté des features teams.

Ce ne serait pas une bonne idée d'avoir une équipe tri pour toute la durée du puzzle. En tout cas, personne ne l'a fait dans les ateliers que j'ai animés. Mais on peut ajouter des features de tri au backlog, qui seront prises par les features teams, en plus de leurs features à valeur client. C'est arrivé, mais seulement 2 fois sur les 15.

Feature tri ajoutée

À la fin du jeu par contre, dans le 4e sprint, il y a une volonté collective de faire participer toutes les équipes à la réalisation d'une seule feature. Il faut dire que les circonstances ont changé (héhé).

Sur quoi se base le choix de mettre telle ou telle équipe sur une feature ?

Dans le jeu, il arrive qu'une équipe soit associée à une zone du puzzle et ensuite s'occupe de tous les personnages de cette zone. Ce critère de choix se retrouve sur les projets, quand on donne à une équipe un domaine fonctionnel (dans LeSS, on retrouve cette idée avec les requirements areas). Sinon la plupart du temps, le choix se fait de façon opportuniste, sans réelle stratégie.

Qui décide du choix d'une équipe pour une feature ? Nous le verrons dans un prochain épisode sur le volet PO et Cie.

Sprints synchronisés façon puzzle

Dans l'atelier Puzzle grand Scrum dont je parlais dans mon dernier billet, il y a donc 3 équipes qui concourent à la réalisation du puzzle. Le format du jeu pousse les équipes à se caler sur le même rythme.

C'est à dire que toutes les équipes commencent et finissent le sprint en même temps.

Avec les mises en œuvre de Scrum multi-équipes que j'accompagne, c'est ainsi que ça se passe, je pense notamment à Intel et Airbus.

Au cours de la quinzaine d'ateliers "puzzle" que j'ai animés, jamais personne n'a émis une proposition différente, des sprints décalés, qui serait par exemple : l'équipe bleue commence puis au bout du tiers du sprint, l'équipe verte commence, et aux deux tiers l'équipe rouge commence.

Dans mon livre édition 4, chapitre 21 "Développer des produits à plusieurs équipes", je ne présente pas d'alternative à la synchronisation des sprints pour du Scrum multi-équipes (§21.2.1). Je mets en avant l'intérêt de l'intégration fréquente entre les équipes pour cette approche.

Une discussion avec Pablo[1] lors du dernier Raid Agile m'a fait percevoir que cet argument n'était pas décisif : on peut aussi intégrer régulièrement si les sprints ne sont pas synchronisés.

Un intérêt plus évident est que cela facilite la tenue des événements du sprint[2]. Il est bien mis en évidence par l'atelier, en particulier pour l'organisation de la revue avec les parties prenantes. L'affinage multi-équipes cadencé est aussi facilité par la synchronisation des sprints.

Dans le chapitre 15 de Scrum et XP depuis les tranchées, Henrik Kniberg raconte qu'il avait d'abord expérimenté les sprints désynchronisés, avant d'être convaincu par Ken Schwaber de les synchroniser.

En plus des arguments évoqués, Kniberg évoque aussi la réorganisation des équipes, faisable en cas de sprints synchronisés, mais qu'il est probablement plus raisonnable de repousser en fin de release.

Notes

[1] Pablo, un partisan revendiqué des sprints multi-équipes désynchronisés.

[2] Dans mon livre, je fournis un tableau récapitulatif des événements du sprint à plusieurs équipes, page 277.

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

- page 2 de 8 -