Scrum, mon sérum à Agile Grenoble

J'ai été très heureux de participer à la 10e conférence Agile Grenoble. Des retrouvailles chaleureuses dans une merveilleuse ambiance.

En tant qu'ancien keynote speaker, j'étais invité à donner une session spéciale 10e anniversaire (HoliScrum) plus une présentation le matin.

C'est de cette présentation dont je vais parler dans ce billet. Je l'ai appelée Scrum ? mon sérum !

Lire la suite...

Scrum Guide 2017

J'ai pris connaissance de la nouvelle hier soir, juste avant de partir au klub de lecture (qui portait sur Reinventing Organizations, passionnant), par un tweet de la Scrum Alliance :

Il s'agit du Scrum Guide (on va l'appeler comme ça) d'une vingtaine de pages, maintenu par les 2 fondateurs Ken Schwaber et Jeff Sutherland. Ils ont mis leur trombine sur la couverture pour qu'on soit bien sûr que ça vient d'eux.

Déjà, je note que la fréquence de mise à jour s'accélère, la dernière version date d'à peine un an.

Je ne considère pas ce Scrum Guide comme les tables de loi, il y a d'autres sources d'inspiration, mais je me suis quand même jeté dessus rapidement car je suis en train d'écrire l'édition 5 de mon livre (Scrum) et on ne sait jamais, ça pouvait avoir un impact.

Après lecture, je suis rassuré, ça ne va pas me faire tout réécrire. Ouf !

Le sous-titre de mon livre est encore, pour quelque temps, "le guide pratique de la méthode agile la plus populaire". Ça va changer pour l'édition 5, car mon livre n'est pas vraiment un guide et Scrum pas vraiment une méthode (quant au populaire…). Il est temps de s'aligner.

J'avais choisi ce sous-titre dès la 1ère édition de mon livre, en 2009, avant la sortie du premier Scrum Guide de Schwaber et Sutherland (daté de 2010).

J'ai eu la semaine dernière un commentaire sur Amazon, le 16e pour l'édition 4. Appréciation moins bonne que les autres, le lecteur trouvant que j'avais perdu de la clarté et même l'esprit de l'agilité en essayant d'être exhaustif, et conseillant le Scrum Guide.

Exhaustif sûrement pas, mais je reçois bien le commentaire sur la clarté et la lourdeur. J'essaie de faire mieux pour l'édition 5 (mes relecteurs m'y aident). Mais cela restera un livre qui ne parle pas que de Scrum, en élargissant sa mise en œuvre.

Moi aussi je conseille vivement la lecture du Scrum Guide. Je viens de relire le nouveau une 2e fois et il me paraît mieux écrit que les versions précédentes (j'avais participé à leur traduction et c'était pas si facile). Je n'ai pas parlé des modifications apportées, je vous laisse les découvrir, mais pas de changement notable, juste des clarifications (réussies), notamment sur le rôle de Scrum Master et la mêlée quotidienne. Pas de quoi susciter des controverses, comme pour la version 2013.

Je vois du mouvement dans ma dropbox, des traducteurs agiles (Fabrice et Nicolas) sont déjà actifs sur la version française, vous n'aurez probablement pas longtemps à patienter. En attendant lisez un article déjà traduit, il y en a plein qui vous intéresseront parmi les 1374 sur le wiki Ayeba.

Mise à jour du 13 novembre : la version française est en ligne.

Auto-organisation

La semaine dernière, j'ai publié sur twitter une photo de grues cendrées en migration au-dessus de la Lorraine. Elles étaient en route pour l'Espagne ou l'Afrique avec une pause probable dans les lacs du Der.

grues.JPG Photo en CC-SA-BY (merci ma sœur).

Les grues pratiquent le vol en groupe sur longue distance et se relaient régulièrement.

C'est un bel exemple d'auto-organisation disais-je dans mon tweet.

En regardant la photo, je me suis souvenu qu'il y avait des oiseaux en migration dans un slide du support de cours de la formation de la Scrum Alliance que j'avais suivie en 2005. Je l'ai retrouvé, et, en fait, c'était un dessin avec des oies sauvages :

oies.jpg

Le terme auto-organisation n'y était pas associé, le vol des oies était là pour illustrer l'approche empirique et la complexité.

Pour qualifier l'équipe Scrum, j'ai utilisé depuis les qualificatifs d'auto-organisée, et parfois d'auto-gérée (comme dans ce billet sur mai 68, où je dis aussi autonome), les 2 de façon interchangeable.

Steeve, qui relit des chapitres de la future édition 5 de mon livre, m'a fait remarquer que ce n'était pas pareil, auto-organisation étant pour lui plus adapté à une équipe Scrum communiquant avec son environnement.

Frédéric Laloux, dans Reinventing Organizations, qui sera discuté ce soir au klub de lecture d'Agile Toulouse utilise auto-gouvernance pour les entreprises opales.

Lui non plus ne confond pas avec autogestion, il explique que c'est associé à la prise de décision par consensus, jugée non efficace, alors qu'il préconise le processus d'avis (advice process).

Auto-gouvernance, autogestion ou auto-organisation, quel terme utiliser dans l'édition 5 ? Je vais probablement me fixer sur auto-organisation, qui colle mieux avec l'approche systémique que je développe.

Quant à Lilian, le mot qui lui vient à l'esprit en voyant les grues, c'est stigmergie. Il a un dossier très intéressant sur le sujet, dont cet article qui présente l'autorisation a priori et les nœuds.

Jardinage, agilité & rock'n roll à Agile tour Toulouse

Je suis particulièrement heureux d'animer une session avec Benjamin Cabanne pour la 10e de la conférence Agile Toulouse.

Je connais Benjamin depuis longtemps et je savais qu'il s'intéressait à la vigne. Mais nous avons découvert cet été, grâce à twitter, que nous aimions tous deux faire pousser des légumes. Et que nous nous intéressions aux nouvelles approches de culture, la permaculture et la biodynamie.

Elles font partie de ce qu'on appelle la systémique, qu'on peut voir comme la rencontre de plusieurs disciplines.

Et si cela pouvait nous inspirer pour la discipline que nous mettons en œuvre dans notre vie professionnelle, l'agilité ?

C'est pourquoi notre session s'appelle "Jardinage, agilité & rock'n roll". Notre intention est d'enrichir l'agilité avec des principes systémiques. Nous mettrons l'accent sur des principes éthiques issus de la permaculture.

Nous sommes pile poil dans le thème choisi pour cette année : les écosystèmes agiles.

Il semblerait qu'on va jouer cette 10e à guichets fermés, c'est déjà complet. Belle aventure, dont Olivier a retracé l'historique.

HoliScrum à Agile Grenoble

Pour la 10e édition, Agile Grenoble ajoute à son programme des sessions spéciales d'une demi-journée. J'animerai une d'entre elles, le mercredi 22 novembre après-midi.

Ma session s'appelle HoliScrum. Cela aura pu être PermaScrum ou CyberScrum. Mais HoliScrum ça sonne mieux, et ça me rappelle les Monty Python.

Holi c'est pour holisme. Holisme, systémique, cybernétique et encore plus permaculture m'intéressent actuellement pour étendre Scrum. Considérer l'équipe Scrum comme un système, considérer le produit réalisé, en interaction avec les parties prenantes, aussi comme un système, considérer l'ensemble comme faisant partie du même écosystème. Renforcer les interactions et les bordures pour le rendre durable.

Ce sont des idées que je vais développer dans l'édition 5 de mon livre, à paraître en 2018.

Toutes les sessions spéciales d'Agile Grenoble sont déjà complètes, quel succès ! Mais sur Twitter, @AgileGrenoble annonce :

Quelques places supplémentaires pour les sessions spéciales #agilegrenoble seront mises en vente ce mercredi matin ... soyez vigilant !

10e saison pour les conférences agiles

L'an dernier j'avais publié un billet pour le 10e anniversaires de l'agilité à Toulouse. Car cela avait commencé en 2006 avec des séminaires à peu près trimestriels.

Les conférences, elles, on démarré en 2008, avec le premier Agile (tour) Toulouse, dans le cadre d'une initiative qui était, à mon goût, un peu parisienne condescendante au départ.

C'est revenu depuis tous les ans depuis et le centralisme a vite été abandonné. Cela se passe toujours en automne. C'est la 10e édition, puisque cela a commencé en 2008, il y a 9 ans.

Agile tour Toulouse fêtera la 10e les 26 et 27 octobre.

C'est aussi la 10e à Grenoble. Je participerai cette année à Agile Grenoble (sans le tour) pour présenter HoliScrum, une approche systémique autour de Scrum, qui devrait être développée dans la 5e édition de mon livre, en 2018.

Agile Grenoble 2017, du 22 au 24 novembre.

Il y un an, à cette époque, je préparais la keynote pour le premier Agile Pays Basque. C'était "Scrum ? mon scrotum ! ".

Cette première conférence agile en Pays Basque avait été rafraichissante, dans une ambiance très chaleureuse. La 2e s'annonce encore plus formidable, avec plein de nouveautés et toujours le même esprit.

Agile Pays Basque, les 22 et 23 septembre.. Inscrivez-vous, c'est bientôt !

Ma sélection rock de l'été 2017

Il n'y a pas que le Scrum et l'Agilité. Il y aussi le Rock'n roll (et son côté rebelle).

Comme l'an dernier, voici mon top3 des albums écoutés cet été.

Peter Perrett - How The West Was Won

Stéphane disait l'autre jour, lors du walkingDev sur la permagilité, que la plupart des gens écoutaient toujours la même musique que quand ils avaient entre 18 et 25 ans.

On pourrait croire que je suis dans ce schéma avec Peter Perrett, puisqu'il était le chanteur des Only Ones groupe qui sévissait à la fin des années 70. Mais non, il n'y avait pas Spotify à l'époque, on n'avait pas accès à tout ce qui sortait. Je n'ai jamais eu de 33 tours des Only Ones. Seulement Magazine, Wire, Devo. Même pas Joy Division.

Peter Perrett (à ne pas confondre avec Pierre Perret, hein) fait d'abord penser à Lou Reed, puis les guitares prennent plus de place, pour mon plus grand bonheur. Pour le clin d’œil avec l'agilité, notons qu'un morceau s'appelle An Epic Story.

Suuns - Hold/Still Remixes

J'avais aimé le dernier album des Suuns sorti en 2016, Hold/Still. Avec ce Remixes de la musique des canadiens, j'ai trouvé le rythme parfait pour une marche rapide en solo. Essayez, c'est irrésistible. Il faut juste enlever le morceau 3 de la liste.

Fufanu - Sports

Je reste dans le sport avec le dernier album des islandais de Fufanu (je ne sais pas comment en prononce). De la très belle pop bien rythmée. Sûrement quelques références à ce que j'écoutais entre 18 et 25 ans.

À ce propos, j'aurais pu mettre dans ma sélection Kraftwerk - 3-D The catalogue, mais finalement non, trop long, je ne réécoute que quelques morceaux (Autobahn, RadioActivity et surtout The Model).

Passation

Il y a 10 ans, quand je participais à une journée, j'en faisais un compte-rendu dans un billet de blog, ici même. J'ai appris et j'ai pris du plaisir en faisant ça. J'ai même gagné le prix du meilleur blog qui en parle aux Valtech Days 2007. J'avais fait un billet pour le premier jour et un autre pour le 2e, qui était le premier Open Space auquel je participais.

J'ai continué quelque temps et puis je me suis lassé. Peut-être parce que d'autres ont fait ça bien mieux que moi. Fabrice est devenu le meilleur, et de loin ; voyez par exemple sa rétrospective d'Agile Grenoble 2011 ou celle du ScrumDay 2012.

Et puis Fabrice est passé lui aussi à d'autres aventures.

En lisant le compte-rendu du #walkingDev de Nathaniel, je me dis que la passation s'est bien faite, dans un autre style.

Je m'étais demandé si j'allais raconter cette belle journée, peut-être Fabrice s'est posé la même question, et c'est Nathaniel qui l'a faite.

Nous avons animé cette journée sur la "permagilité" à trois. J'ai pris beaucoup de plaisir à la préparer et la vivre ; j'ai retrouvé tout ça et même plus dans le billet de Nathaniel.

wlakingDev permagilité

De la permaculture associée à Scrum, il en sera question bientôt, je bricole là-dessus.

Sprint zéro pour l'édition cinq

Il y a tout juste deux ans, je finissais l'édition quatre de mon livre Scrum. J'y mettais une dernière touche en écrivant …l'avant-propos, à l'occasion d'un retour dans mon pays natal.

20170715_084924_HDR.jpg

Cette édition a été publiée en octobre 2015 et continue honorablement sa vie. Scrum 4e éd. est très souvent n°1 des ventes chez Amazon, dans sa catégorie.

Classement Amazon

Elle représentait une édition majeure, avec de nombreuses évolutions et nouveautés.

Je viens de me lancer dans l'édition cinq. Elle comportera probablement moins de changements qu'entre la trois et la quatre (si vous avez des suggestions, dites-moi).

Elle devrait quand même recevoir un nouveau chapitre, dont le titre provisoire est "Démarrer avec le sprint zéro". Ce sera le chapitre 23, le dernier. On y parlera de bordure et d'écosystème.

20170716_170117_HDR.jpg

WalkingDev PermAgilité

Panneau perma

Qu'est-ce que la permaculture peut apporter à l'agilité ?

Ce sera le sujet de la journée WalkingDev qui aura lieu le 30 août à Toulouse. Nous l'animerons à 3, avec Fabrice qui viendra spécialement de Bordeaux, et Nathaniel, qui descendra de Paris (en minimisant son impact carbone).

Nathaniel a fait une présentation remarquée sur le sujet lors du dernier Agile France.

Petit lexique :

  • Agilité : capacité à favoriser le changement et à y répondre en vue de s’adapter au mieux à un environnement turbulent — Highsmith, circa 2005.
  • Permaculture : approche systémique qui permet de construire des écosystèmes viables en s'inspirant des lois de la nature — Alonso, 2016.
  • WalkingDev : apprendre avec ses pieds en explorant des trucs dans des endroits insolites — Langlois, 2017.

Tiens, la marche pour réfléchir, discuter et apprendre, c'est le thème du Philomag hors série que je vais lire cet été.
Marcher, c'est donc ce qu'on fait pendant un WalkingDev (ou un Raid Agile).

Pour en savoir plus sur cette journée et son PaF, lisez la FAQ.

8e Raid Agile en octobre

Les Cévennes

La vue sur les Cévennes, de la salle de formation.

Lire la suite...

La vie de la story selon Elodie

Après Jimmy, c"est Élodie qui a commenté mon billet la vie de la story. Elle me fait des remarques très intéressantes, j'y réponds en dessous, dans un ordre revu.

Élodie :

J'imagine que c'est une simplification, un workflow idéal... mais il donne impression que toute idée aboutira... je serais plus à l'aise avec quelques "portes de sortie" pour prendre en compte les depriorisations, les risques, les imprévus...

Dans une autre vie, il y a plus de 15 ans, j'ai fait de la modélisation de processus en UML ou BPMN, il y avait plein de branches et de boucles… L'agilité m'a appris à simplifier. La finalité du modèle à 5 états que je propose est sa représentation, puis son utilisation sous forme de bacs (ou colonnes). Le management visuel (kanban) pousse à représenter tout process de façon linéaire, de la gauche vers la droite. C'est donc comme tout modèle, une simplification de la réalité. Mais…

Je verrais bien une sortie vers la poubelle au niveau de l'affinage. Oui, je pense qu'il faut savoir renoncer ^^

Bien sûr. Lors de ma présentation à LeanKanbanFrance 2015, j'avais montré ce slide —avec poubelle :

Options et engagement

C'est le rôle du PO de faire en sorte que des options soient explorées, puis abandonnées si elles apportent peu d'impact. Il est donc normal de jeter à la poubelle des stories à partir du bac à sable, ou qui sont en affinage, voire même, exceptionnellement, qui sont prêtes.

Du coup, plus de boucle ?

Dans une approche flux Kanban, la boucle est embêtante, elle peut conduire à violer une limite. On évite de revenir en arrière, de remonter le flux.

Imaginons une story "done", mais qui n'est pas acceptée à la démo (quelle qu'en soit la raison). Quel serait alors son état ?

Le guide Scrum est très clair au sujet de la revue : • L’Équipe de Développement fait la démonstration du travail qui est « Fini ». Il ne s'agit pas d'une revue formelle où une autorité accepte ou pas. Le cas que tu imagines n'arrive pas.

Personne d'extérieur à l'équipe n'a le droit de considérer ce que l'équipe considère fini comme pas fini. Seule l'équipe peut reconnaitre s'être trompée, c'est pourquoi dans iceScrum il y a bien longtemps, nous avions prévu de pouvoir repasser une story finie à en cours tant que le sprint n'est pas clos. C'est une boucle alors cela doit rester exceptionnel.

Ou alors la notion de "fini" inclus l'acceptation par le PO ?

Oui. À mettre de façon explicite dans la définition de fini si ce n'est pas implicite dans l'équipe.

Et si on n'arrive pas à la finir ? Je verrais bien aussi une flèche de la réalisation à l'affinage si on ne n'arrive pas atteindre le Done.

C'est pas fini, et en général reporté au prochain sprint. La story reste en cours.

Et si on considère que l'acceptation n'est pas dans la DoD et se joue en demo il faudrait une étape supplémentaire ça ferait donc 1 étape et 1 état en plus...

Cela ne peut pas arriver car :

  1. on ne montre que ce qui est fini à la démo
  2. fini inclut l'acceptation (qui est là pour confirmer que la story est finie, un des 3C)

Et la revue n'est pas prévue pour ça.

Merci Élodie.

Feedback sur la planification

Pour l'édition 4 de mon livre, j'ai revu complètement le chapitre qui porte sur la planification à moyen terme. J'ai fait un gros effort sur le pourquoi. J'ai commencé le comment par un exemple simple, sans estimation. J'ai introduit des variantes à l'estimation et au planning poker. J'ai essayé d'illustrer les notions présentées.

Je l'ai également déplacé, car cette notion ne fait pas partie du cœur de Scrum. C'est maintenant le chapitre 16, il s'appelle Planifier la release.

Voici sa structure :

Planifier la release

Mots-clés : estimation, prévision, planifier dans l'incertitude, vélocité, capacité, planning poker, T-shirt, noEstimates, estimer par comparaison, points de story, engagement, budget.

À part celui de mes relecteurs —mais cela fait 2 ans, je n'ai pas eu de feedback de mes lecteurs sur ce chapitre. Je suppose que vous êtes maintenant quelques-uns à l'avoir lu, sur les quelques 5000 qui ont fait l'acquisition de l'édition 4.

Je serais heureux de savoir ce que vous en avez pensé et que vous me fassiez part de vos suggestions d'amélioration.

La vie de la story selon Jimmy

Suite à mon billet d'hier, j'ai reçu un commentaire de Jimmy L. que je remercie de son feedback.

Jimmy est tout à fait d'accord avec moi pour ne montrer à la revue qu'une story déjà déclarée finie. Cependant il enchaîne :

…Mais cela m'étonne justement qu'on s'arrête généralement à "Finie" sur ce genre de workflow, et qu'on ne mette pas au moins en bout l'état correspondant à l'avis positif reçu en revue de sprint.

Non. Voilà pourquoi : fini est forcément le dernier état du workflow, sinon c'est pas fini. Plus que fini, ça n'a pas de sens. C'est une autre histoire.

Avec plus de détails :

Jimmy ne parle que d'un avis positif, je comprends que son idée est que la story continue jusqu'à la revue même si elle est finie avant. Soit, mais la revue fait partie du "process", l'équipe sait qu'elle doit y montrer les stories finies. Pas besoin d'un état sur chaque story pour cela, s'il faut vraiment penser à préparer la démo, je suggère plutôt d'ajouter une story de préparation de démo tant que c'est nécessaire.

L'avis (positif ou négatif) sollicité à la revue auprès des parties prenantes s'appelle le feedback. Il est le bienvenu et peut conduire à ajouter une nouvelle story, mais pas à faire revenir la story en arrière (c'est à dire à considérer qu'elle n'est plus finie).

À méditer pour la prochaine fois : et si dans sa définition de fini pour une story, Jimmy avait "avoir reçu un avis positif lors de la revue" ?

Jimmy poursuit :

J'avais tendance à appeler cet état "Acceptée" mais cela est ambigu lorsque le client fait ensuite une phase de recette approfondie (souvent appelée User/Fonctional Acceptance Testing). Du coup, j'opte pour l'état "Revue" après le "Finie".

Oh ! Une phase de recette par le client. Scrum ? mon scrotum !

Bon, il va me falloir au moins un autre billet pour y répondre. Cela concerne plusieurs aspects souvent mal compris dans Scrum :

La vie de la story a changé en 10 ans

Il y a à peu près 10 ans, j'écrivais un billet "Les états significatifs d'un élément de backlog".

Amusant de le relire aujourd'hui et de constater comment mon approche de Scrum a —légèrement— évolué au fil des ans.

Pas beaucoup sur les états, car je décris toujours la vie d'une story avec cinq états, dont les noms ont un peu changé, mais pas les 2 essentiels : prêt et fini.

Depuis l'édition 3 de mon livre j'en reste à ce workflow pour une story :

La vie de la story

C'est ce qui a donné naissance à la présentation du backlog en bacs, qui sont consolidés dans l'édition 4.

J'en reviens aux changements depuis le billet de 2007 :

  • je dis story, c'est plus court qu'élément de backlog
  • identifié est devenu idée, truc qu'on met dans le bac à sable
  • estimé est remplacé par en affinage (cette notion n'existait pas en 2007). Je considère maintenant l'estimation comme une activité, optionnelle, de l'affinage
  • mon schéma de 2007 montre une boucle si la décision de ne pas accepter la story comme finie est prise. Je mentionnais que cela se faisait lors de la revue de sprint. C'est là le changement le plus notoire : on n'attend pas la démo pour déclarer une story finie. Au contraire, on ne montre à la revue qu'une story déjà déclarée finie.
  • la revue de backlog dont je parlais s'appelle maintenant l'affinage (revue de backlog était pas si mal)
  • dans ce billet de 10 ans, je disais qu'une story passait de prête à en cours lors de la planification du sprint. Maintenant je dirais qu'elle reste prête tant qu'on ne travaille pas dessus. Si on commence la story au 8e jour du sprint, elle change d'état à ce moment-là.

Ces 2 derniers points illustrent l'évolution vers du flux : ce ne sont pas les événements Scrum (planif, revue) qui ont un impact sur l'état de l'ensemble des stories. Chacune a sa vie indépendante. C'est ce qu'on retrouve dans Scrum3.0.

7e Raid Agile la semaine prochaine

La semaine prochaine, il fera beau dans les Cévennes, du côté de Lasalle pas loin de Saint-Jean du Gard. J'y serai avec Pablo, car nous animerons le 7e Raid Agile, toujours au Mas du Canton.

La piscine devrait être ouverte ce qui n'était arrivé qu'une seule fois dans les Raids précédents, en juin 2015 (qui est resté connu comme le raid piscine).

Rétro un soir de raid en juin

Ça vous tente ? Trop tard, car nous sommes complets depuis plus de 2 mois. Nous accueillerons comme d'habitude des personnes venant seules de leur société et d'autres venant à plusieurs. Nous aurons d'ailleurs 2 sociétés qui nous envoient des participants pour la 3e ou 4e fois.

Nous serons nourris, comme la dernière fois, par Ratatouille, le cuistot nomade qui se posera avec nous pour ces 3 jours.

Ça se présente bien, je suis ravi d'y aller, c'est pour ça que je continue les Raids alors que j'ai arrêté les cubes, c'est plus rock'n roll.

Avec Pablo, nous avons décidé de faire 2 Raids par an. Le prochain est déjà programmé en automne, du 3 au 6 octobre. Il sera inédit, avec la présence parmi nous de Laurent Morisseau, qui apportera forcément sa touche spéciale.

Pour lire les témoignages des anciens participants, voir les photos souvenirs, lire le guide du raider, savoir argumenter auprès de votre RH, allez sur raidagile.fr

Vous pouvez aussi consulter ici-même des billets de mon blog qui en parlent.

Mon agilité électorale

Pour ces élections qui se terminent demain, je me dis que j'ai fait preuve d'agilité électorale. Agilité au sens capacité à s'adapter et réagir aux changements, tout en restant fidèle à ses valeurs et principes.

Lire la suite...

Flux dans le sprint et engagement

Suite à la lecture de mon billet Scrum3.0, Eric se demande, à propos du sprint en flux continu :

Le flux continu remet en cause le principe "pas de changement pendant un sprint". Comment permettre à l'équipe de s'engager dans ce mode de fonctionnement ? Au jour le jour ? Ou est-ce que ce mode de fonctionnement est réservé à des équipes qui ont dépassé le stade de la nécessité de s'engager ?

Je réponds à Eric :

  • l'engagement de l'équipe porte sur l'objectif du sprint
  • le flux continu ne remet pas en question l'engagement sur cet objectif
  • l'objectif est défini lors de la planification de sprint
  • ce mode de fonctionnement en flux continu est compatible avec un engagement librement consenti
  • on ne revoit pas cet objectif tous les jours au moindre changement, évidemment, car il reste du mou par rapport à la capacité de l'équipe. Il est remis en question seulement si, de façon exceptionnelle, un événement imprévu survient (as usual).
  • on peut donc accepter de nouvelles stories pendant le sprint sans remettre en question l'objectif du sprint sur lequel on s'est engagé, tant que cela n'exclut pas une story indispensable pour l'attente de cet objectif


Lire aussi :

Scrum 3.0

Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l'essence de la méthode.

C'est pourquoi je porte une grande attention à l'article Scrum3.0 qu'ils viennent de publier.

On y retrouve l'approfondissement de quelques sujets déjà abordés dans leur livre.

Parmi leurs propositions :

  • le rôle de Product Owner qui est séparé en 2 : le Business Owner et le Capitaine. Cela permet de réintégrer dans Scrum un pattern fréquemment rencontré, celui du PO Proxy
  • le sprint en flux continu. J'ai présenté cette notion lors d'une session à LeanKanbanFrance 2015 et j'en parle dans l'édition 4 de mon livre, chapitre Appliquer Kanban sur Scrum, § 20.3.
  • le backlog structuré en Deliverable Results Backlog (ce que j'appelle le tableau de features) et Work Backlog (le backlog de stories) lui-même organisé avec le sous-ensemble des stories prêtes

Bienvenue au Scrum3.0 !

Onze

Onze ans de blog !

Le premier commentaire d'Albar, en avril 2006, me disait :

Ciel, un blog ! Très courageux de ta part de te lancer dans l'aventure, parce qu'il faudra assurer pour les mises à jour...

J'ai assuré pas trop mal, je trouve.

Maintenant, je me demande de plus en plus souvent s'il reste des choses à dire sur Scrum. J'ai l'impression d'avoir tout écrit dans la version 4 de mon livre. La motivation diminue.

Cependant de temps à autre, elle revient. Le plus souvent pour dénoncer les méfaits du Scrotum, mais aussi pour annoncer ou présenter une nouveauté, car il y en a.

D'ailleurs demain, pour commencer ma 12e année, je vous parlerai de Scrum3.0.

L'agilité à grande échelle

22-2-changer_dechelle_-_pompiers.jpg

Il faut un vrai besoin pour changer d’échelle.

Dessin de Patrice Courtiade et légende extraits de Scrum, le guide etc. page 278

Lire la suite...

Ma 128e formation Scrum

Demain et jusqu'à vendredi, je serai à Bordeaux pour y donner ma 128e formation Scrum. Eh oui, j'ai commencé en 2005, à raison d'une dizaine par an en moyenne.

Si j'ai arrêté les formations Scrum inter-entreprises en 2014, je ne me lasse pas d'animer des sessions en entreprise, pour des équipes qui démarrent. Le contexte est toujours différent, ma formation aussi et j'y prends du plaisir.

Le contenu varie selon les participants, mais aussi parce que j'expérimente régulièrement des nouveautés. Cette fois, j'ai envie d'essayer un atelier flexible de pliage pour faire de beaux avions en papier. En effet, j'ai pris un peu de retard dans le magnifique calendrier que m'a offert JLM :

calendarAirplane

J'aime à croire que ma formation est un bon moyen d'éviter le Scrotum par ignorance et de se protéger des néocons.

Pour prolonger l'effet de la formation, chaque participant repartira avec un beau livre sur Scrum, qui se vend toujours très bien, un grand merci à mes lecteurs.

Vincent, qui a participé à ma 126e, a fait une belle sketchnote de sa 3e journée.

Les activités de la rétrospective

Mon premier article sur les activités de la rétrospective, en 2007, avait eu gros succès. Quand je relis ce billet aujourd'hui, je me dis que j'en garde l'essentiel, 10 ans après, quand j'anime des rétrospectives (ce que je fais assez souvent).

Ma présentation des activités de la rétro a un peu évolué, voilà ce qu'elle donne maintenant :

activités de la rétro

Mais surtout ce que j'ai changé, c'est le résultat de la rétro. Plutôt que d'essayer à tout prix d'obtenir un plan d'actions, ce qui est assez vain, je pousse les participants à définir un objectif.

En gros à se mettre d'accord sur l'impact qu'ils visent à la fin du sprint suivant. Et je leur laisse le sprint pour définir le comment. Mais à condition qu'ils affichent cet objectif d'amélioration sur leur beau tableau, bien visible, et qu'ils en parlent tous les jours à la mêlée.

La rétrospective, c'est le chapitre 12 de mon livre Scrum. 12 pages illustrées et une technique de rétro originale, la rétro-glandouille.

Prioriser avec CD3

Le Cube de jeudi portait sur Prioriser, estimer et planifier.

J'ai présenté plusieurs techniques de priorisation : HIPPO, 10/10, VRAC et CD3.

CD3, c'est le Coût du Délai Divisé par la Durée.

Le coût du délai est une approche économique : on calcule le coût de ne pas faire une feature et on fait en premier celle qui a le coût du délai le plus élevé.

Bien sûr, cela n'est pas facile. Voyons avec un exemple, celui que j'ai donné aux participants du Cube.

J'ai repris le projet Grands Sites d'Occitanie d'Al tablèu. L'objectif de la région est d'avoir 10 millions de visiteurs sur 12 sites sélectionnés.

Par quel site commencer ? Prenons en 2, la cathédrale d'Albi et les Arênes de Nîmes, et essayons CD3.

exemple pour le coût du délai

On voit sur les cartes un nombre de visiteurs prévus (on va dire que c'est par semaine, soyons optimistes) et l'effort pour les travaux estimés en taille de Tee-shirt. Sachant que L correspond à 5 semaines de travaux et M à 3, par quel site commencer ? ou faut-il commencer les 2, en divisant la force de travail ?

Pour Albi, le CD3 est 24. Pour Nîmes, il est de 33. Il faut faire Nîmes puis Albi. Au bout des 8 semaines nécessaires pour avoir les 2, on gagne 140 000 visiteurs (500 000 contre 360 000). Évidemment ce n'est pas une bonne idée de faire les 2 en parallèle, on n'a pas de visiteurs avant la 6e semaine.

La technique VRAC aurait donné le même résultat (pas de risque, ni d'apprentissage).

Cependant CD3 présente des différences d'approche intéressantes :

  • l'alignement de la réflexion sur un objectif (ici 10 M de visiteurs est la métrique qui compte),
  • l'optimisation économique qui pousse à plus étudier les hypothèses,
  • la prise en compte de la variation dans le temps en définissant des profils d'urgence.

Pour ce dernier point, imaginons qu'un spectacle d'orgue soit prévu pendant les 7e et 8e semaines à Albi et qu'il attire du monde, ce qui fait qu'on passe à 200 000 visiteurs ces 2 semaines. Le coût de ne pas avoir Albi à cette date augmente. Avec cette nouvelle hypothèse, il vaut mieux commencer par Albi, on aura gagné 20 000 visiteurs après les 8 semaines.

Les participants au Cube m'ont paru quelque peu désorientés avec CD3, peut-être aurait-il fallu y passer plus de temps. Pour moi, c'est très séduisant.

En savoir plus sur CD3.

Les activités de l'affinage du backlog

L'affinage du backlog (en anglais Backlog Refinement) se pratique avant le premier sprint, puis pendant chaque sprint.

L’objectif de l'affinage est d'augmenter les chances de succès des futurs sprints, en entretenant le backlog.

Voici les activités qu'on y mène, en équipe :

Les 6 activités de l'affinage

Le moyen mnémotechnique pour retrouver ces activités : ADAPTER.

L'affinage se déroule entre le Product Owner et le reste de l'équipe, à un moment laissé à l'appréciation du collectif, soit sur un rythme régulier (ce qui est plus facile), soit à la demande.

Voici un enchainement possible des activités d'une séance d'affinage :

  • On regarde le nombre de stories prêtes. S’il n'y en a pas assez, l’approvisionnement est primordial. Pour y parvenir, on s'appuie sur les 6D.
  • On identifie ensuite les stories épiques qu’il faut décomposer.
  • On examine le bac à sable et le tableau de features en vue d’approvisionner en nouvelles stories à affiner.
  • On purge en éliminant des stories devenues inutiles et on trie en plaçant certaines dans le bac à glace.
  • On fait une estimation des nouveaux éléments approvisionnés ou décomposés.
  • On réordonne les stories par priorité, ce qui permet d'actualiser le plan de release.

C'est donc au cours de l'affinage qu'on estime, priorise et planifie.

Affiner le backlog, c'est le titre du chapitre 7 de mon livre Scrum.

- page 1 de 130