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.

Publicités

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 !

ScrumDay 2013 (en images) 4/4

Voici le 4ème opus de ma couverture du Scrum Day. J’ai été un peu ambitieux en pensant couvrir 4 posts. Celui-ci sera donc plus court. Vous trouverez les posts précédents :

  • Ici pour le début de matinée.
  • Ici pour la fin de matinée et le début du tour des partenaires.
  • Et enfin là pour la fin du tour des partenaires et le début d’après-midi.

Je n’ai pas aussi bien couvert l’après-midi que je l’aurais dû. Mon arrêt suivant sera la table ronde de Thomas Lissajoux sur la gestion de portefeuille agile.

ScrumDay2013-13-Portefeuille02

L’exercice d’animation d’une telle session est plutôt difficile, mais je fais confiance à Thomas pour cela. En fait, pour vous en rendre compte, il suffit de voir la vidéo de la session accessible en ligne.

Il va être temps de regagner l’amphitéatre Descartes pour la keynote de fermeture de ce ScrumDay 2013.

ScrumDay2013-14-Dupagne01

<Certaines personnes s’étonnaient de voir un médecin venir nous parler d’agilité et plus encore faire notre keynote de clôture ! Dominique Dupagne nous a emenné faire un voyage depuis le système immunitaire vers la formation de notre cerveau pour nous conduire vers le système d’organisation des primates.

Nous n’avons pas inventé l’agilité. La nature l’applique avec succès depuis bien plus longtemps que nous. C’est ce que nous révèle Dominique Dupagne, avec bien plus de talent que je n’ai pu le faire ! Mais le sytème d’organisation naturel des grands primates est le système hiérarchique, qui porte en lui les germes de sa propre destruction. L’approche agile en est le remède, mais il demande efforts et dévouement pour s’imposer.

ScrumDay2013-14-Dupagne03

Fi de mes explications fort peu convaincantes, voyez plutôt la vidéo de sa prestation : 20 minutes de régal !

Cette nouvelle page du Scrum Day est presque tournée. Il nous reste à remercier nos partenaires et toutes les personnes qui nous ont aidé à organiser cette journée.

ScrumDay2013-15-Cocktail01

Comme l’an dernier, nous avons invité ces personnes à échanger autour d’un verre. IBM a mis à notre disposition une terasse située au second étage. Un lieu peut-être moins magique que le précédent, mais un excellent moment de convivialité après le stress de la journée.

ScrumDay2013-15-Cocktail05

Nous avions le lei jusqu’à 22h00, donc “enjoy et relax” !

J’espère que Véronique ne m’en voudra pas de placer cette dernière image dont je trouve qu’elle conclut bien cette journée.

ScrumDay2013-15-Cocktail08

Voilà, cette fois, c’est vraiment fini !

Il nous restera d’autres occasions de profiter de cette excellente journée : les supports de présentation seront mis en ligne bientôt. De même les sessions filmées ainsi que le reportage mené par Véronique Messager seront mis à disposition dès que possible !

Pour les plus pugnaces, nous nous retrouveront dès le mois de Mai pour un “Scrum Boat” juste avant Agile France (qu’il ne faut pas non plus rater).

Retours sur l’agile tour Bruxelles 2012

Je m’étais fixé dans mes objectifs sur ce second semestre, de me joindre à la communauté agile Belge à l’occasion de l’agile tour Bruxelles. je n’ai pas hésité longtemps à répondre à l’appel à orateurs de Bruno Sbille. Plusieurs raisons à cela:

  • L’opportunité de faire une présentation en Anglais. Il faut bien garder la forme !
  • L’occasion de rendre la politesse à Bruno qui nous avait fait le plaisir de venir faire une présentation dur la Programmation Neuro Linguistique lors d’une soirée du Scrum User Group.

J’espérais donc bien être retenu. Je l’ai été : merci au comité d’organisation !

L’aller-retour dans la journée, ça fait une grosse journée, mais ça valait le coup.

Pascal Van Cauwenberghe : 11 steps to perfect code

Pascal s’est présenté comme un “recovery bug writter”. Il nous a présenté son processus destiné à éliminer les bugs. Il compte 11 étapes, pas moins.

La qualité dépend-t-elle des testeurs ? La réponse est non. En fait, elle est souvent inversement proportionnel au nombre de testeurs. Cela peut paraitre provocateur, voir choquant. mais réflechissez à l’impact psychologique sur les développeurs d’‘une très importante équipe de testeurs.

1 – Mettre en évidence le bug. Jusqu’ici tout va bien.

2 – Votre réaction : et meeeerde ! Non, justement. Il faut remercier le rapporteur. Pascal nous fera faire l’exercice plusieurs fois durant cette heure: remercier à haute voix: Thank you !

3 – Reproduire le problème. Identifier les conditions sous lesquelles ce bug se manifeste est une simple question de bon sens.

4 – Ajouter (au moins) un test qui échouera suivant ces conditions.

5 – Corriger le problème. Vous suivez toujours ?

Bon ça y est, on a fini. Comment ça “non” ?

6 – Rejouer la totalité des tests unitaires. La correction d’un bug peut introduire une régression. Nous le savons tous. Mais prenons-nous tous la peine de rejouer la totalité des tests ? Bien sûr le but n’est simplement de les rejouer, mais de les rejouer jusqu’à ce qu’ils passent tous !

7 – Faire une analyse causale : pourquoi ce bug n’a pas été intercepté précédemment ? Il faut toujours faire attention aux objectifs que l’on fixe : on risque de les atteindre. Si le but est la couverture du code, est-on certain qu’elle est synonyme de tests associés ? Le véritable objectif n’est pas la couverture du code, mais la qualité de celui-ci.

8 – Améliorer les tests.

Là, ça devrait être terminé. Non, toujours pas ?

9 – Améliorer la façon dont les tests sont écrits. Mais ceci est autre chose, n’est-ce pas plutôt un point qui devrait être remonté en rétrospective ? La rétrospective ce n’est pas pour la fin de sprint. La démo ce devrait être tout le temps.

10 – “Un bug ne voyage jamais seul” : à la recherche des bugs similaires !

11 – Faites que ce bug soit impossible à reproduire !

Traquer les bugs ainsi peut sembler coûteux. En fait, ça l’est au début. Pascal s’appuie sur la théorie des contraintes pour expliquer que cette approche permet finalement de livrer plus vite ! En l’occurrence sur un projet, au bout de 5 mois au lieu de 8 !

Jan De Baere : Kaban at different levels

Jan a choisi de nous présenter Kanban tel qu’il est utilisé réellement dans les projets auxquels il a participé, avec les leçons qui ont accompagné sa mise en oeuvre.

La règle de conduite que nous propose Jan repose sur 3 axes:

  • Visualiser le workflow.
  • Limiter le “work in progress”, en s’appuyant sur l’expérimentation.
  • Mesurer et gérer le workflow.

L’exemple d’une circulation sur une autoroute illustre assez bien ces 3 points, même si les paramètres conduisant à la formation des bouchons sortent des fondements théoriques de Kanban (eh oui, il n’y a pas que la théorie des contraintes…).

Cette session avait pour but de nous exposer cette mise en oeuvre dans différents contextes:

  • Un projet classique.
  • Un projet distribué
  • Le Kanban au niveau individuel
  • la gestion d’un portefeuille de projets.

Plutôt que d’asséner les différents éléments de la présentation je préfère mettre en avant les éléments principaux:

  • Les “expedites”: lorsqu’ils sont trop nombreux, il ya un problème à régler !
  • Mettre en évidence les éléments qui sont attendus. Là encore, ils peuvent stigmatiser des problèmes à régler au niveau organisationnel.
  • Les “buffers”: ils peuvent apparaitre utiles dans le workflow, mais sont à utiliser avec parcimonie. Ce sont des sources de gâchis, au sens Lean.
  • Il y a un lien direct entre le “work in progress” et le “lead time”. Ils croissent de concert.

L’un des grands moments fut certainement la présentation du “kanban portable” (et pliable) réalisé par Jan !

atbru2012-JanDeBaere

Pour ma part, je garderais dans mes notes l’usage du “personnal kanban” avec ses limites de WIP adaptatives:

  • Les tâches “high energy” : la limite de WIP est de … 1 ! Ce sont les tâches qui demandent un haut niveau de concentration.
  • Les tâches “medium”, c’est le travail ordinaire. La limite de WIP est de 2.
  • Les autres tâches, celles qui ne nous donnent pas vraiment de faire un travail correspondant à notre niveau de qualification. Il n’y a pas de limites de WIP pour celles-ci.

Ce peut être du bon sens, mais c’est sans aucun doute un point à garder !

Alan Holtz : Lessons learned from the Scrum Master

J’espère qu’Alan me pardeonnera de ne pas avoir pris de note lors de sa session. J’étais en fait en train de faire l’ultime préparation de la mienne ! Si une photo vaux mieux que de grands discours, en voici donc une !

atbru2012-SMLessonsLearned

Yves Hanoulles : How 146 people made 13 projects

Yves a acquis une grande notoriété dans la communauté agile, par son implication dans de nombreux projets. J’avoue que j’avais du mal à comprendre comment il pouvait mener à bien cette activité débordante. Cette session répond à ces questions.

atbru2012-YvesHanoulles

Comment nait un projet ?

Yves débute simplement un projet par un problème qu’il rencontre et sur lequel il ne trouve pas sur le net de ressources pouvant l’aider.

Comment construire une communauté de contributeur ?

Simplement en demandant autour de lui, mais en s’adressant de manière directe aux intéressés, s’ils peuvent et souhaitent l’aider sur son projet. C’est une question franche et directe qui n’appelle pas obligatoirement de réponse positive : on peut ne pas avoir le temps, ne pas être intéressé par ce projet, etc… Yves accueille de manière factuelle et simple cette réponse.

A partir de là, Yves accorde une complète confiance aux collaborateurs dès le départ, avec complet accès en lecture et écriture aux ressources du projet : la confiance n’est devrait pas être “gagnée”, mais donnée !

Surtout Yves nous rappelle qu’il faut toujours penser à remercier une personne qui se propose de contribuer.

Collaboration et outillage

Tous ces projets se déroulent sans aucune rencontre face à face : tout est mené et coordonné à distance, l’outillage permettant cela est donc important. Les principaux que j’ai noté :

  • Skype
  • email: Oui, bien qu’Yves soit un fervent défenseur de la limitation de l’usage de l’email en entreprise, il reste un média essentiel pour ces projets collaboratifs.
  • Google doc.

Si les projets agiles défendent la co-location, Yves nous rappelle que selon Jim McCarthy, celle-ci n’est pas une nécessité : ce qui est nécessaire, c’est une communication avec une large bande passante.

Who is agile ?

Yves a terminé sa session sur quelques reflexions sur la rédaction d’un livre en mode agile, tel que “who is agile ?” a été rédigé.

  • La rédaction d’un livre en mode agile est possible, intégrant des itérations et du feedback. C’est non seulement possible et même souhaitable. Une plateforme comme Leanpub est un grand facilitateur en ce sens.
  • La lecture d’un livre réalisé en mode agile est pr contre moins sympathique.

Jeff Cumps : How to solve your thoughthests impediments

Jeff nous invitait à une session-atelier sur le A3 problem solving. Un réel challenge d’ailleurs car il ne disposait que d’une heure pour nous exposer les principes et nous permettre de les mettre en oeuvre sur une problématique de notre choix.

Je ne vais pas détailler l’atelier ici. Le timing était un peu serré, mais nous avons pu avoir la satisfaction de bien avancer sur nos exemples. Disons que 1h30 aurait probablement été un créneau plus confortable. Mais peut-être pas plus, non plus !

En fait le point positif du temps limité était d’aller droit à l’essentiel sur l’exercice pour en comprendre les points principaux. Ce que Jeff a fait avec clarté. Une très bonne session pour conclure cette journée !

Ambiance, boissons et rencontres

Chaque conférence agile est l’occasion de croiser ou recroiser des passionnés. L’évènement a été ciblé petit par les organisateurs : 70 personnes, donc volontairement peu de buzz autour de ce premier Agile Tour Bruxelles. Un grand “up” pour les organisateurs à propos de la convivialité et de l’ambiance sur cet Agile Tour Belge. Ca donne vraiment l’envie d’y revenir.

Couleur locale oblige, nous avons conclu la journée autour d’une bière.

Un geste sympathique pour les orateurs : un assortiment très couleur locale une fois encore. Que je vous laisse découvrir.

atbru2012-orateursgifts

En finir avec la roadmap !

Je vous l’avez promis il y a peu, voici le premier opus de mon feuilleton “en finir avec…”. Ma victime du jour est la roadmap.

Avant que vous commenciez cette lecture, un mot d’avertissement. J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

La roadmap qu’est-ce que c’est ?

Ce terme est utilisé en informatique de manière assez libérale. Il peut concerne aussi bien un projet, qu’un ensemble de projet, une stratégie business et beaucoup d’autres choses encore. Je vais m’intéresser ici à la roadmap d’une organisation de développement. Elle est souvent relative à un portefeuille de projets, comme on le verra.

Mais au fond, que va-t-on attendre d’une roadmap ? Ou du moins, qu’est-ce que moi, je vais en attendre ?

Principalement une certaine perspective d’avenir, capable de me montrer les orientations des mois à venir. Je suis réaliste, je sais bien que :

  • Plus on se projette dans le futur, plus le niveau d’incertitude est élevé. En un an, beaucoup de choses peuvent se passer en terme d’évolution du marché, d’opportunités business, etc… Je considère même que c’est un signe de bonne santé de l’entreprise, du moins tant que l’on ne confond pas évolution de la stratégie et atermoiement.
  • Qu’un changement majeur de stratégie (un “pivot” dans le langage Lean Startup) peut totalement remettre en cause cette perspective à un moment donné.
  • Qu’il n’est ni utile ni raisonnable de chercher à étoffer cette projection de détails que l’on n’a pas encore et qui seront peut-être obsolètes au moment où l’on traitera le sujet.

Bref, quand on va me parler de roadmap, je vais penser à quelque chose comme cela

pushpin on map

En clair : une direction, avec des jalons représentant des niveaux d’accomplissements, mais aussi des dates en dur représentant des contraintes opérationnelles : engagements divers contractualisés, salons, etc…

Le syndrome de la roadmap de projets

Dans les faits, nous allons plutôt devoir composer avec un plan établi sur la base d’une liste de projets priorisés et planifiés en fonction de notre capacité de travail afin d’optimiser celle-ci en l’utilisant au mieux.

Peut-être aurez-vous remarqué le début d’une pointe d’ironie ?

Peut-être aussi, si vous avez suivi des posts et présentations plus anciens que j’ai pu faire, vous dites-vous que j’ai défendu ce même concept de roadmap il n’y a pas si longtemps ? Je l’avoue dès maintenant : mes idées ont sinon changé, du moins pas mal évolué. J’assume.

Le problème avec cette occupation optimisée de la capacité de travail, c’est que la roadmap ressemble désormais à ça:

parking-Small

On peut faire pire. Il y a une variante de la roadmap de projets appelée “roadmap matricielle”. En  voici une vue d’artiste (vous remarquerez les “jolies couleurs”, partie intégrante du concept).

roadmap_matricielle

La roadmap matricielle présente une certaine élégance et peut donner l’apparence d’une maîtrise plus pointue du sujet. Après tout, il faut être plus intelligent pour appréhender les choses en deux dimensions qu’en une seule, non ? Cela bien établi, on se demande pourquoi personne n’a encore eu l’idée de réaliser des roadmaps tridimensionnelles ! La difficulté de rendre cela sous Powerpoint, j’imagine …

En réalité la roadmap matricielle amplifie les travers de la roadmap de projets :

  • Plus d’embouteillage : ce n’est plus une file de projets qui en en attente mais une série de files d’attentes ! L’image du péage de Saint Arnoult s’impose à moi !
  • Alignement des ressources avec le plan. Il est bien facile d’ajouter une ligne à une matrice. Mais qu’en est-il des équipes de développement ? La pratique montre qu’elles sont rarement dimensionnées en conséquence. Souvent cela se traduit par du temps partagé de développeurs (un désastre) ou des équipes de développement fractionnées pour atteindre des tailles d’une ou deux personnes pour certaines d’entre-elles…
  • Pas de focus stratégique. On attend d’un comité de direction qu’il donne justement une direction ! Que peut-il faire quand il est incapable de mener à bien sa mission première ? Il peut ne pas décider de direction stratégique et clamer que “toutes les directions sont prioritaires”. La roadmap matricielle traduit cela.

Qu’elle soit matricielle ou non, la roadmap a des conséquences dont nous allons nous rendre compte qu’elles sont des effets de bord de son existence même. Ce sont pour la plupart en fait des effets psychologiques.

Conséquences, conséquences

La persistance dans l’action

L’une des vertus de la roadmap est de montrer que derrière le projet en cours, il y a un ou plusieurs projets en attente. En principe c’est un bienfait, ce n’est même pas complètement négatif, même si je vais prétendre l’inverse dans deux secondes.

Mais concentrons-nous sur notre projet en cours.

Etant agile, vous savez que l’intérêt d’un projet ainsi réalisé réside dans le feedback, l’émergence de nouvelles idées porteuses de valeur ou l’abandon d’idées initiales qui finalement n’en ont pas. Dit autrement, on devrait arrêter un projet quand il n’y a plus de valeur business dans les fonctionnalités à venir, par contre on devrait le poursuivre si la valeur de ces fonctionnalités à venir le justifie. Il n’est d’ailleurs pas rare que les fonctionnalités différentiantes arrivent relativement tardivement car on doit au préalable assurer les fonctionnalités de base, comme le montre le modèle de Kano.

Modèle de Kano

Hélas la file d’attente crée une pression psychologique vers l’arrêt du projet, même si les fonctionnalités à venir sont intrinsèquement porteuses de valeur. Il faut certes juger de l’intérêt de poursuivre ou passer à autre chose, mais la roadmap tend à créer un biais dans la décision dans le sens de la tenue du plan.

La rigidification du changement

Une roadmap de projet, c’est un plan. Et créer un plan, ça prend du temps. Combien de temps (en délai) allez-vous prendre pour prioriser avec un comité de direction un portefeuille de 20 ou 30 projets ? Si votre réponse est “1 mois”, je pense que vous vous en tirez bien. Généralement, ce sera plutôt plus.

Maintenant, partons sur l’hypothèse de 2 équipes traitant des projets allant de 6 mois à 1 an, ce qui est compatible avec une roadmap d’une vingtaine de projets soit disons 3 ans de travail. Statistiquement, on va donc se retrouver avec un démarrage de projet tous les 3 à 6 mois. Quelle est la probabilité pour qu’un comité de direction réévalue cette roadmap à chaque début de projet (tous les 3 à 6 mois), avec un délai de réévaluation qui sera de 1 à 2 mois ? En théorie, c’est faisable, dans la pratique c’est au mieux improbable.

On se retrouve ainsi devant l’alternative suivante:

  • Pas de réévaluation du portefeuille et on suit le plan sans le remettre en cause, en tout cas pas à chaque début de projet.
  • Le bon sens prédomine, et lors du début du projet suivant, on démarre le projet qui parait être le plus important pour la société, qui n’est pas nécessairement celui prévu par la roadmap. Et la roadmap devient gentiment obsolète…

Incapacité à faire face à l’imprévu

L’un des autres effets pervers de la roadmap est l’effet d’encombrement qu’elle donne. En rendant visible (et priorisés) un grand nombre de projets, elle provoque une censure, voir une autocensure par rapport à de nouvelles opportunités business qui demandent un changement radical de direction. La présence même de la roadmap crée un frein psychologique à l’idée d’arrêter là un développement en cours ou de le réorienter.

Une variantes de ceci est la perte d’opportunités pour les équipes de réalisation elles-mêmes : crucifiées à leur roadmap, elles voient les projets d’actualité passer en d’autres mains car “ces pauvres gars sont bien trop occupés, il faut les soulager”. Là encore l’effet d’encombrement se substitue à l’importance business des projets qui émergent.

Quand c’est pas cher, c’est prioritaire

L’analyse et la priorisation d’un portefeuille de projets se font souvent sur la base d’indicateurs associés à ces projets : risque, importance business, coût, etc… En soi cela est une bonne chose même si calibrer l’importance relative de ces indicateurs est à la fois subjectif et délicat. Mais hélas ce processus nous expose lui-même à deux travers:

  • Perdre de vue l’axe stratégique que l’on s’est fixé.
  • Tomber dans le syndrome de la priorisation par le coût : “ce projet est tout petit, on doit pouvoir le caser avant ce gros”. Une fois tombé dans cette logique, le corollaire est une importance exagérée donnée à la quotation des projets (elle conditionne majoritairement les priorités), donc une logique de coûts préétablis sur les projets fonction des spécifications et par là même une sclérose anticipée du périmètre fonctionnel !

La roadmap de projets, c’est du stock

Quel est l’intérêt avéré d’analyser, évaluer et prioriser une vingtaine de projets lorsqu’au final c’est un et un seul projet qui démarrera au prochain démarrage de projet ?

En fait, il y a bien un intérêt : s’assurer que le bon projet à démarrer est bien celui que l’on a choisi et aucun des 19 autres ! Mais quel est l’intérêt de déterminer que les projets en position 4 et 5 sont correctement priorisés ? Ou même que celui mis en seconde position est le bon ? Le Lean nous apprend deux choses importantes:

  • Le stock, c’est du gâchis. Il doit être éliminé.
  • Les décisions doivent être différées jusqu’au “dernier moment responsable”. Ce dernier moment responsable, c’est celui où l’on va effectivement démarrer le projet.

Etablir, entretenir, réévaluer de longues listes de projet, c’est indubitablement du stock. Combien de projets de cette liste ne seront même jamais démarrés?

Et la roadmap agile ?

Depuis quelques années est apparu le concept de “roadmap agile”. La littérature sur le sujet n’est pas très abondante non plus, mais elle existe. Vous trouverez d’ailleurs une note de lecture sur un de ces ouvrages sur ce blog.

Quel est le but d’une roadmap agile ? Il reste de gérer et prioriser un portefeuille de projet, mais de manière plus efficace en ne remontant que les informations pertinentes à la priorisation. Donc, on décide plus efficacement sans s’engluer dans une masse d’information et un niveau de détails qui ne sont pas pertinents à ce niveau. On est aussi plus efficace à collecter et analyser l’information en amont. Bref, on se met en condition pour permettre le suivi et l’évolution itérative du portefeuille.

Mais cela reste quand même du stock !

Quelle alternative(s) ?

Analyser un gros portefeuille de projet est-il nécessaire ?

D’un point de vue des équipes de réalisation on a guerre besoin d’avoir une vingtaine de projets priorisés. On a même pas besoin d’avoir une visibilité sur ces vingt projets. On a juste besoin de connaitre le prochain projet. Avoir une idée des un ou deux suivants tels qu’on les imaginent aujourd’hui peut aider à donner de la perspective, pour autant que l’on accepte que la vérité d’aujourd’hui ne sera peut-être pas celle de demain…

D’un point de vue business, c’est un peu différent. Il faut identifier le (ou les quelques) bon(s) projet(s) à réaliser. Mais il n’est pas utile de recenser et surtout analyser tous les projets potentiels de l’entreprise ou du département pour cela. Si la stratégie est clairement identifiée, les quelques projets les plus importants remonteront naturellement. Et il y a de bonnes chances pour que ce soit les bons.

Le problème est la “stratégie clairement identifiée”. Ce n’est pas un boulot si facile que cela, mais c’est celui que l’on attend d’une direction.

Se livrer à une grande foire des projets, pardon à une roadmap des projets est aussi une façon d’abdiquer à l’établissement de cette stratégie.

Alors la roadmap, c’est mal ?

C’est le moment où je ne vais pas répondre à la question. C’est à vous d’y répondre.

La roadmap n’est pas intrinsèquement mauvaise, surtout si on essaie de la mener en agile. La vertu qu’elle doit porter est de donner de la perspective.

On peut aussi avoir une liste des “projets potentiels”, sorte d’aide-mémoire entretenu au fil du temps et de discussions informelles. Je le fais. Et cela m’aide lorsque le sujet et des sujets proches sont évoqués.

Mais les effets néfastes de la roadmap de projets existent et peuvent être plus importants que ses bienfaits. A vous de juger.

Personnellement je pense que la roadmap commence par une stratégie. Elle doit permettre de se focaliser sur un petit nombre de projets.

Portfolio agile : de la visibilité au pilotage, par Caroline Damour-Nobi

Caroline Damour-Nobi a eu la gentillesse de m’autoriser à faire figurer sa présentation dans mon blog.
La gestion d’un portefeuille de projets est un sujet difficile, tiraillé entre les vertus de vision et de transparence qu’elle apporte et l’idée de “stock” qu’elle sous-tend ! Cette présentation fait le point sur la démarche et l’évolution de la mise en place de la roadmap telle que l’a vécue Caroline.

Note de lecture : Manage Your Project Portfolio, Increase your capacity and finish more projects, par Johanna Rothman

Note:6 ; Pas aussi bien qu’espéré

Voilà un sujet qui m’intéresse au premier chef : comment gérer, non pas un projet, mais un ensemble de projets organisés en un « portefeuille ». La grande qualité de cet ouvrage est certainement de ne pas chercher midi à quatorze heures, et de rester simple et pragmatique. D’ailleurs le format du livre reflète cette concision : 11 chapitres couvrant 160 pages.

Les deux premiers chapitres nous font découvrir ce qu’est un portefeuille de projets, comment le structurer et comprendre le cycle de vie de ses projets.

Dans les chapitres 3 et 4, on apprend tout d’abord à organiser ses projets : quel doit être leur granularité ? Les projets doivent-ils être structurés en programmes ? On y voit finalement quoi envisager de l’avenir d’un projet commit, kill, transform) en fonction de sa nature.

Prioriser et travailler en groupe pour décider du devenir du portefeuille sont l’objet des chapitres 5 et 6. L’auteur y propose plusieurs techniques à cet égard.

Les chapitres 7 à 9 s’avèrent moins originaux : ils traitent de la vie et de l’évolution itérative du portefeuille. Ce qu’on y lit, bien qu’intéressant, ne diffère guère de ce que l’auteur a pu dire de la gestion de projets dans « Manage It ». Même si le propos sur l’approche agile en général, et le Lean en particulier sont clairement intéressants, ils n sont pas spécialement originaux dans le contexte de ce sujet en particulier.

Le chapitre 10 sur les mesures peut également aussi bien s’appliquer au niveau d’un portefeuille que d’un projet. Je pense quand même qu’appliquer ces métriques au niveau de l’itération relève d’une granularité trop fine. Simple question d’appréciation personnelle.

Fort heureusement, on termine avec une note plus originale : définir sa mission, en tant qu’équipe ou en tant que manager. C’est un exercice à la fois simple et dans le principe et difficile dans la mise en œuvre. Mais il éclaire beaucoup dans la ligne de conduite et la façon d’évaluer son portefeuille de projets.

En bref, voici un livre qui donnera un certain nombre de clés pour réussir à gérer son portefeuille de projets. En fait, j’ai déjà utilisé une partie de ce que l’auteur propose pour travailler mon propre portefeuille de projets, avec succès. Je suis toutefois un peu déçu par ce que j’y ai trouvé, mais certainement parce que mes attentes se situaient assez haut, eu égard à ce que l’auteur nous a livré jusqu’ici.

Ma note reflète surtout mon niveau d’exigence par rapport aux textes écrits par Johanna Rothman : il est bien plus élevé que pour le commun des auteurs. Malgré une notation qui peut paraître modérée, c’est un livre que je recommande sans réserves.

manage-project-portfolio-pragprog

Référence complète : Manage Your Project Portfolio, Increase your capacity and finish more projects – Johanna Rothman – The Pragmatic Bookshelf 2009 – ISBN: 978 1 93435 629 6

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects


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