Nous façonnons nos outils, et ceux-ci à leur tour, nous façonnent
Marshall McLuhan
Gojko Adzic : Making impact !
L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !
Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !
On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.
Making Impact par Gojko Adzic
La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :
- Le facteur local
- Le facteur temps
- Le facteur Humain
Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.
Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :
- Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
- Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
- Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !
Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.
D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.
Rechercher de nouvelles idées, essayer de nouvelles choses.
Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.
En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !
Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !
La survivabilité
Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !
Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !
Selection
Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.
Non aux roadmaps, oui aux map of roads"
Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !
C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !
L’alignement rapide avec l’impact Mapping
L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution :
- Pourquoi ?
- Qui ?
- Comment ?
- Quoi ?
Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !
On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…
Nicolas Gouy : Agile with GUTS
Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.
Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…
Parlons de valeur
Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.
En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !
Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.
Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.
Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…
Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !
Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !
Faites suivre l’action efficace d’une réflexion calme. De la réflexion calme viendra une action encore plus efficace.
Peter Drucker
Molecular Structure of Nucleic Acids
Un article qui marque l’histoire des sciences n’est pas nécessairement un monument. L’article original de Watson et Crick décrivant la structure de l’ADN, la fameuse double hélice tient en un peu moins de deux pages de l’édition de Nature datant du 25 Avril 1953. Il vaudra aux deux auteurs associés à Wilkins, le prix Nobel de médecine en 1962.
Pour l’anecdote, le dessin de la double hélice est dû à Odile Crick, la femme de l’un des auteurs, peintre de profession. Ce dessin est par ailleurs la seule oeuvre pour laquelle elle est connue.
Moins drôle : le point de départ de l’article de Watson et Crick est une photographie, connue sous le nom de “photo 51”, prise par Rosalyn Franklin, que Wilkins a montré aux deux auteurs sans en informer sa collègue ! Voici la photo en question
Rosalyn Franklin apparait uniquement dans les remerciements de l’article, une bien piètre reconnaissance de sa contribution par ailleurs involontaire !
A Community Library
I haven’t written much on this blog recently. In those rare spare hours between my full-time job, working on my second book, contributing to my local community, building a studio extension to our tiny house, and raising our wonderful baby (now nine months old) I’ve been building AgileLib.Net as…
Les prévisions vous en disent beaucoup sur ceux qui les font, elles ne vous disent rien sur l’avenir.
Warren Buffet
Rendez-vous au Scrum Day 2014 !
Cette année le ScrumDay change de lieu ! La belle affaire me direz-vous : il a changé de lieu presque chaque année ! Mais cette fois, il quitte le centre de Paris pour aller chez Mickey.
Rassurez-vous, je suis presque sûr que nous ne serons pas obligé de nous coiffer d’une paire d’oreilles signées Walt Disney. J’animerais pour ma part un atelier avec mon collègue Benoit Nouyrigat. Allons-y pour une petite présentation : c’est l’Acceptance Tests Workshop !
Teaser, teaser…
Le développement guidé par les acceptance tests devient un standard dans le monde agile. Cela signifie que les tests fonctionnels seront au moins décrits avant le début des développement.
Mais partant de là, il existe de nombreuses façons de procéder, de multiples variations.
Cet atelier s’articule autour d’une pratique que nous utilisons régulièrement : l’acceptance test workshop. Il s’appuis sur l’intelligence collective pour faire émerger les tests fonctionnels pour valider le développement et assurer la compréhension partagée des fonctionnalités attendues.
Cet atelier vous donnera l’opportunité de pratiquer cette nouvelle technique sur des exemples que vous aurez construit.
Comment ça marche ?
Les participants à cet atelier forment des équipes de 4 à 5 personnes. A partir d’une courte étude de cas, ils devront élaborer quelques users stories sur la base desquels ils devront décliner des tests d’acceptance en groupe en revêtant des Personna (développeur, Product Owner, Testeur, etc.).
Lors d’une première phase, on cherchera à décrire les tests sous forme libre, en se concentrant sure la couverture de la specification en cas passants et non-passants.
La seconde phase accentuera l’aspect formel des spécification de tests via la formalisation Given / When / Then utilisée pour les tests BDD (Behavior Driven Development).
Voilà, vous savez (presque) tout sur ce quii se passera durant cette atelier. Libre à vous de vous joindre à moi et à Benoit !
ScrumBeer de Mars (en images)
Cela aurait dû être une ScrumBeer de Février, mais une collision de dates avec l’Agile Playground en a décidé autrement. C’est donc début Mars que nous nous sommes retrouvés en petit comité d’agilistes !
C’est dans un bar faisant la place belle aux jeux (et à la bière, bien sûr) que nous nous sommes retrouvés.
Outre nos discussions de comptoir habituelles, Arnaud nous proposait d’apporter notre contribution aux revues des propositions du ScrumDay 2014.
J’ai dit : le ScrumDay 2014 !
Après une rapide selection initiale, revue des propositions en binômes.
J’ai eu le plaisir de me livrer à l’exercice avec Pablo Pernot dont je dois dire que je le croise trop peu souvent !
L’exercice est intéressant, mais je le vois plutôt dans ce contexte comme une agréable récréation. J’espère que le comité de sélection ne regardera pas le résultat de nos cogitations de manière trop appuyée, d’autant que le filtrage initial a été particulièrement arbitraire !
Il faut un peu varier les plaisirs lors de nos rencontres. Mais pas trop quand même : les discussions, le p’tit verre de rouge ou la bière et la charcuterie, ça reste notre fond de commerce !
You have to make the rules, not follow them.
Isaac Newton
