Pessimism never won any battle.
Dwight D. Eisenhower
Carnet de route : Le ScrumDay 2014 (2/4)
Je vous avais laissé au moment du déjeuner. La pause n’aura pas été si longue. Sur le créneau suivant, j’ai coché la session de Véronique Messager sur mon programme.
En tant que Scrum Master, je veux m’améliorer pour mieux coacher mon équipe
Cette session de Véronique Messager, n’en est pas une : c’est une table ronde à laquelle elle a convié des Scrum Masters allant du néophyte à l’expérimenté, qu’elle-même coach chez Orange. Cet aréopage de Scrum Masters vient partager avec nous leurs points de vue sur leur travail, leurs manières d’aider les équipes et leurs sensibilités qui peuvent varier.
Le contexte
A l’origine, il y a un groupe d’échange de pratiques se réunissant tous les mois. Le produit de ce groupe d’échange est aujourd’hui une check-list de 52 bonnes pratiques. Véronique nous propose de les aborder regroupées en 3 thèmes, avec le panel de Scrum Masters. Hélas, les contraintes de temps nous limiteront à deux de ces thèmes.
Le changement dans la posture du Scrum Master
Un premier constat partagé est la perte de connaissance sur le code ! Le travail de Scrum Master tient ceux-ci de plus en plus éloigné de cette matière première. De cette perte de connaissance nait un certain sentiment de culpabilité : Suis-je toujours légitime dans mon rôle ? Le travail du Scrum Master n’est pas quantifiable, il n’est même pas visible car il n’a pas de raison d’être évoqué en stand-up. Une crainte qui n’est pas nécessairement étayée : il n’y a guère de remarques sur le fait que le Scrum Master développe beaucoup moins.
Malgré tout, le Scrum Master peut-il continuer à développer ? Les avis sont un peu plus partagés, mais des « oui » s’élèvent, toutefois tempérés :
- Pas question de prendre des tâches critiques ! A cet égard, binômer ou prendre en charges des corrections d’anomalies s’avèrent de bonnes idées.
- En tout état de cause, les tâches de Scrum Master doivent rester prioritaires.
- Rester impliquer dans le développement peut induire un travers de partialité lorsque des discussions s’engagent sur l’architecture, les solutions, etc. Il faut y prendre garde.
La maturité de l’équipe allant croissant, peut-on un jour se passer de Scrum Master ? Une question réccurente, que l’on a aussi trouvé sur Quora. Ici la réponse est unanime : non, le Scrum Master reste indispensable !
Par contre la question reste ouverte sur le Scrum Mastering à temps plein ou à temps partiel ! Si certains par ailleurs pensent qu’au final ce rôle peut tourner (ce que j’ai expérimenté), Bruno Margueritat ne suit pas cet avis, par exemple.
Motiver les membres de l’équipe
Comment s’appercevoir que cette motivation baisse ? En regardant la productivité de l’équipe (donc les « retards »). Véronique a une affinité particulière pour la Process Com, il n’est donc pas étonnant que les Scrum Masters présents évoquent cet outil pour comprendre le fonctionnement des membres de l’équipe.
Ils évquent aussi le temps libre : l’importance d’en ménager (par exemple entre les itérations), mais aussi d’observer comment ce temps libre est utilisé.
Donner du sens et visualiser l’avancement : c’est bien entendu un leitmotiv bien connu et pourtant souvent négligé. Mais il s’agit aussi d’impliquer activement les membres de l’équipe. Pour l’un des Scrum Masters cela passe par la délégation d’une partie des tâches … du Scrum Master ! Par exemple lors des rétrospectives. J’aime bien l’idée et l’état d’esprit !
Ce que j’en ai pensé
Nombreux sont les experts prêts à nous expliquer le rôle et la posture du Scrum Master. Tous ces experts ne sont d’ailleurs pas tous d’accord entre-eux (j’en fais partie !). Ici, ce ne sont pas des experts, mais des vrais praticiens de terrain avec différents niveaux d’expérience et une certaine variété de point de vue.
Du coup, je pense que l’échange aurait pu être encore plus riche avec des Scrum Masters venant d’autres horizons. Les débats auraient été plus intense, ce qui ne serait possible qu’avec un format un peu plus long toutefois.
La culture du programmeur, par Jean-Laurent de Morlhon
J’avais une double raison d’assister à cette session : tout d’abord J’aime bien Jean-Laurent qui est aussi un ancien collègue (double ancien collègue, devrais-je dire). Et ensuite le sujet éveille mon intérêt, même si ma propre crédibilité en tant que programmeur s’étiole certainement de jour en jour… Jean-Laurent est certainement la bonne personne pour transmettre cette culture, sans compter l’humour et le dynamisme qu’il met dans ses interventions. Celle-ci ne fera pas exception !
Pourquoi programmeur ?
Jean-Laurent nous explique quel était son plan pour devenir maître du monde et partir à la retraite à 35 ans. Cela n’a pas marché. Pour moi non plus, d’ailleurs. Car sa passion c’est programmeur (qu’il préfère à « développeur » ou « codeur »). Donc c’est « programmeur ». Et ça veut dire quoi ? Le Larousse dit qu’il s’agit « d’une personne de la préparation, de l’écriture et de la mise au point d’un programme pour ordinateur ». Pour les personnes en-dehors de notre domaine, ils sont souvent perçus comme des personnes aptes à faire des choses mystiques (t’es dans l’informatique ? Tu peux m’aider à brancher mon imprimante ?).
Mais hélas, dans notre milieu professionnel, nous sommes confrontés à un problème de jeunisme. Programmeur n’est pas considéré comme un métier au-delà d’une certaine tranche d’âge. Pour de nombreuses entreprises et écoles, l’évolution normale du programmeur est de devenir chef de projet !
Une culture
La culture, c’est ce qui lie les gens entre eux. Quels sont donc les éléments de cette culture ? L’une d’entre-elle est le « craftmanship ».
C’est avant tout une attitude de pragmatisme, un rééquilibre entre processus et technique. C’est aussi un état d’esprit d’amélioration qui passe par l’entrainement (les dojo, les code retreat, les kata). C’est évidemment utiliser les ressources en ligne : les MOOC sont partout, sur tous les sujets. La culture du programmeur, c’est aussi :
- Disposer des meilleurs outils que l’on puisse acheter : aujourd’hui, c’est disposer de grands écrans, de CPU puissants, ne pas être limité par la mémoire, booster les I/O avec des disques SSD, des environnements d’intégration, les bons IDEs, etc..
- Vivre en permanence avec de la frustration : nous passons un temps considérable à essayer de faire marcher des trucs … ou à essayer de comprendre pourquoi ils ne marchent pas !
Ce que j’en pense
Une session de « J-Lau », ça vaut toujours le déplacement. Certes, je n’y ai pas appris grand chose, mais je n’étais pas non plus le public visé. Mais la présentation fait un très bon boulot à faire toucher du doigt cette culture du développeur. A voir absolument pour les PO / MOA / Managers à qui sont étranger ces aspects.
Acceptance Tests Workshop
Voilà, c’est mon tour ! J’avais préparé cet atelier avec Benoit Nouyrigat afin de transmettre par la pratique un aspect du développement agile qui nous semble avoir un impact crucial : l’écriture de tests d’acceptance collaborativement entre les différents intervenants d’un projet. Nous avions donc structuré notre atelier en petites équipes, l’atelier lui-même nous conduisant depuis l’écriture de user stories sur notre étude de cas jusqu’à l’implémentation des acceptance tests en BDD avec Cucumber JVM !
Je ne vais pas détailler l’atelier ici, je réserve cela pour un futur post !
Ils ont aimé
- Clarifier les specifications en les « instanciant » avec des cas de test.
- Découvrir les cas aux limites qui font émerger des règles métier.
- Travailler collaborativement autour des cas de test.
Ils pensent que l’on peut améliorer
- La phase initiale, avec l’écriture des user stories par les équipe qui apporte peu.
- L’absence de temps pour s’approprier les persona.
- La brièveté du temps consacré à la partie « outils ».
Ce que j’en pense
Nous devons ajuster certaines parties, c’est tout à fait normal, compte tenu qu’il s’agissait d’une première. Je pense toutefois que les conditions ne nous ont pas permis de juger de l’atelier de manière adéquate : nous avions été programmé en toute fin d’après-midi (avec en plus un démarrage en retard), ce qui équivaut pratiquement à une garantie d’échec pour un atelier très intense comme celui-ci.
La première heure s’est très bien passé, mais la fatigue a rattrapé le groupe dans la seconde. En fait, je suis plutôt satisfait d’avoir eu une bonne moitié d’atelier, car je m’attendais à un échec complet. Les participants se sont même déclarés très satisfaits !
J’aimerais toutefois pouvoir jouer cet atelier dans de bonnes conditions pour avoir un meilleur aperçu de son impact.
Nous avons joué l’écriture des acceptance tests en deux temps, avec ou sans le style « given when then », mais nous n’avons pas donné d’indications suffisantes pour marquer la différence. A retravailler.
Une certaine déception de Benoit et moi-même sur la demande d’avoir plus sur la partie outil ! Notre expérience commune est que la différence se fait dans l’écriture collaborative (d’ailleurs la collaboration est à gauche et les outils à droite, si vous voyez ce que je veux dire…). Soit nous ne sommes pas parvenus à être assez marquants sur l’importance de cet aspects, soit notre public est incorrigible sur l’idée que les outils sont ce qui importe le plus. Nous avons là un sujet de reflexion pour la version 2.0 de notre atelier…
Le diner
J’ai fait l’éloge du lunch du midi, je dois les mêmes au diner auquel j’étais convié n tant qu’orateur. C’est bien sûr une belle occasion d’échanger avec les membres de la communauté…
… Ainsi qu’avec les joyeux membres du bureau.
J’ai aussi passé un très agréable moment avec Alex Boutin, à échanger sur ce que l’un et l’autre nous aimons faire, les questions que nous nous posons… Alex est l’une des personnalités de la communauté agile que j’apprécie le plus, pour son sens du partage et de l’invitation. Je n’en apprécie que plus ce genre d’opportunités.
Il est maintenant temps de retourner dans mes pénates. Rendez-vous bientôt pour la seconde journée de ces Scrum Days !
Note de lecture : Business Process management with JBoss jBPM, par Matt Cumberlidge
Note : 3 ; Ciblant l’analyste, un ouvrage trop superficiel et d’avantage focalisé sur le processus de réalisation que sur l’outil ! Dommage.
Difficile de faire autrement que de comparer ce livre à son pendant adressant OSWorkflow ! Même type d’ouvrage, même éditeur et même taille, l’auteur du premier est même relecteur du second. Bref, deux ouvrages courant dans la même catégorie ! Mais autant j’ai été accroché par le premier, autant j’ai été déçu par celui-là. Explications.
En réalité, dès le départ, on s’aperçoit que cela va être difficile : le premier chapitre n’évoque guère jBPM en guise d’introduction. On y évoque plutôt le processus d’analyse et de modélisation. Va pour les 20 premières pages.
Le second chapitre évoque de manière plus détaillée le processus de modélisation du BPM à l’aide d’une étude de cas ici introduite. Ce livre n’étant pas réellement un ouvrage de BPM, le traitement de ce sujet est quelque peu léger, sinon naïf. Et l’on est arrivé page 52 (sur 200) et toujours pas de jBPM à l’horizon.
On en parle enfin au chapitre 3, où tout le processus d’installation et de configuration est détaillé, un peu trop à la façon « pour les nuls » à mon goût. Mais on finit quand même par aborder le sujet qui m’intéresse ici en premier lieu, c’est-à-dire jPDL (on est quand même page 74). Au final nous avons quand même droit ici à 25 pages de matière réellement pertinente.
Le chapitre 4 évoque l’interface utilisateur, c’est-à-dire les formulaires JSP que l’on peut construire directement sur la plateforme jBPM.
Le chapitre 5 revient sur le leitmotiv des auteurs : le processus de développement. Nous avons toutefois droit à 7 pages particulièrement intéressantes sur l’intégration de systèmes : juste de quoi nous mettre l’eau à la bouche, mais clairement pas assez pour nous délivrer une information pertinente et utilisable !
Le chapitre 6 « proof of concept implémentation » noie pas mal d’informations importantes sous couvert de processus de développement (encore lui), mais sont toutefois évoqués : configuration, déploiement et même monitoring et BAM avec la plateforme SeeWhy. Ce dernier volet est tout à fait intéressant, à la fois par l’évocation de SeeWhy que par le fait que l’intégration en est bien décrite.
Le dernier chapitre sur le « process improvement » n’est que du bla-bla, oubliez-le.
Bref, ce livre est une grosse déception, je n’y aie trouvé que 50 à 60 pages d’informations utiles. D’un autre coté je n’ai pas ici une couverture complète du sujet me permettant de jauger si cet outil correspond à mes besoins. Je doute que vous-même y trouviez votre bonheur.
Référence complète : Business Process management with JBoss jBPM, a practical Guide for Business Analysts – Matt Cumberlidge – Packt publishing 2007 – EAN: 9 781847192 36 3
Rules reduce the team to novice level.
Andrew Hunt
Carnet de route : Le ScrumDay 2014 (1/4)
Bienvenue au ScrumDay 2014 !
Cette édition sera particulière pour moi : c’est la première où je ne fais pas partie du comité d’organisation ! Certes, j’y aurais ma session, mais je vais faire mon possible pour profiter pleinement de ces deux jours, et vous en faire bénéficier maintenant !
Pour tout dire, ça commence par un peu de galère : Xavier Warzee voulait depuis longtemps organiser l’évènement chez Disney. C’est loin et cher (le prix de la conférence triple donc au passage), mais mon statut de conférencier me donne accès à la conférence « full package », celui qui vaut 290 € ! Reste l’accès. Venir en voiture s’avère plus galère que si nous avions été en plein Paris, j’opte pour le RER.
L’accès est un rien compliqué, mais le SUG a tout prévu : Pascal est là pour nous accueillir dès la sortie de la gare !
N’oublions pas que chez Mickey on est presque aux états-unis, le délit de sale gueule existe encore. Pour moi, c’est fouille minutieuse à chaque contrôle de sécurité. Même avec une certaine habitude de la chose, ça ne me met pas spécialement de bonne humeur. C’est dommage d’autant que le French SUG n’y est pour rien. Mais si c’est au même endroit l’an prochain, ce sera probablement sans moi.
Je découvre le centre de conférence en arrivant : vraiment très spacieux (et même un chouia labyrinthique), quand au hall principal…
Le temps de prendre un café et d’échanger avec les amis, nouveaux ou anciens, l’heure est vite passée et nous sommes attendus dans la salle où se dérouleront discours d’ouverture et keynote.
Ouverture du Scrum Day
Rameuter Presque 500 personnes, ça prend du temps, on va donc débuter avec un peu de retard. Que du classique pourrait-on dire.
Comme il est de coutume, le président du SUG ouvre ce ScrumDay ou ScrumDays, devrai-je plutôt dire.
On retrace un peu d’histoire, quelques chiffres et surtout on présente le déroulement de ces deux jours, le maître de cérémonie de la seconde journée sera Laurent Bossavit, épaulé de Raphael Pierquin pour un grand open-space, à l’image de ce qui se fait à Grenoble.
On termine cette ouverture par le mot des sponsors. Les sponsors ! Il y en a 17 ! C’est certainement un record, en tout cas c’est un marathon de les écouter tour à tour.
Laurent Delvaux ouvre le tir pour Zenika, et j’ai vite perdu le compte. Mention spéciale pour le représentant de HP France qui nous a gratifié d’une introduction au style humoristique bien enlevé !
Heureusement, on va maintenant enchainer sur la keynote.
Alistair Cockburn : What’s new with agile ?
J’étais curieux de voir ce dont Alistair allait parler. Après tout, j’ai l’habitude de l’entendre parler d’agilité, ou comme dirait Géry Derbier de jeu de coopération et collaboration. En fait, il commence par évoquer les personnes … et les difficultés que nous avons face aux problèmes et à nos décisions. C’est un préambule au manifeste agile dont il est l’un des signataires.
Mais pour parler de Scrum, Alistair évoque le Shu Ha Ri ! Curieusement, c’était le sujet de ma présentation à Caen il y a 3 semaines, je suis tout ouï. Si vous l’ignorez, il s’agit des 3 niveaux de maturité en agile, emprunté par Alistair aux arts martiaux, à l’Aikido pour être plus précis.
- Le Shu est le niveau initiatique. Le Shu c’est copier la technique sans en dévier. Hélas, nombre de personnes tombent amoureux du Shu et ne le quitte jamais…
- Le Ha est le perfectionnement, il signifie « cassure ». Dans le Ha, on collectera nombre de techniques utiles.
- Le Ri est le niveau de la maîtrise, c’est littéralement l’abandon. On invente, mixte ses propres techniques.
Core Scrum
Scrum n’est pas fondamentalement du niveau Shu, il est du niveau Ri. Et au niveau Ri, le « core Scrum » se définit ainsi :
- Délivrer à chaque Sprint (plutôt que démontrer)
- Laisser l’équipe décider (en assignant une tâche)
- Inspecter et adapter à chaque Sprint
Ca c’est l’esprit du Scrum. Autour de cela, gravitent des rumeurs ou des freins (Alistair parle de balanes).
Les « balanes » sont tous ces éléments de Scrum, des éléments « Shu » sur lesquels on se focalise alors qu’ils n’ont qu’une importance secondaire :
- Le burndown chart : il n’est pas essentiel, faites-le si vous en avez envie, d’ailleurs il ne fait plus même plus partie des éléments « obligatoires du Scrum Guide !
- Le Scrum Board : Doit-on en faire un ? A quoi doit-il ressembler ? L’équipe décidera.
- Le Scrum Master est-il un chef de projet ? Un tech Lead ? Cela dépendra du contexte.
- Le Product Owner doit-il assister au stand-up ? Laissez l’équipe décider !
- Les 3 questions du stand-up : ce peut être une aide, mais pas un dogme !
Rumeurs et ouïe dire, ou les « lutins » comme dirait Laurent Bossavit:
- Les User Stories : Elles ne font pas partie de Scrum, elles ont été créées avec XP. Scrum n’oblige pas à utiliser les stories.
- Le Planning Poker : Cette pratique vient également d’XP ; si elle convient, alors utilisez-la !
- La suite de Fibonacci / les story points : Ce ne sont pas non plus des pratiques spécifiquement liées à Scrum. Tirez-en parti si vous aimez.
Le « big agile »
Alistair évoque pour commencer le framework SAFe. J’avoue y avoir porté peu d’intérêt, bien que ce soit un sujet dont on parle en ce moment. Je m’attendais à voir Alistair le démonter, mais non ?!?
Quand on parle d’agile en grand en ce moment, on évoque souvent Spotify autour duquel Henrik Kniberg communique beaucoup en ce moment. Ce qu’il appelle l’organisation 3D semble aussi une référence pour Alistair. Et qui dit grande organisation dit dépendances : l’architecture du système doit prendre en compte cet aspect afin de rendre le déploiement asynchrone.
Disciplined learning
Le dernier point évoquer par notre keynote speaker est l’un de ceux qui lui tiennent beaucoup à coeur : l’apprentissage. Alistair oppose le « big bang » synonyme d’apprentissage tardif d’un apprentissage au plus tôt (ou réduction des risques, mais l’emphase sur l’apprentissage n’est-il pas préférable ?). Cette courbe n’est d’ailleurs pas une courbe, mais une espèce d’escalier, car tous les progrès ne se valent pas et certaines expérimentations d’avèrent stériles. Géry Derbier évoque souvent la chose quand il anime le Carpaccio Game : il y a 4 dimensions d’apprentissage sur un projet :
- Business (ce volet pouvant lui-même avoir différents axes, et pas seulement le ROI).
- Social (la formation de l’équipe).
- Technique
- Coût / délais (découverte de la vélocité, par exemple).
Cette façon d’appréhender le projet permet de le borner (trim the tail), soit par la date, soit par la valeur.
Ce que j’en ai pensé
Peut-être Alistair Cockburn n’était pas aussi percutant qu’il nous en a donné l’habitude, mais s’agissant du Scrum Day il nous a livré une keynote s’articulant autour du Scrum, du vrai Scrum ! Je ne peux qu’apprécier le propos faisant écho à ma propre présentation du Printemps Agile, bien sûr, mais surtout je trouve important de mettre en exergue les aspects importants de Scrum (le Scrum Core), par rapport aux choses secondaires qui sont celles sur lesquelles se focalisent souvent les détracteurs de Scrum !
Romain couturier nous a aussi gratifié d’un « scribing » de la session d’Alistair. Il a bien voulu le partager avec nous, et je m’incline devant son talent !
Nous avons déjà pris un peu de retard sur le timing, le changement de salle est un tout petit peu serré. Pour moi, le choix de la session suivante était déjà fait.
Coaching Teams Through Change, par Rachel Davies
Rachel Davis est l’auteur d’un des quelques ouvrages disponibles en rayonage sur le coaching agile. Un ouvrage que j’avais trouvé correct sans être fantastique. Le sujet de cette session lui, me fait plutôt penser au Fearless Change !
D’abord, quel est le plus grand obstacle au changement ? Bien entendu : la résistance ! Alors certes, on voit beaucoup de choses à faire … tellement à faire et si peu de temps ! Mais la première précaution est justement de ne pas se précipiter !
Communiquer
Choisir ses mots avec soin (en fonction du canal de votre interlocuteur, comme dirait Véronique Messager). N’oublions pas de nous mettre à la place de notre interlocuteur : ce que nous voulons dire correspond rarement à ce que nos interlocuteurs veulent entendre !
La communication, c’est aussi un processus bidirectionnel. N’oublions pas l’écoute, en fait, commençons par cela. Une bonne écoute c’est :
- Absorber de l’information
- Rester calme et attendre.
- Encourager l’interlocuteur.
Voilà qui me rappelle la session de Florence Chabanois à l’Agile France 2013.
Leadership
Et ceci me rappelle à nouveau le Fearless Change. On y trouve plusieurs idées:
Aller parler aux sceptiques : comprendre ce qui les retiens est le premier pas vers la compréhension des faiblesses de notre message. De plus les sceptiques ne sont pas des opposants, du moins pas nécessairement. Ils peuvent même s’avérer être à terme vos plus ardents défenseurs.
Plusieurs facteurs peuvent influencer le refus de suivre :
- La difficulté
- La permission
- Le (mauvais) timing
- Ce n’est de toute manière pas mon idée !
L’exemplarité: Pour inciter les autres à suivre, commencer par faire vous-même. Vous voulez mettre en place un Kanban ? Utilisez déjà un « personal Kanban ».
Traiter les problèmes
Les rétrospective sont là pour les mettre en évidence et dresser des plans d’action. Mais plus encore, rendons les problèmes visibles tous les jours en les affichant !
Ce que j’en ai pensé
Pour être franc, j’ai eu du mal à m’enthousiasmer pour cette session un peu fourre-tout, avec un fil conducteur un peu difficile à saisir ! Bref, un peu déçu, je l’avoue…
Sébastien Ferron a publié un excellent post sur cette session sur le blog de SOAT.
Pollénisation croisée avec la communauté des designers ?
Pierre Hervouet et Joumana Mattar nous proposaient cette session. Si l’audience était nettement plus réduite qu’avec Rachel Davies, le contenu… eh bien j’ai préféré cette session, voilà !
Pourtant je suis venu sans trop savoir à quoi m’attendre. Mais j’avais aimé la session que Pierre avait animé avec Pascal Van Cauwenberghe à Agile France 2013. Je l’ai donc suivi ici.
Pierre vient ici avec une étiquette « Agile Lebanon », et il venait nous parler du Global Service JAM !
Le Global Service JAM, c’est une sorte de Startup Week-end pour les designers : une unité de lieu et d’action pour 48 heures, et pour sortir avec un produit ! Le JAM s’organise sur 3 jours.
1ère journée : Open minder
Au programme : ice-breaker, brainstorming et agile games !
On explore l’espace, on répartit des idées sur une table (cela offre une meilleure circulation qu’un mur) et on met l’utilisateur au centre en utilisant des personas.
A ce stade, on ne sait pas encore ce que l’on va construire !
Une première journée jugée très positive par Pierre et Joumana. Avec un outil atypique : l’unstuck jarre, remplie de questions perturbantes quand on est en panne…
2nd journée
Beaucoup de choses dans cette seconde journée ! En fait tellement d’outils que Pierre et Joumana nous ont distribué un jeu de cartes les rassemblant tous ! Voilà, vous n’aviez qu’à être à cette session !
On va donc y trouver pêle-mêle :
- Get out of the building : à l’image du Lean Startup Machine, pour aller valider son concept dans la rue !
- Des energizers
- Le bottleneck game de Pascal Van Cauwenberghe et Portia Tung, pour introduire l’amélioration continue
- 5 focus steps !
- La carte d’empathie pour explorer les personas. A l’image de ce que l’on fait en Lean Startup.
- Le User Journey map pour explorer l’expérience utilisateur via du story telling.
- Le PoP (prototyping on paper).
3ème journée : stress et deadline
A la fin de cette journée, il faut livrer !
Ce que j’en ai pensé
Beaucoup de choses dans cette session, j’ai la sensation d’en avoir raté la moitié. Au moins ! Cela m’a permis d’explorer un concept que je ne connaissais pas et je repars donc avec pas mal de pointeurs à investiguer !
Si l’aventure du Global Service JAM Libanais vous a intéressé ou intrigué, vous pouvez les retrouver sur leur Blog Tumblr.
Il est bientôt l’heure du déjeuner. En passant, je vois Romain qui termine sa session.
Déjeuner
Disons-le tout net : ce ScrumDay est de loin celui qui m’aura laissé la meilleure impression sur cet aspect : on a de la place et plusieurs buffet sont disposés de manière à ce que l’on ait jamais besoin d’attendre très longtemps. Les plats sont diversifiés et de qualité, et l’on peut s’assoir pour converser en même temps que l’on se restaure. Bravo !
Profiter de la pause déjeuner pour converser avec les nombreuses brillantes personnes que je peux croiser ici est un luxe que je n’ai jamais eu jusqu’à présent au ScrumDay ! C’est avec Jean-Laurent de Morlhon que je passerais la plus grande partie de cette pause. Le développement (le vrai) est la passion de Jean-Laurent. Aujourd’hui il partage son temps entre les missions de dev orientées « craftmanship », Serpodile la société créé par sa femme et le partage au sein des communautés qui lui tiennent à coeur. Nous retrouverons Jean-Laurent au cours de l’après-midi pour sa session.
Je clos ici le premier volet de mon retour sur ce ScrumDay, il ne faudrait pas risquer l’indigestion !
FKUG #3 avec Laurent Morisseau
Laurent n’est pas un inconnu pour nous, car il a fait partie du French SUG avant de s’orienter nettement vers le Kanban, en créant tout d’abord l’association Lean Kanban France qui organise la conférence du même nom et dont il est président, et en écrivant un livre sur le Kanban, le seul en Français à ce jour si l’on excepte la traduction du livre de David J. Anderson.
D’ailleurs la seconde édition de ce livre vient de sortir, elle évoque quelques nouveautés, des avancées dans la communauté Kanban. C’est pour les évoquer que Laurent est venu au FKUG la veille du ScrumDay.
C’est aussi hélas parce que c’était la veille du ScrumDay et que j’avais quelques petites choses à terminer pour l’atelier que j’animais que je n’ai pu venir de nouveau.
Fort heureusement cette soirée a été entièrement filmée (la vidéo est donc très longue) et nous pouvons profiter de cette soirée en différé comme si nous y avions été.
Enjoy !
(Source: https://www.youtube.com/)
Le doute est le commencement de la sagesse.
Aristote
Scrum Shu Ha Ri, la présentation
« On a pas mal de nouveaux venus à l’agilité, et on n’a pas beaucoup de sessions pour eux ». C’est ce que Jean-Luc Lambert me disait à propos de ce Printemps Agile 2014. En fait, je fais peu de sessions d’initiation, ce n’est pas ce que je préfère. Puis j’ai repensé à mes expériences récentes et ma façon d’appréhender Scrum comme un framework à même de nous accompagner du débutant à l’agiliste expérimenté.
Ainsi est née cette présentation « Scrum Shu Ha Ri ». Il n’est pas certain que j’aurais l’occasion de la resservir, ce n’est en tout cas pas prévu pour l’instant.
Le thème est inspiré du « Shu Ha Ri » présenté par Alistair Cockburn. J’ai en quelque sorte « instancié » ses idées à l’image que je me fais de Scrum.
J’escompte aussi pouvoir vous proposer plus tard cette présentation sous forme d’article, comme je fais parfois. Il vous faudra quand même patienter un peu.
Carnet de route : Le Printemps Agile 2014 à Caen (2/2)
Suite de ma visite au Printemps Agile.
Pause déjeuner !
Je m’en veux un peu : d’habitude je fais 2 ou 3 photos à ce moment-là. Ca fait un peu “ambiance” et ça change des photos des sessions qui finissent toutes par se ressembler… pas de chance, ou plutôt gros oubli de ma part : je n’en ai pas à vous partager !
Pause de courte durée par ailleurs, nous arrivons pour racler les plats … et repartir bientôt vers de nouvelles aventures
Sophrologie avec Céline Desmons
Une session / atelier bien curieuse que celle-ci ! D’abord quelques mots sur la sophrologie.
Fondé en 1960 par Alfonso Caycedo, un psychiatre Colombien, il s’agit d’une approche psychocorporelle associant le mental (pensées et émotion) et le corps. Elle s’inspire des techniques orientales telles que le Yoga ou l’hypnose déjà présents dans le Boudhisme Thibétain par exemple. Vous suivez ? Tant mieux, car moi plus tellement…
Céline nous propose une mise en pratique pour prendre conscience de notre corps. Désolé mais malgré les efforts de l’animatrice je m’avoue très peu convaincu…
Un géant peut-il être agile ?
Elodie et Emmanuel, tous deux chefs de projet / scrum masters chez Orange présentaient cet atelier. J’avais fait la connaisance d’Elodie juste quelques heures avan,t en allant chercher Géry à l’hôtel. Elle-même et Christophe Keromen ont ainsi profité du transport.
L’exercice du retour d’expérience n’est finalement pas si facile : il faut d’abord rendre cela intéressant, et il faut aussi faire preuve d’honnêteté et d’objectivité. Celui-ci s’en tire plutôt bien et la franchise dont font preuve les deux orateurs est rafraichissante.
L’agilité chez Orange
L’agilité chez Orange, c’est une décision du groupe ! Peut-être est-ce pour cela qu’on y consomme tellement de coaches agiles ? Par ailleurs, “agile” ne signifie pas la même chose partout dans le groupe. Voyons ce qu’Elodie et Emmanuel ont à nous dire sur ce qui se passe chez eux.
Les projets, même agiles, tels que nous les présente Emmanuel ont une forte coloration « classique »: on parle de « points de visibilité », de demandes de changements, l’orateur parle même d’effet tunnel !
Ce qui chiffonne plus encore c’est l’identification du PO. On semble en plein syndrome du « proxy PO » qui n’a pas de pouvoir décisionnaire et est en fait un AMOA à l’ancienne ! Le sponsor (le vrai PO) existe mais n’est pas disponible.
Ils ont essayé…
Quand l’environnement est fortement contraint, on en est réduit aux « petites victoires ». Par exemple.
Etre agile dans le cercle interne : Le projet tourne à l’ancienne, mais au moins l’équipe de développement emprunte des pratiques agiles. Il faut dire que l’environnement, il est un peu lourd…
Une gestion de changements à deux niveaux. Les demandes de changements étant un peu lourdes (elles sont « à l’ancienne »), on arrive à simplifier la procédure pour les petits changements (alors qualifiés d’agiles).
La « trade-off matrix » : elle permet de partager le niveau de volatilité des différents axes du projet.
La check-list pour se lancer, avec:
- Un kick-off via des jeux
- La marketing qui présente sa vision et les enjeux. Que se passe-t-il si on ne fait pas le projet ?
La priorisation via le backlog. Avant il y avait les fonctionnalités classées en P0, P1 et P2, donc avec le gros de la troupe classé en P0 et presque rien en P2 ; les équipes sont parvenues à basculer vers un mode « backlog ordonnancé » : belle victoire !
Visiblement
Visiblement, l’agilité est arrivé par le top management (pour quelles motivations ?), déclenchant l’embauche de hordes de coaches. Elle a convaincu au moins certaines équipes. Mais entre les deux, le middle management est bien décidé à résister et à mener (et contrôler) la barque comme avant.
Cela ne veut pas dire que rien n’est possible. Les équipes sont parvenus à progresser sur certains fronts et même à convaincre avec certains outils (les jeux, le management visuel), tandis que d’autres échouent à se mettre en place, comme les rétrospectives.
Break
Dernière pause avant la dernière session et la rétrospective !
J’en profite pour alimenter le « mur de la rétrospective ». En fait, Géry et moi n’allons pas retourner dans une session, nous préférons utiliser ce temps-là pour échanger. Je remarque une chose : dans les conférences assez matures, il traine pas mal de monde dans les espaces d’échange pendant les sessions. Les conférences plus récentes voient cette population plus restreinte. A Caen, Géry et moi étions seuls !
Peut-être il y a-t-il ici une opportunité de faire évoluer la formule ? Il y a pas mal d’étudiants sur place, pourquoi ne pas ménager un petit open-space qui serait très bénéfique à cette population ?
Rétrospective
Tout comme l’ice-breaker du matin, voici une nouvelle originalité proposée par la conférence Bas-Normande ! Nous voici de nouveau réunis dans le grand amphi pour une rétrospective animée par Myriam Boure. Jean-Luc a été bien aidé dans l’organisation de ce Printemps Agile. La gentillesse et l’énergie de Myriam ont probablement été parmi les apports les plus remarqués.
On s’appuie sur le « mur de post-it » qui était à disposition durant toute la journée. Les points remarquables sont pour moi l’ice-breaker, cette rétrospective mais aussi le concept de « participation libre » qui sont tous trois uniques à cette conférence. Sans compter l’ambiance et le programme ! Le point faible est sans aucun doute le déjeuner. Mais comme chauque édition propose son lot d’améliorations, je ne m’en fais pas trop.
Faire une retrospective à 200, ce n’est pas chose aisée. Peut-être faudrait-il envisager une rétrospective par petits groupes comme nous avions fait à Agile Game France ?
Stop ? Encore !
En tant que « local de l’étape », je fais le taxi pour mes confrères. Je dépose Géry et Christophe Kéromen à la gare. Les bretons et le Lyonnais (!) ne reournant dans leurs pénates que le lendemain, nous décidons de terminer cette journée dans un bar sur les quais de l’Orne, où nous rejoignent Jean-Luc et Myriam.
Une belle conférence, qui me permet de voir l’Agilité progresser à grand pas à Caen ! Jean-Luc nous promet une nouvelle édition l’an prochain, je la voie déjà prendre de l’ampleur…
On en parle aussi ici…
Le retour De Christophe Keromen, sur le Blog Coactiv
L’histoire est une suite de mensonges sur lesquels on est d’accord.
Blaise Pascal
Software Freethinker 
