Note de lecture : Fifty Quick Ideas to Improve your User Stories, par Gojko Adzic & David Evans

Note : 7 ; De bonnes recettes, surtout pour le découpage des user stories

Les auteurs l’annoncent clairement dès le début : ceci n’est pas un livre pour le débutant. Il s’adresse à ceux qui ont déjà une connaissance et une compréhension de base de ce qu’est une user stories. Les 200 pages de l’ouvrage sont consacrées à solidifier cette connaissance et à améliorer le savoir-faire qui y est lié. Le tout en 5 parties et en, comme l’indique le titre, 50 idées ou principes. Je ne vais pas parler des 50 principes, ce serait fastidieux.

Chaque « idée » emprunte la même présentation. D’abord une introduction que l’on pourrait appeler « motivation ». Elle développe ce qu’il y a derrière le titre, le « pourquoi » de cette idée. Vient ensuite une section intitulée « key benefits », comme son nom l’indique elle met en exergue l’amélioration apportée par cette pratique ou le travers qu’elle évite. Enfin, la 3ème partie est consacrée au « how to make it works », c’est à dire le mode d’emploi.

La première partie est dédiée à la création de User Stories. Ce sont 8 idées sur environ 35 pages qui constituent celle-ci. On retrouve quelques idées qui font leur chemin aujourd’hui comme les « 3 C » de Ron Jeffries ou les 3 questions de Jeff Patton plutôt que le template de Mike Cohn qui perd son aura de jour en jour. Mon « take away » de cette partie est certainement la notion de sphère de contrôle liée à la sphère d’influence qui est le thème de l’idée n° 7.

Lire la suite

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Tout est incroyablement plus simple avec les User Stories. L’utilisateur évoque une possibilité ? Hop ! Une User Story ! Une idée autour d’un café ? En voilà une autre !

Plus besoin de gros document, simplement de me balader avec mon calepin sous le bras ! Hélas, cette simplicité est trompeuse. En nous débarrassant d’un artéfact lourd et compliqué, j’ai nommé le célébrissime IEEE 830-1998, les créateurs des User Stories voulaient laisser la place au vrai travail de spécification : l’observation du terrain, la collecte des informations, les conversations constructives, l’exploration des alternatives. Décider ce que l’on doit faire est souvent un véritable travail d’abnégation, ou du moins il devrait l’être.

La simplicité du formalisme des User Stories est trop souvent interprété comme une licence à la superficialité. Pourtant le corpus de connaissance existe, encore faut-il aller le chercher !

La littérature traitant des spécifications est riche de dizaines d’années de publication d’excellente valeur. Oui, d’excellente valeur. Tout cela a souvent été interprété à tord au sein des projets classiques comme la nécessité d’écrire de lourds et nombreux documents se paraphrasant entre-eux (et souvent eux-mêmes).

La spécification agile a fait table rase du passé et de ses enseignements. Table rase d’un formalisme qui a fini par prendre le pas sur le contenu.

Mais est-ce vraiment le cas ?

Template Zombies

Dans l’ouvrage qui leur sont consacrés [Cohn04], Mike Cohn nous propose une formulation aujourd’hui devenu le standard de rédaction des User Stories.

“En tant que xxx, je veux yyy, afin de zzz”

Le template a comme vertu première d’obliger à capturer les éléments importants. C’est bien le cas ici. Cette approche est surtout nécessaire aux débutants comme le relèvent Tom DeMarco et ses co-auteurs [DeMarco+08]. Mais elle vient aussi avec un travers important, où la forme prends le pas sur le fond : c’est le « template zombie ». Gojko Adzic nous en donne un bon exemple [Adzic13] :

“As a user, I want to register in order to log in”

Ah oui ! Etre obligé de me logger et devoir m’enregistrer pour ce faire, j’ai vraiment hâte… D’autres sont des tâches afférentes au travail de développement. Par exemple :

“En tant que développeur, je veux automatiser le processus de déploiement, afin de mettre à disposition l’application plus rapidement et plus souvent”

Bien sûr, cela doit certainement être fait, mais qu’est-ce que cela a à voir avec le produit ? Cela a surtout à voir avec le dogmatisme qui veut que tout ce qui figure dans le plan de sprint soit sous forme de User Story. Si votre motivation est d’être conforme au processus, félicitations : vous faites un projet non-agile en utilisant des techniques agiles !

Dans le même ordre d’idées, nous pourrions évoquer les « stories techniques », mais j’ai déjà écrit sur ce sujet il y a quelques temps.

On peut accuser une certaine paresse, ou une indolence à donner un véritable sens aux user stories. Mais il n’y a pas que cela.

More rules, more pain…

On dit qu’une story doit être petite, de manière à tenir dans une itération ou à être une « survivable experiment » [Adzic+14]. De manière à avoir du feedback plus rapidement aussi, bien sûr, l’un des moteurs de l’agilité. Mais plus de focus, c’est aussi moins de contexte et moins d’invitation à aller le chercher. C’est ainsi que l’on finit par se retrouver avec des User Stories de ce genre :

“En tant qu’analyste financier, je veux un export Excel, afin de manipuler les données comme je le souhaite”

Autant pour la qualité de l’analyse. Et ce n’est pas fini. Nos stories doivent aussi être INVEST. Une bonne idée de manière générale, mais que dois-je faire si certaines de mes stories ne sont effectivement pas indépendantes ? Est-ce si grave ?

Que se passe-t-il si ma User Story consiste à explorer des options ? Dois-je rejeter cette user story car justement, je ne serais pas capable de l’estimer … ou même de la tester ?

L’approche agile doit en principe nous aider à faire face à l’inconnu ou aux idées novatrices. Au lieu de cela, nous nous engageons gaillardement dans une voie qui cherche à éliminer tout risque, à prétexter que notre story n’est « pas prête », bref à aseptiser gentiment notre beau projet.

Alors, doit-on en finir avec ces User Stories ?

Dans son livre, Jeff Patton [Patton14] nous rappelle la véritable nature d’une spécification : créer de la compréhension partagée. Les «  3 C » (carte, conversation, confirmation) nous rappellent que la carte est l’élément le moins important, simplement un « jeton pour une conversation ». Le template de des User Stories a insidieusement déplacé notre attention sur les cartes, et plus précisément l’élément situé au milieu. Ce dernier représente la solution, ironiquement c’est celui qui devrait constituer la marge de négociation du « INVEST » !

Au template, je préfère les 3 questions que nous suggère Jeff Patton (encore lui) : Qui ? Pourquoi ? Quoi ? Et précisément dans cet ordre, avec le « quoi » à la fin !

Enfin, si les User Story remettent l’église au milieu du village en redonnant aux interactions l’importance qui leur est dû, elles ne doivent pas occulter la nécessité de développer des savoir-faire, d’appréhender d’autres techniques permettant la compréhension du contexte et des enjeux, ou supportant l’acquisition d’information. Certaines de ces techniques viennent de la communauté agile, d’autres viennent d’autres domaines comme l’UX ou le « requirements management » que nous avons déjà évoqué.

Bien comprises, les User Stories véhiculent réellement l’état d’esprit agile à ce que nous appelons spécifications (à défaut d’un autre nom plus adapté) : se focaliser sur ce qui compte réellement. Mais il s’agit juste d’un point de départ, à compléter et renforcer comme nous le faisons avec nos pratiques d’ingénierie.

Références

[Adzic13] : Writing “As a User” does not make it a user story ; Gojko Adzic ; http://gojko.net/2013/09/30/writing-as-a-user-does-not-make-it-a-user-story/

[Adzic+14] : Fifty Quick Ideas to Improve your User Stories – Gojko Adzic & David Evans – Leanpub 2014 – ASIN : B00OGT2U7M

[Cohn04] : User Stories Applied, for agile software development – Mike Cohn – Addison Wesley / Signature series 2004 – ISBN: 0-321-20568-5; EAN: 978-0-321-20568-1

[DeMarco+08] : Adrenaline Junkies and Template Zombies ; Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson & Suzanne Robertson

[Patton14] : User Story Mapping – Jeff Patton – O’Reilly 2014 – ISBN : 978 1 491 90490 9

L’Impact Mapping s’invite au French SUG !

Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.

image

A l’image de la soirée « en finir avec… », cette rencontre prend la forme d’un open-space. Le principe est simple et commence à être bien connu, ne revenons pas dessus. Le thème est encadré, certes. On dispose de 2 créneaux horaires et 3 salles qui seront finalement 4 ! Une restitution en fin de première session, pour la seconde, ce sera autour des pizzas !

La place de marché est rapidement alimentée et il ne reste plus qu’à faire son choix. Pas mal de monde ne connait pas en fait l’Impact Mapping ! Pour toi, cher lecteur, sache que j’avais fait une note de lecture sur le livre éponyme et que Gojko Adzik était venu en parler dans les locaux de Zenika !

Session 1 : un « why mesurable »

Ce point précis est souvent vu comme une difficulté, et s’en est bien une. Mais c’est aussi une aide, car ne pas avoir de mesure signifie souvent que l’on encore dans le moyen et non dans le « pourquoi » ! Un certains nombre d’idés et pratiques remontent rapidement :

  • Le « why » est notre pôle nord, la direction à prendre sans nécessairement devoir l’atteindre.
  • L’impact est notre boussole, qui nous indique si nous sommes dans la bonne direction.
    • Les OKR : Objective Key Results.
    • Les NPS : Net Promoter Scores.

Bien sûr, rapidement la conversation dévie sur des sujets connexes : User Story mapping et le problème de la convergence sur le why… Il est temps de passer à la restitution !

Restitution !

C’est Géraldine qui se charge de la restitution pour le groupe. Inutile de revenir là-dessus.

L’impact mapping de la soirée

Beau challenge que s’était donné l’une des équipes : construire un impact mapping sur la soirée elle-même ! Une sorte de paradoxe auto-référençant… Laurent se charge de la restitution.

La construction de la map a donné lieu à 2 difficultés :

  • D’abord converger sur un même objectif quantifiable. Au final celui qui est choisi me semble sujet à caution. Mais l’exercice est difficile.
  • Choisir dans quel sens construire la map ! Descendant ou montant 

Finalement, l’équipe aura utilisé les deux directions alternativement. C’est en fait ce qu’on fait dans la vraie vie !

Qu’est-ce que l’Impact Mapping

C’était le track « débutant », mais qui manquait un peu de praticiens expérimentés pour aider ! Le group a donc exploré diverses questions liées à l’impact mapping :

  • L’impact Mapping permet de redonner du sens à ce que l’on fait !
  • Comment se positionne l’Impact Mapping par rapport au Story Mapping ?
  • La construction d’un impact mapping conduit à des cycles successifs de divergence / convergence à l’image de ce que l’on fait en Design Thinking. Cette alternance évite l’effet fractal des mind-maps et induit une sorte de « respiration ».
  • Qu’il y a-t-il au delà de l’Impact Mapping ? Les cartes heuristiques ?

Second créneau

Impact Mapping et Lean Startup

L’Impact Mapping et le Lean Canvas sont deux outils qui me semblent pertinents pour donner du sens à ce que l’on construit, de manière agile. Mais sont-ils concurrents ou complémentaires ? Peuvent-ils s’utiliser en association ? Si oui, comment ? Voilà des questions sur lesquelles je reste pour l’instant complètement sans réponse.

C’est pour réfléchir ensemble à cette question que j’avais choisi ce groupe. Hélas pour moi, la session prend la tournure d’un long exposé.

Non seulement la teneur ne m’intéresse pas, mais je viens aux open-space pour échanger : réfléchir, écouter, enrichir les autres de mes idées et m’enrichir de même. Je ne trouve pas cela ici, je fais marcher la « loi des deux pieds » !

Retours d’expérience

Je m’arrête dans la salle où se discutent des retours d’expérience. Plusieurs sujets d’intérêt sont évoqués :

  • Comment sait-on qu’un Impact Mapping est réussi : lorsque les participants ont envie de continuer !
  • L’impact Mapping crée un effet positif important au niveau des conversations et de l’alignement.
  • Il est important de construire une branche complète (avec les 4 niveaux) assez tôt. Ce premier accomplissement soulage les participants.
  • Il faut rester « macro » sur les impacts. Cet outil n’est pas là pour créer des stories détaillées.
  • C’est un outil utile quand on ne sait pas par où commencer !
  • On peut l’utiliser dans les projets qui ont déjà commencé pour consolider ce qui existe, ou pour s’en servir comme outil de communication.
  • Ce n’est pas un outil « fire and forget » : on l’initialise avec de premiers chemins, puis on revient dessus plus tard, à la lumière de ce que l’on a appris.

Fin de soirée

Sans aller jusqu’à dire que la 3ème mi-temps est ma préférée, c’est au moins un moment dont j’essaie de profiter. Discussions avec Frédéric sur les spécifications et l’agilité, retrouvailles avec Sébastien après 8 ans… Il se fait hélas tard…

Note de lecture : Specification by Example, par Gojko Adzic

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

La seconde partie est la plus imposante du livre, avec environ 130 pages et 6 chapitres. C’est le cœur de l’ouvrage. Les 11 pages du chapitre 5 « deriving scope from goal » sont un prélude à « impact mapping » et on y retrouve les mêmes thèmes. Je ne peux qu’en recommander la lecture. Le chapitre 6 est un de mes thèmes préférés car on y évoque la spécification collaborative. Tous les patterns de cette vingtaine de pages valent de l’or. J’applique déjà certains d’entre eux mais trouve ici des éléments pour m’améliorer. Encore un chapitre à ne pas rater.

Les deux chapitres suivants sont au cœur de l’ouvrage. Le chapitre 7 aborde l’écriture même des tests, comment les concevoir, comment les penser pour couvrir une spécification. Là encore ce sont des patterns desquels se dégage une stratégie claire et précise : sur la conception des tests, des cas passants et non passants, des données de test et des exigences « non fonctionnelles » ! Le chapitre 8 est un approfondissement du précédent, avec un accent mis sur les antipatterns.

Il était probablement difficile de parler de ce sujet sans évoquer les questions d’automatisation. C’est ce que font les 2 chapitres suivant. Le chapitre 9 évoque les options techniques d’automatisation y compris l’épineuse question des IHM. Le chapitre 10 se préoccupe surtout de l’intégration de ces tests dans des plateformes d’intégration et des stratégies possibles : isolation des systèmes tiers, plusieurs niveaux de validation, etc. Le chapitre 11 qui clos cette partie reprend le thème de la « documentation vivante ». Les patterns n’y sont pas sans intérêt, mais il reste le chapitre le plus léger de cette partie.

La Troisième partie est consacrée aux études de cas, c’est à dire les projets principaux (pas tous) qui ont donné la matière au livre. Des 7 chapitres qui la compose, 6 sont consacrés à ces études de cas sur 40 pages. J’ai eu du mal à me passionner pour cette partie. Y sont exposés les challenges auxquels ces différents projets ont été exposés à leur passage à le spécification par l’exemple, pourquoi ils l’ont fait et ce qu’il y ont appris.

Le dernier chapitre du livre nous livre les conclusions de l’auteur. L’une des plus importantes me semble être le passage d’une pratique des tests basée sur la défiance (coûteuse et inefficace), à une dynamique basée sur la collaboration et la confiance. Pas étonnant que cette pratique marche mieux en milieu agile.

L’ATDD ou plutôt la spécification par l’exemple est aujourd’hui ce que je considère comme un des plus forts effets de levier pour un projet agile, une fois acquis les pratiques d’ingénierie. L’auteur aborde les différents aspects (collaboration, processus, écriture et conception) avec un regard aiguisé que corrobore des données de terrain. En le lisant, je suis passé du « waouh effect » au « mais bien sûr » jusqu’à « ah oui, c’est ce que je fais et ça marche du tonnerre ». Cet éventail de réactions me rappelle la lecture du Design Patterns. Une autre façon de dire que je pense qu’il s’agit là d’un texte majeur !

image

Référence complète : Specification by Example, How successful teams deliver the right software – Gojko Adzic – Manning 2011 – ISBN : 978 1617290084

Specification by Example

https://www.goodreads.com/book/add_to_books_widget_frame/1617290084?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

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.

image

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.

image

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.

image

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.

image

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 !

Note de lecture : Impact Mapping, par Gojko Adzic

Note : 8 ; Simple, puissant et très facile à lire !

A peine un livre, cette nouvelle prose est plutôt un livret de 70 pages. Et encore ! Nombre d’entre elles sont couvertes entièrement ou partiellement de figures pour non-voyants. Alors, comment prendre au sérieux un texte qui, entre nos mains, ressemble d’avantage à une plaquette publicitaire qu’à une prose solide, sérieuse et dense ?

La réponse est simple : il suffit de lire le livre ! Tout d’abord la technique elle-même est non seulement intéressante, elle est en train de devenir un grand classique de la définition des produits. Elle me rappelle en partie la pyramide de Leffingwell, mais projetée dans une réelle pratique agile, et m’évoque également le “start with a why” de Simon Sinek. L’autre aspect est la prose très épurée. On sent que l’auteur, loin d’avoir essayé de noircir du papier, à cherché à épurer sa prose. Au final, on obtient un texte très simple et court. Justement, le contenu, parlons-en !

Il est compose de 3 chapitres. Je les appelleraient “chapitres” même s’ils ne sont pas présents ainsi.

Le premier chapitre “what is an impact map” nous montre ce qu’est une “impact map” et l’illustre avec deux exemples. L’explication est très claire, mais le but de ce chapitre n’est pas d’indiquer comment on procède pour construire cet outil.

Le second chapitre “the role of impact map” fait le lien entre cette pratique et d’autres du monde agile : les user stories, le MVP du Lean Startup, le design thinking (une référence aussi importante que celle des users stories !). Ce chapitre donne de nombreuses références complémentaires, plusieurs à chaque page, en fait !

Enfin le troisième chapitre “creating an impact map” nous propose un processus complet de construction de la map en plusieurs étapes, dispensant de nombreux conseils pratiques au long du chemin. Ce chapitre se termine par différentes catégories d’anti-patterns, qui auraient mérité leur propre chapitre.

Vu la taille de l’ouvrage, celui-ci se lit très, très vite … et c’est tant mieux ! Notre temps est précieux et l’on appréciera l’auteur qui sait être concis et cependant nous livrer de la matière. La dernière page tournée, on pense quand même que l’auteur aurait pu donner un peu plus de corps à son propos. Par exemple, deux études de cas nous faisant vivre la construction de la map auraient donné un aspect plus concret à cette pratique. Je me dis aussi que les chapitres 2 et 3 auraient pu être intervertis avec profit (sauf les anti-patterns). Mais au final, je suis très satisfait par cette lecture.

Il s’agit là d’un investissement de temps extrêmement minime, n’en faites pas l’économie !

impact-mapping

Référence complète : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Impact Mapping: Making a Big Impact with Software Products and Projects

http://www.goodreads.com/book/add_to_books_widget_frame/0955683645?atmb_widget%5Bbutton%5D=atmb_widget_1.png