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.

Prioriser, estimer et planifier

Lire la suite...

Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Cube_marche2_600_263.svg.png

Comment on priorise ? Pourquoi on estime ? À quoi ça sert ? Qu'est-ce qu'on estime avec Scrum et l'agilité ? Comment faire en sorte que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l'agilité ?

Lire la suite...

Les 6 activités de planification du sprint

La planification du sprint (en anglais Sprint Planning) est un événement Scrum qui se déroule à chaque début de sprint.

L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories.

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

6 activités de planification du sprint

Voici un enchainement possible des activités :

L’équipe embrasse le contexte du sprint. Pour chaque story prête, en commençant par la première, l’équipe confirme avec le PO sa confiance pour la finir dans le sprint.

Pour faciliter la réalisation de la story, on prépare la tactique d’essaimage et on procède à l’identification des tâches.

Avec cette connaissance du travail à faire, l’équipe s’engage sur l’objectif du sprint. Le sprint est alors lancé et chacun, aligné sur l'objectif et la tactique collective, part réaliser une tâche.

Lectures en compléments :

Planifier pour réussir le sprint

En parcourant mon livre à la recherche du 6e D, je m'arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l'article près. Évidemment ce n'est pas ce que j'ai voulu. C'est un bug.

Je mène l'enquête et découvre rapidement que le bon titre du §9.1 est "Planifier pour réussir le sprint". D'ailleurs ce titre était déjà présent dans l'édition 3 et il apparaît dans les fichiers que j'ai conservés pour la fabrication de l'édition 4.

En fait, lors de ma dernière relecture juste avant mise en production, j'ai demandé à ce qu'on ajoute "Les" devant le titre du §9.2, par souci de cohérence. Voici un extrait du fichier markdown que j'ai utilisé pour communiquer mes retours de lecture :

Capture_d_e_cran_2017-01-31_a__06.23.36.png

L'éditrice de réalisation s'est trompée en l'appliquant au §9.1. Je ne m'en suis pas rendu compte avant la publication et je m'en excuse auprès de mes lecteurs. Je l'ajoute immédiatement aux quelques errata de cette édition. Voici ce que cela aurait dû donner :

Capture_d_e_cran_2017-01-31_a__05.52.59.png

J'en profite pour mettre en évidence le titre du § "C'est la story qui sprinte". Oui, l'idée que ce soit l'équipe qui sprinte pose problème, c'est pourquoi je préfère appliquer cette notion de sprint à la story.

Boite et outil

De 2005 à 2013, j'étais impliqué –et même très impliqué, ce blog en témoigne– dans le développement de l'outil iceScrum.

J'ai quitté Kagilum, la startup dédiée à la diffusion d'iceScrum, il y a 4 ans et je me suis converti, un peu plus, au management visuel physique.

Mes anciens étudiants ont continué leur chemin avec iceScrum. Je viens de visiter leurs nouveaux locaux, dans un lieu convivial très sympa : Ô local. Avec babyfoot.

À cette occasion, ils m'ont fait une démo de la nouvelle version d'iceScrum, la R7, peaufinée depuis si longtemps. Ça a l'air pas mal au niveau UX.

Ils m'ont aussi montré la Kagibox, une boite avec plein de trucs pour le management visuel physique. Belle idée pour tenter de concilier outil et note collante.

Séduit par les locaux, je vais y organiser mon prochain Cube "Prioriser, estimer et planifier", le 23 février matin. Et pour 3 billets achetés, j'offre une Kagibox. De quoi bien affiner et estimer en équipe.

La boiboite qui vous attend dans la salle de formation ô local :

ô boite ô local

Critères VRAC pour la priorité dans le backlog

Les critères VRAC

Lire la suite...

Expérimentations pédagogiques

Quand j'étais prof à la fac, j'avais expérimenté pas mal de façons d'enseigner avec les étudiants de l'IUP ISI. Mais j'ai arrêté la fac.

Cependant je donne toujours des formations et je continue à expérimenter.

  • Cela fait des années que je fais du #noSlides.
  • Avec Pablo, nous avons lancé le Raid Agile et cela dure depuis quelques saisons. Une formation vraiment différente.
  • En fin d'année dernière, j'ai organisé le premier Cube à Toulouse. Bientôt le 2e, qui porte sur Estimer, pour prioriser et planifier. Le concept 1CUBE&GO repose sur une pédagogie modulaire originale.
  • One step beyond. Demain je participe à mon premier WalkingDev avec Stéphane : Détournons GitHub.

Tableau Scrum

La story, élément du backlog, a une vie qui passe par 5 états.

La tâche, travail contribuant à une story, se représente sur 3 états.

Un tableau Scrum avec les 2 niveaux montre à la fois l'avancement des travaux pendant le sprint (la vie des tâches, les stories en cours de réalisation et finies) et le backlog pour les sprints suivants (bac à sable, stories en affinage, stories prêtes). C'est tout simple, pas besoin de plus d'états (et donc, ni de colonnes supplémentaires).

tableau Scrum avec stories et tâches

Cela peut s'appliquer dans tous les usages de Scrum. Pour les features, c'est également recommandé de faire un tableau, mais les états sont spécifiques à chaque contexte.

Impressions cubistes

Denis, qui a participé à mon premier cube en décembre, m'a offert cette fresque (lui il dit sketch).

Ça me fait un bien beau souvenir de cette matinée.

Le concept 1CUBE&GO consiste à expérimenter en groupe, pendant une demi-journée, une solution à un problème couramment rencontré par les participants. Pour ce premier cube, le problème était l'expression du besoin, jusqu'à arriver à un backlog priorisé.

Voilà ce qu'en ont pensé des participants :

Le format est intéressant. 1/2 journée pour faire le plein de pratiques. Très bonne interactivité entre participants et avec le coach.

Christophe Crapez, Engineering Manager, Intel

Je le recommande

Marion Hayet, Product Owner, Mobydoc

"Très positif" - "Pouce en l'air" - "J'ai aimé être acteur"

un collectif d'AE&T (AE&T est très collectif, bientôt une belle histoire sur l'aventure de leur libération)

Je trouve le format intéressant et interactif ce qui aide à l'apprentissage.

Pierre Cauquil, SQLI

Format compact très intéressant.

Anne-Laure Lugan, récemment PO , Airbus D&S

1CUBE&GO a déjà une couverture nationale, avec 18 animateurs de cubes dans toute la France. Pour ce cube, j'avais apporté ma touche personnelle, et une nouveauté, la notion d'hypothèse pour lier les features aux impacts (je reviendrai dans un prochain billet sur cette approche "Hypothesis-Driven Development").

Ce sera le cas aussi pour le prochain cube à Toulouse, qui porte sur un sujet très demandé. En effet, de nombreuses équipes ont des problèmes avec l'estimation. Pourquoi on estime ? À quoi ça sert ? Qu'est-ce qu'on estime ? Comment faire pour que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l'agilité ?

J'ai quelques solutions à ces problèmes ; cela devrait intéresser des SSII toulousaines, si elles me lisent… Les inscriptions sont ouvertes.

- page 1 de 129