Ce qu’il faut savoir sur le Daily Scrum
(via http://www.youtube.com/attribution_link?a=Zg-yIKJZVbk&u=/watch?v=MR88bbHf0wA&feature=share)
(Source: https://www.youtube.com/)
Étiquette : scrum
Les 3 rôles de Scrum
Irène Doan nous propose cette très belle animation de 5 minutes pour présenter les 3 rôles de Scrum. Je ne peux m’empêcher de penser aux vidéo dont nous gratifie Henrik Kniberg de temps autres : c’est clair, intéressant et concis !
(Source: https://www.youtube.com/)
Scrum Shu Ha Ri : l’article
Après vous avoir infligé le support de la présentation que j’avais faite lors du Printemps Agile à Caen, voici le contenu de la présentation elle-même. Peaufiné, retravaillé, il ne correspond peut-être pas (certainement pas, en fait) à la transcription de ma présentation, mais en révèle le contenu de manière plus approfondie.
En effet, ce ne sont pas moins de 93 renvois et 80 références bibliographiques (sans compter les 27 illustrations) qui émaillent les 29 pages du texte.
Bonne lecture !
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 !
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 !
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.
The Scrum Primer
Plus étoffé que le Scrum en 5 minutes, ce “primer” donne une vision plus précise de Scrum, mais aussi plus subjectives, car elle intègre des pratiques qui, si elles sont généralement acceptées" ne font pas partie de le définition stricte de Scrum. L’article présente aussi l’avantage d’être abondemment illustré de photos mais aussi de représentations d’artefacts tels que les auteurs les utilisent sur leurs projets (je reconnais au moins l’un d’eux que j’avais hérité de Craig Larman).
Avec ses 22 pages et une police plus classique, c’est plutôt 1 heure, voir plus, qu’il vous faudra consacrer à cette lecture. Le public n’est donc pas le manager très occupé. De plus certaines techniques comme les réestimations systématiques ou le burndown ne font pas nécessairement partie de votre processus.
Ce primer figure aussi en annexe du livre co-écrit par Craig Larman : Scaling Lean & Agile Development.
Note de lecture : Software in 30 days, par Ken Schwaber & Jeff Sutherland
Note : 3 ; Déçu, déçu, déçu et anachronique !
Jurgen Apello a qualifié ce livre de « poorly writen marketing brochure ». Je dois avouer que cela résume bien le livre. Pourtant, je me réjouissais d’avoir enfin un texte co-écrit par les 2 créateurs de la méthode, mes attentes étaient donc élevées, c’est certain. Voyons ce qu’il en est.
Le livre est bref : 125 pages (rajoutons les 3 très volumineuses annexes qui comptent tout de même 60 pages), sur 10 chapitres rassemblées en 2 sections. C’est du John Wiley, le papier est dégueulasse, c’est une habitude chez cet éditeur. En fait, ça commence même mal dès la couverture : qui fait encore du Scrum sur 30 jours ? Les auteurs sont restés campés sur leur position vieille de 20 ans (pour être précis). Le monde a changé entre temps, ils ont choisi de décider que le monde avait tord et que la Vérité promulguée il y a 2 décennies était inaltérable. En tout cas, cela ressemble à ça.
Long d’un peu plus de 50 pages et fort de 4 chapitres, la première section défends l’idée que toutes les organisations peuvent produire du logiciel… en 30 jours (encore !). Les 13 pages du 1er chapitre introduisent la « crise du logiciel ». C’est l’introduction classique à l’agilité. L’intérêt ici, c’est de s’appuyer sur des études datant de 2011 au lieu de la classique étude du Standish group de 2002 !
Au chapitre 2, on s’intéresse à l’essence de Scrum : l’empirisme. Un propos que j’ai l’impression d’avoir déjà lu il y a 10 ans dans les ouvrages précédents de Ken Schwaber. Plus pathétique encore : comparer cette approche au Waterfall. Sans doute il y a-t-il encore un peu de Waterfall sur des projets dans des coins, mais que diable, nous sommes en 2013 !
Après l’introduction, la mise en œuvre. Le chapitre 3 nous propose de choisir un projet pilote pour mettre en œuvre Scrum. C’est à mon avis un anachronisme de plus, car si ce concept pouvait exister il y a 10 ans, aujourd’hui les projets qui ne sont pas critiques ne sont simplement pas faits. Seule bonne nouvelle : le chapitre est court.
Cette première partie s’achève sur un court chapitre de 8 pages qui pose et investigue la question : quelle est la prochaine étape ? C’est une introduction à la seconde partie.
Cette seconde partie, justement, compte 70 pages sur 6 chapitre. Elle débute par le chapitre 5 qui présente les grandes lignes du framework Scrum. Le grand moment de rigolade de ce chapitre, c’est quand les auteurs prétendent que la majorité des mises en œuvre de Scrum se font avec des durées de 30 jours et que la réduction de cette durée à 2 semaines n’affecte que de façon très marginale les durées des meetings de début et fin d’itération. C’est ce qu’on appelle être bien à côté de ses pompes !
Le chapitre 7 nous présente le « studio Scrum ». C’est peut-être le chapitre le plus intéressant du livre, sans qu’il soit non plus transcendant. Mais au moins on parle un peu sérieusement de la « definition of done », par exemple.
Les chapitres 8 et 9 évoquent Scrum au niveau de l’entreprise. Cela reste dans la même veine que l’Enterprise Scrum de Ken Schwaber, rien de nouveau et c’est nettement plus superficiel.
Enfin le chapitre 10 nous parle de cycles d’amélioration de Scrum. Là encore un propos qui fait double emploi avec la prose de Agile Project Management with Scrum de Ken Schwaber.
Le Scrum Guide de l’annexe B est celui disponible en ligne. OK, cela occupe au moins un peu de place. Le « playbook » de l’annexe 3 est plus originel, quoiqu’il date de 2005 !
Ce livre est une grosse déception à de nombreux niveaux. Clairement j’attendais mieux des créateurs de la méthode. Le propos est très superficiel, et même carrément marketing. Je m’attendais à y voir les tripes des auteurs, y sentir des choses profondément ancrées : rien. Le seul intérêt que je peux voir est l’usage exclusif des termes et concepts originaux de Scrum. Ainsi on y parle exclusivement de « product backlog items (PBIs) », là où il semble admis un peu partout de parler de user stories… le retour aux fondamentaux n’est pas nécessairement un mal partout.
S’il n’y a pas de raison à bouleverser le framework Scrum, le propos n’a pas non plus changé d’un iota. Un certain nombre de points souvent dogmatiques sont toujours là et présentés comme indiscutables. Pourtant ils peuvent l’être ou être anachroniques, tel la durée des sprints sur 30 jours (ce que je n’ai ni pratiqué, ni jamais vu pratiqué). Un livre que je déconseille très fortement à tout le monde. Les bons livres sur Scrum existent. Ailleurs.
Référence complète : Software in 30 days – Ken Schwaber & Jeff Sutherland – John Wiley & sons 2012 – ISBN : 978-1-118-20666-9
My “Business Craftsmanship” keynote given at Agile Spain 2013, Bilbao. The slides are not visible in this video so I recommend just listening to the soundtrack and following along with the slides available here.
(Source: https://www.youtube.com/)
De l’agilité pour mon projet, pour quoi faire ?
J’avais évoqué lors de mon teasing de la DevFest 2013 la présentation que Martin Mouterde et moi-même y ferions. Vous trouverez le support de cette présentation ici.
Préparer une présentation à quatre mains n’est pas un exercice facile. Comme j’ai des idées tranchées et personnelles (mais pas nécessairement bonnes, toutefois) de ce à quoi devraient ressembler des présentations, il reste improbable que je sois réellement satisfait du résultat. Ne comptez toutefois pas sur moi pour dire qui a engendré quoi.
J’ai hésité à modifier cette présentation avant de la poster. Finalement je me suis dit qu’elle devrait figurer telle qu’elle a été jouée () . Même si je la modifie de manière substantielle si je sui amené à la rejouer…
