Chasser l'ignorance avec des cubes

4 raisons de scrotum

Lire la suite...

Anars vs neocons

J'ai eu le plaisir de faire la keynote d'introduction d'Agile Pays Basque :

Scrum ? mon scrotum !

Sur Twitter, ce qui a été le plus cité de ma présentation, c'est "anars vs néocons", juste devant "le cycle en Vrum".

Voici un exemple[1] :

Je ne vais pas expliquer ici tout ce qui m'a amené à cette formulation[2], je le réserve d'abord à ceux qui viendront m'écouter à Rennes dans 2 semaines.

Sachez que le titre est important, je parle des influenceurs, et comme toute catégorisation, elle est réductrice.

Cependant, elle dénote d'une tendance, exprimée par exemple dans ce retour ô sources. Paradoxalement, elle n'a rien de passéiste, elle est ultramoderne. Bientôt en français.

Notes

[1] venant d'un Software Anarchist"

[2] Tiens, en 2010, j'avais publié un billet : Agilité et anarchie où j'évoquais en filigrane la possibilité qui s'incarne maintenant dans les "néocons".

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 !

Ouverture d'Agile Pays Basque

J'aurai le plaisir de faire la présentation d'ouverture du premier Agile Pays Basque, à Bidart (presque sur la plage).

bidart.png

Lire la suite...

Prioriser, estimer et planifier

Lire la suite...

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.

Lire la suite...

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.

Lire la suite...

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.

Lire la suite...

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

- page 1 de 125