Different every time

wyatt.jpg

Lire la suite...

Agile Pays Basque dans un mois

L'automne est la saison des conférences sur l'Agilité. Depuis 2008, Toulouse et quelques autres villes ont lancé le mouvement. Cette année encore, de nombreuses conférences seront organisées en octobre, novembre et même jusqu'en décembre (notamment pour Agile tour Toulouse).

Mais cette fois, cela va commencer dès septembre avec une nouvelle conférence, le premier Agile Pays Basque.

C'est dans un mois exactement, le vendredi 23 septembre. Une période où la Côte Basque est généralement très agréable.

Vous avez bien d'autres raisons d'assister à Agile Pays Basque, organisé par une équipe particulièrement dynamique, qui a fait un bien beau site où vous trouverez toutes les informations :

=> Agile Pays Basque

On y voit ce logo, où je crois reconnaître le maillot de l'Aviron :

J'aurais bien profité de ma participation à Agile Pays Basque pour aller voir Pottoka à Jean Dauger, mais c'est un week-end où Bayonne joue à l'extérieur.

Ma sélection rock de l'été

Mon blog s'appelle Scrum, Agilité & Rock'n roll, cependant je n'y parle pas si souvent de rock que, pourtant, j'écoute à longueur de journée.

Je profite de l'été pour présenter 3 albums que j'ai plaisir à écouter en ce moment. Ce sont 3 albums récents, sortis en 2016, de groupes parfois constitués depuis longtemps, mais que j'ai découverts récemment. Merci à "Sous les jupes de FIP" qui m'a révélé ces pépites. Avec cette émission, j'ai enfin retrouvé un peu de ce que j'avais perdu depuis que Bernard Lenoir est parti.

DIIV - Is the is Are

Du rock, du rythme, de la belle guitare. On pense parfois à The Cure.

Woods - City Sun Eater In The River Of Light

Un disque de pop absolument lumineuse, avec une pointe de reggae. Je ne m'en lasse pas, c'est le truc qui met de bonne humeur.

DeWolff - Roux-Ga-Roux

Un titre bizarre, un groupe hollandais, pour du rock inspiré par le début des années 70. Certains morceaux rappellent du bon vieux Deep Purple, d'autres sont plus orientés "progressive rock", avec toujours un bon groove.

Les cubes débarquent à Toulouse

Cube_marche2_600_263.svg.png

Lire la suite...

Mes évenements de l'automne 2016

Voici mon programme de la rentrée. Nouvelles conférences et nouvelles formations !

Conférences

Agile Pays Basque

Cette conférence ouvrira le cycle des conférences d'automne. Il y avait bien eu un Agile Tour à Pau il y a quelques années, mais ce sera le premier événement de ce genre en Pays Basque. Avec une équipe d'organisation particulièrement dynamique, nul doute que cette première soit un succès. En plus, la Côte Basque à cette époque, c'est magnifique.

-> Agile Pays Basque les 23 et 24 septembre

Agile tour Rennes

Cette conférence a acquis une belle réputation depuis plusieurs années, mais je ne suis pas encore allé. À la fin d'une soirée d'Agile Games France où j'étais avec quelques Rennais, je m'étais laissé convaincre d'y venir cette fois. Engagement qui sera tenu, et je viens de faire une proposition pour y être orateur, avec une nouvelle présentation sur un sujet qui me tient à cœur.

-> Agile tour Rennes les 14 et 15 octobre

Agile tour Toulouse

La conférence à laquelle j'assiste tous les ans depuis 2008. Cette année, le thème est "Retour ô Sources". L'occasion de faire parler les vétérans à l'origine des SigmaT, les séminaires qui accueillaient les pionniers de l'Agilité à Toulouse voilà 10 ans ?

-> Agile tour Toulouse les 1er et 2 décembre

Formations publiques

Raid Agile

Il y a 2 ans, avec Pablo, nous essayions de lancer un nouveau type de formation, vraiment différent. Disruptif disais-je en l'annonçant. Le succès a été au rendez-vous. Déjà 5 Raids Agiles ont eu lieu en Cévennes. En juin, nous avons animé une variante, le premier Raid Agile tribal sur la Côte d'Opale. À chaque fois, des participants enchantés.

Il y aura peut-être un Raid Agile hivernal, mais en attendant retour au Raid normal avec le 6e en Cévennes.

-> Raid Agile du 27 au 30 septembre

Cubes

Il y a 2 ans aussi, je donnais ma dernière formation Scrum inter-entreprises. J'en fais toujours en entreprise, mais j'ai arrêté de proposer des formation Scrum publiques.

Eh bien, je vais relancer une activité de formation publique sur l'agilité à Toulouse ! Sur un concept totalement nouveau, qui m'a séduit dès que Romain m'en a parlé : les cubes !

Le concept a été expérimenté avec succès à Lyon.

-> 1CUBE&GO

Les cubes vont se diffuser avec des relais dans toute la France ; je serai celui de Toulouse. J'envisage de faire 3 cubes d'ici la fin de l'année. Bientôt les dates et l'inscription !

L'impact mapping pour dialoguer avec les artisans

Pour définir les travaux du paysagiste qui rénove la zone de mon bassin, j'ai utilisé l'impact mapping.

Lire la suite...

Les 6 activités de l'affinage du backlog

Il y a tout juste un an, je consacrais beaucoup de mon temps à l'écriture de Scrum#4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s'écoule bien : nous avons dépassé les 2000 exemplaires en mai et elle est toujours bien classée chez Amazon.

Amazon 13 juin 2016 8h

L'édition 4 comporte de nombreuses nouveautés. En particulier, apparait un chapitre dédié à l'affinage du backlog.

Voici un extrait qui présente les activités d'affinage. Chapitre 7, page 85. Ces activités sont détaillées dans les pages suivantes.


Le détail et l’ordre des activités menées lors d’une séance d’affinage dépendent de la situation. Voici une séquence possible :

Les 6 activités d'affinage

  1. On regarde le bac de départ. S’il ne contient pas assez d’éléments, l’approvisionner en stories prêtes est primordial.
  2. On observe ensuite le bac d’affinage pour identifier les stories épiques qu’il faut décomposer.
  3. On examine le bac à sable et le tableau de features en vue d’approvisionner en stories à affiner.
  4. On estime les éléments approvisionnés ou décomposés qu’il contient.
  5. On réordonne le bac d’affinage.
  6. On purge les bacs.

Des lecteurs m'ont indiqué qu'ils n'utilisaient pas la notion de bacs, sur laquelle je me base dans cet extrait pour coller au schéma. Cela ne change pas les activités. Les bacs ne sont que des containers où on met les stories selon leur état. Il suffit de remplacer bac à sable par idées et bac de départ par stories prêtes.

-> voir le glossaire

Et en complément :

Planifier la release

Pourquoi prévoir à un horizon plus lointain que le sprint ?

Lire la suite...

SigmaT -> klub

Lundi soir, il y avait une belle affluence au klub de jeu d'Agile Toulouse. Nous avons commencé à proposer cette nouvelle activité en début d'année, et c'était déjà le 4e.

Lire la suite...

La série La Voix du Coach sur InfoQ

InfoQ a lancé une série d'articles "La voix du Coach", invitant des coachs agiles à parler de leur métier et à réfléchir sur la diffusion de l'agilité en France.

=> Lire les interviews

Mon article a été publié la semaine dernière, je suis le 9e à m'être prêté à l'exercice. Exercice difficile…

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

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

- page 1 de 124