How do you know that your product works ?

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

  • Quand le code est commité ?
  • Quand le produit est testé ?
  • Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Un produit commence avec une grande idée

Mais au-delà de cette idée, ou plutôt en chemin, nous avons toute sorte de risques.

  • Des risques techniques : avons-nous la technologie pour réaliser notre produit, la maîtrisons-nous ?
  • Des risques sociaux : pourrons-nous faire travailler ces personnes ensemble.
  • Des risques de coût et de planification : pourrons-nous sortir le produire à temps et aurons-nous les fonds pour le faire ?
  • Mais surtout, surtout : des risques business ! Notre produit doit être pertinent, donc désirable.

Henrik Kniberg nous rappelle ainsi 3 exemples de produits qui ont échoué à l’épreuve de la pertinence, pourtant tous issus de Google !

Suis-je en train de construire le mauvais produit ? C’est là la question clé à laquelle le Lean Startup nous invite à répondre afin de vérifier nos hypothèses par le biais de MVP et d’expérimentations.

C’est l’exemple de Dropbox que j’utilise moi-même souvent (et cité dans le livre d’Eric Ries que Kniberg reprend : ici le MVP est une vidéo ! Une vidéo totalement « fake » bien sûr, mais qui a permis de tester le marché à pas cher !

Une technique alternative est le « paper prototyping ».

De l’idée à la mesure

La « pirate metric ». Pourquoi « pirate », car le cri du pirate à l’abordage, c’est AARRR !!

  • Acquisition : Les clients viennent-ils ?
  • Activation : Utilisent-ils le produit
  • Rétention : Reviennent-ils ?
  • Référent : Nous recommandent-ils à leurs semblables ?
  • Revenu : Paient-ils ?

Le tout en forme de « funnel ».

Après le big bang

Par rapport à ceci, le big bang apparait une approche très risquée : on accumule les coûts en différent l’acquisition de valeur (si jamais elle arrive). Le chaos manifesto 2013 nous explique même que limiter la taille et la complexité est le principal facteur clé de succès. Autant pour ceux qui clament qu’il faut faire de l’agilité à plus grande échelle… Pensez plutôt à descaler, à faire de plus petites choses, de plus petits projets… ou de petites releases. Petites releases qui signifient déploiement en production réellement aisé.

A contrario, l’approche « big bang » nous conduit à faire de grosses releases, donc des releases difficiles. Et comme celles-ci sont difficiles, on s’efforcera d’en faire le moins souvent possible… Pour sortir de ce cercle vicieux, il faut faire de la release une routine. Comme on l’a fait il y a 15 ans pour l’intégration

Si quelque chose est difficile, faites-le souvent.

Où l’on (re)parle de la rapidité d’apprentissage

Déployer plus souvent, c’est avoir un feedback plus rapide de ses utilisateurs : c’est apprendre plus rapidement ! Apprendre plus rapidement cous permet de délivrer ce qui a le plus de valeur en premier, et ainsi de « dépasser la courbe d’investissement » tôt dans le cycle, et ceci en sélectionnant nos fonctionnalités de manière plus pertinente.

Nous le savions déjà, ce n’est pas l’occupation que nous devons optimiser, ni même « l’output », ce que nous délivrons, non c’est la valeur que nous délivrons que nous devons optimiser. Et cela ne peut se faire qu’en apprenant de nos utilisateurs. Henrik Kniberg trouve une manière très élégante d’exprimer cela :

Être focalisé sur la réduction de la distance plutôt que sur l’augmentation de la vitesse.

Spotify again

C’est avec Spotify, bien sûr, que l’orateur choisit d’illustrer tout son fil conducteur.

On part d’une idée. C’est le « think it » de Spotify. Pour toucher terre, il faut l’associer à un « narrative » et déterminer les métriques qui nous guideront.

Le « build it » qui suit s’inspire directement du Lean Startup, car c’est d’un MVP qu’il est question.

Le « ship it » met ce MVP entre les mains de l’utilisateur, pour en recueillir le feedback et en tirer les enseignements. On passe du « guessing » aux enseignements.

De ces enseignements, on tire les ajustements ou les changements de direction à opérer. C’est le « tweak it ».

Plus que savoir, c’est s’assurer que le produit fonctionne : en comprenant le problème, en apprenant de nos utilisateurs. Puis en itérant jusqu’à ce que le problème soit résolu.

La captation est de mauvaise qualité hélas, mais suffisante pour entendre le propos de l’auteur lors d’Agile Ceylon en 2014 à Colombo

Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !

Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.

Pour commencer, voici le livret des sessions, en mode présentation

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie – part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

Coactiv nous livre aussi ses retours.

How Spotify Builds Products

J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :

  • Think it : on a une idée !
  • Build it : on construit un MVP.
  • Ship it : On le met en production.
  • Tweak it : Puis on l’améliore continuellement.

C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.

Think it

Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !

La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.

Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !

Build it !

C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.

Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.

Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.

Ship it

Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.

Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.

Tweak it

C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.

Agile Game France 2014 en images (4/4)

Dernier volet de notre périple de 3 jours, ce post conclut mon retour sur l’Agile Game France dont vous retrouverez les opus précédents ici, ici et ici.

Rétrospective

Nos scribers sont réellement talentueux, voici ce à quoi ressemble désormais notre fresque

image

Et les voici à l’oeuvre.

image

Certains devant partir tôt, nous n’attendons pas le dernier moment pour nous livrer à une rétrospective de l’évènement. Elle s’effectue en 3 groupes, Jacques facilite le nôtre.

image

On prends très peu de temps, juste ce qu’il faut pour identifier un point d’amélioration.

image

La restitution se déroule tout aussi rapidement.

image

Tombola

Toujours dans le thème “je conclue l’Agile Games France en beauté”, il y avait une petite tombola pour gagner des polos. Il n’y en avait pas pour tout le monde ! En fait, il n’y en avait que 3 : tailles M, L et XL respectivement. Comme vous pouvez le voir de dos ici.

image

Et les gagnants sont : Alfred, Michel et … moi-même ! Le sort m’est généralement défavorable, c’est bien sympa que les choses ait tourné dans le bon sens justement aujourd’hui !

image

Et nous reste juste le temps pour 2 ateliers assez rapide.

Le jeu du Tao

Ce jeu avait été animé hier par Romain Couturier. Il avait été apprécié et une seconde session a eu lieu dans la matinée, mais animé cette fois par des participants de la session précédente. Alfred s’était tout d’abord proposé d’en animer une 3ème session, puis avait finalement décidé de remplacer cela par un retour sur ce jeu. D’abord déçu, j’ai vite compris qu’il ne se sentait pas armé pour une animation.

image

D’ailleurs, le jeu n’en est pas vraiment un, avec un livret qui ressemble plutôt à un annuaire et un contenu plus proche de la psychanalyse de groupe que du bon moment de détente ! Je trouve d’autant plus remarquable la prestation de Romain dont j’ai eu d’excellents echos qui se livrait à cette animation pour la première fois !

image

La chose mérite donc un peu de réflexion avant de s’y lancer tête la première. Tao Village propose des initiations, peut-être à essayer…

The Lean Takeoff

Alfred Almendra s’est donné un gros challenge : illustrer l’amorçage d’un cycle Lean Startup à l’aide d’un jeu ! Le jeu se focalise sur le “fit” entre le problème et la solution et tourne autour de cycles d’expérimentations. En l’état, le jeu ne me semble pas convainquant. Nous avons donné du feedback à Alfred pour lui donner des idées d’évolution.

L’exercice de construire un jeu autour de cette idée me semble vraiment très difficile. Je ne me vois pas relever le challenge. Je ne peux que souhaiter bon courage à Alfred (qui n’en manque pas par ailleurs) pour faire aboutir son idée !

Cloture

Cette 3ème édition d’Agile Game France se conclut maintenant.

image

Mon regret le plus important est d’avoir surtout été consommateur lors de cette édition, ce qui ne me convient guère ! Au départ je voulais présenter la version 2 du Business Value Fail que j’avais développé conjointement avec Yannick Ameur et présenté lors d’un Agile Playground. Mais j’ai été trop occupé pour mener à bien mon projet ! J’ai donc au moins deux objectifs pour l’an prochain (car oui, j’ai bien l’intention d’en être à nouveau !) :

  • Proposer l’animation d’au moins 1 jeu.
  • Mettre en place le Kanban des sessions que nous avons proposé lors de la rétrospective.

Un évènement comme celui-ci, c’est plutôt à la base pour les extravertis. Etant une sorte d’introvertis de compétition (si, si je vous assure), ce ne devrait pas être un lieu où je serais particulièrement à l’aise. Et poutant ! Pourtant, j’en suis ressortis gonflé à bloc avec des idées. Il faut dire que l’évènement garde son caractère bon enfant, détendu et bienveillant. Je ne peux comparer à l’an dernier, mais le lieu se prêtait plutôt bien à nos activités : 2 salles avec l’utilisation du palier, cela nous permettait 5 activités en parallèle, voir plus !

Pour terminer, je me dois de saluer la famille Siber venue au complet. Pas évident de venir avec un enfat en bas âge, mais ils l’ont fait !

image

Et bien entendu un grand bravo et merci aux artisans de cette évènement auto-organisé !

L’agilité à grande échelle chez Spotify, par Henrik Kniberg & Anders Ivarsson

Dans cet article, les auteurs décrivent la façon dont Spotify est parvenu à maintenir une dynamique agile malgré une montée en taille importante et rapide sur les 6 dernières années. Elle s’appuie sur un petit nombre de concepts organisationnels

Les squads

A mi-chemin entre la Scrum Team et la Feature Team, le squad est doté d’une mission sur le long terme, possède un espace de travail en propre et regroupe toutes les compétences nécessaires à sa mission. Son mode de travail s’inspire du Lean Startup, mais ici on appelle cela “think it, build it, ship it, tweak it”. Les squads bénéficient aussi des 10% hack days inspirés des 20% ou des exploration days de Jurgen Appelo (c’est la même chose).

L’objectif, sinon la clé est d’avoir des squads autonomes.

Les tribus

Les squads sont nombreux : il y en a 30 chez Spotify. Ils sont regroupés en tribus. Une tribu est focalisée sur une problématique métier particulière est fonctionne un peu en “incubateur de startup”. Elles sont de taille variées mais ne dépassent pas 100 personnes.

Les tribus organisent leur propres rassemblements et partagent outils, idées, etc… 

Les chapitres

Ce sont des regroupements “transverses” de personnes de même domaine d’expertise. Ils se rencontrent régulièrement pour partager outils, expérience, challenges, etc.. Chaque chapitre est géré par un manager qui est de fait le responsable hiérarchique de ses membres … mais est lui-même membre d’un squad avec des responsabilités opérationnelles ! Les chapitres sont locaux aux tribus.

Les guildes

Ce sont des communautés d’intérêt, plus informelles que les chapitres. Elles sont transversales à l’entreprise et regroupent souvent les chapitres correspondant des différentes tribus. L’animateur d’une guilde l’est à temps plein. 

Là aussi, la lecture du Management Workout de Jurgen Appelo peut être instructive…

L’organisation dans son ensemble

Elle est en quelque sorte matricielle. La dimension dominante est celle du “quoi”, l’axe opérationnel, donc les squads et les tribus. Il y a une seconde dimension, celle du “comment” qui correspond aux chapitres et aux guildes.

Et bien d’autres choses…

Voilà, il s’agit juste de l’apéritif pour vous encourager à lire cet article par ailleurs fort bien écrit et illustré. Il y a de nombreux éléments que j’ai passé sous silence, comme la gestion des dépendances entre les squads.

Spotify est une entreprise dont la structure dominante est tournée vers l’opérationnel. Elle rompt avec les structures traditionnelles orientées compétences qui fragmentent l’organisation en silos, obligeant les projets à franchir les obstacles entre ces silos, consommant temps et énergie et souvent aussi hélas, vidant les projets de leur substance !

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

Carnet de route : Agile Tour Rennes en Images (2/2)

Nous nous sommes quitté lors du premier post à l’heure du déjeuner. En fait cette heure du déjeuner était réservée aux lightning talks, chacun sur son créneau horaire afin de permettre de les voir tous au besoin !
Hélas cette méthode n’est pas très efficace. Seuls les derniers lightning talks rencontreront un public. Pas facile de gérer cela. Seul l’Agile Tour Nantes m’a convaincu sur ce point l’an dernier. Mais les organisateurs de l’Agile Tour Rennes restent très loin du fiasco du Scrum Day !
On en termine donc rapidement avec la pause déjeuner pour voir cela.

AT Rennes 2013 : Lunch (8)

Prélude au second mouvement : Le Podojo par Emilie Esposito et Damien Sainte

Un Ligtning Talk, c’est déjà court. J’arrive pourtant à en rater la moitié. C’est quoi le PO Dojo ? Un atelier construit collaborativement pour les PO et un groupe Google pour le faire vivre ! Ce qui semble remarquable, c’est l’aspect complètement communautaire, sans PO donc. Sans roadmap non plus, avec un catalogue d’ateliers qui évolue au fil des besoins et des idées.

AT Rennes 2013 : PO Dojo (1)

Alors que le concept de PO promeut que quelqu’un tienne la barre, ces PO ont su s’affranchir de l’idée d’avoir un chef (quelque soit la forme qu’on lui donne), une roadmap prévue à l’avance et tout et tout. Chapeau à eux !

Avant de me rendre à la session de Laurent Morisseau, je passe rapidement la tête dans la salle où officie Dov…

AT Rennes 2013 : Dov

Reprise : #OMG, mon équipe fait son haka en Kanban style ! Par Laurent Morisseau

Un petit challenge pour notre ami Laurent en ce début d’après-midi : faire bouger le public à l’heure de la digestion…

Et d’abord, c’est quoi Kanban dans un projet agile ? De l’amélioration continue + de la gestion de projets !

Commençons avec Scrum

Quand l’on part de Scrum, le point de départ, c’est le tableau des tâches : à faire, en cours, fait… MAIS on met un nom sur une tâche ! C’est un antipattern. Le stand-up devient un reporting !

AT Rennes 2013 : Scrum et Kanban (2)

Améliorer les choses

  • En utilisant les “classes de service”, pour traiter les bugs urgent, par exemple
  • En régulant le flux des stories et des tâches en cours en utilisant des limites de WIP (work in progress) à chaque niveau.

Bref, l’idée est de rendre les problèmes visibles dès qu’ils sont évoqués et de poser des limites hautes et basses.

Quand le PO est dépassé…

Que dire d’un backlog de 70 user stories pour 7 développeurs ?
C’est bien trop, ou bien trop détaillé ! Scrum en tant que process met la contrainte sur l’équipe de développement. En amont, le PO doit travailler en flux, donc sans faire trop de stock.
On peut remédier à cela en matérialisant ce flux tiré et en étendant le Kanban aux activités amont et un matérialisant les états des stories.
Vous pourrez en savoir plus sur le site de Laurent, où vous trouverez non seulement une video mais le matériel de cette présentation sous forme de podcast.

Entracte : Zenika à l’Agile Tour Rennes

Je vous l’ai dit, nous étions présent en force à cet Agile Tour Rennes, pour représenter Zenika. Non seulement depuis l’agence de Rennes, mais aussi de Paris et de Nantes ! Cela valait bien une petite photo de famille.

AT Rennes 2013 : Staf Zenika (4)

Pour une fois, ce n’est pas moi qui prend la photo, cela me donne l’occasion d’y avoir l’air d’un niais. Et tant que j’y suis, j’en profite pour remercier Allison qui s’est dépensée sans compter pour préparer notre présence ici.

AT Rennes 2013 : Allison (2)

Les session s’enchainent. Il est l’heure de celle de Géry

Interlude : Carpaccio Game avec Géry Derbier

Géry nous propose un grand classique : Le carpaccio game. Mais qu’il anime avec grand talent et tout autant d’énergie.

AT Rennes 2013 : Carpaccio Game (2)

C’est très studieux, car il s’agit de programmer le sujet proposé par tranches de 8 minutes et d’apporter de la valeur à chaque itération. Un exercice auquel je me suis d’ailleurs livré il y a peu.

AT Rennes 2013 : Carpaccio Game (3)

Acte 2 : Booster Scrum avec le Lean Startup par Olivier Lafontan

Là encore j’ai bel et bien raté une partie de la session, mais j’étais très curieux de la voir, car elle a eu une belle affluence au Scrum Day en Avril dernier.

Lean Startup nous apprends à mettre l’investissement là où il y a de la valeur. Scrum tend à se “débarrasser” de ces questions sur le PO qui se tape un peu tout sur cet aspect. Et celui-ci se trouve un peu démuni face à ce genre de problème avec pour seul appui le backlog… Lean startup apporte quelques outils :

  • Le Lean Canvas
  • Le Validation Board
AT Rennes 2013 : Olivier Lafontan (1)

La charnière entre Lean Startup et Scrum se trouve au niveau de ces outils. La priorisation du travail devient une priorisation des hypothèses à vérifier. Car Lean Startup ne parle pas de besoin … mais d’hypothèses. Tant que ces “besoins” n’ont pas été vérifiés ils sont en effet hypothétiques. Le cycle Scrum devient un cycle de validation des hypothèses.
A plus grande échelle, un gestion de portefeuille se traduit en portefeuille de Canvas.

Conclusion : Christophe Keromen

C’était ma dernière session de l’après-midi (même si en fait il y en avait une après).

Christophe nous offre une session rafraichissante pour nous ressourcer aux origines de l’agilité. Il remonte au manifeste agile et à l’invitation d’Alistair Cockburn. Non, en fait il remonte plus loin : à Henry Ford, Richard Denning et Taïcho Ohno…

AT Rennes 2013 : Christophe Keromen (1)

Je ne vais pas essayer de reconter la session de Christophe qui mérite plutôt d’être vue. Toutefois, je ne résiste pas au plaisir de dévoiler le Lean version Dan Brown : “Le Lean est un projet Franc-Maçon pour dominer le monde” ! Un grand moment…
Pour finir, Christophe nous propose un nouveau gourou agile : Bob l’éponge … pour absorber les pratiques qui marchent !

Tombée de rideau : A l’année prochaine !

Cet Agile Day était un peu marathonien, force est de l’avouer. Sur la durée, je dirais qu’il y avait une session de trop. Mais ce fut une excellente journée, aussi bien du point de vue de la qualité des sessions que de celle des échanges. Figurez-vous que j’y ai même rencontré l’un des fidèles lecteurs de mon blog (du coup, je le salue !).

AT Rennes 2013 : A l'accueil (1)

Il est temps de se quitter et de se donner rendez-vous à l’année prochaine. A moins qu’un coach retreat, entre-temps…