<img src="https://picsum.photos/200/300?random=1"/>
Bienvenue dans cette histoire agile dont vous êtes le héros. Je vous propose d'influencer les aventures professionnelles d'un Scrum Master.
L'histoire que vous allez me raconter aujourd'hui, vous pourrez l'explorer en ligne. En aucun cas, les quelques instants de vie que nous allons explorer ne représentent une réalité unique pour nos personnages fictifs ou pour des personnes existantes (ou ayant existé). Pour la lisibilité de la keynote, vos choix seront définitif et unitaires, dans une vraie carrière nous avons beaucoup plus souvent la possibilité de poursuivre plusieurs voies en même temps...
Avant de nous lancer, décidons de notre héros pour les 40 minutes à venir :
Voulez que notre héros soit:
# Eva Yarivai, qui est Scrum Master dans une petite start up, [[2 - Introduction de Eva]]
# James Huyvre, qui lui est Scrum Master d
ans une grande structure (client final) [[2 - Introduction de James]].
<<if setup.steps gt 2>>
Yeah
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva travaille chez LudiGames, une société éditrice de Serious Games en ligne.
Eva a débuté chez LudiGames entant que développeur fullstack, et adore explorer les innovations des différents languages utilisés dans la création de leur portail de serious games en ligne.
Depuis quelques temps, l'équipe a décidé qu'il lui fallait un Scrum Master. Les raisons sont multiples et comptent parmi:
* L'augmentation de la taille de l'équipe de développement de 3 à 8 développeurs
* Les demandes de plus en plus urgentes de la part des responsables de l'entreprise
* L'aspect chaotique de la priorisation des demandes
* La taille des releases qui commence à augmenter.
Eva accepte donc ce nouveau challenge et décide :
#De demander une [[3 - Formation de Scrum Master]] afin de mieux comprendre ce qui est attendu d'elle sur ce rôle
#De se lancer toute seule en lisant le [[3 - Guide Scrum et les ressources en ligne]] disponibles
#D'explorer son intuition qui lui indique que LudiGames souffre du [[3 - Syndrôme de la grosse release]]
<img src="https://picsum.photos/200/300?random=1"/>James intègre la DSI des Rois du ballon, plus gros fabriquant de verres à pieds de France entant que Scrum Master.
Il débute dans la structure et n'a pas beaucoup d'expérience entant que Scrum Master. Il a suivi une formation et vient d'obtenir sa certification PSM1.
Il a rendez-vous avec son nouveau manager et ils discutent du positionnement du Scrum Master au sein de l'équipe que James va intégrer.
Comment se passe la discussion?
#James, fort de ses convictions, annonce à son manager que pour lui, le rôle de Scrum Master est un rôle à temps plein. [[3 - Un Scrum Master à temps plein]]
#James, fort de ses convictions, annonce à son manager que pour lui, le rôle de Scrum Master n'est qu'un rôle assigné à un membre de l'équipe et qu'il souhaite pouvoir continuer à produire pour l'équipe. [[3 - Un Scrum Dev]]
#Le manager de James ne lui laisse pas le temps de s'exprimer sur ses convictions et lui annonce la vision de l'entreprise vis à vis des Scrum Masters. [[3 - Le Scrum vu par les Rois du ballon]].La vision de James n'est pas tout à fait en accord avec celle des Rois du ballon qui préfèrent avoir des personnes polyvalentes et donc des Scrum Devs, cependant son manager est ouvert à l'avis de James et lui propose de tester cette vision dans l'entreprise.
Que se passe-t-il ensuite?
#Au bout de quelques temps, son manager l'aborde : Une équipe a perdue son Scrum Master et il propose à James de le remplacer, endossant alors le rôle de Scrum Master sur 2 équipes. [[4 - Un Scrum Master multi équipe pour les Rois du Ballon]].
#Au bout de quelques temps, son manager l'aborde : il a l'impression que James n'est pas à 100% d'occupation et il lui demande de repasser en mode Scrum Master comme vu par les Rois du ballon [[4 - Le Scrum vu par les Rois du ballon]].
#James se rend compte que son équipe semble maintenant suffisemment auto-organisée pour ne plus avoir besoin d'un Scrum Master à temps plein. cependant, la qualité du produit délivré semble poser quelques soucis depuis plusieurs itérations. James décide donc d'aider son équipe en faisant des tests lorsque nécessaire. [[4 - James passe Scrum QA]]
La vision de James est simple: le boulot de Scrum Master n'est pas un boulot à temps plein sur le long terme avec une seule équipe.
De ce qu'il a appris en formation, un Scrum Master va passer du mode "Srum Mom" au début de la vie d'une équipe au mode "dispensable" lorsque l'équipe a pris en compétence et auto-organisation.
C'est ca le rôle du servant leader, il en est sur!
Quelle étape allons nous explorer ensuite?
#L'aventure de James entant que Scrum Dev chez les Rois du Ballon. [[4 - James fait un bout de chemin chez RDB]].
#Au bout de quelques temps, James se rend compte qu'il est moins efficace au niveau développement à force de passer d'un sujet à l'autre trop souvent. Il discute avec son manager et ils décident qu'il est temps qu'il devienne [[4 - Un Scrum Master multi équipe pour les Rois du Ballon]].
#L'aventure Scrum Master de James se déroule comme toutes les histoires agiles que nous connaissons bien, voyons ce qu'il se passe aprés. [[4 - Fast Track Scrum Master James]]
<!--#James n'est pas plus attaché que ca au développement, mais il est attaché à l'équipe et à son succès au niveau de la production de valeur. Il propose alors de les aider autrement. [[4 - James passe Scrum QA]]-->La vision des Rois du ballon est la suivante: Scrum est un framework qui permet aux équipes d'être efficaces. Cependant, lors de la présentation du framework par un formateur bien attentionné, ils ont entendu et retenu, les choses suivantes:
* Les rôles de Scrum Master et de PO ne sont pas des nouveaux métiers.
* Etre Scrum Master ca prend pas plus de 30% du temps d'un individu en moyenne sur la durée de vie d'une équipe.
* Un PO venant du métier est plus efficace.
La situation est donc la suivante:
* Les Scrum Masters font du dev à hauteur de 70%.
* Les PO sont des personnes ayant un métier dans la fabrication des verres à pied en plus d'avoir la responsabilité du backlog d'un produit informatique.
* L'efficacité du système doit pouvoir être suivi et le point d'effort a été choisi comme unité.
James doit décider de ce qu'il fait devant cette situation:
#Il décide que la vision est trop éloignée de la sienne et met fin à sa période d'essai [[4 - James micro-entrepreneur]]
#Il décide de voir se qui va se passer et pense pouvoir changer les mentalités en interne. [[4 - James fait un bout de chemin chez RDB]]
#James n'est pas si à l'aise que ca en développement et décide cependant de tenter d'aider l'équipe du mieux de ses capacités, notamment dans le test. [[4 - James passe Scrum QA]]
#Aprés d'âpres négociations, il réussi à atteindre un compromis avec son manager et devient donc [[4 - Un Scrum Master multi équipe pour les Rois du Ballon - 2]] .Le manager de James propose à ce dernier un entretien d'évolution. James y arrive confiant : il a eu du mal au début mais son équipe est maintenant efficace.
Ils ont déployé Scrum "By the book" et le PO semble satisfait de ce qui est produit. Les utilisateurs sont au rendez-vous également et l'équipe a un turn over limité.
Alors oui, il a rencontré quelques challenges... Notamment liés au fait que dans l'industrie tout bouge à son propre rythme.
Mais maintenant James se sent à l'aise dans son rôle...
L'entretien se déroule plutôt bien, le manager de James lui propose d'utiliser son budget de formation car James ne l'a pas encore entamé. James dit qu'il va y réfléchir.
Puis le manager de James lui propose plusieurs possibilités :
#James pourrait prendre en charge une équipe qui a besoin d'un scrum master. James décide de se lancer dans une phase d'observation. [[5 - Observation et nouvelle équipe - RDB]]
#Le manager de James lui propose de prendre en charge une équipe de plus en lui assurant qu'elle est complètement autonome. [[5 - Une équipe autonome chez les Rois du Ballon]]
#James et son manager tombent d'accord sur le fait que la qualité de la production pourrait être améliorée. Du fait, James propose de prendre en charge une partie de l'assurance qualité. [[5 - James passe Scrum QA]]
James a testé Scrum comme le guide le lui a appris et cela semble avoir bien fonctionné avec sa première équipe. En effet, celle-ci débutait sur un nouveau produit et le métier étant ultra impliqué, il n'a eu aucun mal à s'entendre avec le PO.
Que va faire James avec sa seconde équipe?
#Il va tenter d'appliquer les mêmes pratiques et méthodes avec la seconde équipe: si ca a marché pour la première, y'a pas de raison que ca foire pour la seconde quoi que... [[5 - Le Cargo Cult ca pique - RDB]]
#Il se pose quelques jours/semaines pour voir comment l'équipe fonctionne et adapte son accompagnement à cette dernière [[5 - Observation et nouvelle équipe - RDB]]
#L'équipe ne lui laisse pas le choix: ils sont autonomes et n'ont que peu besoin de lui [[5 - Une équipe autonome chez les Rois du Ballon]]James rejoint donc Vertes Prairies, un voyagiste spécialisé dans les excursions bas carbonne (proche de chez vous).
L'équipe informatique n'est pas trés grande mais ils ont tout de même 2 grosses applications: une pour les clients et une pour les vendeurs en agence ou au téléphone.
Ces deux applications sont maison et donc maintenues en interne.
James prend en main une 20aine de personnes entant que Scrum Master.
"Ca va être simple", lui annonce le DSI. En effet, il se targue que les équipes sont déjà agiles mais sans cadre... James se rend compte que le terme agile n'est pas bien employé, il voit même des affiches "Passez votre entreprise en mode agile" qui trainent dans les bureaux.
Où allons nous à partir de là?
#James va mettre en place exactement ce qu'il a appris chez les Rois du Ballon. Il réplique à la fois les pratiques agiles mais réussi à convaincre le DSI de changer l'organisation afin de se rapprocher de celle qu'il a connu avant. [[6 - Le Cargo Cult ca pique - Vertes Prairies]]
#James analyse la situation. Certes la taille de la DSI pourrait lui permettre de lancer une initiative Scrum sur 2 à 3 équipes mais il a le sentiment qu'il y a plus à aller chercher. Il accompagne donc son entreprise vers la mise en place d'une méthode maison. [[6 - Une méthode maison pour les vertes prairies]]
#On a pas envie de voir comment James s'en sort entant que Scrum Master, ce qu'on veut voir c'est le résultat et ce qu'il fait après!! [[6 - Fast Track Scrum Master - Vertes Prairies]]
James s'interroge, que veut dire l'équipe quand elle se sent autonome?
De son expérience de Scrum Master, une équipe est autonome lorsqu'elle s'auto-organise. Elle n'a pas besoin d'un Scrum Master qui soit tout le temps présent mais de temps à autre, quand l'équipe rencontre des freins importants, elle est contente d'avoir un rôle dédié à ce genre de situation.
De plus, James sait ce que veut dire auto-organisé, il sait aussi qu'il arrive à certaines équipes de dériver d'une vraie démarche d'amélioration continue s'ils ne font que de l'entre soi... Ils finissent pas ne plus se remettre en question ou leur manière de travailler...
Que va-t-il se passer ensuite?
#James passe pas mal de temps avec les membres de l'équipe pour comprendre ce qui les fait se sentir autonome et sans besoin de Scrum Master. Et en effet, l'équipe est trés trés agile et autonome. Les seuls freins qu'ils rencontrent sont généralement liés aux besoins présentés en début de sprint. Il décide donc d'[[6 - Accompagner le PO]]
#Malheureusement, l'équipe n'est pas si agile que celà. Certes, elle est autonome mais principalement parcequ'elle ne demande rien à personne et se débrouille toute seule. Ca ne veut pas forcément dire qu'elle est efficace, et James le sait bien. Comment faire comprendre à son équipe qu'elle est sans doute dans un piège de rigidité? James décide de voir ce que les autres agilistes lillois peuvent lui proposer [[6 - James participe à son premier Agi'Lille - RDB]]
#L'équipe se dit autonome, mais ne l'est pas réellement. James, au départ, pensait pouvoir passer en mode ScrumDev, mais il est vite confronté à la notion de [[6 - Production VS Servant Leadership - RDB]] L'observation se passe bien. James se rend compte que son accompagnement pour la nouvelle équipe ne peut pas être le même que pour la plus ancienne. Cette dernière est beaucoup plus autonome et ne lui demande que peu de choses. Entre animation de rétro et gestion des freins, James a plus de temps pour lui.
Que se passe-t-il ensuite?
#James se rend compte d'un manque côté Product Owner sur la nouvelle équipe. Il se rapproche du métier et décide d'[[6 - Accompagner le PO]].
#James s'en sort pas mal avec ses deux équipes, mais il ressent le besoin de se renouveler. Il décide de participer à des conférences pour creuser un peu plus la démarche agile et les méthodes associées. Il se rend à l'[[6 - James participe à son premier Agi'Lille - RDB]].
#James commence à envisager son futur. Il cherche une formation qui pourrait l'emmener plus loin dans son développement agile. [[6 - Une formation agile pour James- RDB]]James rejoint DoctoChat, une société qui travaille à une application pour faciliter le travail des médecins dans leurs cabinet en proposant des questionnaires à compléter par les patients lorsqu'ils sont en salle d'attente.
Depuis quelques temps, l'équipe a décidé qu'il lui fallait un Scrum Master. Les raisons sont multiples et comptent parmi elles:
* L'augmentation de la taille de l'équipe de développement de 3 à 8 développeurs
* Les demandes de plus en plus urgentes de la part des responsables de l'entreprise
* L'aspect chaotique de la priorisation des demandes
* La taille des releases qui commence à augmenter.
James se lance donc à corps perdu dans ce nouveau challenge et décide :
#D'explorer son intuition qui lui indique que DoctoChat souffre du [[Syndrôme de la grosse release - DoctoChat]]
#De mettre en place ce qu'il a appris chez son précédent employeur et d'appliquer exactement la même méthode. [[Le Cargo Cult ca pique - DoctoChat]]
#James décide de prendre son temps et se lance dans une phase d'[[Observation de l'équipe DoctoChat]]James met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Il tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'il est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il décide de revoir sa copie. Quelle est la prochaine étape?
#[[6 - Le management remet en question la capacité de James à avancer seul]]
#James se rend compte qu'il faut absolument [[6 - Accompagner le PO]]
#James entend parler de la communauté agile lloise et décide de participer à [[6 - James participe à son premier Agi'Lille - RDB]] James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[7 - James devient PPO]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[7 - Product Box - RDB]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[7 - Se former aux démarches produits]].
James cherche une formation pour l'aider à s'améliorer dans ses accompagnements.
Il discute avec son manager des différentes formations à sa disposition. Entre les formations de gestion d'équipe, de management, de gestion de produit... James a la tête qui tourne mais trouve peu de formations agiles.
Il trouve tout de même deux formations qui pourraient l'interesser:
* Une formaiton de coach
* Une formation sur le Kanban
Il doit donc faire un choix :
#Passer une [[7 - Formation certifiante Coach - RDB]]
#Prendre la formation sur [[7 - Le Kanban par Laurent Morisseau - James]]
#Quelque soit la formation suivie, James se voit offrir une promotion. [[7 - James devient coach agile chez les Rois du Ballon]] L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[8 - Valeur Business - RDB]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[8 - Le WSJF chez RDB]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[8 - La dette technique et Scrum - RDB]] James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez RDB.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez RDB il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[8 - DevOps et RDB]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[8 - Le WSJF - RDB]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[8 - Kanban - RDB]] en espérant prouver par l'exemple que le workflow actuel est saturé.Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projetter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[8 - La dette technique et Scrum - RDB]]
#Aborder la [[8 - Valeur Business - RDB]]
#Mettre en place un mode de priorisation simple et rapide. [[8 - Prioriser en tailles de TShirt - RDB]]
#Déployer le WiSJiF [[8 - Le WSJF - RDB]] Le manager de James lui propose un rendez-vous pour faire un petit état des lieux.
Il en ressort qu'au travers de ces différentes tâches et missions, James a peu de temps pour s'occuper réellement de faire de la veille ou de simplement prendre du recul sur les situations rencontrées. Aprés tout, l'expérience agile de James s'est entièrement construite chez les Rois du Ballon.
Entre hésitation, non dits... ils finissent par tombre d'accord sur une manière d'accompagner James au mieux.
Quelle décision prennent-ils?
#James doit impérativement faire de la veille de son coté, pour ce faire, les Rois du Ballons sont OK pour lui payer sa [[7 - James participe à son premier Agi'Lille]]
#James prend mal la critique, il décide de se lancer seul. [[7 - James micro-entrepreneur]] Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[8 - Kanbanzine - RDB]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[8 - Une formation avec Laurent Morisseau - RDB]]?
#Quelque soit la manière, il réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[8 - Le Kanban ca marche, mais ca prend du temps! - RDB]].<img src="https://picsum.photos/200/300?random=1"/>Eva réussi à obtenir le financement de sa formation de Scrum Master.
En consultant le catalogue en ligne de leur platforme de formation inter-entreprise, elle trouve 3 formations possibles:
* Une formation qui prépare à la certification Scrum.org
* Une formation certifiante au format ScrumAlliance
* Une formation proposant beaucoup de mises en pratique mais ne menant pas nécessairement à une certification officielle SCRUM.
Le choix risque de ne pas être facile et surtout d'impliquer un certain nombre de conséquence pour la suite de sa carrière. Surtout que chez LudiGames, les budgets formation ne sont pas illimités. Alors certe, le temps des équipes sur de l'autoformation n'est pas compté mais débloquer un budget spécifique est plus compliquer.
Que décide Eva?
#[[4 - Certification Scrum.org]]
#[[4 - Formation certifiante ScrumAlliance]]
#[[4 - Formation pragmatique]]<img src="https://picsum.photos/200/300?random=1"/>La lecture du guide Scrum, bien que facile, a apporté son lot de complications pour Eva.
En effet, elle voit bien l'aspect théorique, et imagine bien que les quelques éléments de pratique proposés fonctionnent pour des équipes qui travaillent au sein d'une organisation déjà en place.
Mais elle rencontre quelques souci d'appropriation du sujet. Pour commencer, la nature Start Up de son entreprise est-elle compatible avec Scrum?
Pour continuer, quelles sont les vraies pratiques derrière les notions de plannification, de gestion du backlog... telles que proposées par Scrum?
Quelle suite voulez-vous donner à l'aventure?
#Pas envie de revivre la vie d'un Scrum Master, voyons ce qu'il se passe aprés l'expérience Scrum d'Eva. [[4 - Fast Track Scrum Master]]
#Comment passer du guide Scrum à de vraies pratiques? [[4 - Le chemin de l'auto-formation]]
#Scrum et les Start up... explorons les limites de ce mélange. [[4 - Scrum c'est bien, mais limité chez LudiGames]]<img src="https://picsum.photos/200/300?random=1"/>C'est étrange ce qui se passe chez Ludigames: c'est comme si plus ils veulent mettre en prod, plus ils retardent leurs mises à jour.
Mais quel est donc ce mal qui les touche?
Eva a discuté il y a quelques temps avec un ami qui lui décrivait une situation similaire: le syndrôme de la grosse release.
Plus on veut mettre de nouveautés en ligne d'un coup, plus la mise à jour du produit prend du temps à être créée.
Plus le temps s'écoule entre 2 mises en production, plus on veut profiter du temps disponible pour faire une grosse mise à jour.
Plus la mise à jour est importante, plus il faut prévoir d'accompagnement au changement auprés des utilisateurs et plus les attentes de ces derniers augmentent.
Plus les attentes des utilisateurs augmentent, plus on essaye d'en mettre dans la nouvelle version du produit...
Eva se doit donc d'agir... mais que va-t-elle pouvoir faire?
#Elle décide que le mieux qu'elle puisse faire est de se centrer sur l'équipe et d'être [[4 - Une Scrum Master qui reste dans la technique]].
#Elle décide de parler de son diagnostic aux demandeurs chez Ludigames et de revoir avec eux les ambitions derrière les mises à jour du produit. [[4 - Eva travaille aux ambitions de LudiGames]]
#Pour Eva c'est sûr, tout passe par les POs et [[4 - La démarche produit chez LudiGames]]!
#On s'en fout de la vie de Scrum Master d'Eva, nous on veut voir la suite! [[4 - Fast Track Scrum Master]] Eva participe à une formation au format Scrum.org.
L'avantage de cette formation, c'est qu'Eva sort de celle-ci prête à passer la certification PSM1.
Elle rentre le lundi suivant pleine d'énergie et d'envies. Son équipe est en attente de la voir en action, sa direction est impatiente de voir des changements suite à ces 2 jours "hors prod"...
Maintenant, elle se doit de décider quelle sera sa prochaine action?
#[[5 - Eva tente d'appliquer l'intégralité de Scrum chez LudiGames]]
#Eva se lance entant que Scrum Dev et est rapidement confrontée aux contradictions de [[5 - Production VS Servant Leadership]]
#Eva présente à sa directin ce qu'elle a appris durant la formation. La première réaction de LudiGames est [[5 - Scrum ca coute cher]]
#[[5 - Eva décide de passer la certification Scrum.org]] Eva participe à une formation au format Scrum.org.
L'avantage de cette formation, c'est qu'Eva sort de celle-ci une certification en poche.
Elle rentre le lundi suivant pleine d'énergie et d'envies. Son équipe est en attente de la voir en action, sa direction est impatiente de voir des changements suite à ces 2 jours "hors prod"...
Maintenant, elle se doit de décider quelle sera sa prochaine action?
#[[5 - Eva tente d'appliquer l'intégralité de Scrum chez LudiGames]]
#Eva se lance entant que Scrum Dev et est rapidement confrontée aux contradictions de [[5 - Production VS Servant Leadership]]
#Eva présente à sa directin ce qu'elle a appris durant la formation. La première réaction de LudiGames est [[5 - Scrum ca coute cher]]<img src="https://picsum.photos/200/300?random=1"/>Eva participe avec enthousiasme à la formation.
Elle tombe sur un formateur aguerri dans les accompagnements de transformations agiles et profite à la fois des ateliers proposés pour acquerir de la pratique et des retours d'expériences du formateur.
Elle a même la possibilité de poser des questions sur des exemples précis qu'elle a rencontré chez LudiGames.
Quelle première étape choisit Eva en sortant de sa formation?
#[[5 - Eva décide de passer la certification Scrum.org]]
#[[5 - Eva tente d'appliquer l'intégralité de Scrum chez LudiGames]]
#Eva entend parler par le formateur, du mouvement Agnostic Agile et s'intéresse au sujet, elle décide d'organiser un atelier de travail avec son équipe pour qu'ils choisissent ensemble l'agilité LudiGames. [[5 - Agnostic Agile - L'agilité LudiGames]].
La préparation lui demande pas mal de temps, mais Eva réussi à trouver l'énergie pour s'entrainer! Elle trouve un site qui l'aide dans ces entrainements (www.certifagile.com) et bachotte, bachotte, bachotte.
Elle obtient cette certification haut la main. Et se dit que c'est un bon apport pour son CV.
Elle rentre fièrement chez LudiGames et se demande que faire avec cette certiffication.
A-t-elle un interet pour son application de Scrum au sein de l'équipe?
La connaissance acquise peut-elle s'appliquer directement à l'équipe?
Voyons ce que vous allez choisir d'explorer.
#Eva a tellement apprécié obtenir cette certification, la décharge de dopamine a été tellement agréable, qu'elle décide de se lancer dans un parcours l'amenant à toujours plus de certifications. [[6 - Des certifs, toujours plus de certifs]]
#Forte de cette certiffication, et du boost de confiance en elle qui l'accompagne, Eva tente d'appliquer Scrum "by the book" avec son équipe. Comment va se passer ce retour dans le cadre? [[6 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Aprés quelques semaines d'application stricto sensu de ce qu'elle a appris pour sa certification, Eva rencontre [[6 - Des problèmes d'engagement chez LudiGames]]
#C'est bien beau d'avoir un Scrum Master certifié, mais il fait quoi aprés l'équipe le Scrum Master? [[6 - Fast Track Scrum Master - Eva]] Scrum c'est beaucoup de choses à mettre en place, mais Eva est courageuse et se lance dans une mise en place complète du Framework.
Elle travaille avec l'organisation pour identifier un PO, avec lequel elle travaille afin de préparer au mieux les sprints de l'équipe.
Elle a déployée les différents rituels d'une équipe Scrum: Affinage, Sprint Planning, Daily, Revue, Rétrospective...
Aprés quelques temps elle se pose et fait un bilan de ce déploiement :
#Il semblerait que les résultats ne soient pas tout à fait à la hauteur des promesses, pourtant Eva à tout fait comme le guide le dit! [[6 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#C'est un succès, l'équipe livre de la valeur, le PO est aux anges. [[6 - Scrum ca marche pour LudiGames]]
#Malgré un engagement total de l'équipe et du PO, beaucoup de Sprints sont en échec : l'équipe ne livre pas ce à quoi elle s'était engagée. [[6 - Des problèmes d'engagement chez LudiGames]]
Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de LudiGames et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[6 - LudiGames et Kanban]]
#Au final, Scrum reste une proposition interessante, il leur faudra s'adapter aux contraintes mais ils décident d'essayer de rentrer dans le cadre. [[6 - LudiGames et Scrum]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[6 - LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[6 - Une méthode maison pour LudiGames]]
La vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans gros challenge.
Eva a tout de même plusieurs gros succès avec son équipe agile initiale chez LudiGames :
* Mise en place d'une notion de valeur relative et d'un WSJF
* Capacité à prendre en compte le run facilement
* Gestion des compétences en interne à l'équipe avec une augmentation régulière du Craft de celle-ci
* Capacité de l'équipe à gérer plusieurs produits en même temps.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[5 - Eva micro-entrepreneuse]]
#Eva se confronte à la réalité du marché, elle est Scrum Master depuis quelques temps certes, mais auto-formée. [[5 - Un Scrum Master auto-formé]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investir dans un rôle de coach. [[5 - Eva devient coach agile chez LudiGames]]Eva met du temps à comprendre ce qui arrive à son équipe.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que LudiGames doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être
agile.
De quelle pratique vont-ils s'inspirer?
#[[7 - Kanban - LudiGames]]
#[[7 - Shape Up - LudiGames]]
#[[7 - DevOps - LudiGames]]Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[7 - Kanbanzine - Eva]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[7 - Une formation avec Laurent Morisseau]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[7 - Le Kanban ca marche, mais ca prend du temps!]].
Rentrer dans un cadre, quand on est une StartUp, ca pourrait paraître antinomiqe.
Et pourtant, c'est ce à quoi s'attèle Eva.
Revenir aux bases, expliquer pourquoi Scrum. Le fait qu'une équipe c'est comme une mêlée au rugby...
Revenir aux bases, reposer le cadre. Des sprints de 2 semaines, des rituels toujours à la même heure, au même moment du sprint.
Faire du lean même : éliminer le superflu (notamment toutes ces réunions qui ne produisent pas de valeur). Revoir le tableau scrum, enlever ces étapes dictées par leur outil de ticketting. Ajuster le process dans l'outil de ticketting pour qu'il s'adapte à Scrum (et pas l'inverse).
Puis retravailler l'empirisme. Travailler aux bons indicateurs (burn up, burn down). Utiliser les données pour aider l'équipe à s'engager. Challenger l'équipe sur son engagement (vers le haut ou vers le bas). Faire en sorte qu'ils se synchronisent correctement en vue de la tenue de cet engagement.
Retourner aux bases... de Scrum.
Au final, Eva dépense énormément d'énergie pour ce retour dans le cadre. L'équipe est souvent frustrée de devoir se conformer à un cadre... "Scrum c'est pas flexible" s'entend-t-elle critiquée parfois... Scrum c'est pas flexible... Scrum c'est pas agile?
Mais elle tient bon...
#Et le résultat est à la hauteur de l'investissement d'Eva et des frustrations de l'équipe. [[7 - Scrum ca marche pour LudiGames]]
#L'équipe a bneau être rentrée dans le cadre, rien n'y fait, ils continuent à ne pas livrer l'attendu. [[7 - Des problèmes d'engagement chez LudiGames]]
#Rentrer dans le cadre oui, mais pour combien de temps? Doit-on y rester longtemps? Eva explore [[7 - Le ShuHaRi appliqué à Scrum - LudiGames]] Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[7 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[7 - Gérer le run en Scrum - LudiGames]]
#Eva va galérer, mais elle va y arriver, nous ce qu'on veut voir c'est l'après [[7 - Eva micro-entrepreneuse]] Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner LudiGames correctement et l'aider à traverser ses challenges.
Eva a une équipe motivée, constituée de LudiGamers de la première heure. Ils connaissent le contexte, le produit et les utilisateurs. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.[[7 - Scrum Master et QA chez LudiGames]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[7 - La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[7 - Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[7 - La dette technique et Scrum - Eva]] Tout dans Scrum s'applique correctement chez LudiGames!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe d'Eva et LudiGames, le succés est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
Eva n'est plus sollicité par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Elle a donc du temps pour explorer des sujets complémentaires sur la toile.
Elle a réussi à amener un peu de fun dans les différents rituels. En commencant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, elle trouve un format ludiquer que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Elle change à chaque fois le focus de l'équipe et elle a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvent des anomalies, elles sont résolues séance tenante par l'équipe.
Eva est donc prête pour passer à la suite.
#En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!! [[7 - Eva se passionne pour le No Estimate - LudiGames]]
#Le manager d'Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[7 - Le Cargo Cult ca pique - LudiGames]]
#Forte de ce succés, Eva se dit qu'elle aimerait changer un peu d'horizon et se lancer dans le coaching agile. [[7 - Eva devient coach agile chez LudiGames]] C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[7 - Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[7 - Le WSJF chez LudiGames]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[7 - Fast Track Scrum Master - Eva]]
Tout le monde en parle, et les agilistes expérimentés autour d'Eva n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant il lui faut trouver des clients et se lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale d'Eva?
#Une chose est certaine pour Eva : elle veut être coach agile. Et donc elle n'acceptera que des missions de cet ordre. [[6 - On ne devient pas coach tout seul]]
#Ces copains lui ont dit : au départ, il faut te faire ta clientèle. Elle décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[6 - Engranger des missions]]
#Au bout de quelques temps Eva commence à subir les effets secondaires du lancement en indépendant. Elle a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[6 - Indep c'est bien, toute seule ca craint!!]]
Se débrouiller par soi-même quand on est Scrum Master c'est pas si facile. Il faut faire appel à beaucoup de ressources en ligne, lire énormément d'écrits sur le sujet, se nourrir de l'expérience des autres.
Eva s'en est sortie. De meetups en conférences agiles en ligne, d'eLearning en vidéo explicative, elle pense avoir écumée la toile jusqu'à sortir la substantifique moelle de son métier de Scrum Master.
Cependant, la vie de scrum master auto-formé peut apporter son lot de surprises / inconvénients.
Par exemple, lorsqu'elle parle à certaines personnes en ligne, et qu'on lui demande son niveau de certification, elle a l'impression que ne pas en avoir met tout de suite une barrière invisible entre elle et son interlocuteur.
Egalement, Eva n'a pas forcément eu la chance d'expérimenter beaucoup des concepts qu'elle a rencontrée durant ses recherches et ne sait pas forcément comment faire pour acquérir cette expérience.
Que pouvons-nous proposer à Eva pour la suite de son expérience professionnelle?
#Le virtuel c'est bien, mais rien de tel que de participer à des événements aagiles en physiques. [[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva a explorée Scrum toute seule, mais explorer Kanban lors d'une formation avec Laurent Morisseau pourrait lui apporter des idées et expériences complémentaires. [[6 - Une formation avec Laurent Morisseau]]
#Eva devrait se rapprocher du mouvement Agnostic Agile! Rien de tel qu'un retour aux sources pour se rendre compte du chemin parcouru. [[6 - Eva devient Agnostic Agile]]
Eva semble touchée par le syndrôme de l'imposteur. Elle pourrait chercher quelques remèdes à ses crises !! [[Syndrôme de l'imposteur - Eva]]Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[5 - Production VS Servant Leadership]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[5 - Le craftsmanship]].
#Eva se rend compte de ces difficultés. Elle se demande si elles ne viennent pas du fait qu'elle est [[5 - Un Scrum Master auto-formé]] Eva est fière d'elle, elle a obtenu sa première certification! Et puis ce sentiment de satisfaction généré par la dopamine!!
Elle décide de continuer, de monter les échelons des certifications. D'abord chez scrum.org avec les niveaux supérieurs de PSM (2 et 3), puis PSPO (1, 2 et 3)... elle passe son temps libre sur le site et dans les préparations.
Aprés quelques mois, elle est fière d'aborer ses médailles sur Linked In (où elle a même passé la certif agile).
Maintenant elle réfléchie à se lancer dans les certifications SAFe...
Posons nous un moment quand même...
Eva a clairement un problème d'addiction à la dopamine (comme les ados!), et elle délaisse aussi, malheureusement une partie de son job.
A force d'être dans les théories des certifications, elle en oublie d'acquérir de l'expérience avec son équipe qui commence à se débrouiller seule (plus ou moins bien) sur beaucoup d'aspects du rôle de scrum master.
De plus, elle perd un peu en flexibilité : tout ce qui n'entre pas dans ce qu'elle a appris ne devrait pas être dans le paysage de LudiGames.
Au bout de quelques temps, tout de même, Eva calme un peu ses ardeurs au niveau des certifications... c'est vrai, aprés tout ca coûte cher (à la fois en temps et en argent)!
Eva reprend un peu le dessus sur son addiction et se rapproche un peu plus du terrain.
Quelle est la prochaine étape?
#Eva tente de ramener l'équipe dans le droit chemin de Scrum! Mais les résultats ne sont pas tout à fait à la hauteur des promesses, pourtant Eva à tout fait comme le guide le dit! [[7 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva se rend compte que son équipe a pris en autonomie. Comme elle a besoin de dopamine (on se soigne pas en une nuit), elle décide de les aider en produisant avec eux. Mais elle est vite rattrapée par la notion de [[7 - Production VS Servant Leadership - LudiGames]]
#Le plus gros soucis actuel de l'équipe c'est la gestion du run... Et Eva a bien regardé ses différentes notes, elle ne trouve pas de solution miracle! [[7 - Gérer le run en Scrum - LudiGames]]
#Eva va se remettre de son addiction et comme elle a plein de nouvelles certifications elle va daire autre chose que Scrum Master. [[7 - Fast Track Scrum Master - Eva]]
Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[8 - Le principe de l'amélioration continue face au chaos - RDB]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à DoctoChat mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[8 - La démarche produit - RDB]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[8 - James micro-entrepreneur]]Avec Internet maintenant, on trouve tout ce qu'il faut pour avancer sur les chemins de la démarche agile non?
Des forums d'experts prêts à s'entraider, aux sites de vente déguisés qui proposent une partie de solution à des problèmes précis et où il faut payer pour avoir l'avis d'un expert, il existe tout un tas de modèles possibles et imaginables.
Eva continue à vouloir avancer sans passer par une formation ou par l'intervention d'un expert externe.
Du fait, elle se renseigne, visionne l'intégralité de la vidéothèque ScrumLife, lit tous les articles sur coach-agile.com et relis le slack "les agilistes" en profondeur.
Bien sur, elle n'en néglige pas pour autant son équipe et commence à appliquer les pratiques Scrum tel qu'elle les a comprise, ainsi, planification, daily, revue et rétrospective ont fait leur apparition chez LudiGames.
Quelle sera l'étape suivante de l'exploration d'Eva?
#[[5 - Eva tente d'appliquer l'intégralité de Scrum chez LudiGames]]
#Au travers des différents articles qu'elle a pu lire, elle se passionne pour les échanges en ligne. [[5 - Eva découvre les communautés en ligne]]
#Le virtuel c'est bien, mais Eva préfère le contact réela avec les gens. [[5 - Eva découvre les meetups et Nord Agile]]Eva a exploré le guide Scrum de fond en comble.
Mais certaines choses ne semblent pas coller avec l'esprit start-up qui caractérise LudiGames.
En effet, la notion même de backlog produit ne fonctionne pas pour son équipe qui gère différents outils en ligne en fonction des retours clients. Impossible pour eux de vraiment se projetter à plus de 2 semaines.
De plus, chez LudiGames c'est expérience utilisateur first, donc toute chose rencontré en ligne par un utilisateur doit prendre le pas sur le reste.
Pour finir, personne ne porte réellement le rôle de PO. En effet, tous le monde est responsable de faire de LudiGames un aventure couronnée de succès, et donc chacun peut et doit porter la vision de l'entreprise et des ses produits d'animation en ligne.
Aprés s'être bien pris la tête, Eva décide qu'il est temps de prendre un peu de recul. Elle essaye donc de prendre de la hauteur tout en continuant à se documenter via les différents moyens qu'elle a rencontré en ligne.
Quelle est la prochaine étape pour Eva?
#Eva se rend compte qu'elle s'est lancée à corps perdu dans une solution plutôt que d'envisager le problème global. Elle retourne aux bases et découvre le mouvement Agnostic Agile. Elle décide donc d'être agile plutot que de faire du SCRUM! [[5 - Agnostic Agile - L'agilité LudiGames]]
#A force de creuser, Eva fini par se dire que Scrum est un carcant que LudiGames n'est pas prêt à accepter, elle propose alors à son équipe d'explorer le Kanban. [[5 - Kanban LudiGames]]
#Eva cherche comment avoir de l'inspiration sur ce sujet. Toute seule elle se sent au bout de ses connaissances. Elle décide de participer à un événement agile, histoire de récupérer des idées ailleurs. [[5 - Eva participe à son premier Forum Ouvert]]Scrum Life, Coach Agile, Les agilistes...
Que de communautés en ligne!! En plus, avec l'avénement du télétravail et des conférences en ligne, elle réussi à participer à de grands événements sans se déplacer!!
Eva se sent bien accompagnée. Elle a pu se faire un petit réseau de connaissances en ligne et réussi à trouver de l'aide lorsqu'elle en a besoin.
Cependant, aprés quelques temps Eva commence à rencontrer des difficultés avec son équipe et ne sait plus trop où chercher de l'aide. Elle a tout essayé, mais rien n'y fait, soit l'engagement de l'équipe n'est pas tenu, soit ces membres ne sont pas aussi engagés qu'Eva le souhaiterait sur la tenue de l'engagement ou la levée de freins.
Où allons-nous emmener Eva ensuite?
#Eva devrait essayer de trouver du support plus local. Pour se faire, pourquoi ne pas aller à son premier Agi'Lille? [[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#Il faut absolument qu'Eva se focalise sur les problèmes d'engagement! [[6 - Des problèmes d'engagement chez LudiGames]]
#Eva devrait se concentrer sur l'équipe et sa capacité à produire de la valeur via la technique. Elle explore [[6 - Accelerate chez LudiGames]] Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu'[[6 - On ne devient pas coach tout seul chez LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[6 - Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[6 - Eva participe à son premier Agi'Lille - LudiGames]]
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), James se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Mais il se rend compte aussi que, malgré la présence de plusieurs testeurs officiels chez les Rois du Ballon, la phase de QA reste le goulot d'étranglement du process!
James décide d'investiguer ce qui se fait sur le marché, quelle décision va-t-il prendre?
#James décide d'explorer le monde de l'assurance qualité et obtenir la prise en charge d'une [[5 - Formation ISTQB]] par les Rois du Ballon.
#James se documente et découvre [[5 - Les 3 amigos]] qu'il décide de mettre en pratique tout de suite.
#James parle à un vieux de la vieille chez les Rois du Ballon et tous les deux ils évoquent la possibilité de mettre en place [[5 - Un déversement de backlog - RDB]]
Quand on regarde la manière dont LudiGames gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#Eva propose au Scrum Master de suivre une formation ISTQB. [[8 - Formation ISTQB SM - LudiGames]]
#Eva propose la mise en place des 3 amigos [[8 - Les 3 amigos - LudiGames]]
#Le Scrum Master propose la mise en place d’[[8 - Un déversement de backlog - LudiGames]]Eva a une jolie expérience avec son équipe LudiGames. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, Eva veut trouver des missions interessantes, cependant, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'elle voit passer dans les offres auxquelles elle a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[7 - Un miroir coach - Eva Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[7 - Une formation certifiante Coach - Eva Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[7 - Eva participe à son premier Agi'Lille entant qu'Indep]]Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
Eva n'est donc pas trés regardante quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'elle devra engagée sont dans ses domaines de compétence.
Elle se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Elle reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, Eva n'hésite pas à partager ses réflexions, ses expériences... Elle est donc active sur les réseaux sociaux, elle crée son propre site internet, et se demande si elle ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : Eva recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'elle recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'elle ne maitrise pas tous ces sujets.
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle va devoir choisir sa prochaine mission. Que trouve-t-elle dans sa bannette (boite mail)?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[7 - Agile dans l'Infra? - Eva]]
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur [[7 - La fresque du climat - Eva Indep]]
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'[[7 - Agile Hors IT - Eva]]
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[7 - Eva se passionne pour le Serious Gaming - Indep]]Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[8 - Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]] Se former au test, quelle drôle d'idée? Pas vraiment pour James.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais James réussi à l'obtenir! Ca va faire bien sur son CV!!
James a hâte de mettre tout ca en pratique. Mais que fait-il une fois cette certification en poche?
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[6 - James participe à son premier Agi'Lille entant que Testeur]]
#James propose de mettre en place [[6 - Les 3 amigos - RDB]]
#James, bien que faisant avancer les tests quand il le peut, ne trouve pas toujours le temps necessaire pour terminer les tests à chaque sprint. Il est confronté à la notion de [[6 - Production VS Servant Leadership - RDB]]
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[6 - Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[6 - Un refinement revisité - RDB]].
#Les 3 amigos on connait! Maintenant, que fait James? [[6 - James participe à son premier Agi'Lille entant que Testeur]]
Le raisonnement de James et Jean-Paul (un vieux de la vieille chez les Rois du Ballon) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez les Rois du Ballon, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[6 - Les 3 amigos - RDB]]
#James et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprés du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais[[6 - Ca peut vraiment être efficace? - RDB]]Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[6 - Des problèmes d'engagement chez LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[6 - Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes.[[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#C'est bien beau tout ca mais ce sont des problématiques de Scrum Master, nous ce qu'on veut c'est voir la suite. [[6 - Fast Track Scrum Master - Eva]]Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[6 - La dette technique et Scrum]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[6 - Accelerate chez LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[6 - DevOps et Ludigames]]
#Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[6 - Developpeurs et IA]]Et oui, produire en Scrum coûte plus cher que de produire sans Scrum. Eva se demande s'il en est de même pour toutes les pratiques liées à la démarche agile.
Elle se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Dans sa recherche de réponses, Eva entend parler d'un événement Lillois autour de la démarche agile. [[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva trouve rapidement une réponse qu'elle souhaite amener à sa direction [[6 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Eva propose découvre d'autres manière d'être agiles que Scrum. Elle lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue LudiGames. [[6 - LudiGames et Shape Up]]
#Forte des retours de sa direction, Eva propose de créer [[6 - Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[7 - Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[7 - Un refinement revisité - RDB]].
#Les 3 amigos on connait! Maintenant, que fait James? [[7 - James participe à son premier Agi'Lille entant que Testeur]]
LudiGames est une bonne boîte. Tout le monde se connait, tout le monde s'apprécie.
Le souci, c'est que tout le monde veut tellement bien faire que personne ne dit jamais non.
Et donc, quand les grands chefs proposent de mettre en place de nouvelles choses, personne n'ose leur dire qu'il y a trop de sujets qui essayent d'avancer en même temps.
Certes, il est assez facile de justifier la création de nouvelles équipes, et les budgets ne manquent que rarement (voir jamais), mais comme le disais Luc S. (un ancien de chez LudiGames): "9 femmes ne ferront pas un bébé en un mois!".
Il est donc temps d'agir!
Que fait Eva?
#Elle organise une réunion avec les grands chefs pour leur parler du [[5 - Trade in - trade out - LudiGames]]
#Elle propose au mangement de LudiGames de rencontrer des experts de la vision d'entreprise [[5 - Les experts de la vision]]
#Elle travaille avec les POs pour mettre en avant la notion de [[5 - Valeur Business LudiGames]]
#Elle parle de la [[5 - Démarche OKR]] dont tous ses amis lui parlent de ces temps-ciNotre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
<!--#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[5 - Sensibilisation agile des PP Ludigames]]-->
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[5 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[5 - Eva organise un séminaire produit - LudiGames]] pour LudiGamesQuel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[7 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[7 - Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[7 - Syndrôme de l'imposteur - LudiGames]]
#Aprés l'atelier auquel elle a participé, [[7 - Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[7 - Eva se lance dans l'écriture d'une conférence - LudiGames]]En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, elle décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais elle se dit que si elle doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[9 - Le Kanban ca marche, mais ca prend du temps! - Eva]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à LudiGames d'entrer dans les cases. Eva propose alors de créer [[9 - Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[9 - LudiGames et Shape Up]]
#Y'en a marre de la vie de Scrum Master, que fait Eva aprés avoir tout tenté avec son équipe agile? [[9 - Fast Track Scrum Master - Eva]] Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas de LudiGames, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à LudiGames...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler de son équipe. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grans chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[7 - Sensibilisation agile des PP - LudiGames]]
#Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de [[7 - Production VS Servant Leadership - LudiGames]].
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum. [[7 - Eva se passionne pour le No Estimate - LudiGames]]
#On en a marre du SM! Place à la suite ... [[7 - Fast Track Scrum Master - Eva]] Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
Eva se propose d'étudier les points de concordance entre LudiGames et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[8 - Prioriser en tailles de TShirt - LudiGames]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[8 - Le WSJF - LudiGames]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[8 - Le craftsmanship - LudiGames]]
#Eva propose à l'équipe d'explorer le [[8 - Kanban - LudiGames]]James est donc nommé Scrum Master sur 2 équipes en même temps. Les deux équipes travaillent déjà de manière coordonnée car l'une se focalise sur une application de suivi de la production dans l'usine quand l'autre est organisée autour de la pise de mesures tout au long de la chaine de production.
L'application de suivi de prod se nourrit donc des données de la seconde.
James ne s'en sort pas trop mal. Les équipes sont heureuses d'avoir une personne centrale permettant de mettre en avant les interdépendances.
Aprés quelques mois, les équipes tournent bien et le manager de James vient lui proposer de prendre en charge une équipe complémentaire.
Que va faire James?
#Il va tenter d'appliquer les mêmes pratiques et méthodes avec la seconde équipe: si ca a marché pour la première, y'a pas de raison que ca foire pour la seconde quoi que... [[5 - Le Cargo Cult ca pique - RDB]]
#Il se pose quelques jours/semaines pour voir comment l'équipe fonctionne et adapte son accompagnement à cette dernière [[5 - Observation et nouvelle équipe - RDB]]
#L'équipe ne lui laisse pas le choix : ils sont autonomes et n'ont que peu besoin de lui [[5 - Une équipe autonome chez les Rois du Ballon]]DoctoChat est une bonne boîte. Tout le monde se connait, tout le monde s'apprécie.
Le souci, c'est que tout le monde veut tellement bien faire que personne ne dit jamais non.
Et donc, quand les grands chefs proposent de mettre en place de nouvelles choses, personne n'ose leur dire qu'il y a trop de sujets qui essayent d'avancer en même temps.
Certes, il est assez facile de justifier la création de nouvelles équipes, et les budgets ne manquent que rarement (voir jamais), mais comme le disais Luc S. (un ancien de chez LudiGames): "9 femmes ne ferront pas un bébé en un mois!".
Il est donc temps d'agir!
Que fait James?
#Il organise une réunion avec les grands chefs pour leur parler du [[9 - Trade in - trade out - DoctoChat]]
#Il propose au mangement de LudiGames de rencontrer des experts de la vision d'entreprise [[Les experts de la vision - DoctoChat]]
#Il travaille avec les POs pour mettre en avant la notion de [[9 - Valeur Business - DoctoChat]]
#Il parle de la [[Démarche OKR - DoctoChat]] dont tous ses amis lui rabachent les oreilles de ces temps-ciLe manager de James lui propose un rendez-vous pour faire un petit état des lieux.
Il en ressort qu'au travers de ces différentes tâches et missions, James a peu de temps pour s'occuper réellement de faire de la veille ou de simplement prendre du recul sur les situations rencontrées. Aprés tout, l'expérience agile de James s'est entièrement construite chez les Rois du Ballon.
Entre hésitation, non dits... ils finissent par tombre d'accord sur une manière d'accompagner James au mieux.
Quelle décision prennent-ils?
#James doit impérativement faire de la veille de son coté, pour ce faire, les Rois du Ballons sont OK pour lui payer sa [[9 - James participe à son premier Agi'Lille - DoctoChat]]
#James doit faire de la veille mais de son côté, il découvre alors les [[9 - Meetups de la communauté Lilloise - DoctoChat]]
#James prend la mouche et il devient freelance [[James micro-entrepreneur]] James propose au PO un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[9 - James devient PPO chez DoctoChat]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[9 - Product Box - DoctoChat]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[Se former aux démarches produits - DoctoChat]].
James prend ses billets pour assister à l'Agi'Lille. Il regarde le programme en amont et se fait un petit parcours pour explorer l'événement.
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[8 - James rejoint Nord Agile - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - RDB]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! James n'est pas déçue!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadée qu'[[8 - On ne devient pas coach tout seul chez RDB]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[8 - James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - RDB]]
Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[9 - Gamifier une rétrospective - RDB]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[9 - Kanbanzine - RDB]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[9 - Scrumble - RDB]]
#Il se dit qu'il doit acquerir plus d'expérience et [[9 - James découvre les meetups et Nord Agile - RDB]]Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[6 - Kanbanzine - Eva]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[6 - Une formation avec Laurent Morisseau]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[6 - Le Kanban ca marche, mais ca prend du temps! - LudiGames]].En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, elle décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais elle se dit que si elle doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[7 - Le Kanban ca marche, mais ca prend du temps!]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à LudiGames d'entrer dans les cases. Eva propose alors de créer [[7 - Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[7 - LudiGames et Shape Up]]
#Y'en a marre de la vie de Scrum Master, que fait Eva aprés avoir tout tenté avec son équipe agile? [[7 - Fast Track Scrum Master - Eva]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[7 - Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[7 - La démarche produit - LudiGames]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après [[7 - Fast Track Scrum Master - Eva]] Eva et son équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[7 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[7 - La démarche produit - LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[7 - Des noms de rôles chez LudiGames]]Eva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre plusieurs manières de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ca n'est pas facile mais c'est finalement validé [[6 - Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[6 - Une formation agile - Eva]]
#Eva aimerait pouvoir accompagner LudiGames sur une voie qui ne soit pas forcément formatée par un framewok. Elle se renseigne sur le mouvement [[6 - Agnostic Agile - L'agilité LudiGames]] lorsqu'un de ces contacts lui dit qu'elle doit pouvoir s'y reconnaitre.
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[6 - Eva participe à son premier Agi'Lille - LudiGames]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Le sujet de son premier meetup : "Les focus groups au service de la démarche produit".
Un grand sujet. Eva échange avec des personnes de tous horizons: des professionels du marketting au manageur d'équipe qui essaye de redonner du sens au fonctionnement de celle-ci.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#Pour une démarche produit cohérente, il faut que l'intégralité de LudiGames se mette en ordre de marche. Elle propose de mettre en place [[6 - Un comité de transformation chez LudiGames]]
#LudiGames ne peut pas rentrer dans un moule existant, en plus, du point de vue d'Eva, ca irait à l'encontre de la démarche agile. Elle propose donc de mettre en place [[6 - Une méthode maison pour LudiGames]]
#Eva a tellement apprécié cette rencontre qu'elle décide de voir ce qui se fait chez Nord-Agile. [[6 - Eva rejoint Nord Agile - LudiGames]] Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[6 - Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[6 - Faire vivre les actions aprés un séminaire]]!
#La conclusion de leur séminaire est qu'il leur faut [[6 - Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management de LudiGames demande à Eva de justifier les investissements passés et futurs : [[6 - L'agile ca coûte cher!]]C'est bien beau d'avoir mis en place une démarche qui permet d'être au plus prêt des retours utilisateurs, de faciliter les changements de cap en fonction de ces derniers, et d'accepter de ne pas partir avec une feuille de route figée à J1.
Cependant, quand le management entend : "Avec la démarche agile, le changement c'est tout le temps !" l'équipe perd un peu les pédales.
Eva tente d'expliquer le fonctionnement d'un backlog à son management, le fait qu'on peut changer de cap dans les limites de la vision produit... mais le plus dur à comprendre pour eux semble être le trade in / trade out.
Cette pratique qui permet de garantir un engagement cohérent de l'équipe quant à la tenue des objectifs de livraison court et moyen terme.
Elle l'aborde un peu dans ces mots :
"Le fort d'une équipe agile c'est de pouvoir travailler avec des moyens finis. Si vous voulez forcément sortir une version d'un produit à une date précise, l'équipe doit être en mesure de vous dire ce qui peut ou ne peut pas rentrer dans ce délai. De fait, lorsqu'un nouveau besoin apparait et que vous souhaitez forcément le faire sortir avec la version planifiée, il faudra faire un choix : pour une quantité (estimée) d'effort à fournir pour ce nouveau besoin, il faudra enlever une quantité équivalente d'effort du backlog".
Aprés plusieurs aller-retours, le management semble avoir compris.
Que se passe-t-il ensuite?
#Un des managers a tout compris! L'équipe ayant une capacité limitée à fournir de l'effort à chaque version de leur plateforme, il propose de moduler la taille de l'équipe en fonction de la taille de la version! [[6 - 9 femmes... - LudiGames]]
#C'est bien beau de parler de capacité de l'équipe à produire, mais on avait vendu Scrum au management comme étant un cadre permettant de favoriser l'atteinte de ROI le plus vite possible. Eva se propose de leur expliquer un concept de plus [[6 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Le management ne comprend pas, du fait, d'où viennent les dérives sur le projet. [[6 - Des problèmes d'engagement chez LudiGames]]
#Il aura fallu déployer beaucoup d'effort mais au final ils payent. Le fonctionnement de l'équipe s'assainit, la valeur produite est au rendez-vous [[6 - Scrum ca marche pour LudiGames]] Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[6 - Eva pilote de vision LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[6 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Le projet vision se lance. Eva fait partie des groupes de travail et influence ce projet avec sa vision agile de la partie delivery. Aprés plusieurs rencontres de ces groupes de travail, et une première version de la vision de LudiGames, on propose à Eva de s'occuper de [[6 - La démarche produit chez LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[6 - Eva micro-entrepreneuse]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[6 - Prioriser en tailles de TShirt]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[6 - Le WSJF chez LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[6 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Oublions un peu l'expérience Scrum Master, passons à la suite [[6 - Fast Track Scrum Master - Eva]] Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[6 - Et toi, en quoi tu contribue aux OKRs?]]
#Le management comprend les OKR, le président de LudiGames a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explirer le Kanban. [[6 - LudiGames et Kanban]]
#Lançez-vous, a dit le président au manager d'Eva. Il est convenu que l'équipe va servir de pilote. Eva se lance donc et s'interroge sur [[6 - La ritualisation du suivi des OKR]]
#OKR check, Scrum check... et aprés? [[6 - Fast Track Scrum Master - Eva]] Un premier événement agile c'est toujours une expérience!! Surtout quand il s'agit d'un forum ouvert.
Ce type de rencontre agile est interessant :
* les participants ne savent pas à l'avance le contenu de l'événement.
* l'organisation est libre
* ce qu'il se passe dans le forum est ce qu'il doit se passer
* au sortir de l'événement, les agilistes sont généralement ravi de ce qui se passe.
Eva n'est en effet pas décue. Au début, elle s'est sentie un peu perdue dans cet événement non organisé. Elle ne savait pas par où commencer. Puis, grace à la facilitation de quelques participants des éditions précédentes et à l'esprit agile des participants, les sujets passionnants se développent.
Eva participe à plusieurs échanges. Pour commencer, un coach expérimenté propose de refléchir à la suite de l'agilité, ensuite une autre personne se demande si on peut être agile sans Scrum Master et PO, puis elle teste un outil créé par un groupe de collègues autour de la gestion de la dette technique.
Durant ce rendez-vous agile, Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#En discutant avec plusieurs participants, Eva a découvert le mouvement Agnostic Agile et se demande si elle ne peut pas s'en inspirer avec son équipe [[6 - Agnostic Agile - L'agilité LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[6 - Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#La vie de Scrum Master c'est bien mais on voudrait vir ce qu'il y a aprés [[6 - Fast Track Scrum Master - Eva]] L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[5 - James micro-entrepreneur]]
#James se met en visibilité sur son réseau d'entreprise préféré. [[James Quitte les rois du Ballon]]
#James explore ce qu'il se passe chez les Rois du Ballon et se rend compte des limitations de son poste actuel. [[5 - ScrumMaster c'est bien, mais limité]]Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[6 - On ne devient pas coach tout seul - James Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[6 - Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[6 - Indep c'est bien, tout seul ca craint!! - James]]
Chez les Rois du Ballon, le rôle de Scrum Master est bien défini, avec ses responsabilités, ses zones d'influence mais aussi ses limites et ses interdits.
De plus, l'organisation actuelle des Rois du Ballon fait que James n'a pas accés, entant que Scrum Master, aux différentes personnes d'influence de l'entreprise.
Que faire dans ce cas là?
#James pourrait se pencher sur l'aspect produit en lien avec ses équipes. C'est vrai qu'il s'est beaucoup concentré sur l'efficacité opérationnelle de l'équipe mais il pourrait peut-être atteindre d'autres personnes au travers du PO et pourquoi pas, acquérir de nouvelles expériences. [[6 - Accompagner le PO]]
#Chez les Rois du Ballon c'est mort, ca sert à rien d'essayer de faire bouger les choses de l'intérieur, sans aide. Mais est-ce le cas ailleurs? James décide d'aller à la rencontre de la communauté agile Lilloise. [[6 - James participe à son premier Agi'Lille - RDB]]
#Il va se battre! James décide d'aborder le sujet avec son manager. Celui-ci lui propose de monter un dossier pour expliquer son point de vue. [[6 - James devient coach agile chez les Rois du Ballon]]James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[7 - Un miroir coach - James Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[7 - Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[7 - James participe à son premier Agi'Lille entant qu'Indep]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" James se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engagé sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[7 - Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[7 - La fresque du climat - James Indep]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[7 - Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[7 - James se passionne pour le Serious Gaming - Indep]]
James s'est lancé. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant que James est établie entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[7 - James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[7 - James organise un séminaire produit Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[7 - James participe à son premier Agi'Lille pour un client]]
Le manager d'Eva lui propose un rendez-vous pour faire un petit état des lieux.
Eva déploie énormément d'efforts à tenter de faire évoluer son équipe et ses parties prenantes mais sans gros succès. Comment faire pour maximiser son retour sur investissement?
Quelle décision prennent-ils?
#Eva doit impérativement faire de la veille de son coté, pour ce faire, LudiGames est OK pour lui payer sa participation à l'Agi'Lille [[8 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva doit faire de la veille mais de son côté, elle découvre alors les [[Meetups de la communauté Lilloise - LudiGames]]
#LudiGames décide de faire intervenir une personne plus expérimentée pour accompagner Eva [[8 - Un coach agile chez LudiGames]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - Eva découvre le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelque chose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[9 - Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - LudiGames]]
#Après l'atelier auquel elle a participé, [[9 - Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]]LudiGames décide donc de faire appel à un coach agile plus expérimenté que'Eva.
Esprit StartUp oblige, eva est incluse dans les entretiens de sélection de la personne qui va l'accompagner. Elle donne son avis sur les différentes personnes et aprés quelques jours, elle recontacte James Huyvre pour qu'il les accompagne
James arrive quelques jours aprés. Il rencontre Eva et lui expose ce qu'il se propose de mettre en place.
Quelle option James propose-t-il à Eva?
#James a l'habitude de ne pas faire de fausse promesse, d'adapter son accompagnement aux besoins de l'organisation qu'elle accompagne. Pour se faire, il doit passer du temps dans [[9 - Une phase d'observation - LudiGames]] afin de faire des suggestions cohérentes.
#James va accompagner Eva dans son évolution jusqu'à ce qu'elle ne soit plus une scrum master débutante. [[9 - Fast Track Scrum Master - Eva]] L'observation se passe bien. James rencontre l'équipe d'Eva, le management, les parties prenantes... sans Eva.
Il lui a bien sûr expliqué pourquoi il voulait le faire sans elle : "Les personnes que je vais rencontrer doivent pouvoir dire tout ce qu'elles pensent sur la démarche appliquée sans essayer d'aller dans le sens d'Eva si elle est dans la pièce".
Que se passe-t-il ensuite?
#James conclue que la plus grande problématique n'est pas liée à l'aspect opérationnel agile de l'équipe, mais de la gestion de la vision produit par LudiGames. Il propose à Eva de mettre en place [[Une vraie démarche produit chez LudiGames]]
#James motive Eva à proposer la mise en place d’un [[Un comité de transformation - LudiGames]]
#James accompagne Eva dans son évolution, maintenant qu'elle n'est plus Scrum Master débutante, elle se lance en Indep. [[Eva micro-entrepreneuse]] Pour Eva, son équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une[[7 - Sensibilisation agile des PP - LudiGames]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes de LudiGames (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ca, [[7 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Déjà 5 étapes de la vie d'une Scrum Master, et si on regardait plus loin?[[7 - Fast Track Scrum Master - Eva]] La vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans grosse difficulté.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[7 - Eva micro-entrepreneuse]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investire dans un rôle de coach. [[7 - Eva devient coach agile chez LudiGames]]
Tout le monde en parle, et les agilistes expérimentés autour d'Eva n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale d'Eva?
#Une chose est certaine pour Eva : elle veut être coach agile. Et donc elle n'acceptera que des missions de cet ordre. [[8 - On ne devient pas coach tout seul - Eva Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Elle décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[8 - Engranger des missions - Eva]]
#Au bout de quelques temps Eva commence à subir les effets secondaires du lancement en indépendant. Elle a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[8 - Indep c'est bien, toute seule ca craint!!]]Eva semble tout indiquée pour accompagner LudiGames sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules d'Eva.
La première chose à laquelle Eva doit s'atteler c'est de trouver un nouveau Scrum Master pour la remplacer. Puis, elle devra accompagner la création d'une nouvelle équipe agile. Elle devra également trouver comment accompagner LudiGames plus en amont dans sa démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec Eva?
#Eva doit décider comment trouver quelqu'un pour la remplacer au mieux auprés de son équipe. Elle se pose énormément de questions quant à la démarche à proposer [[6 - Un Scrum Master pour remplacer Eva]]
#Eva va devoir accompagner la nouvelle équipe formée. Elle a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[6 - Créer une nouvelle équipe Scrum]]
#Eva ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[6 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva décide de se lancer dans la description de la démarche agile selon LudiGames afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[6 - Une méthode maison pour LudiGames - Coach]] Eva semble tout indiquée pour accompagner LudiGames sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules d'Eva.
La première chose à laquelle Eva doit s'atteler c'est de trouver un nouveau Scrum Master pour la remplacer. Puis, elle devra accompagner la création d'une nouvelle équipe agile. Elle devra également trouver comment accompagner LudiGames plus en amont dans sa démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec Eva?
#Eva doit décider comment trouver quelqu'un pour la remplacer au mieux auprés de son équipe. Elle se pose énormément de questions quant à la démarche à proposer [[8 - Un Scrum Master pour remplacer Eva]]
#Eva va devoir accompagner la nouvelle équipe formée. Elle a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[8 - Créer une nouvelle équipe Scrum - LudiGames]]
#Eva ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[8 - Eva participe à son premier Agi'Lille]]
#Eva décide de se lancer dans la description de la démarche agile selon LudiGames afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. Elle se renseigne alors sur la tendance Agnostic Agile. [[8 - Coach et Agnostic - LudiGames]]
Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva se rend compte qu'elle s'inscrit complètement dans ce mouvement.
Elle propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de son client et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[7 - LudiGames et Kanban]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[7 - LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[7 - Une méthode maison pour LudiGames]]
#Eva, se rendant compte de ce qu'elle vaut, se dit que partir sur un rôle de coach pourrait être sa prochaine évolution professionnelle! Cependant [[7 - On ne devient pas coach tout seul chez LudiGames]]
Eva lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[7 - La dette technique et Scrum - LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[7 - DevOps - LudiGames]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d'accelration il faut avant tout que LudiGames travaille à sa démarche produit. [[7 - Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[7 - Une présentation de la démarche agile à l'équipe - LudiGames]]
Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[7 - Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[7 - Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[7 - Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
#Bon, assez de Scrum Mastering, elle fait quoi ensuite Eva? [[7 - Fast Track Scrum Master - Eva]] James semble tout indiquée pour accompagner les Rois du Ballon sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Rois du Ballon.
Au bout de 9 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Rois du Ballon!
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Rois du Ballon plus en amont dans leur démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[Un Scrum Master pour remplacer James - RDB]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[7 - Créer une nouvelle équipe Scrum - James]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[7 - James participe à son premier Agi'Lille - RDB Coach]]
#James décide de se lancer dans la description de la démarche agile selon les Rois du Ballon afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[7 - Une méthode maison pour RDB - Coach]] Eva a une jolie expérience avec son équipe LudiGames. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, Eva veut trouver des missions interessantes, cependant, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'elle voit passer dans les offres auxquelles elle a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[9 - Un miroir coach - Eva Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[9 - Une formation certifiante Coach - Eva Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[9 - Eva participe à son premier Agi'Lille entant qu'Indep]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
Eva n'est donc pas très regardante quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'elle devra engagée sont dans ses domaines de compétence.
Elle se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Elle reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, Eva n'hésite pas à partager ses réflexions, ses expériences... Elle est donc active sur les réseaux sociaux, elle crée son propre site internet, et se demande si elle ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : Eva reçoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'elle reçoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'elle ne maitrise pas tous ces sujets.
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle va devoir choisir sa prochaine mission. Que trouve-t-elle dans sa bannette (boite mail)?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - Eva]]
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur [[9 - La fresque du climat - Eva Indep]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l’accompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'[[9 - Agile Hors IT - Eva]]
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[9 - Eva se passionne pour le Serious Gaming - Indep]]Eva s'est lancée. Elle savait qu'être indépendante lui demanderait de faire des sacrifices. Mais elle n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, elle comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Elle décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, elle en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel elle n'avait pas non plus pensé, réside dans le fait qu'elle rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, Eva réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et notament [[9 - Eva découvre les meetups et Nord Agile entant qu'Indep]]
#C'est bien beau de devoir gérer sa montée en compétences toute seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient la voir avec un challenge d'organisation d'événement interne à grande échelle, Eva doit explorer de nouveaux domaines. [[9 - Eva organise un séminaire produit Indep]]
#Un des clients d'Eva est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[9 - Eva participe à son premier Agi'Lille pour un client]]
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Mais pas tant de sujets testing que ca. On parle qualité logiciel mais plus du côté des développeurs. Il a cependant entendu parler d'une pratique : les 3 amigos, qu'il compte bien mettre à profit à son retour chez les Rois du Ballon
Au sortir de l'événement, James peut prendre plusieurs directions :
#James va mettre en place les [[7 - Les 3 amigos - RDB]]
#James se renseigne sur le [[7 - Le craftsmanship - RDB]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[7 - James se lance dans l'écriture d'une conférence - RDB]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[7 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[7 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[7 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[7 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[7 - James se lance dans l'écriture d'une conférence - RDB]]
James met du temps à comprendre ce qui arrive à sa nouvelle équipe.
James tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'il est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il décide de revoir sa copie. Quelle est la prochaine étape?
#[[7 - Vertes Prairies remet en question la capacité de James à avancer seul]]
#James se rend compte qu'il faut absolument [[7 - Accompagner le PO - VP]]
#James entend parler de la communauté agile Lilloise et décide de participer à son premier Agi'Lille. [[7 - James participe à son premier Agi'Lille - VP]] L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[7 - James micro-entrepreneur]]
#James explore ce qu'il se passe chez Vertes Prairies et se rend compte des limitations de son poste actuel. [[7 - ScrumMaster c'est bien, mais limité - VP]]
#Les réussites de James l'amènent à monter à un niveau supérieur d'abstraction [[7 - James devient coach agile chez VP]]
#La transformation de Vertes Prairies ne fait que commencer, James s'attaque maintenant à la [[7 - Démarche produit chez Vertes Prairies]]Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[8 - On ne devient pas coach tout seul - James Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[8 - Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[8 - Indep c'est bien, tout seul ca craint!! - James]]
Chez les Vertes Prairies, le rôle de Scrum Master est maintenant bien défini, avec ses responsabilités, ses zones d'influence mais aussi ses limites et ses interdits.
De plus, l'organisation actuelle des Vertes Prairies fait que James n'a pas accés, entant que Scrum Master, aux différentes personnes d'influence de l'entreprise.
Que faire dans ce cas là?
#James pourrait se pencher sur l'aspect produit en lien avec ses équipes. C'est vrai qu'il s'est beaucoup concentré sur l'efficacité opérationnelle de l'équipe mais il pourrait peut-être atteindre d'autres personnes au travers du PO et pourquoi pas, acquérir de nouvelles expériences. [[8 - Accompagner le PO - VP]]
#Chez les Vertes Prairies c'est mort, ca sert à rien d'essayer de faire bouger les choses de l'intérieur, sans aide. Mais est-ce le cas ailleurs? James décide d'aller à la rencontre de la communauté agile Lilloise. [[8 - James participe à son premier Agi'Lille - VP]]
#Il va se battre! James décide d'aborder le sujet avec son manager. Celui-ci lui propose de monter un dossier pour expliquer son point de vue. [[8 - James devient coach agile chez VP]]James semble tout indiquée pour accompagner les Vertes Prairies sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Vertes Prairies.
Au bout de 3 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Vertes Prairies.
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Vertes Prairies plus en amont dans leur démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[8 - Un Scrum Master pour remplacer James - VP]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[8 - Créer une nouvelle équipe Scrum - VP]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[8 - James participe à son premier Agi'Lille - VP]]
#James décide de se lancer dans la description de la démarche agile selon les Vertes Prairies du Ballon afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[8 - Une méthode maison pour VP - Coach]] Notre start-up, Vertes Prairies, a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#James propose d'évangéliser toutes les parties prenantes à la démarche agile [[8 - Sensibilisation agile des PP - VP]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[8 - James organise un séminaire produit - VP]]
#Pour James, rien de tel que d'aller à la rencontre de la communauté pour savoir se qui est disponible sur ce sujet. [[8 - James participe à son premier Agi'Lille - VP]] Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA. [[Scrum Master et QA - VP]]
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement. [[7 - La Rache chez VP]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[7 - Valeur Business VP]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[7 - La dette technique et Scrum - VP]] <img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[7 - Un comité de transformation chez LudiGames]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[7 - Faire vivre les actions aprés un séminaire - LudiGames]]
#Demander à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[7 - Se former aux démarches produits - LudiGames]]
#S'enfermer chez elle et se prendre un méga [[7 - Syndrôme de l'imposteur - LudiGames]]Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[7 - Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[7 - Démarche OKR - LudiGames]].
#Personne, durant l'atelier, n'a été capable de définir ce qu'est la valeur business des différentes solutions. Avant d'avancer dans la démarche produit, ils décident de travailler à la [[7 - Valeur Business - LudiGames]]
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[7 - Eva devient coach agile chez LudiGames]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Elle se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Dans sa recherche de réponses, Eva entend parler d'un événement Lillois autour de la démarche agile. [[7 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva trouve rapidement une réponse qu'elle souhaite amener à sa direction [[7 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Eva propose découvre d'autres manière d'être agiles que Scrum. Elle lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue LudiGames. [[7 - LudiGames et Shape Up]]
#Forte des retours de sa direction, Eva propose de créer [[7 - Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[7 - Eva continue avec son équipe Scrum]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[7 - Valeur Business - LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[7 - Les experts de la vision - LudiGames]]
Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
Eva se veut rassurante. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
#Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe. [[7 - Gérer le run en Scrum - LudiGames]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[7 - Valeur Business - LudiGames]]
#Arrêtons de nous prendre la tête sur les développeurs, voyons ce que fera Eva aprés Scrum Master. [[7 - Fast Track Scrum Master - Eva]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[7 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[7 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[7 - Prouver l'impact de la dette technique - LudiGames]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[7 - Fast Track Scrum Master - Eva]] Qu'il est beau ce dicton! C'est un des préférés d'Eva.
9 femmes ne feront pas un bébé en 1 mois... y'a-t-il quelquechose de plus immuable?
Eva essaye de faire passer le message au management :
* Une équipe Scrum utilise l'empirisme, et notamment l'inspection et l'adaptation pour pouvoir se projeter et s'améliorer en continue. Si on change la taille de l'équipe, les données récoltées en inspection ne correspondrons pas à l'équipe qui mettre en place les adaptations validées.
* Il en est de même pour la taille du sprint.
* De plus, une équipe agile est une machine bien huilée. Chaque individu sait ce qu'il a à faire, quand il doit le faire... Augmenter la taille d'une équipe implique généralement une perte d'efficacité temporaire pour l'équipe. En effet, pour aider le ou les nouveaux arrivants à monter en compétence (et capacité) sur le produit, les anciens de l'équipe délaissent une partie de leur engagement. C'est ainsi que l'équipe réduit le temps de montée en compétence mais l'impact sur le (ou les) premier(s) sprint(s) aprés l'ajout est toujours visible.
* La taille de l'équipe est généralement optimisée par rapport au backlog produit, aux priorités du PO et à la taille des user stories (et leurs interdépendances). Ajouter une nouvelle personne dans une équipe n'est jamais anodin et peut trés bien avoir un effet négatif sur la performance sur le moyen terme. Il faudra du temps pour ré-équilibrer les forces.
Eva réussi à convaincre le manager en question.
Quelle est sa prochaine action?
#En discutant avec le manager, ils tombent d'accord sur le fait que la gestion du run doit maintenant faire partie des priorités de l'équipe. Mais comment [[7 - Gérer le run en Scrum - LudiGames]] ?
#Eva propose une [[7 - Sensibilisation agile des PP - LudiGames]], afin de travailler aux incompréhensions mutuelles.
#Le fait est que sur le long terme il faudra augmenter la capacité de LudiGames à créer de la valeur. Le manager demande à Eva de lui faire une proposition pour [[7 - Créer une nouvelle équipe Scrum - LudiGames]].
#Le manager comprend mais il reste frustré. Il a l'impression que l'équipe ne se concentre pas assez sur les sujets qui lui importent à lui. Eva propose d'explorer[[7 - Le WSJF chez LudiGames]] avec le PO.Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier LudiGames.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein de LudiGames qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à Eva de porter cette vision au sein de l'entreprise. La partie visibilité de LudiGames vers l'extérieur sera traitée dans un second temps.
Comment réagit Eva à cette proposition?
#Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet. [[7 - De vision à action - LudiGames]]
#Le projet vision sera un succès, on a pas de doute là dessus, aprés tout VisionMaster sont les experts de la vision. Voyons plutôt comment se débrouille Eva avec son équipe. [[7 - Eva continue avec son équipe Scrum]]Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[7 - Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[7 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[7 - Eva organise un séminaire produit]] pour LudiGamesEva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre 4 manières principales de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ca n'est pas facile mais c'est finalement validé [[8 - Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[8 - Une formation agile - Eva]]
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[8 - Eva participe à son premier Agi'Lille]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Le sujet de son premier meetup : "Les focus groups au service de la démarche produit".
Un grand sujet. Eva échange avec des personnes de tous horizons: des professionels du marketting au manageur d'équipe qui essaye de redonner du sens au fonctionnement de celle-ci.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#Pour une démarche produit cohérente, il faut que l'intégralité de LudiGames se mette en ordre de marche. Elle propose de mettre en place [[8 - Un comité de transformation - LudiGames]]
#LudiGames ne peut pas rentrer dans un moule existant, en plus, du point de vue d'Eva, ca irait à l'encontre de la démarche agile. Elle propose donc de mettre en place [[8 - Une méthode maison pour LudiGames]]
#Eva s'est prise une claque. Que de choses à savoir, que de personnes expérimentées. Pour elle c'est sur : elle n'est pas là où il faut. Eva nous fait un gros [[8 - Syndrôme de l'imposteur - LudiGames]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[8 - Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[8 - Faire vivre les actions aprés un séminaire]]!
#La conclusion de leur séminaire est qu'il leur faut [[8 - Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le managment de LudiGames demande à Eva de justifier les investissements passés et futurs : [[8 - L'agile ca coûte cher! - Ludigames]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[9 - Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[9 - Valeur Business - LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[9 - Les experts de la vision - LudiGames]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner LudiGames correctement et l'aider à traverser ses challenges.
Eva a une équipe motivée, constituée de LudiGamers de la première heure. Ils connaissent le contexte, le produit et les utilisateurs. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.[[9 - Scrum Master et QA Chez LudiGames]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[9 - La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[9 - Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[9 - La dette technique et Scrum - LudiGames]] <img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[9 - Un comité de transformation chez LudiGames]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[9 - Faire vivre les actions aprés un séminaire - LudiGames]]
#Demander à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[9 - Se former aux démarches produits - LudiGames]]
#S'enfermer chez elle et se prendre un méga [[9 - Syndrôme de l'imposteur - LudiGames]]Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[9 - Les experts de la vision]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[9 - Démarche OKR - LudiGames]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[9 - Eva devient coach agile chez LudiGames]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[9 - LudiGames et Shape Up]]
#Forte des retours, Eva propose de créer [[9 - Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Eva entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu )à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, Eva a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
Eva retourne à son bureau avec quelques questions. Elle se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Elle tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Elle entend le terme antipatern.... Ca l'inquiète.
Elle se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour Eva.
Forte de ces arguments elle en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'elle fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée. On lui propose prendre plus de hauteur par rapport à son rôle de Scrum Master [[7 - Eva devient coach agile chez LudiGames]]
#Ils prennent la mouche, ils n'aiment pas qu'on leur montre qu'ils ont tord. A partir de là Eva remet en question son implication avec LudiGames. [[7 - Eva micro-entrepreneuse]]
#L'utilisation des OKRs est revue. Maintenant Eva se refocalise sur son équipe et l'utilisation qu'ils vont faire des OKR. [[7 - La ritualisation du suivi des OKR - LudiGames]]
#OK, OKRs :D Mais maintenant que se passe-t-il dans l'équipe d'Eva? [[7 - Eva continue avec son équipe Scrum - LudiGames]]Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[7 - Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[7 - Eva micro-entrepreneuse]]
#Les OKR c'est bien, couplé à une démarche agile c'est top, mais il y a encore au moins une étape dans la transformation de LudiGames. [[7 - La démarche produit - LudiGames]] .
#Eva souhaite faire évoluer LudiGames sur la voix vertueuse de la démarche agile. Cependant, son manager n'est pas persuadé qu'elle peut y arriver seule. [[7 - Le management remet en question la capacité d'Eva à avancer seule]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJ. [[7 - Le WSJF chez LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[7 - Sensibilisation agile des PP - LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[7 - Eva organise un séminaire produit]] Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[7 - Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[7 - Production VS Servant Leadership]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[7 - Eva devient coach agile chez LudiGames]]
Eva passant coach, il faut trouver un Scrum Master pour la remplacer auprès de l'équipe existante.
En réunion avec son manager elle hésite sur les préconisations qu'elle pourrait faire.
En effet, pour la remplacer LudiGames a le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, après tout LudiGames est capable d'embaucher de nouvelles personnes, Eva se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et Eva se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
Eva est également tentée de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Elle entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ça risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en délaissant un peu le développement.
Après plusieurs longues réunions, le management accepte la solution préconisée par Eva : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu’elle amène le sujet à l'équipe, personne ne se porte volontaire directement, Eva leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
Eva est enchantée, elle cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu’elle est remplacée, Eva peut se consacrer à la suite :
#[[7 - Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez LudiGames, Eva proposer la mise en place d’ [[7 - Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[7 - Des problèmes d'engagement chez LudiGames]] Nouveau challenge pour Eva : elle doit accompagner LudiGames dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager d'Eva a choisi l'option "Seeding".
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[7 - Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d’[[7 - Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[7 - Des problèmes d'engagement - LudiGames]]Bien qu'ayant eu des succès avec Scrum et sa première équipe, Eva est persuadée que le framework n'est pas 100% adapté pour LudiGames au général.
Elle décide de se poser et de refléchir à la situation.
Il est trés probable que les problématiques rencontrées par sa première équipe se répêtent pour d'autres équipes.
Y'a-t-il une solution universelle pour résoudre les différentes problématiques et proposer un fonctionnement agile commun à tout LudiGames?
Aprés plusieurs échanges en interne, beaucoup de lecture... Eva se retrouve devant un choix pas facile.
Quelle direction voulons-nous la voir explorer?
#Chez LudiGames, jusqu'à maintenant, le gros souci des developpeurs est le côté imprévisible du run (la gestion des anomalies de production et des demandes de support). Du fait, Eva propose de mettre en place des étapes complémentaires de qualité dans le processus de livraison. [[7 - Scrum Master et QA chez LudiGames - Coach]]
#Pour Eva, avant de s'attaquer à rendre les pratiques des équipes de développement communes, il faut mettre en place une approche d'entreprise à la démarche produit.Elle travaille donc à [[7 - La démarche produit chez LudiGames - Coach]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[7 - La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[7 - Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[7 - La dette technique et Scrum - Eva]] Quand on regarde la manière dont LudiGames gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#Eva propose au Scrum Master de suivre une formation ISTQB. [[8 - Formation ISTQB SM - LudiGames - Coach]]
#Eva propose la mise en place des 3 amigos [[8 - Les 3 amigos - LudiGames]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - LudiGames - Coach]]Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
Eva se propose d'étudier les points de concordance entre LudiGames et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[8 - Prioriser en tailles de TShirt - LudiGames]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[8 - Le WSJF - LudiGames]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[8 - Le craftsmanship - LudiGames]]
#Eva propose à l'équipe d'explorer le [[8 - Kanban - LudiGames]]Eva a une jolie expérience avec son équipe. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[7 - Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[7 - Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[7 - Eva participe à son premier Agi'Lille - LudiGames]]
Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#A force de petits succés et de travail hors du cadre stricte de Scrum Master, Eva réussi à montrer à LudiGames qu'elle a l'étoffe d'un coach. On lui propose donc de suivre ce chemin. [[7 - Eva devient coach agile chez LudiGames]]
#Eva a ouvert la boite de Pandore! Elle a maintenant accès à une communauté agile locale (à laquelle elle aurait eu accès sans nécessaire s'engager dans l'association!), à des connaissances complémentaires, à un réseau. Aprés plusieurs mois d'hésitation, elle décide de prendre son indépendance vis à vis de LudiGames et devient micro-entrepreneuse. [[7 - Eva micro-entrepreneuse]]
#Par le biais de ces meetups et événement, Eva découvre la démarche Kanban qu'elle essaye d'explorer avec son équipe. [[7 - LudiGames et Kanban]]
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[7 - Eva se passionne pour le Serious Gaming - LudiGames]] Scrum Life, Coach Agile, Les agilistes...
Que de communautés en ligne!! En plus, avec l'avénement du télétravail et des conférences en ligne, elle réussi à participer à de grands événements sans se déplacer!!
Eva se sent bien accompagnée. Elle a pu se faire un petit réseau de connaissances en ligne et réussi à trouver de l'aide lorsqu'elle en a besoin.
Cependant, aprés quelques temps Eva commence à rencontrer des difficultés avec son équipe et ne sait plus trop où chercher de l'aide. Elle a tout essayé, mais rien n'y fait, soit l'engagement de l'équipe n'est pas tenu, soit ces membres ne sont pas aussi engagés qu'Eva le souhaiterait sur la tenue de l'engagement ou la levée de freins.
Où allons-nous emmener Eva ensuite?
#Eva devrait essayer de trouver du support plus local. Pour se faire, pourquoi ne pas aller à son premier Agi'Lille? [[7 - Eva participe à son premier Agi'Lille - LudiGames]]
#Il faut absolument qu'Eva se focalise sur les problèmes d'engagement! [[7 - Des problèmes d'engagement chez LudiGames]]
#Eva devrait se concentrer sur l'équipe et sa capacité à produire de la valeur via la technique. Elle explore [[7 - Accelerate chez LudiGames]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[8 - Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - LudiGames]]
#Aprés l'atelier auquel elle a participé, [[8 - Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - Eva se lance dans l'écriture d'une conférence - LudiGames]]C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[8 - Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[8 - Le WSJF chez LudiGames]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[8 - Fast Track Scrum Master - Eva]] Eva lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[8 - La dette technique et Scrum - LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[8 - DevOps et LudiGames]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d'accelration il faut avant tout que LudiGames travaille à sa démarche produit. [[8 - Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[8 - Une présentation de la démarche agile à l'équipe - LudiGames]]
Le raisonnement d’Eva et Jean-Paul (un vieux de la vieille chez les Rois du Ballon) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! Eva et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#Eva décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[9 - Les 3 amigos - LudiGames]]
#Eva et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - LudiGames]]Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva se rend compte qu'elle s'inscrit complètement dans ce mouvement.
Elle propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de LudiGames et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[7 - LudiGames et Kanban]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[7 - LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[7 - Une méthode maison pour LudiGames]]
#Eva, se rendant compte de ce qu'elle vaut, se dit que partir sur un rôle de coach pourrait être sa prochaine évolution professionnelle! Cependant [[7 - On ne devient pas coach tout seul chez LudiGames]]
Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[8 - Kanbanzine - Eva]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[8 - Une formation avec Laurent Morisseau]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[8 - Le Kanban ca marche, mais ca prend du temps!]].
Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi. Elle engage malgré tout un chantier avec le PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[8 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[9 - Gérer le run en Scrum - LudiGames]]
#Hop, on quitte le scrum master [[9 - Fast Track Scrum Master - Eva]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner LudiGames correctement et l'aider à traverser ses challenges.
Eva a une équipe motivée, constituée de LudiGamers de la première heure. Ils connaissent le contexte, le produit et les utilisateurs. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.[[8 - Scrum Master et QA chez LudiGames]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[8 - La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[8 - Valeur Business LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[8 - La dette technique et Scrum - Eva]] Eva a une jolie expérience avec son équipe. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[8 - Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[8 - Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[8 - Eva participe à son premier Agi'Lille - LudiGames]]
Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
Eva se propose d'étudier les points de concordance entre LudiGames et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[9 - Prioriser en tailles de TShirt - LudiGames]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[9 - Le WSJF - LudiGames]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[9 - Le craftsmanship - LudiGames]]
#Eva propose à l'équipe d'explorer le [[9 - Kanban - LudiGames]]Tout dans Scrum s'applique correctement chez LudiGames!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe d'Eva et LudiGames, le succés est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
Eva n'est plus sollicité par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Elle a donc du temps pour explorer des sujets complémentaires sur la toile.
Elle a réussi à amener un peu de fun dans les différents rituels. En commencant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, elle trouve un format ludiquer que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Elle change à chaque fois le focus de l'équipe et elle a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvent des anomalies, elles sont résolues séance tenante par l'équipe.
Eva est donc prête pour passer à la suite.
#En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!! [[8 - Eva se passionne pour le No Estimate - LudiGames]]
#Le manager d'Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[Le Cargo Cult ca pique - Eva]]
#Forte de ce succés, Eva se dit qu'elle aimerait changer un peu d'horizon et se lancer dans le coaching agile. [[8 - Eva devient coach agile chez LudiGames]] Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de LudiGames et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[7 - LudiGames et Kanban]]
#Au final, Scrum reste une proposition interessante, il leur faudra s'adapter aux contraintes mais ils décident d'essayer de rentrer dans le cadre. [[7 - LudiGames et Scrum]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[7 - LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[7 - Une méthode maison pour LudiGames]]
Rentrer dans un cadre, quand on est une StartUp, ca pourrait paraître antinomiqe.
Et pourtant, c'est ce à quoi s'attèle Eva.
Revenir aux bases, expliquer pourquoi Scrum. Le fait qu'une équipe c'est comme une mêlée au rugby...
Revenir aux bases, reposer le cadre. Des sprints de 2 semaines, des rituels toujours à la même heure, au même moment du sprint.
Faire du lean même : éliminer le superflu (notamment toutes ces réunions qui ne produisent pas de valeur). Revoir le tableau scrum, enlever ces étapes dictées par leur outil de ticketting. Ajuster le process dans l'outil de ticketting pour qu'il s'adapte à Scrum (et pas l'inverse).
Puis retravailler l'empirisme. Travailler aux bons indicateurs (burn up, burn down). Utiliser les données pour aider l'équipe à s'engager. Challenger l'équipe sur son engagement (vers le haut ou vers le bas). Faire en sorte qu'ils se synchronisent correctement en vue de la tenue de cet engagement.
Retourner aux bases... de Scrum.
Au final, Eva dépense énormément d'énergie pour ce retour dans le cadre. L'équipe est souvent frustrée de devoir se conformer à un cadre... "Scrum c'est pas flexible" s'entend-t-elle critiquée parfois... Scrum c'est pas flexible... Scrum c'est pas agile?
Mais elle tient bon...
#Et le résultat est à la hauteur de l'investissement d'Eva et des frustrations de l'équipe. [[8 - Scrum ca marche pour LudiGames]]
#L'équipe a beau être rentrée dans le cadre, rien n'y fait, ils continuent à ne pas livrer l'attendu. [[8 - Des problèmes d'engagement - LudiGames]]
#Rentrer dans le cadre oui, mais pour combien de temps? Doit-on y rester longtemps? Eva explore [[8 - Le ShuHaRi appliqué à Scrum - LudiGames]] Tout dans Scrum s'applique correctement chez LudiGames!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe d'Eva et LudiGames, le succès est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
Eva n'est plus sollicité par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Elle a donc du temps pour explorer des sujets complémentaires sur la toile.
Elle a réussi à amener un peu de fun dans les différents rituels. En commençant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, elle trouve un format ludique que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Elle change à chaque fois le focus de l'équipe et elle a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvrent des anomalies, elles sont résolues séance tenante par l'équipe.
Eva est donc prête pour passer à la suite.
#En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!! [[9 - Eva se passionne pour le No Estimate - LudiGames]]
#Le manager d'Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[9 - Le Cargo Cult ca pique - LudiGames]]
#Forte de ce succès, Eva se dit qu'elle aimerait changer un peu d'horizon et se lancer dans le coaching agile. [[9 - Eva devient coach agile chez LudiGames]] C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[9 - Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[9 - Le WSJF - LudiGames]]
#On sait comment ça va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[9 - Fast Track Scrum Master - Eva]] Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[8 - Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[8 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[8 - Eva organise un séminaire produit]] pour LudiGamesUn premier meetup c'est toujours une expérience!! Eva n'est pas déçue.
Le sujet de son premier meetup : "Les focus groups au service de la démarche produit".
Un grand sujet. Eva échange avec des personnes de tous horizons: des professionnels du marketting au manageur d'équipe qui essaye de redonner du sens au fonctionnement de celle-ci.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#Pour une démarche produit cohérente, il faut que l'intégralité de LudiGames se mette en ordre de marche. Elle propose de mettre en place [[9 - Un comité de transformation chez LudiGames]]
#LudiGames ne peut pas rentrer dans un moule existant, en plus, du point de vue d'Eva, ca irait à l'encontre de la démarche agile. Elle propose donc de mettre en place [[9 - Une méthode maison pour LudiGames]]
#Eva s'est prise une claque. Que de choses à savoir, que de personnes expérimentées. Pour elle c'est sur : elle n'est pas là où il faut. Eva nous fait un gros [[9 - Syndrôme de l'imposteur - LudiGames]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[9 - Dégager des actions d'un séminaire]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le managment de LudiGames demande à Eva de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher!]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[Un comité de transformation - LudiGames]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[Faire vivre les actions aprés un séminaire - LudiGames]]
#Demander à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - LudiGames]]
#S'enfermer chez elle et se prendre un méga [[Syndrôme de l'imposteur - LudiGames]]Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la [[Démarche OKR - LudiGames]].
#Personne, durant l'atelier, n'a été capable de définir ce qu'est la valeur business des différentes solutions. Avant d'avancer dans la démarche produit, ils décident de travailler à la [[Valeur Business - LudiGames]]
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[Eva devient coach agile chez LudiGames]] Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner LudiGames correctement et l'aider à traverser ses challenges.
Eva a une équipe motivée, constituée de LudiGamers de la première heure. Ils connaissent le contexte, le produit et les utilisateurs. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.[[Scrum Master et QA chez LudiGames]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - LudiGames]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[LudiGames et Shape Up]]
#Forte des retours, Eva propose de créer [[Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[Les experts de la vision - LudiGames]]
Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas de LudiGames, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à LudiGames...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler de son équipe. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grans chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[8 - Sensibilisation agile des PP - LudiGames]]
#Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de [[8 - Production VS Servant Leadership - LudiGames]].
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum. [[8 - Eva se passionne pour le No Estimate - LudiGames]]
#On en a marre du SM! Place à la suite ... [[8 - Fast Track Scrum Master - Eva]] Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
<<if setup.steps lt 12>>
Eva se propose d'étudier les points de concordance entre LudiGames et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - LudiGames]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[Le WSJF - LudiGames]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - LudiGames]]
#Eva propose à l'équipe d'explorer le [[Kanban - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[8 - Sensibilisation agile des PP LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[8 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[8 - Eva organise un séminaire produit]] pour LudiGamesLa vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans grosse difficulté.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[8 - Eva micro-entrepreneuse]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investire dans un rôle de coach. [[8 - Eva devient coach agile chez LudiGames]]
Eva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre 4 manières principales de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ca n'est pas facile mais c'est finalement validé [[9 - Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[9 - Une formation agile - LudiGames]]
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]Tout le monde en parle, et les agilistes expérimentés autour d'Eva n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale d'Eva?
#Une chose est certaine pour Eva : elle veut être coach agile. Et donc elle n'acceptera que des missions de cet ordre. [[9 - On ne devient pas coach tout seul]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Elle décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[9 - Engranger des missions]]
#Au bout de quelques temps Eva commence à subir les effets secondaires du lancement en indépendant. Elle a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[9 - Indep c'est bien, toute seule ca craint!!]]Eva semble tout indiquée pour accompagner LudiGames sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules d'Eva.
La première chose à laquelle Eva doit s'atteler c'est de trouver un nouveau Scrum Master pour la remplacer. Puis, elle devra accompagner la création d'une nouvelle équipe agile. Elle devra également trouver comment accompagner LudiGames plus en amont dans sa démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec Eva?
#Eva doit décider comment trouver quelqu'un pour la remplacer au mieux auprés de son équipe. Elle se pose énormément de questions quant à la démarche à proposer [[9 - Un Scrum Master pour remplacer Eva - LudiGames]]
#Eva va devoir accompagner la nouvelle équipe formée. Elle a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[9 - Créer une nouvelle équipe Scrum - LudiGames]]
#Eva ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva décide de se lancer dans la description de la démarche agile selon LudiGames afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[9 - Une méthode maison pour LudiGames - Coach]] Eva a une jolie expérience avec son équipe LudiGames. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, Eva veut trouver des missions interessantes, cependant, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'elle voit passer dans les offres auxquelles elle a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[Eva participe à son premier Agi'Lille - LudiGames]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
Eva n'est donc pas trés regardante quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'elle devra engagée sont dans ses domaines de compétence.
Elle se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Elle reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, Eva n'hésite pas à partager ses réflexions, ses expériences... Elle est donc active sur les réseaux sociaux, elle crée son propre site internet, et se demande si elle ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : Eva recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'elle recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'elle ne maitrise pas tous ces sujets.
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle va devoir choisir sa prochaine mission. Que trouve-t-elle dans sa bannette (boite mail)?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur [[La fresque du climat - Eva Indep]]
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'[[Agile Hors IT - Eva]]
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[Eva se passionne pour le Serious Gaming - Indep]]Eva s'est lancée. Elle savait qu'être indépendante lui demanderait de faire des sacrifices. Mais elle n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, elle comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Elle décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, elle en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel elle n'avait pas non plus pensé, réside dans le fait qu'elle rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, Eva réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et notament [[Eva découvre les meetups et Nord Agile entant qu’Indep]]
#C'est bien beau de devoir gérer sa montée en compétences toute seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient la voir avec un challenge d'organisation d'événement interne à grande échelle, Eva doit explorer de nouveaux domaines. [[Eva organise un séminaire produit - Indep]]
#Un des clients d'Eva est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[Eva participe à son premier Agi'Lille pour un client]]
Eva et son équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[8 - La démarche produit chez LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[8 - Des noms de rôles chez LudiGames]]
Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[9 - Sensibilisation agile des PP LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[9 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[9 - Eva organise un séminaire produit]] pour LudiGamesEva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre plusieurs manières de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[Une formation agile - LudiGames]]
#Eva aimerait pouvoir accompagner LudiGames sur une voie qui ne soit pas forcément formatée par un framewok. Elle se renseigne sur le mouvement [[Agnostic Agile - L'agilité LudiGames]] lorsqu'un de ces contacts lui dit qu'elle doit pouvoir s'y reconnaitre.
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[Eva participe à son premier Agi'Lille - LudiGames]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Le sujet de son premier meetup : "Les focus groups au service de la démarche produit".
Un grand sujet. Eva échange avec des personnes de tous horizons: des professionels du marketting au manageur d'équipe qui essaye de redonner du sens au fonctionnement de celle-ci.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#Pour une démarche produit cohérente, il faut que l'intégralité de LudiGames se mette en ordre de marche. Elle propose de mettre en place [[Un comité de transformation - LudiGames]]
#LudiGames ne peut pas rentrer dans un moule existant, en plus, du point de vue d'Eva, ca irait à l'encontre de la démarche agile. Elle propose donc de mettre en place [[Une méthode maison pour LudiGames]]
#Eva s'est prise une claque. Que de choses à savoir, que de personnes expérimentées. Pour elle c'est sur : elle n'est pas là où il faut. Eva nous fait un gros [[Syndrôme de l'imposteur - LudiGames]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - LudiGames]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le managment de LudiGames demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - LudiGames]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[Les experts de la vision - LudiGames]]
<<else>>
* C'est pourquoi Eva continue avec son équipe Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Elle souhaite également travailler avec le PO afin de mettre en avant la Valeur Business LudiGames.
* Elle proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision LudiGames.
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Elle se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[LudiGames et Shape Up]]
#Forte des retours, Eva propose de créer [[Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, Eva entend parler d'un événement Lillois autour de la démarche agile. Eva participe donc à son premier Agi'Lille.
* Eva trouve rapidement une réponse qu'elle souhaite amener à sa direction et prépare un atelier pour montrer qu'il faut se focaliser sur la création de valeur et plus sur les dépenses.
* Eva découvre d'autres manière d'être agiles que Scrum. Elle lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue LudiGames.
[[Conclusion]]
<</if>>Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - LudiGames]]
#Forte de toutes ses expériences, Eva décide de passer indépendante [[Eva micro-entrepreneuse]]
<<else>>
Il lui faudra ensuite
* Récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, en se rapprochant de la communauté agile Lilloise.
* Avant de plonger plus en profondeur elle devra travailler avec l'équipe à la gestion du run en Scrum.
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner LudiGames correctement et l'aider à traverser ses challenges.
Eva a une équipe motivée, constituée de LudiGamers de la première heure. Ils connaissent le contexte, le produit et les utilisateurs. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.[[Scrum Master et QA chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - LudiGames]]
<<else>>
Avec l'équipe, Eva va engager les actions suivantes :
* Pour garantir le bon fonctionnement à tout moment de leur solution en ligne, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva se propose donc de l'aider en devenant ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business LudiGames.
* Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[8 - Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[8 - Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - Eva se lance dans l'écriture d'une conférence - Indep]]Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est parée, elle se lance. Que fait-elle en premier?
#Elle décide de [[9 - Gamifier une rétrospective - Eva Indep]]
#Elle choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[9 - Kanbanzine - Eva Indep]]
#Lors d'un accompagnement d'équipe débutante, elle utilise [[9 - Scrumble - Eva Indep]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[9 - Eva découvre les meetups et Nord Agile entant qu'Indep]] Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prises.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[8 - Dégager des actions d'un séminaire - Eva Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[8 - Faire vivre les actions aprés un séminaire - Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[8 - Une méthode maison pour son client - Eva Indep]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à Eva de justifier les investissements passés et futurs : [[8 - L'agile ca coûte cher! - Eva Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais Eva a la chance de ne pas être toute seule sur l'animation du stand et elle trouve donc un peu de temps pour son apprentisage personnel.
Eva peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[8 - Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[8 - Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - Eva se lance dans l'écriture d'une conférence - Indep]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[8 - Eva rejoint Nord Agile - Indep]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[8 - Eva participe à son premier Agi'Lille entant qu'Indep]]
Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[9 - Eva organise un séminaire produit Indep]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[9 - Agile Games France - Eva Indep]]
#Eva se rend compte qu'elle a des choses interessantes à dire et les personnes avec lesquelles elle échange dans la communauté lilloise la motive à les partager avec un maximum de gens. [[9 - Eva se lance dans l'écriture d'une conférence - Indep]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[9 - Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - Eva - Indep]]
#Aprés l'atelier auquel elle a participé, [[9 - Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - Eva se lance dans l'écriture d'une conférence - Indep]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[9 - Un comité de transformation - Eva Indep]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[9 - Faire vivre les actions aprés un séminaire - Eva Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[9 - Se former aux démarches produits - Eva Indep]]
#S'enfermer chez elle et se prendre un méga [[9 - Syndrôme de l'imposteur - Eva Indep]]Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[9 - Les experts de la vision - Eva Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[9 - Démarche OKR - Eva Indep]].
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
Eva réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client d'Eva. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - Eva Indep]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[9 - La Rache - Eva Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[9 - Valeur Business Client - Eva Indep]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[9 - La dette technique et Scrum - Eva Indep]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - Indep]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[9 - Shape Up pour son client - Eva Indep]]
#Forte des retours de son client, Eva propose de créer [[9 - Une méthode maison pour son client - Eva Indep]] tout en restant dans la démarche agile.Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est parée, elle se lance. Que fait-elle en premier?
#Elle décide de [[Gamifier une rétrospective - Eva Indep]]
#Elle choisi un outil d'apprentissage et l'anime auprès d'un de ces clients. Ils testent [[Kanbanzine - Eva Indep]]
#Lors d'un accompagnement d'équipe débutante, elle utilise [[Scrumble - Eva Indep]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[Eva découvre les meetups et Nord Agile entant qu’Indep]] Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - Eva Indep]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - Eva Indep]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Eva est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, elle propose à son commanditaire d'animer l'atelier avec une des équipes qu'elle accompagne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - Eva Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[Une méthode maison pour son client - Eva Indep]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[Shape Up - Eva Indep]] Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[8 - Un miroir coach - Eva Indep]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[8 - Une formation certifiante Coach - Eva Indep]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[8 - Eva rejoint Nord Agile - Indep]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[8 - La fresque du climat - Eva Indep]] James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[8 - James rejoint Nord Agile - RDB]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[8 - La fresque du climat - RDB]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[8 - James micro-entrepreneur]] Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[Un miroir coach - Eva Indep]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[Une formation certifiante Coach - Eva Indep]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[Eva rejoint Nord Agile - Indep]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[La fresque du climat - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>>Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux développeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héros.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l’héroïne de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héros. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapitres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ça ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[9 - Un miroir coach - Eva Indep]]
#Ça fait quelques temps qu'elle se dit qu'elle aimerait suivre [[9 - Une formation certifiante Coach - Eva Indep]]
#Après avoir participé à ses événements et y avoir présenté ses sujets, [[9 - Eva rejoint Nord Agile - Indep]]
#Eva est profondément coresponsable, elle souhaite devenir animatrice de [[9 - La fresque du climat - Eva Indep]] James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[9 - James rejoint Nord Agile - RDB]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[9 - La fresque du climat - RDB]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[James micro-entrepreneur]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est parée, elle se lance. Que fait-elle en premier?
#Elle décide de [[8 - Gamifier une rétrospective - Eva Indep]]
#Elle choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[8 - Kanbanzine - Eva Indep]]
#Lors d'un accompagnement d'équipe débutante, elle utilise [[8 - Scrumble - Eva Indep]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[8 - Eva découvre les meetups et Nord Agile entant qu'Indep]] Eva consulte les ressources qu’elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de rétrospective à sa disposition.
Les premiers exemples qu’Eva voudrait explorer :
* Scrum Health Check, il faut bien commencer quelque part et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[9 - Le principe de l'amélioration continue face au chaos - Eva Indep]]
#En recherchant des formats de rétrospectives, Eva est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[9 - Eva découvre les meetups et Nord Agile entant qu'Indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[9 - Kanbanzine - Eva Indep]]
#Eva se rend compte que [[9 - Peu importe le format, seuls les résultats comptent - Eva Indep]] quand on parle de rétrospective.
En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Eva est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, elle propose à son commanditaire d'animer l'atelier avec une des équipes qu'elle accompagne.
L'atelier se passe bien. L'équipe de chez DoctoChat comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[9 - Le Kanban ca marche, mais ca prend du temps! - Eva Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[9 - Une méthode maison pour son client - Eva Indep]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[9 - Shape Up - Eva Indep]] Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ça fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[9 - Le craftsmanship - Eva Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[9 - La dette technique et Scrum - Eva Indep]]
#Eva a pris goût aux outils gamifiés, elle se lance dans [[9 - Kanbanzine - Eva Indep]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais Eva se demande souvent si elle est légitime. [[9 - Syndrôme de l'imposteur - Eva Indep]] Eva passant coach, il faut trouver un Scrum Master pour la remplacer auprès de l'équipe existante.
En réunion avec son manager elle hésite sur les préconisations qu'elle pourrait faire.
En effet, pour la remplacer LudiGames a le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, après tout LudiGames est capable d'embaucher de nouvelles personnes, Eva se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et Eva se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
Eva est également tentée de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Elle entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ça risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en délaissant un peu le développement.
Après plusieurs longues réunions, le management accepte la solution préconisée par Eva : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu’elle amène le sujet à l'équipe, personne ne se porte volontaire directement, Eva leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
Eva est enchantée, elle cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu’elle est remplacée, Eva peut se consacrer à la suite :
#[[9 - Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez LudiGames, Eva proposer la mise en place d’ [[9 - Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[9 - Des problèmes d'engagement chez LudiGames]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son activité d'indépendante elle décide acheter la version éditée qui, de plus, lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
<<if setup.steps lt 12>>
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - Eva Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[Une méthode maison pour son client - Eva Indep]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[Shape Up - Eva Indep]]
<<else>>
Eva accompagne l'équipe qui se lance tête baissée dans la démarche Kanban.
Eva travaille avec le scrum master pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et propose au scrum master de regarder un peu aux goulots d'étranglement au sein de leur tableau. Ils se rendent compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Ils s'engagent donc dans l'identification des workflow externes à l'équipe et proposent aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Eva et l'équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ça leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clôtures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Après 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le client d'Eva l'interpelle car ils considèrent que les progrès certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[Une méthode maison pour son client - Eva Indep]]
#De Kanban à Scrum c'est très beau tout ça, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - Eva Indep]]
#L'aventure d'Eva interpèle à chaque fois qu'elle en parle dans ses réseaux, du fait elle se dit qu'elle pourrait en faire une histoire à raconter... [[Eva se lance dans l'écriture d'une conférence - Indep]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
James est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, il propose à son commanditaire d'animer l'atelier avec une des équipes qu'il accompagne.
L'atelier se passe bien. L'équipe de DoctoChat comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[9 - Le Kanban ca marche, mais ca prend du temps! - James Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. James propose alors de créer [[9 - Une méthode maison pour son client - James Indep]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[9 - Shape Up - James Indep]] Eva s'est lancée. Elle savait qu'être indépendante lui demanderait de faire des sacrifices. Mais elle n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, elle comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Elle décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, elle en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel elle n'avait pas non plus pensé, réside dans le fait qu'elle rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, Eva réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et notament [[7 - Eva découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences toute seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient la voir avec un challenge d'organisation d'événement interne à grande échelle, Eva doit explorer de nouveaux domaines. [[7 - Eva organise un séminaire produit Indep]]
#Un des clients d'Eva est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[7 - Eva participe à son premier Agi'Lille pour un client]]
Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[8 - James rejoint Nord Agile Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[8 - James participe à son premier Agi'Lille entant qu'Indep]]
James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[8 - Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[8 - Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[8 - Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[8 - L'agile ca coûte cher! - James Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais James a la chance de ne pas être tout seul sur l'animation du stand et il trouve donc un peu de temps pour son apprentisage personnel.
James peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - Indep]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - Indep]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[Eva participe à son premier Agi'Lille - Indep]]
Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prises.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - Eva Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour son client - Eva Indep]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - Eva Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais Eva a la chance de ne pas être toute seule sur l'animation du stand et elle trouve donc un peu de temps pour son apprentisage personnel.
Eva peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - Indep]]Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - James se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client de James lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais James se lance. [[9 - James organise un séminaire produit - Indep]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[9 - Agile Games France - James Indep]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[9 - James se lance dans l'écriture d'une conférence - Indep]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[9 - James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[9 - James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - Indep]]Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - James Indep]]
#Il choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[Kanbanzine - James Indep]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[Scrumble - James Indep]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile entant qu'indep]] James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - James Indep]]James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - Indep]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - James Indep]] <img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit à son client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors il a le choix :x
#Proposer au client de créer un [[9 - Un comité de transformation - James Indep]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[9 - Faire vivre les actions aprés un séminaire - James Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - James Indep]]
#S'enfermer chez lui et se prendre un méga [[9 - Syndrôme de l'imposteur - James Indep]]Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[9 - Les experts de la vision - James Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[9 - Démarche OKR - James Indep]].
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client de James. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. James propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - James Indep]]
#Un des membres de l'équipe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[9 - La Rache - James Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - James Indep]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[9 - La dette technique et Scrum - James Indep]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à son client [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - James Indep]]
#James propose à son client de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up pour son client - James Indep]]
#Fort des retours de son client, James propose de créer [[9 - Une méthode maison pour son client - James Indep]] tout en restant dans la démarche agile.<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors elle a le choix :
#Proposer au management de créer un [[Un comité de transformation - Eva Indep]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[Faire vivre les actions aprés un séminaire - Eva Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - Eva Indep]]
#S'enfermer chez elle et se prendre un méga [[Syndrôme de l'imposteur - Eva Indep]]
<<else>>
Elle propose au client de créer un comité de transformation auquel elle pourrait se joindre.
Elle pourrait aussi animer elle même la transformation de manière itérative.
Elle cherche aussi à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>>Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
<<if setup.steps lt 12>>
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - Eva Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[Démarche OKR - Eva Indep]].
<<else>>
Eva fait partie des acteurs, et de ce fait elle est impliquée dans plusieurs initiatives :
* Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la démarche OKR.
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Elle se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - Indep]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up pour son client - Eva Indep]]
#Forte des retours de son client, Eva propose de créer [[Une méthode maison pour son client - Eva Indep]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, Eva entend parler d'un événement Lillois autour de la démarche agile. Eva participe donc à son premier Agi'Lille.
* Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients et prépare un atelier pour montrer qu'il faut se focaliser sur la création de valeur et plus sur les dépenses.
* Eva découvre d'autres manière d'être agiles que Scrum. Elle lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante en fonction du contexte.
[[Conclusion]]
<</if>>James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[9 - James rejoint Nord Agile - Indep]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[9 - La fresque du climat - James Indep]] James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - James Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - Indep]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - James Indep]] Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client de James. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. James propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - James Indep]]
#Un des membres de l'équipe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[La Rache - James Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - James Indep]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - James Indep]] James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - James Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - Indep]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - James Indep]]
<<else>>
* James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum.
* James se dit qu'il pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO chez son client d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. Il a la chance de travailler avec un client qui est sponsor de l'Agi'Lille et qui le prend avec lui sur son stand.[[James participe à son premier Agi'Lille pour un client]]
#James se dit qu'avant d'aller plus loin dans les évolutions de méthode, il faudrait sans doute explorer la notion de [[Valeur Business Client - James Indep]]
#James continue à explorer les alternatives à Scrum et se renseigne sur le [[Kanban - James Indep]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - James Indep]]
<<else>>
Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James se rapproche de la communauté agile Lilloise.
James se dit aussi qu'il faudrait peut être déjà que l'équipe se souci du run en Scrum.
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client de James. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec l'équipe, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. James propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - James Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - James Indep]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - James Indep]]
<<else>>
Avec l'équipe, James doit donc mettre en place :
* Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. James propose donc que les Scrum Master deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la valeur Business Client.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres de l'équipe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>James et l'équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le client de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - James Indep]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[Une méthode maison pour son client - James Indep]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - James Indep]] Nous avons ensemble suivi l'évolution de notre héros durant 10 étapes type de son évolution d'agiliste. Nombreuses sont les autres voix possibles, nombreux sont les choix dans une vie professionnelle!
Vous pouvez suivre de nouvelles péripéties en recommancant l'histoire au début et en modifiant vos réponses.
Toutes ces choses que j'aurais voulu mettre mais... "peut-être pour une V2"
* Une fiche personnage qui évolue en fonction des expériences que vous faites vivre à notre héro.
* Plus d'illustrations
* Un résumé écrit de votre histoire, celle que vous m'avez aidé à créer.
[[Sponsors et ROTI]]
[[1 - Choix du personnage]] Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[Eva organise un séminaire produit - Indep]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[Agile Games France - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>>Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - Eva Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - Indep]]
#Eva se dit qu'elle pourrait aussi creuser [[Shape Up - Eva Indep]]
<<else>>
* Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Elle propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum.
* Eva se dit qu'elle pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>>Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - Eva Indep]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - Eva Indep]]
<<else>>
Elle devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise.
* Elle devrai également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
<<if setup.steps lt 12>>
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prises.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - Eva Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour son client - Eva Indep]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - Eva Indep]]
<<else>>
Au sortir de cet événement elle se retrouve avec beaucoup de contenu. Elle n'est pas tombée dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambicieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels elle aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie Eva aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[8 - Des problèmes d'engagement - LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[8 - Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes.[[8 - Eva participe à son premier Agi'Lille]]
#C'est bien beau tout ca mais ce sont des problématiques de Scrum Master, nous ce qu'on veut c'est voir la suite. [[8 - Fast Track Scrum Master - Eva]]La vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans grosse difficulté.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[Eva micro-entrepreneuse]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investire dans un rôle de coach. [[9 - Eva devient coach agile chez LudiGames]]
Tout le monde en parle, et les agilistes expérimentés autour d'Eva n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale d'Eva?
<<if setup.steps lt 12>>
#Une chose est certaine pour Eva : elle veut être coach agile. Et donc elle n'acceptera que des missions de cet ordre. [[On ne devient pas coach tout seul - Eva Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Elle décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[Engranger des missions]]
#Au bout de quelques temps Eva commence à subir les effets secondaires du lancement en indépendant. Elle a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[Indep c'est bien, toute seule ca craint!!]]
<<else>>
Eva va devoir choisir comment orienter sa recherche de missions, va-t-elle décider qu'elle a maintenant la capacité d'endosser des missions de coaching et donc n'accepter que celles-ci ou pour sa prise d'activité va-t-elle favoriser le reseau et prendre toutes les missions qui se présentent, du moment qu'elles sont dans un contexte agile.
Ensuite, elle devra aussi gérer sa montée en compétence. Comment trouver le temps pour se former, faire de la veille quand on est à son compte? Doit-on uniquement faire ce genre de choses en HNO? Peut-on investir de son temps directement la première année? Quel impact sur les revenus et la qualité de vie sur le moyen terme?
En plus, Eva a plein d'envie d'un point de vue collaboration mais c'est pas des plus facile quand on est indep. Pour le peu que les personnes avec lesquelles elle veut collaborer soient elles aussi indep, l'alignement des agendas ne sera pas des plus aisé.
Mais Eva aura du succés, elle sera régulièrement challengée par ses clients et réussira à se faire un nom à force de réseautage, de participation à la communauté agile via des événements, des publications en ligne, des créations...
[[Conclusion]]
<</if>>Eva semble tout indiquée pour accompagner LudiGames sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules d'Eva.
La première chose à laquelle Eva doit s'atteler c'est de trouver un nouveau Scrum Master pour la remplacer. Puis, elle devra accompagner la création d'une nouvelle équipe agile. Elle devra également trouver comment accompagner LudiGames plus en amont dans sa démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec Eva?
#Eva doit décider comment trouver quelqu'un pour la remplacer au mieux auprès de son équipe. Elle se pose énormément de questions quant à la démarche à proposer [[Un Scrum Master pour remplacer Eva - LudiGames]]
#Eva va devoir accompagner la nouvelle équipe formée. Elle a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[Créer une nouvelle équipe Scrum - LudiGames]]
#Eva ne veut pas se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva décide de se lancer dans la description de la démarche agile selon LudiGames afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. Elle se renseigne alors sur la tendance Agnostic Agile. [[Coach et Agnostic - LudiGames]]
<img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - Indep]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
Elle revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et elle se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, elle développe l'envie de rendre à la communauté à hauteur de ce qu'elle y a récupéré depuis quelques mois. Elle commence à rédiger une conférence. Peut-être la croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais Eva a la chance de ne pas être toute seule sur l'animation du stand et elle trouve donc un peu de temps pour son apprentisage personnel.
Eva peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
Au sortir de l'événement Eva a plein d'idées et d'envies.
* Elle a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
* Elle a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. Elle aimerait pouvoir un jour leur ressembler!
* Aprés l'atelier auquel elle a participé, elle se passionne pour le No Estimate.
* Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!!
Cependant, elle subit un effet secondaire souvent rencontré lors de ce genre d'événements. Aprés avoir rencontré toutes ces personnes bienveillantes et bien pensantes, tous ces puits de culture agile, d'expériences variées, Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros Syndrôme de l'imposteur!
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[8 - Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[8 - Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[8 - Eva devient coach agile chez LudiGames]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - LudiGames]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[Fast Track Scrum Master - Eva]] La vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans grosse difficulté.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[Eva micro-entrepreneuse]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investire dans un rôle de coach. [[Eva devient coach agile chez LudiGames]]
Eva passant coach, il faut trouver un Scrum Master pour la remplacer auprés de l'équipe existante.
En réunion avec son manager elle hésite sur les préconnisations qu'elle pourrait faire.
En effet, pour la remplacer LudiGames a le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, aprés tout LudiGames est capable d'embaucher de nouvelles personnes, Eva se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et Eva se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
Eva est également tentée de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Elle entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ca risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en delaissant un peu le développement.
Aprés plusieurs longues réunions, le management accepte la solution préconnisée par Eva: faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'elle amène le sujet à l'équipe, personne ne se porte volontaire directement, Eva leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
Eva est enchantée, elle cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et Eva peut entamer sereinement sa nouvelle vie de coach.
<<if setup.steps lt 12>>
Maintenant qu’elle est remplacée, Eva peut se consacrer à la suite :
#[[Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez LudiGames, Eva proposer la mise en place d’ [[Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Premier challenge pour Eva : Non seulement elle a du trouver un scrum master remplacant, mais elle doit aussi accompagner LudiGames dans la création d'une nouvelle équipe.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant avec LudiGames pour identifier un périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent chez LudiGames et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est qu'Eva a déjà parcouru ce chemin avec LudiGames pour sa précédente équipe. Elle connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
LudiGames pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
<<if setup.steps lt 12>>
La nouvelle équipe est créée. Le manager d'Eva a choisi l'option "Seeding".
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d'[[Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement - LudiGames]]
<<else>>
Il est aussi possible que le management ne lui laisse pas le choix et qu'elle doive composer avec une équipe de 15 personnes. Si c'est cette solution qui est choise, elle se demande si le modèle Scrum chez LudiGames ne va pas exploser...
[[Conclusion]]
<</if>>Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
Eva n'est donc pas trés regardante quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'elle devra engager sont dans ses domaines de compétence.
Elle se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Elle reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, Eva n'hésite pas à partager ses réflexions, ses expériences... Elle est donc active sur les réseaux sociaux, elle crée son propre site internet, et se demande si elle ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : Eva recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'elle recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'elle ne maitrise pas tous ces sujets.
<<if setup.steps lt 12>>
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle va devoir choisir sa prochaine mission. Que trouve-t-elle dans sa bannette (boite mail)?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur [[La fresque du climat - Eva Indep]]
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'[[Agile Hors IT - Eva]]
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[Eva se passionne pour le Serious Gaming - Indep]]
<<else>>
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle doit choisir sa prochaine mission. Les choix qui se présentent devant elle sont les suivants :
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur la fresque du climat.
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'agile hors it.
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, elle se passionne pour le serious gaming et participe entre autre aux meetups et événements lillois.
[[Conclusion]]
<</if>>Eva s'est lancée. Elle savait qu'être indépendante lui demanderait de faire des sacrifices. Mais elle n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, elle comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Elle décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, elle en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel elle n'avait pas non plus pensé, réside dans le fait qu'elle rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, Eva réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d' amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
<<if setup.steps lt 12>>
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et notament [[Eva découvre les meetups et Nord Agile entant qu’Indep]]
#C'est bien beau de devoir gérer sa montée en compétences toute seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient la voir avec un challenge d'organisation d'événement interne à grande échelle, Eva doit explorer de nouveaux domaines. [[Eva organise un séminaire produit - Indep]]
#Un des clients d'Eva est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[Eva participe à son premier Agi'Lille pour un client]]
<<else>>
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), elle va pouvoir explorer les sujets suivants :
* Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et va notamment découvrir les meetups Nord Agile, l'Agi'Lille et les Agile Games Hauts de France.
* Un de ses clients va lui a proposé d'animer un séminaire autour de la vision produit de son entreprise. L'animation d'événements n'est pas encore son point fort mais elle va se lancer avec ce client bienveillant.
* Un des clients d'Eva est sponsor de l'Agi'Lille cette année grace à Eva qui le tanne avec le sujet depuis quelques mois! Chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé!
[[Conclusion]]
<</if>>
Il lui aura fallu beaucoup réfléchir. Mais Eva a rejoint le groupe HouVert, une ESN de quelques milliers de personnes.
Etant un joueur important dans la région Lilloise, les clients sont variés, aussi bien dans la grande distribution que dans l'industrie. De fait, les perspectives de missions sont nombreuses.
Le jour de son arrivée elle fait son parcours d'intégration et on lui présente la communauté agile nationale. Eva est invitée à la rejoindre au plus vite.
Elle rencontre les autres agilistes HouVerts locaux et apprécie particulièrement les échanges qu'elle a eu avec David, coach agile dans sa mission actuelle. Ce genre de missions interesse énormément Eva.
Eva décide d'en parler le plus rapidement possible à son ingénieur d'affaires attitré. Celui-ci semble un peut embêté. En effet, lors de ses entretiens, Eva a indiqué son passé de tech. Le contrat qu'elle a signé mentionne le fait qu'elle est experte technique. Sur le moment ca n'avait pas choqué Eva. Mais maintenant l'ingénieur d'affaire ne sait pas trop quel type de mission lui proposer pour sa première intervention.
Eva va-t-elle rester experte technique pendant quelques missions histoire de continuer à se forger une expérience terrain? Il se pourrait que cette voie l'emmène sur les chemins de l'expertise test par exemple, avant de revenir sur des missions plus agiles.
Va-t-elle au contraire se voir proposer, voir n'accepter, que des missions agiles et continuer à augmenter son expérience d'accompagnement des équipes pour finir par partir vers une expertise produit ou coaching?
Recommencez l'histoire en changeant vos choix pour lire ce qui aurait pu arriver ;)
[[Conclusion]]
Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[8 - Production VS Servant Leadership - LudiGames]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[8 - Le craftsmanship - LudiGames]].
#Bon, et si on avancait plus rapidement dans le temps! Que fais Eva aprés Scrum Master? [[8 - Fast Track Scrum Master - Eva]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[9 - La dette technique et Scrum]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[9 - Accelerate chez LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[9 - DevOps - LudiGames]]
#Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - LudiGames]]Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - LudiGames]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[Fast Track Scrum Master - Eva]] Eva lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[DevOps - LudiGames]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d'acceleration il faut avant tout que LudiGames travaille à sa démarche produit. [[Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[Une présentation de la démarche agile à l'équipe - LudiGames]]
Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
#Bon, assez de Scrum Mastering, elle fait quoi ensuite Eva? [[Fast Track Scrum Master - Eva]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[8 - Prioriser en tailles de TShirt]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[8 - Le WSJF - LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[8 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Oublions un peu l'expérience Scrum Master, passons à la suite [[8 - Fast Track Scrum Master - Eva]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJ. [[9 - Le WSJF - LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[9 - Sensibilisation agile des PP LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[9 - Eva organise un séminaire produit]] Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[9 - Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[9 - Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[9 - Eva devient coach agile chez LudiGames]]
Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas de LudiGames, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à LudiGames...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler de son équipe. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grans chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[9 - Sensibilisation agile des PP LudiGames]]
#Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de [[9 - Production VS Servant Leadership - LudiGames]].
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum. [[9 - Eva se passionne pour le No Estimate - LudiGames]]
#On en a marre du SM! Place à la suite ... [[9 - Fast Track Scrum Master - Eva]] Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement - LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[Eva participe à son premier Agi'Lille - LudiGames]]
#C'est bien beau tout ca mais ce sont des problématiques de Scrum Master, nous ce qu'on veut c'est voir la suite. [[Fast Track Scrum Master - Eva]]<img src="https://picsum.photos/200/300?random=1"/>La vie de Scrum Master d'Eva se passe plutôt bien. Elle rencontre quelques difficultés qu'elle gère sans grosse difficulté.
Au bout de quelques mois comme Scrum Master, elle décide de regarder à ce qui se passe ailleurs (à la fois au sein de LudiGames mais aussi en dehors).
<<if setup.steps lt 12>>
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière d'Eva?
#Eva décide qu'il est temps pour elle de passer indépendante et se lance dans l'aventure seule. [[Eva micro-entrepreneuse]]
#Eva se met en visibilité sur Linked In et ne tarde pas à être submergée de proposition de rencontres. [[Un Scrum Master en disponibilité]]
#Eva crée ses propres opportunités, ca a toujours été le cas. Aprés plusieurs rendez-vous avec les dirigeants de LudiGames, elle réussi à leur montrer la nécessité d'investire dans un rôle de coach. [[Eva devient coach agile chez LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Eva se met en disponibilité.
Son réseau agile est réduit mais son expérience est recherchée, elle est donc contactée par plusieurs entreprises...
Elle se rend compte qu'il peut y avoir de grandes différences de propositions en fonction des certifications qu'elle détient.
De plus, les fiches de postes peuvent être vraiment différentes.
Voici un florilège de ce qu'elle a pu trouver comme requis :
* 15 d'expérience en Scrum Master
* 10 ans d'expérience SAFe
* Expert en CNV, Solutiuon Focus, Management 3.0, Team Topologies, Design Thinking et Product Led Growth
* Scrum Master expert technique (Flutter et Angular)
* ...
Elle verra aussi passer des annonces qui la tentent mais elle se posera la question si elle est à la hauteur pour devenir Coach agile dans une autre StartUp par exemple.
Elle pourra aussi rejoindre une ESN, grande ou petite et les communautés agiles qui les composent.
Elle se pose néanmoins une question: pourquoi ne voit-elle que des propositions d'agilistes dans l'IT? Est-ce qu'elle cherche mal?
Une chose est sur, c'est qu'elle saura rebondir. Scrum Master toute sa vie? Eva ne pense pas. Elle est trés attirée par l'éco-responsabilité et tout ca et espère pouvoir s'engager, entant qu'agiliste, sur des projets qui y touche (Fresque du climat, Fresque du numérique). Sinon, elle sait aussi qu'elle pourrait retourner à la nature pour élever des chêvres en Corrèze.
[[Conclusion]]Eva semble tout indiquée pour accompagner LudiGames sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules d'Eva.
La première chose à laquelle Eva doit s'atteler c'est de trouver un nouveau Scrum Master pour la remplacer. Puis, elle devra accompagner la création d'une nouvelle équipe agile. Elle devra également trouver comment accompagner LudiGames plus en amont dans sa démarche agile.
<<if setup.steps lt 12>>
Pleins de gros projets, lequel voulez-vous explorer avec Eva?
#Eva doit décider comment trouver quelqu'un pour la remplacer au mieux auprés de son équipe. Elle se pose énormément de questions quant à la démarche à proposer [[Un Scrum Master pour remplacer Eva - LudiGames]]
#Eva va devoir accompagner la nouvelle équipe formée. Elle a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[Créer une nouvelle équipe Scrum - LudiGames]]
#Eva ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva décide de se lancer dans la description de la démarche agile selon LudiGames afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[Une méthode maison pour LudiGames]]
<<else>>
Eva va d'abord devoir explorer les différentes possibilités pour trouver quelqu'un pour la remplacer au mieux auprés de son équipe. Va-t-elle proposer de prendre un Scrum Master externe, avec ou sans expérience? Ou va-t-elle essayer de pousser pour faire monter quelqu'un de l'équipe actuelle au rôle de Scrum Master? Peut-être que le jeune Antoine, le stagiaire en alternance qui doit signer avec LudiGames une fois son diplôme en poche, est-il le candidat idéal?
Eva va ensuite devoir accompagner la nouvelle équipe formée. En plus de proposer également un moyen d'identifier un Srum Master, elle sait que l'impact de la création d'une nouvelle équipe n'est pas à négliger. Va-t-elle proposer de créer une toute nouvelle équipe, avec son propre backlog ou avec un backlog commun? Ou utilisera-t-elle le principe de seeding en créant 2 équipes à partir de celle existante?
Entant que coach, elle va aussi avoir plus de temps pour faire de la veille (enfin elle espère) et compte bien sur la communauté agile lilloise pour l'aider. Elle participera entre autre à l'Agi'Lille et aux différents meetups qui sont à sa disposition sur Lille.
Pour fini, Eva devra aussi décider de comment accompagner LudiGames dans son évolution agile. Voudra-t-elle pousser pour une démarche agile maison? Poussera-t-elle pour avancer sur la démarche produit?
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[Eva devient coach agile chez LudiGames]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
<<if setup.steps lt 12>>
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - LudiGames]]
#Aprés tout ca, Eva décide de passer Indep! [[Eva micro-entrepreneuse]]
<<else>>
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec de nouvelles perspectives :
* Eva a l'impression que la partie test de l'application pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé Eva est persuadée que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Elle cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. Elle va se confronter à la gestion de run en Scrum ;)
* Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>>Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[8 - Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[8 - Eva micro-entrepreneuse]]
#Les OKR c'est bien, couplé à une démarche agile c'est top, mais il y a encore au moins une étape dans la transformation de LudiGames. [[8 - La démarche produit chez LudiGames ]] .
#Eva souhaite faire évoluer LudiGames sur la voix vertueuse de la démarche agile. Cependant, son manager n'est pas persuadé qu'elle peut y arriver seule. [[8 - Le management remet en question la capacité d'Eva à avancer seule]] Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[9 - Sensibilisation agile des PP LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[9 - Meetup produit sur Lille]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[9 - Eva organise un séminaire produit]] pour LudiGamesLe manager d'Eva lui propose un rendez-vous pour faire un petit état des lieux.
Eva déploie énormément d'efforts à tenter de faire évoluer son équipe et ses parties prenantes mais sans gros succès. Comment faire pour maximiser son retour sur investissement?
Quelle décision prennent-ils?
#Eva doit impérativement faire de la veille de son coté, pour ce faire, LudiGames est OK pour lui payer sa participation à l'Agi'Lille [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#LudiGames décide de faire intervenir une personne plus expérimentée pour accompagner Eva [[9 - Un coach agile chez LudiGames]]
#Eva prend la mouche et se lance en indep [[Eva micro-entrepreneuse]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[8 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[8 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[8 - Prouver l'impact de la dette technique - Eva]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[8 - Fast Track Scrum Master - Eva]] Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[8 - Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[8 - Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[8 - Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
#Bon, assez de Scrum Mastering, elle fait quoi ensuite Eva? [[8 - Fast Track Scrum Master - Eva]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[9 - Le WSJF - LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Oublions un peu l'expérience Scrum Master, passons à la suite [[9 - Fast Track Scrum Master - Eva]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJ. [[Le WSJF chez LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[Sensibilisation agile des PP - LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[Eva organise un séminaire produit]] Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas de LudiGames, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à LudiGames...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler de son équipe. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grans chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - LudiGames]]
#Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de [[Production VS Servant Leadership - LudiGames]].
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - LudiGames]]
#On en a marre du SM! Place à la suite ... [[Fast Track Scrum Master - Eva]] <img src="https://picsum.photos/200/300?random=1"/>
Eva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre 4 manières principales de faire cette sensibilisation.
<<if setup.steps lt 12>>
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[Une formation agile - LudiGames]]
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGames.
* Eva a aussi la possibilité de proposer elle même une formation aux parties prenantes. Aprés tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? Eva pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* Eva pourrait aussi mettre l'équipe à contribution. Aprés tout, elle est plus à même qu'Eva pour parler aux parties prenantes de leur quotidien! Elle pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>>Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
<<if setup.steps lt 12>>
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - LudiGames]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le managment de LudiGames demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - LudiGames]]
<<else>>
Au sortir de cet événement elle se retrouve avec beaucoup de contenu. Elle n'est pas tombée dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels elle aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie Eva aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement - LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Elle fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, elle se rend compte qu'elle a un peu plus de temps pour faire d'autres choses.
Comme au départ elle n'ose pas prendre d'engagement de réalisation pour l'équipe, elle utilise ce temps pour de la veille et de l'évangélisation.
Aprés quelques mois, l'équipe devient réellement autonome. Eva commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
Au bout d'un moment, elle devient coach, se fait remplacer par un membre de l'équipe entant que Scrum Master.
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
<<if setup.steps lt 12>>
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[Production VS Servant Leadership - LudiGames]]
#Eva se renseigne sur une nouvelle tendance [[LudiGames et Shape Up]]
#Eva se décide à voler de ses propres ailes [[Eva micro-entrepreneuse]]
<<else>>
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) Eva continue son accompagnement de la transformation.
* Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames et déploie une démarche adaptée à leur contexte.
* Elle va également se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile.
* Aprés quelques mois supplémentaires avec son équipe, et forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile. Elle propose donc de devenir coach au sein de l'entreprise.
[[Conclusion]]
<</if>>Eva met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Elle tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu'elle est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, elle décide de revoir sa copie. Quelle est la prochaine étape?
#[[8 - Le management remet en question la capacité d'Eva à avancer seule]]
#Eva se rend compte qu'il faut absolument [[8 - Accompagner le PO - LudiGames]]
#Eva entend parler de la communauté agile lilloise et décide de participer à son premier Agi'Lille. [[8 - Eva participe à son premier Agi'Lille]] Eva met du temps à comprendre ce qui arrive à son équipe.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelque part la notion de ShuHaRi et se dit que LudiGames doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tomber dans le CargoCult pour Scrum
Lorsque Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être
agile.
De quelle pratique vont-ils s'inspirer?
#[[8 - Kanban - LudiGames]]
#[[8 - Shape Up - LudiGames]]
#[[8 - DevOps - LudiGames]]Eva propose au PO un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Elle découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour Eva?
#Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[Eva devient PPO - LudiGames]]
#Eva le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[Product Box - LudiGames]].
#Eva se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Elle décide alors de [[Se former aux démarches produits - LudiGames]].
Eva met du temps à comprendre ce qui arrive à son équipe.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que LudiGames doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être
agile.
De quelle pratique vont-ils s'inspirer?
#[[9 - Kanban - LudiGames]]
#[[9 - Shape Up - LudiGames]]
#[[9 - DevOps - LudiGames]] Tout dans Scrum s'applique correctement chez LudiGames!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe d'Eva et LudiGames, le succés est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
Eva n'est plus sollicité par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Elle a donc du temps pour explorer des sujets complémentaires sur la toile.
Elle a réussi à amener un peu de fun dans les différents rituels. En commencant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, elle trouve un format ludiquer que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Elle change à chaque fois le focus de l'équipe et elle a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvent des anomalies, elles sont résolues séance tenante par l'équipe.
Eva est donc prête pour passer à la suite.
#En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!! [[Eva se passionne pour le No Estimate - LudiGames]]
#Le manager d'Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[Le Cargo Cult ca pique - LudiGames]]
#Forte de ce succés, Eva se dit qu'elle aimerait changer un peu d'horizon et se lancer dans le coaching agile. [[Eva devient coach agile chez LudiGames]] <img src="https://picsum.photos/200/300?random=1"/>Eva met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Elle tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu'elle est apparemment entrée en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
<<if setup.steps lt 12>>
Fort de ce constat, elle décide de revoir sa copie. Quelle est la prochaine étape?
#Eva se rend compte qu'il faut absolument [[9 - Accompagner le PO - LudiGames]]
#Eva entend parler de la communauté agile Lilloise et décide de participer à son premier Agi'Lille. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Fort de ce constat, elle décide de revoir sa copie. Elle décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, elle décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais elle se dit que si elle doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[8 - Le Kanban ca marche, mais ca prend du temps!]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à LudiGames d'entrer dans les cases. Eva propose alors de créer [[8 - Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[8 - LudiGames et Shape Up]]
#Y'en a marre de la vie de Scrum Master, que fait Eva aprés avoir tout tenté avec son équipe agile? [[8 - Fast Track Scrum Master - Eva]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[8 - La démarche produit chez LudiGames ]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après [[8 - Fast Track Scrum Master - Eva]] Eva et son équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[9 - La démarche produit - LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[9 - Des noms de rôles chez LudiGames]]Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi. Elle engage malgré tout un chantier avec le PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[9 - Gérer le run en Scrum - LudiGames]]
#Hop, on quitte le scrum master [[9 - Fast Track Scrum Master - Eva]]
<img src="https://picsum.photos/200/300?random=1"/>Eva et l'équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
<<if setup.steps lt 12>>
Qu'allons nous observer ensuite?
#Le client de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - James Indep]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[Une méthode maison pour son client - James Indep]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - James Indep]]
#L'aventure de James interpèle à chaque fois qu'il en parle dans ses réseaux, du fait il se dit qu'il pourrait en faire une histoire à raconter... [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
<<if setup.steps lt 12>>
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[James micro-entrepreneur]]
#James se met en visibilité sur son réseau d'entreprise préféré. [[James Quitte les rois du Ballon]]
<<else>>
[[Conclusion]]
<</if>>James se met en disponibilité. Son réseau agile est réduit mais son expérience est bien débutée, il est donc contacté par plusieurs entreprises... toutes autres considérations mises à part, il doit faire un choix entre :
<<if setup.steps lt 12>>
#Une petite société dynamique qui rêve de lancer un nouveau produit le plus efficacement possible. [[6 - James rejoint une startup]]
#Un client final qui se lance dans la démarche agile et qui souhaite, au travers de James dans un rôle de Scrum Master, être dans l'air du temps. [[6 - James développe la démarche agile chez un client final]]
#Passer à son compte. [[6 - James micro-entrepreneur]]
<<else>>
#Une petite société dynamique format startup qui rêve de lancer un nouveau produit le plus efficacement possible.
#Un acteur central de la vente en ligne cherche à étoffer son équipe agile.
#Une grosse ESN qui met en avant sa communauté agile, sa participation à des événements ainsi que tous les coachs qui la composent.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - James Indep]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - James Indep]] L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[James micro-entrepreneur]]
#James se met en visibilité sur son réseau d'entreprise préféré. [[James rejoint une startup]]
#James explore ce qu'il se passe chez les Rois du Ballon et se rend compte des limitations de son poste actuel. [[ScrumMaster c'est bien, mais limité - RDB]]<img src="https://picsum.photos/200/300?random=1"/>Chez les Rois du Ballon, le rôle de Scrum Master est bien défini, avec ses responsabilités, ses zones d'influence mais aussi ses limites et ses interdits.
De plus, l'organisation actuelle des Rois du Ballon fait que James n'a pas accés, entant que Scrum Master, aux différentes personnes d'influence de l'entreprise.
<<if setup.steps lt 12>>
Que faire dans ce cas là?
#James pourrait se pencher sur l'aspect produit en lien avec ses équipes. C'est vrai qu'il s'est beaucoup concentré sur l'efficacité opérationnelle de l'équipe mais il pourrait peut-être atteindre d'autres personnes au travers du PO et pourquoi pas, acquérir de nouvelles expériences. [[Accompagner le PO - RDB]]
#Chez les Rois du Ballon c'est mort, ca sert à rien d'essayerr de faire bouger les choses de l'intérieur, sans aide. Mais est-ce le cas ailleurs? James décide d'aller à la rencontre de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#Il va se battre! James décide d'aborder le sujet avec son manager. Celui-ci lui propose de monter un dossier pour expliquer son point de vue. [[James devient coach agile chez les Rois du Ballon]]
<<else>>
[[Conclusion]]
<</if>>James a une jolie expérience avec ses différentes équipes. Il a passé presque 2 ans au sein de la dernière et les challenges de celle-ci lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Cependant, il a plusieurs possibilités devant lui.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James prévoit de s'inscrire dés que ses finances lui permettront à un cursus de formation "coach progessionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James se promet de participer à l'événement le plus proche de chez lui pour commencer : Agi'Lille
[[Conclusion]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engager sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
<<if setup.steps lt 12>>
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contactée via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec elle mais elle a beaucoup entendu parler de lui. Elle lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[La fresque du climat - James Indep]]
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[James se passionne pour le Serious Gaming - Indep]]
<<else>>
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il doit choisir sa prochaine mission. Les choix qui se présentent devant lui sont les suivants :
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec elle mais elle a beaucoup entendu parler de lui. Elle lui propose une rencontre car elle cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.
#EJames est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur la fresque du climat.
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'agile hors it.
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, il se passionne pour le serious gaming et participe entre autre aux meetups et événements lillois.
[[Conclusion]]
<</if>>James s'est lancé. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d' amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
<<if setup.steps lt 12>>
Maintenant que James est établi entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[James organise un séminaire produit - Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[James participe à son premier Agi'Lille pour un client]]
<<else>>
Maintenant que James est établi entant qu'agiliste indépendant (coach), il va pouvoir explorer les sujets suivants :
* Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et va notamment découvrir les meetups Nord Agile, l'Agi'Lille et les Agile Games Hauts de France.
* Un de ses clients va lui a proposé d'animer un séminaire autour de la vision produit de son entreprise. L'animation d'événements n'est pas encore son point fort mais il va se lancer avec ce client bienveillant.
* Un des clients de James est sponsor de l'Agi'Lille cette année grâce à James qui le tanne avec le sujet depuis quelques mois! Chance rare, il compte sur James pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé!
[[Conclusion]]
<</if>>James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[James devient PPO - RDB]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[Product Box - RDB]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[Se former aux démarches produits - RDB]].
<<else>>
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permis de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projetter sur la prochaine évolution de leur organisation).
En prenant ces responsabilités de "rédaction", James se rend compte que certains basics sont à revoir. Il propose au PO d'animer un atelier Product Box pour être sur qu'ils sont sur la même longueur d'onde au niveau de la vision du produit.
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]] James semble tout indiquée pour accompagner les Rois du Ballon sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Rois du Ballon.
Au bout de 9 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Rois du Ballon!
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Rois du Ballon plus en amont dans leur démarche agile.
<<if setup.steps lt 12>>
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[Un Scrum Master pour remplacer James - RDB]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[Créer une nouvelle équipe Scrum - RDB]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[James participe à son premier Agi'Lille - RDB]]
#James décide de se lancer dans la description de la démarche agile selon le Rois du Ballon afin de créer la pierre fondatrice de la suite de l'avent
<<else>>
James va d'abord devoir explorer les différentes possibilités pour trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Va-t-il proposer de prendre un Scrum Master externe, avec ou sans expérience? Ou va-t-il essayer de pousser pour faire monter quelqu'un de l'équipe actuelle au rôle de Scrum Master? Peut-être que le jeune Antoine, le stagiaire en alternance qui doit signer avec LudiGames une fois son diplôme en poche, est-il le candidat idéal?
James va ensuite devoir accompagner la nouvelle équipe formée. En plus de proposer également un moyen d'identifier un Srum Master, il sait que l'impact de la création d'une nouvelle équipe n'est pas à négliger. Va-t-il proposer de créer une toute nouvelle équipe, avec son propre backlog ou avec un backlog commun? Ou utilisera-t-il le principe de seeding en créant 2 équipes à partir de celle existante?
Entant que coach, il va aussi avoir plus de temps pour faire de la veille (enfin il espère) et compte bien sur la communauté agile lilloise pour l'aider. Il participera entre autre à l'Agi'Lille et aux différents meetups qui sont à sa disposition sur Lille.
Pour fini, James devra aussi décider de comment accompagner les Rois du Ballons dans leur évolution agile. Voudra-t-il pousser pour une démarche agile maison? Poussera-t-il pour avancer sur la démarche produit?
[[Conclusion]]
<</if>>Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu'[[8 - On ne devient pas coach tout seul chez LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[8 - Eva rejoint Nord Agile]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[8 - Eva participe à son premier Agi'Lille]]Eva a une jolie expérience avec son équipe. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[9 - Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[9 - Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#A force de petits succés et de travail hors du cadre stricte de Scrum Master, Eva réussi à montrer à LudiGames qu'elle a l'étoffe d'un coach. On lui propose donc de suivre ce chemin. [[9 - Eva devient coach agile chez LudiGames]]
#Eva a ouvert la boite de Pandore! Elle a maintenant accès à une communauté agile locale (à laquelle elle aurait eu accès sans nécessaire s'engager dans l'association!), à des connaissances complémentaires, à un réseau. Aprés plusieurs mois d'hésitation, elle décide de prendre son indépendance vis à vis de LudiGames et devient micro-entrepreneuse. [[Eva micro-entrepreneuse]]
#Par le biais de ces meetups et événement, Eva découvre la démarche Kanban qu'elle essaye d'explorer avec son équipe. [[9 - LudiGames et Kanban]]
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - Eva se passionne pour le Serious Gaming - LudiGames]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - LudiGames]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - LudiGames]]Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]].
<img src="https://picsum.photos/200/300?random=1"/>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
<<if setup.steps lt 12>>
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva décide d'explorer [[Kanbanzine - LudiGames]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[La démarche produit - LudiGames]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après [[Eva micro-entrepreneuse]]
<<else>>
Au sortir de cette formation Eva se lance dans le Kanban mais commence par expliquer à son manager que cette démarche va prendre du temps. Elle essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva et l'équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
<<if setup.steps lt 12>>
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[Une méthode maison pour LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - LudiGames]]
#L'aventure d'Eva interpèle à chaque fois qu'elle en parle dans ses réseaux, du fait elle se dit qu'elle pourrait en faire une histoire à raconter... [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>LudiGames a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, Eva a du pain sur la planche.
Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[Eva découvre les meetups et Nord Agile - LudiGames]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[Eva organise un séminaire produit - LudiGames]]L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[James micro-entrepreneur]]
#James explore ce qu'il se passe chez les Rois du Ballon et se rend compte des limitations de son poste actuel. [[9 - ScrumMaster c'est bien, mais limité]]Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - RDB]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Rois du Ballon. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - RDB - Coach]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - RDB]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[James se lance dans l'écriture d'une conférence - RDB]] James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - RDB]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - RDB]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille - RDB]]
Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant il faut trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
Il va devoir choisir comment orienter sa recherche de missions, va-t-il décider qu'il a maintenant la capacité d'endosser des missions de coaching et donc n'accepter que celles-ci ou pour sa prise d'activité va-t-il favoriser le reseau et prendre toutes les missions qui se présentent, du moment qu'elles sont dans un contexte agile.
Ensuite, il devra aussi gérer sa montée en compétence. Comment trouver le temps pour se former, faire de la veille quand on est à son compte? Doit-on uniquement faire ce genre de choses en HNO? Peut-on investir de son temps directement la première année? Quel impact sur les revenus et la qualité de vie sur le moyen terme?
En plus, James a plein d'envie d'un point de vue collaboration mais c'est pas des plus facile quand on est indep. Pour le peu que les personnes avec lesquelles il veut collaborer soient elles aussi indep, l'alignement des agendas ne sera pas des plus aisé.
Mais James aura du succés, il sera régulièrement challengée par ses clients et réussira à se faire un nom à force de réseautage, de participation à la communauté agile via des événements, des publications en ligne, des créations...
<<if setup.steps lt 12>>
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[On ne devient pas coach tout seul - James Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[Indep c'est bien, tout seul ca craint!! - James]]
<<else>>
[[Conclusion]]
<</if>>Chez les Rois du Ballon, le rôle de Scrum Master est bien défini, avec ses responsabilités, ses zones d'influence mais aussi ses limites et ses interdits.
De plus, l'organisation actuelle des Rois du Ballon fait que James n'a pas accés, entant que Scrum Master, aux différentes personnes d'influence de l'entreprise.
Que faire dans ce cas là?
#James pourrait se pencher sur l'aspect produit en lien avec ses équipes. C'est vrai qu'il s'est beaucoup concentré sur l'efficacité opérationnelle de l'équipe mais il pourrait peut-être atteindre d'autres personnes au travers du PO et pourquoi pas, acquérir de nouvelles expériences. [[Accompagner le PO - RDB]]
#Chez les Rois du Ballon c'est mort, ca sert à rien d'essayerr de faire bouger les choses de l'intérieur, sans aide. Mais est-ce le cas ailleurs? James décide d'aller à la rencontre de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#Il va se battre! James décide d'aborder le sujet avec son manager. Celui-ci lui propose de monter un dossier pour expliquer son point de vue. [[James devient coach agile chez les Rois du Ballon]]<img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!! James n'est pas déçue!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadé qu'[[On ne devient pas coach tout seul - James Indep]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille entant qu'Indep]]
<<else>>
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>James rejoint DoctoChat, une société qui travaille à une application pour faciliter le travail des médecins dans leurs cabinet en proposant des questionnaires à compléter par les patients lorsqu'ils sont en salle d'attente.
Depuis quelques temps, l'équipe a décidé qu'il lui fallait un Scrum Master. Les raisons sont multiples et comptent parmi elles:
* L'augmentation de la taille de l'équipe de développement de 3 à 8 développeurs
* Les demandes de plus en plus urgentes de la part des responsables de l'entreprise
* L'aspect chaotique de la priorisation des demandes
* La taille des releases qui commence à augmenter.
<<if setup.steps lt 12>>
James se lance donc à corps perdu dans ce nouveau challenge et décide :
#D'explorer son intuition qui lui indique que DoctoChat souffre du [[Syndrôme de la grosse release - DoctoChat]]
#De mettre en place ce qu'il a appri chez son précédent employeur et d'appliquer exactement la même méthode. [[Le Cargo Cult ca pique - DoctoChat]]
#James décide de prendre son temps et se lance dans une phase d'[[Observation de l'équipe DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>Bien qu'ayant eu des succès avec Scrum et sa première équipe, Eva est persuadée que le framework n'est pas 100% adapté pour LudiGames au général.
Elle décide de se poser et de refléchir à la situation.
Il est trés probable que les problématiques rencontrées par sa première équipe se répêtent pour d'autres équipes.
Y'a-t-il une solution universelle pour résoudre les différentes problématiques et proposer un fonctionnement agile commun à tout LudiGames?
Aprés plusieurs échanges en interne, beaucoup de lecture... Eva se retrouve devant un choix pas facile.
Quelle direction voulons-nous la voir explorer?
#Chez LudiGames, jusqu'à maintenant, le gros souci des developpeurs est le côté imprévisible du run (la gestion des anomalies de production et des demandes de support). Du fait, Eva propose de mettre en place des étapes complémentaires de qualité dans le processus de livraison. [[Scrum Master et QA chez LudiGames - Coach]]
#Pour Eva, avant de s'attaquer à rendre les pratiques des équipes de développement communes, il faut mettre en place une approche d'entreprise à la démarche produit.Elle travaille donc à [[La démarche produit chez LudiGames]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[7 - La Rache chez LudiGames]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - LudiGames]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - LudiGames]] Nouveau challenge pour James : il doit accompagner RDB dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, il pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager de James a choisi l'option "Seeding".
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[8 - James organise un séminaire produit - RDB]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, James propose la mise en place d’[[8 - Un comité de transformation - RDB]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[8 - Des problèmes d'engagement - RDB]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - RDB]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[8 - Scrum Master et QA - RDB]]
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[8 - La Rache chez RDB - Coach]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[8 - Valeur Business - RDB]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[8 - La dette technique et Scrum - RDB]] James passant coach, il faut trouver un Scrum Master pour le remplacer auprés de l'équipe existante.
En réunion avec son manager il hésite sur les préconnisations qu'il pourrait faire.
En effet, pour le remplacer les Rois du Ballon ont le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, aprés tout les Rois du Ballon sont capables d'embaucher de nouvelles personnes, James se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et James se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
James est également tenté de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Il entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ca risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en delaissant un peu le développement.
Aprés plusieurs longues réunions, le management accepte la solution préconnisée par James : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'il amène le sujet à l'équipe, personne ne se porte volontaire directement, James leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
James est enchanté, il cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
<<if setup.steps lt 12>>
Maintenant qu'il est remplacé, James peut se consacrer à la suite :
#[[8 - James organise un séminaire produit - RDB - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d’[[8 - Un comité de transformation chez RDB]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[8 - Des problèmes d'engagement chez RDB - Coach]]
<<else>>
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez RDB - Coach]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business RDB - Coach]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - RDB - Coach]]
<<else>>
Avec son groupe de travail, James doit donc s'atteler aux chantiers suivants :
* Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business chez les Rois du Ballon.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner DoctoChat correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez DoctoChat]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - DoctoChat]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - DoctoChat]]
<<else>>
Avec son groupe de travail, James doit donc s'atteler aux chantiers suivants :
* Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business chez les Rois du Ballon.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille entant qu'Indep]]
#Aprés tous ces meetups, [[James se passionne pour le Serious Gaming - Indep]]
<<else>>
Il revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et il se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, il développe l'envie de rendre à la communauté à hauteur de ce qu'il y a récupéré depuis quelques mois. Il commence à rédiger une conférence. Peut-être le croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais James a la chance de ne pas être tout seul sur l'animation du stand et il trouve donc un peu de temps pour son apprentisage personnel.
James peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
Au sortir de l'événement James a plein d'idées et d'envies.
* Il a adoré les ateliers ludiques auxquels il a participé. il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
* Il a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. Il aimerait pouvoir un jour leur ressembler!
* Aprés l'atelier auquel il a participé, il se passionne pour le No Estimate.
* Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
Cependant, il subit un effet secondaire souvent rencontré lors de ce genre d'événements. Aprés avoir rencontré toutes ces personnes bienveillantes et bien pensantes, tous ces puits de culture agile, d'expériences variées, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros Syndrôme de l'imposteur!
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit des Rois du Ballon à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation - RDB]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions aprés un séminaire - RDB]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - RDB]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - RDB]]
<<else>>
Il propose au management de créer un comité de transformation auquel il pourrait se joindre.
Il pourrait aussi animer lui même la transformation de manière itérative.
Il cherche aussi à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
<<if setup.steps lt 12>>
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - RDB]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[Démarche OKR - RDB]].
<<else>>
* Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la démarche OKR.
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez RDB]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - RDB]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - RDB]]
<<else>>
Avec son groupe de travail, James doit donc s'atteler aux chantiers suivants :
* Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business chez les Rois du Ballon.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à RDB [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
#James propose à son manager de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up - RDB]]
#Fort des retours de son manager, James propose de créer [[Une méthode maison pour RDB]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, James entend parler d'un événement Lillois autour de la démarche agile. James participe à son premier Agi'Lille.
* James trouve rapidement une réponse qu'il souhaite amener à sa direction et prépare un atelier sur le fait de se focaliser sur la création de valeur et plus sur les dépenses.
* James découvre d'autres manière d'être agiles que Scrum. Il lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue Rois du Ballon
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>C'est étrange ce qui se passe chez DoctoChat: c'est comme si plus ils veulent mettre en prod, plus ils retardent leurs mises à jour.
Mais quel est donc ce mal qui les touche?
James a discuté il y a quelques temps avec un ami qui lui décrivait une situation similaire: ''le syndrôme de la grosse release'' :
* Plus on veut mettre de nouveautés en ligne d'un coup, plus la mise à jour du produit prend du temps à être créée.
* Plus le temps s'écoule entre 2 mises en production, plus on veut profiter du temps disponible pour faire une grosse mise à jour.
* Plus la mise à jour est importante, plus il faut prévoir d'accompagnement au changement auprés des utilisateurs et plus les attentes de ces derniers augmentent.
* Plus les attentes des utilisateurs augmentent, plus on essaye d'en mettre dans la nouvelle version du produit...
James se doit donc d'agir... mais que va-t-il pouvoir faire?
<<if setup.steps lt 12>>
#Il décide de faire appel à une aide extérieur. Pour celà, il participe à [[8 - Son premier forum ouvert - DoctoChat]]
#Il décide de parler de son diagnostic aux demandeurs chez DoctoChat et de revoir avec eux les ambitions derrière les mises à jour du produit. [[8 - James travaille aux ambitions de DoctoChat]]
#Pour James c'est sûr, tout passe par les POs et [[La démarche produit - DoctoChat]]!
<<else>>
* Aller cherche de l'aide lors d'un Forum Ouvert
* Parler de son diagnostic aux demandeurs chez DoctoChat et de revoir avec eux les ambitions derrière les mises à jour du produit.
* Pour James c'est sûr, tout passe par les POs et la démarche produit chez DoctoChat!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James met du temps à comprendre ce qui arrive à son équipe / entreprise.
Il tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'il est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
<<if setup.steps lt 12>>
Fort de ce constat, il décide de revoir sa copie. Quelle est la prochaine étape?
#[[8 - Le management DoctoChat remet en question la capacité de James à avancer seul]]
#James se rend compte qu'il faut absolument [[8 - Accompagner le PO - DoctoChat]]
#James entend parler de la communauté agile Lilloise et décide de participer à [[8 - Son premier forum ouvert - DoctoChat]]
<<else>>
Fort de ce constat, il décide de revoir sa copie. Il décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>L'observation se passe bien. James se rend compte que son accompagnement pour la nouvelle équipe ne peut pas être le même que lors de son expérience précédente. Cette dernière est beaucoup plus autonome et ne lui demande que peu de choses. Ce ne sont donc pas l'animation ou les freins rencontrés par l'équipe qui sont reponsable de leur capacité réduite à livrer de la valeur
<<if setup.steps lt 12>>
Que se passe-t-il ensuite?
#James se rend compte d'un manque côté Product Owner sur la nouvelle équipe. Il se rapproche du métier et décide d'[[6 - Accompagner le PO]].
#James s'en sort pas mal avec ses deux équipes, mais il ressent le besoin de se renouveler. Il décide de participer à des conférences pour creuser un peu plus la démarche agile et les méthodes associées. Il se rend à l'[[6 - James participe à son premier Agi'Lille - RDB]].
#James commence à envisager son futur. Il cherche une formation qui pourrait l'emmener plus loin dans son développement agile. [[6 - Une formation agile pour James- RDB]]
<<else>>
* James identifie un manque côté Product Owner sur la nouvelle équipe. Il se rapproche du métier et décide d'accompagner le PO. Ils travaillent ensemble à la priorisation par la valeur, à la définition de prêt.
* James s'en sort pas mal avec ses deux équipes, mais il ressent le besoin de se renouveler. Il décide de participer à des conférences pour creuser un peu plus la démarche agile et les méthodes associées. Il se rend à son premier Agi'Lille.
* James commence également à envisager son futur. Il cherche une formation qui pourrait l'emmener plus loin dans son développement agile : Kanban, Démarche produit, Management 3.0...
[[Conclusion]]
<</if>>James a une jolie expérience avec ses différentes équipes. Il a passé presque 2 ans au sein de la dernière et les challenges de celle-ci lui ont forgé certaines convictions.
James comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - DoctoChat]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - DoctoChat]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille - DoctoChat]]
<<else>>
Cependant, il a plusieurs possibilités devant lui.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James prévoit de s'inscrire, enfin si son manager valide le budget, à un cursus de formation "coach progessionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James se promet de participer à l'événement le plus proche de chez lui pour commencer : Agi'Lille
[[Conclusion]]
<</if>>Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Après cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - DoctoChat]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Rois du Ballon. Ça sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - DoctoChat]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - DoctoChat]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[James se lance dans l'écriture d'une conférence - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - DoctoChat]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - DoctoChat]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - DoctoChat]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - DoctoChat]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - DoctoChat]]
<<else>>
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>>James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[9 - Un miroir coach - RDB]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[9 - Une formation certifiante Coach - RDB]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[9 - James participe à son premier Agi'Lille - RDB]]
Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - James se passionne pour le Serious Gaming - RDB]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Rois du Ballon. Ca sort un peu de sa zone de confort mais James se lance. [[9 - James organise un séminaire produit - RDB]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[9 - Agile Games France - RDB]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[9 - James se lance dans l'écriture d'une conférence - RDB]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - RDB]]
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[8 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[8 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[8 - Prouver l'impact de la dette technique - LudiGames]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[8 - Fast Track Scrum Master - Eva]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[9 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - LudiGames]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[9 - Fast Track Scrum Master - Eva]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - LudiGames]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[Le WSJF chez LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
] <img src="https://picsum.photos/200/300?random=1"/>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF. [[Le WSJF - LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[Sensibilisation agile des PP - LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[Eva organise un séminaire produit - LudiGames]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une Sensibilisation agile des PP.
* Eva a grandement apprécié de travailler avec le PO, elle se dit qu’elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - LudiGames]]
#Ne suivons plus l'aspect Scrum Master et voyons l'aprés [[Fast Track Scrum Master - Eva]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - LudiGames]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[Le WSJF - LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
<<else>>
Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez LudiGames. [[Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - LudiGames]]
<<else>>
#Travailler à la Valeur Business chez LudiGames.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>>C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt - RDB - Coach]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[9 - Le WSJF chez RDB - Coach]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB - Coach]]
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez les Rois du Ballon. [[9 - Valeur Business RDB - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - RDB - Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - RDB - Coach]]C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - RDB]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - RDB]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[8 - Et toi, en quoi tu contribue aux OKRs? - LudiGames]]
#Le management comprend les OKR, le président de LudiGames a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explirer le Kanban. [[8 - LudiGames et Kanban]]
#Lançez-vous, a dit le président au manager d'Eva. Il est convenu que l'équipe va servir de pilote. Eva se lance donc et s'interroge sur [[8 - La ritualisation du suivi des OKR]]
#OKR check, Scrum check... et aprés? [[8 - Fast Track Scrum Master - Eva]] Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[8 - Eva pilote de vision - LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[8 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[8 - Eva micro-entrepreneuse]] Tout le monde en parle, et les agilistes expérimentés autour d'Eva n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant il lui faut trouver des clients et se lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale d'Eva?
#Une chose est certaine pour Eva : elle veut être coach agile. Et donc elle n'acceptera que des missions de cet ordre. [[7 - On ne devient pas coach tout seul - Eva]]
#Ces copains lui ont dit : au départ, il faut te faire ta clientèle. Elle décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[7 - Engranger des missions - Eva]]
#Au bout de quelques temps Eva commence à subir les effets secondaires du lancement en indépendant. Elle a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[7 - Indep c'est bien, toute seule ca craint!!]]
Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier LudiGames.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein de LudiGames qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yaourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yaourt" pour commencer à définir ce qui correspond à une bonne vision
** Après midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Après midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Après ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge après, à Eva de porter cette vision au sein de l'entreprise. La partie visibilité de LudiGames vers l'extérieur sera traitée dans un second temps.
Comment réagit Eva à cette proposition?
#Emballée par le programme, après tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet. [[9 - De vision à action - LudiGames]]
#Le projet vision sera un succès, on a pas de doute là dessus, après tout VisionMaster sont les experts de la vision. Voyons plutôt comment se débrouille Eva avec son équipe. [[9 - Eva continue avec son équipe Scrum - LudiGames]]Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[Production VS Servant Leadership - LudiGames]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[Le craftsmanship - LudiGames]].
#Bon, et si on avancait plus rapidement dans le temps! Que fais Eva aprés Scrum Master? [[Fast Track Scrum Master - Eva]] Eva lit le livre de Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[DevOps - LudiGames]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d'acceleration il faut avant tout que LudiGames travaille à sa démarche produit. [[Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[Une présentation de la démarche agile à l'équipe - LudiGames]]
<<else>>
Eva explore ensuite les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum.
Un autre des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. Le DevOps dont tout le monde parle pourrait-il être une solution?
Eva se dit que pour amener toute l'entreprise à se poser les questions d'acceelration il faut avant tout que LudiGames travaille à sa démarche produit.
Eva se demande enfin, si avant d'accélérer en agile il ne faudrait pas plutôt revenir aux bases de la démarche.
[[Conclusion]]
<</if>>Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
<<if setup.steps lt 12>>
#Elle pourrait demander à TechSys de venir lui présenter [[Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
<<else>>
* Elle pourrait demander à TechSys de venir lui présenter Gunther.
* Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le Lego, Scrum et Chocolat pour le DevOps.
[[Conclusion]]
<</if>>
Eva entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu )à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, Eva a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
Eva retourne à son bureau avec quelques questions. Elle se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Elle tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Elle entend le terme antipatern.... Ca l'inquiète.
Elle se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour Eva.
Forte de ces arguments elle en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunio an avec les dirigeants, ce qu'elle fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée. On lui propose prendre plus de hauteur par rapport à son rôle de Scrum Master [[9 - Eva devient coach agile chez LudiGames]]
#L'utilisation des OKRs est revue. Maintenant Eva se refocalise sur son équipe et l'utilisation qu'ils vont faire des OKR. [[9 - La ritualisation du suivi des OKR - LudiGames]]
#OK, OKRs :D Mais maintenant que se passe-t-il dans l'équipe d'Eva? [[9 - Eva continue avec son équipe Scrum - LudiGames]]Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[9 - Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[9 - Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[9 - Le Kanban ca marche, mais ca prend du temps! - Eva]].
Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[9 - Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[Eva micro-entrepreneuse]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva décide d'explorer [[Kanbanzine - LudiGames]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[La démarche produit - LudiGames]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après [[Fast Track Scrum Master - Eva]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[9 - La démarche produit - LudiGames]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après et notamment ce qu'elle pourrait faire en Indep [[Eva micro-entrepreneuse]]Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[Eva micro-entrepreneuse]]
#Eva souhaite faire évoluer LudiGames sur la voix vertueuse de la démarche agile. Cependant, son manager n'est pas persuadé qu'elle peut y arriver seule. [[Le management remet en question la capacité d'Eva à avancer seule - LudiGames]] Eva et son équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles chez LudiGames]]Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[Eva pilote de vision - LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se mêler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[Eva micro-entrepreneuse]] Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - LudiGames]]
#Le management comprend les OKR, le président de LudiGames a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explirer le Kanban. [[LudiGames et Kanban]]
#Lançez-vous, a dit le président au manager d'Eva. Il est convenu que l'équipe va servir de pilote. Eva se lance donc et s'interroge sur [[La ritualisation du suivi des OKR - LudiGames]]
#OKR check, Scrum check... et aprés? [[Fast Track Scrum Master - Eva]] <img src="https://picsum.photos/200/300?random=1"/>Eva entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu )à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, Eva a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
Eva retourne à son bureau avec quelques questions. Elle se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Elle tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Elle entend le terme antipatern.... Ca l'inquiète.
Elle se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour Eva.
Forte de ces arguments elle en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'elle fait.
<<if setup.steps lt 12>>
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée. On lui propose prendre plus de hauteur par rapport à son rôle de Scrum Master [[Eva devient coach agile chez LudiGames]]
#L'utilisation des OKRs est revue. Maintenant Eva se refocalise sur son équipe et l'utilisation qu'ils vont faire des OKR. [[La ritualisation du suivi des OKR - LudiGames]]
#OK, OKRs :D Mais maintenant que se passe-t-il dans l'équipe d'Eva? [[Eva continue avec son équipe Scrum - LudiGames]]
<<else>>
Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée. On lui propose prendre plus de hauteur par rapport à son rôle de Scrum Master et devient coach agile chez LudiGames.
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
<<if setup.steps lt 12>>
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[Production VS Servant Leadership - LudiGames]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[Le craftsmanship - Eva]]
<<else>>
Elle continue à se poser des questions et cherche de nouveaux sujets.
* Eva se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur).
* Dans le même temps, elle décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors le craftsmanship.
[[Conclusion]]
<</if>>Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
<<if setup.steps lt 12>>
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[Eva micro-entrepreneuse]]
#Eva souhaite faire évoluer LudiGames sur la voix vertueuse de la démarche agile. Cependant, son manager n'est pas persuadé qu'elle peut y arriver seule. [[Le management remet en question la capacité d'Eva à avancer seule - LudiGames]]
<<else>>
Que va faire Eva ensuite?
* Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. Eva devient coach agile chez LudiGames.
* Aprés 2 ans au rôle de coach, Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. Elle devient donc micro-entrepreneuse.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[Eva pilote de vision - LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[Eva micro-entrepreneuse]]
<<else>>
Impressionnés par le travail et l'engagement d'Eva, les dirigeants lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à Eva de porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
Eva est Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet.
[[Conclusion]]
<</if>>Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier LudiGames.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein de LudiGames qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à Eva de porter cette vision au sein de l'entreprise. La partie visibilité de LudiGames vers l'extérieur sera traitée dans un second temps.
<<if setup.steps lt 12>>
Comment réagit Eva à cette proposition?
#Emballée par le programme, après tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet. [[De vision à action - LudiGames]]
#Le projet vision sera un succès, on a pas de doute là dessus, après tout VisionMaster sont les experts de la vision. Voyons plutôt comment se débrouille Eva avec son équipe. [[Eva continue avec son équipe Scrum - LudiGames]]
<<else>>
Eva est Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet.
[[Conclusion]]
<</if>>Eva met du temps à comprendre ce qui arrive à son équipe.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que LudiGames doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsqu'Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
[[Conclusion]]
Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]].
<<else>>
Pour aborder le kanban avec son équipe, Eva va se lancer dans plusieurs initiatives.
* Elle explore l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son équipe.
* Quitte à explorer ce sujet, elle se dit qu'il vaut mieux se renseigner directement à la source. Elle s'inscrit à une formation avec Laurent Morisseau.
Via cette double initiative,, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!
[[Conclusion]]
<</if>>Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
<<if setup.steps lt 12>>
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - LudiGames]]
#Le management comprend les OKR, le président de LudiGames a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explorer le Kanban. [[LudiGames et Kanban]]
#Lançez-vous, a dit le président au manager d'Eva. Il est convenu que l'équipe va servir de pilote. Eva se lance donc et s'interroge sur [[La ritualisation du suivi des OKR - LudiGames]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. Eva découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>>Eva a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et son client.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur le client.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que l'entreprise entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[Eva pilote de vision - Indep]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - Eva Indep]] Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - Eva Indep]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explorer le Kanban. [[Kanban - Eva Indep]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. Eva les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - Eva Indep]]<img src="https://picsum.photos/200/300?random=1"/>Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe test d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Forte de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
<<if setup.steps lt 12>>
Quelle est maintenant la suite pour Eva?
#Eva est surprise par une conversation en salle de pause. [[Et toi, en quoi tu contribue aux OKRs? - Eva Indep]]
#Etant écoresponsable dans l'ame, Eva participe un à atelier [[La fresque du climat - Eva Indep]]
#Une des équipes client est empêtrée dans la dette technique. Eva tente de leur amener des pistes de réflexion. [[La dette technique et Scrum - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
<<if setup.steps lt 12>>
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva décide d'explorer [[Kanbanzine - Eva Indep]]
#Eva se lance dans le Kanban mais commence par expliquer à son client que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
<<else>>
Au sortir de cette formation Eva se lance dans le Kanban mais commence par expliquer à son client que cette démarche va prendre du temps. Elle essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva et une équipe client se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc l'équipe dans l'identification des workflow externes et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
<<if setup.steps lt 12>>
Qu'allons nous observer ensuite?
#Le client d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[Une méthode maison pour son client - Eva Indep]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Eva propose au Scrum Master de lui en parler ensemble. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez son client. [[Valeur Business Client - Eva Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - Eva Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - Eva Indep]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu )à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, Eva a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
Eva retourne à son bureau avec quelques questions. Elle se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Elle tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Elle entend le terme antipatern.... Ca l'inquiète.
Elle se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
<<if setup.steps lt 12>>
Bref, c'est pas une bonne idée pour Eva.
Forte de ces arguments elle en parle à son client. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'elle fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - Eva Indep]]
#L'utilisation des OKRs est revue. Maintenant Eva se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - Eva Indep]]
<<else>>
Bref, c'est pas une bonne idée pour Eva.
Forte de ces arguments elle en parle à son sponsor. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'elle fait. Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. Eva gagne en notoriété et son initiative est remarquée.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a fait pas mal de recherches pour proposer à son un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts, Eva et son client.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur le client.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que l'entreprise entant que telle n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[Eva pilote de vision - Indep]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - Eva Indep]]
<<else>>
Impressionnés par le travail et l'engagement d'Eva, les dirigeants lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, au client, de trouver un interne pour porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
Eva est Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet.
[[Conclusion]]
<</if>>Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
<<if setup.steps lt 12>>
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - Eva Indep]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explorer le Kanban. [[Kanban - Eva Indep]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. Eva les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - Eva Indep]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. Eva découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>>Eva s'est lancée. Elle savait qu'être indépendante lui demanderait de faire des sacrifices. Mais elle n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, elle comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Elle décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, elle en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel elle n'avait pas non plus pensé, réside dans le fait qu'elle rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, Eva réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant qu'Eva est établie entant qu'agiliste indépendante (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, elle découvre la communauté lilloise, les différents événements et notament [[8 - Eva découvre les meetups et Nord Agile entant qu'Indep]]
#C'est bien beau de devoir gérer sa montée en compétences toute seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient la voir avec un challenge d'organisation d'événement interne à grande échelle, Eva doit explorer de nouveaux domaines. [[8 - Eva organise un séminaire produit - Indep]]
#Un des clients d'Eva est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur Eva pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[8 - Eva participe à son premier Agi'Lille pour un client]]
Eva a une jolie expérience avec son équipe LudiGames. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, Eva veut trouver des missions interessantes, cependant, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'elle voit passer dans les offres auxquelles elle a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[8 - Un miroir coach - Eva Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[8 - Une formation certifiante Coach - Eva Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[8 - Eva participe à son premier Agi'Lille entant qu'Indep]]
Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" Eva se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
Eva n'est donc pas trés regardante quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'elle devra engagée sont dans ses domaines de compétence.
Elle se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Elle reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, Eva n'hésite pas à partager ses réflexions, ses expériences... Elle est donc active sur les réseaux sociaux, elle crée son propre site internet, et se demande si elle ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : Eva recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'elle recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'elle ne maitrise pas tous ces sujets.
Eva est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Elle va devoir choisir sa prochaine mission. Que trouve-t-elle dans sa bannette (boite mail)?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais il a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - Eva]]
#Eva est investie, comme la plupart d'entre nous, dans l'éco-responsabilité. Elle entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animatrice de la "Fresque du numérique". Avant cela, elle participe à un atelier sur [[8 - La fresque du climat - Eva Indep]]
#Son apporteur d'affaire a trouvé une mission plutot interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Elle a l'opportunité de travailler sur l'[[8 - Agile Hors IT - Eva]]
#Lors de sa dernière mission, elle a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements; Elle a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[8 - Eva se passionne pour le Serious Gaming - Indep]]Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[9 - Eva rejoint Nord Agile Indep]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[9 - Eva participe à son premier Agi'Lille entant qu'Indep]]
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais Eva a la chance de ne pas être toute seule sur l'animation du stand et elle trouve donc un peu de temps pour son apprentisage personnel.
Eva peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[9 - Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[9 - Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - Eva se lance dans l'écriture d'une conférence - Indep]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - Eva Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire - Eva Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour son client - Eva Indep]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le managment de LudiGames demande à Eva de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - Eva Indep]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[Un comité de transformation - Eva Indep]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[Faire vivre les actions aprés un séminaire - Eva Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - Eva Indep]]
#S'enfermer chez elle et se prendre un méga [[Syndrôme de l'imposteur - Eva Indep]]Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - Eva Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[Démarche OKR - Eva Indep]].
<img src="https://picsum.photos/200/300?random=1"/>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
Eva réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client d'Eva. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - Eva Indep]]
#Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[La Rache - Eva Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - Eva Indep]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - Eva Indep]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de litérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - Eva Indep]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up pour son client - Eva Indep]]
#Forte des retours de son client, Eva propose de créer [[Une méthode maison pour son client - Eva Indep]] tout en restant dans la démarche agile.Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Par le biais de ces meetups et événement, Eva découvre la démarche Kanban qu'elle essaye d'explorer avec son équipe. [[Kanban - Eva Indep]]
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - Indep]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - Indep]]C'est une notion difficile la valeur business!! Comment comparer la création de valeur d'un nouveau produit vs l'ajout de fonctionnalités sur une application existante?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet chez le client d'Eva, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - Eva Indep]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[Le WSJF - Eva Indep]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - Eva Indep]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Eva propose au Scrum Master de lui en parler ensemble. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez son client. [[Valeur Business Client - Eva Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - Eva Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - Eva Indep]]Comme beaucoup de personnes, les membres des équipes du client d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[Kanbanzine - Eva Indep]] pour faire découvrir, par la pratique, ces différents concepts à son client.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - Eva Indep]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son client. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - Eva Indep]].
<<else>>
Eva a plusieurs chantiers devant elle :
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, elle réussi à déployer la démarche auprés de son client. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>>Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein de l'entreprise qui participeront aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à un interne de porter cette vision au sein de l'entreprise. La partie visibilité de son client vers l'extérieur sera traitée dans un second temps.
<<if setup.steps lt 12>>
Comment réagit Eva à cette proposition?
#Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet. [[De vision à action - Eva Indep]]
#Son interaction avec David lui fait se dire qu'elle peut enfin accepter une mission qui la fasse sortir de sa zone de confiance. Un client la solicite et accompagne la [[Démarche OKR - Eva Indep]]
<<else>>
Eva est Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva met du temps à comprendre ce qui arrive chez son client.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsqu'Eva retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - Eva Indep]]
#[[Shape Up pour son client - Eva Indep]]
#[[DevOps - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>>
C'est une notion difficile la valeur business!! Comment comparer la création de valeur d'un nouveau produit vs l'ajout de fonctionnalités sur une application existante?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet chez le client d'Eva, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - Eva Indep]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[Le WSJF - Eva Indep]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - Eva Indep]]
<<else>>
Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer.
[[Conclusion]]
<</if>>Eva en est persuadée. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre 4 manières principales de faire cette sensibilisation.
<<if setup.steps lt 12>>
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité du client. James doit négocier le déblocage de budget de formation auprés d'un manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - Eva Indep]]
#Utiliser [[Scrumble - Eva Indep]] pour la sensibilisation à Scrum
#Proposer de mettre en place [[Une nouvelle communauté agile nationale - Eva Indep]]
<<else>>
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de son client.
* Eva a aussi la possibilité de proposer elle même une formation aux parties prenantes. Aprés tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? Eva pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* Eva pourrait aussi mettre les équipes à contribution. Aprés tout, elles sont plus à même qu'Eva pour parler aux parties prenantes de leur quotidien! Elle pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>>Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - Eva Indep]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[Gérer le run en Scrum - Eva Indep]]
<<else>>
Elle devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise.
* Elle devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'accompagner le Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement - Eva Coach Indep]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - Eva Indep]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec Eva.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose au PO qu'elle accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
<<if setup.steps lt 12>>
Maintenant que le WSJF est adopté chez le client (au moins pour les équipes accompagnées par Eva) quelle pourrait-être la prochaine étape pour notre héroïne?
#Eva doit maintenant accompagner un nouveau Scrum Master, elle doit lui expliquer la notion de [[Production VS Servant Leadership - Eva Indep]]
#Eva décide d'explorer encore un nouveau sujet. [[Shape Up - Eva Indep]]
<<else>>
Maintenant que le WSJF est adopté chez son client (au moins pour les sujets qui touchent les équipes accompagnées par elle) Eva continue son accompagnement de la transformation.
Elle propose d'organiser un séminaire pour discuter de la vision produit chez son client et déploie une démarche adaptée à leur contexte.
[[Conclusion]]
<</if>>James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts, lui même et son client.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur le client.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que l'entreprise entant que telle n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - Indep]]
#Un ami de la femme de l'ex docteur du président de son client a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - James Indep]]
<<else>>
Impressionnés par le travail et l'engagement de James, les dirigeants lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, au client, de trouver un interne pour porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
James est Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>>James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
<<if setup.steps lt 12>>
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - James Indep]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[Kanban - James Indep]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - James Indep]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. James découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>>James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et son client.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur le client.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que l'entreprise entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - Indep]]
#Un ami de la femme de l'ex docteur du président de son client a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - James Indep]]
#Le projet vision se lance. James fait partie des groupes de travail et influence ce projet avec sa vision agile de la partie delivery. Aprés plusieurs rencontres de ces
groupes de travail, et une première version de la vision du client, on propose à James de s'occuper de [[La démarche produit - James Indep]] James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - James Indep]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[Kanban - James Indep]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - James Indep]]<img src="https://picsum.photos/200/300?random=1"/>James se lance avec les OKR et il a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
James propose à son une équipe test chez son client d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, James propose au départ de mettre en place une réunion bimestrielle.
Il réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat de James est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. James est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, James amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
<<if setup.steps lt 12>>
Quelle est maintenant la suite pour James?
#James est surpris par une conversation en salle de pause. [[Et toi, en quoi tu contribue aux OKRs? - James Indep]]
#Etant écoresponsable dans l'ame, James participe un à atelier [[La fresque du climat - James Indep]]
#Une des équipes client est empêtrée dans la dette technique. James tente de leur amener des pistes de réflexion. [[La dette technique et Scrum - James Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
<<if setup.steps lt 12>>
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son client que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James décide d'explorer [[Kanbanzine - James Indep]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à son client mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[La démarche produit - James Indep]]
<<else>>
Au sortir de cette formation James se lance dans le Kanban mais commence par expliquer à son client que cette démarche va prendre du temps. Il essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, James a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
James retourne à son bureau avec quelques questions. Il se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Il tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Il entend le terme antipatern.... Ca l'inquiète.
Il se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour James.
<<if setup.steps lt 12>>
Fort de ces arguments il en parle à son client. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - James Indep]]
#L'utilisation des OKRs est revue. Maintenant James se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - James Indep]]
<<else>>
Fort de ces arguments il en parle à son sponsor. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait. Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez son client. [[Valeur Business Client - James Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - James Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - James Indep]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF. [[Le WSJF - Eva Indep]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[Sensibilisation agile des PP - Eva Indep]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son client, [[Eva organise un séminaire produit - Indep]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une Sensibilisation agile des PP.
* Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse.
[[Conclusion]]
<</if>>Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - Eva Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - Indep]]
#Eva se dit qu'elle pourrait aussi creuser [[Shape Up - Eva Indep]]
<<else>>
* Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum.
* Eva se dit qu'elle pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions d'Eva. Elle voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus elle en connaitra, plus elle pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
Eva réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client d'Eva. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec l'équipe, Eva doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - Eva Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - Eva Indep]].
#Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - Eva Indep]]
<<else>>
Avec l'équipe, Eva doit donc mettre en place :
* Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. Eva propose donc que les Scrum Master deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la valeur Business Client.
* Eva propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres de l'équipe propose à Eva de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez son client. [[Valeur Business Client - James Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - James Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - James Indep]]C'est une notion difficile la valeur business!! Comment comparer la création de valeur d'un nouveau produit vs l'ajout de fonctionnalités sur une application existante?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet chez le client de James, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes il réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - James Indep]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - James Indep]]
#James abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - James Indep]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'il a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF - James Indep]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - James Indep]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son client, [[James organise un séminaire produit - Indep]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une Sensibilisation agile des PP.
* James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse.
[[Conclusion]]
<</if>>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez son client (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit désormais accompagner un nouveau Scrum Master, il doit lui expliquer la notion de [[Production VS Servant Leadership - James Indep]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - James Indep]]
<<else>>
Il propose d'organiser un séminaire pour discuter de la vision produit chez son client et déploie une démarche adaptée à leur contexte.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompagner le Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure de James?
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille entant qu'Indep]]
#James se rend compte du souci d'engagement avec une des équipes qu'il accompagne et travaille sur ce sujet [[Des problèmes d'engagement - James Indep]]
#A force d'avancer dans les missions, et de progresser dans des missions de coach, James se rend compte qu'[[On ne devient pas coach tout seul - James Indep]]
#James se demande comment gérer [[La dette technique en temps réel - James Indep]]
<<else>>
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec James.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - James Indep]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - James Indep]]
<<else>>
Il devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise.
* Il devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye de passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure de James?
#James se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement chez RDB]]
#James se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - RDB]]
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille - RDB]]
#Aprés toutes ces aventures, James décide de partir de chez les Rois du Ballon [[James micro-entrepreneur]]
<<else>>
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec James.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#James revient sur une notion clé : la [[Valeur Business - RDB]]. Aprés tout, on a beau faire tout ce qu'on veut, tant que cette dernière n'est pas d'équerre on va nul part.
#James va galérer, mais il va y arriver, nous ce qu'on veut voir c'est l'après [[James micro-entrepreneur]]
<<else>>
Il devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise.
* Il devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* James n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
<<if setup.steps lt 12>>
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans les Rois du Ballons. Il passe donc indépendant [[James micro-entrepreneur]]
<<else>>
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
[[Conclusion]]
<</if>>James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - RDB]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
<<if setup.steps lt 12>>
Les choix qui se présentent devant lui sont :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité du client. James doit négocier le déblocage de budget de formation auprés d'un manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - James Indep]]
#Utiliser [[Scrumble - James Indep]] pour la sensibilisation à Scrum
#Proposer de mettre en place [[Une nouvelle communauté agile nationale - James Indep]]
<<else>>
Il se rend compte qu'il a le choix entre 4 manières principales de faire cette sensibilisation.
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de son client.
* James a aussi la possibilité de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? James pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* James pourrait aussi mettre les équipes à contribution. Aprés tout, elles sont plus à même que James pour parler aux parties prenantes de leur quotidien! Il pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>>James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit chez son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - James Indep]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>James et l'équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
[[Conclusion]]James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - RDB]]James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - RDB]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - RDB]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[James micro-entrepreneur]] <img src="https://picsum.photos/200/300?random=1"/>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
James propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'il a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF chez RDB]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - RDB]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[James organise un séminaire produit - RDB]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une Sensibilisation agile des PP.
* James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voie agile vertueuse.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - RDB]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - RDB]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - RDB]]
<<else>>
* James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum.
* James se dit qu'il pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>>C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - RDB]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF chez RDB]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez les Rois du Ballon. [[Valeur Business RDB - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - RDB - Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - RDB - Coach]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF chez RDB - Coach]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - RDB]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[James organise un séminaire produit - RDB - Coach]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB - Coach]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB - Coach]] James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - RDB]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - RDB - Coach]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - RDB - Coach]] James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
<<if setup.steps lt 12>>
Il se rend compte qu'il a le choix entre :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de Vertes Prairies. James doit négocier le déblocage de budget de formation auprés de son manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - RDB]]
#James a envie de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[Une formation agile - RDB]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'évément agile lillois. [[James participe à son premier Agi'Lille - RDB]]
<<else>>
Il se rend compte qu'il a le choix entre 4 manières principales de faire cette sensibilisation.
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de son client.
* James a aussi la possibilité de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? James pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* James pourrait aussi mettre l'équipe' à contribution. Aprés tout, elle est plus à même que James pour parler aux parties prenantes de leur quotidien! Il pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB - Coach]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB - Coach]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
<<if setup.steps lt 12>>
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[Valeur Business - RDB]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - RDB]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF chez RDB]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[Fast Track Scrum Master - James]]
<<else>>
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discuter avec james qui lui propose de nouvelles perspectives :
* James se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Il cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. James et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* James propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[9 - James rencontre des coachs inspirants - RDB coach]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[9 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - RDB]]
<<else>>
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompagner le Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure de James?
#James se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement chez RDB - Coach]]
#James se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - RDB - Coach]]
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille - RDB Coach]]
#Aprés toutes ces aventures, James décide de partir de chez les Rois du Ballon [[James micro-entrepreneur]]
<<else>>
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec James.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - RDB]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - RDB]]
<<else>>
Il devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise.
* Il devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - Eva Indep]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[Gérer le run en Scrum - Eva Indep]] <img src="https://picsum.photos/200/300?random=1"/>Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas de LudiGames, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à LudiGames...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler de son équipe. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#Eva semble avoir convaincu les grans chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - LudiGames]]
#Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de [[Production VS Servant Leadership - LudiGames]].
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - LudiGames]]
<<else>>
Par la suite :
* Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une Sensibilisation agile des PP
* Aprés cette explication Eva retourne à son bureau. Elle est heureuse d'avoir pu faire passer ses arguments mais elle se pose la question de son rôle de Scrum Master. Devrait-elle faire plus de production pour le produit? Elle essaye pour un temps mais se retrouve vite confronter à la notion de Production VS Servant Leadership.
* Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer avec son équipe le No Estimate dont elle a entendu parler sur un forum.
[[Conclusion]]
<</if>>Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - LudiGames]]
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - LudiGames]]
#Eva se dit qu'elle pourrait aussi creuser [[LudiGames et Shape Up]] Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi. Elle engage malgré tout un chantier avec le PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - LudiGames]]
#Hop, on quitte le scrum master [[Eva micro-entrepreneuse]]
Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[9 - On ne devient pas coach tout seul - James Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[9 - Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[9 - Indep c'est bien, tout seul ca craint!! - James]]
James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - James Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille entant qu'Indep]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" James se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engagé sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[La fresque du climat - James Indep]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[James se passionne pour le Serious Gaming - Indep]]
James s'est lancée. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant que James est établie entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[James organise un séminaire produit - Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[James participe à son premier Agi'Lille pour un client]]
James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - Indep]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - James Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation - James Indep]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions aprés un séminaire - James Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - James Indep]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - James Indep]]
<<else>>
Il propose au client de créer un comité de transformation auquel il pourrait se joindre.
Il pourrait aussi animer lui même la transformation de manière itérative.
Il cherche aussi à être formé aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>>Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
<<if setup.steps lt 12>>
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - James Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[Démarche OKR - James Indep]].
<<else>>
James fait partie des acteurs, et de ce fait il est impliqué dans plusieurs initiatives :
* Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la démarche OKR.
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - James Indep]]
#James propose à son client de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up pour son client - James Indep]]
#Fort des retours de son client, James propose de créer [[Une méthode maison pour son client - James Indep]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, James entend parler d'un événement Lillois autour de la démarche agile. Il participe donc à son premier Agi'Lille.
* James trouve rapidement une réponse qu'il souhaite amener à ses clients et prépare un atelier pour montrer qu'il faut se focaliser sur la création de valeur et plus sur les dépenses.
* James découvre d'autres manière d'être agiles que Scrum. Il lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante en fonction du contexte.
[[Conclusion]]
<</if>>C'est bien beau d'avoir mis en place une démarche qui permet d'être au plus prêt des retours utilisateurs, de faciliter les changements de cap en fonction de ces derniers, et d'accepter de ne pas partir avec une feuille de route figée à J1.
Cependant, quand le management entend : "Avec la démarche agile, le changement c'est tout le temps !" l'équipe perd un peu les pédales.
James tente d'expliquer le fonctionnement d'un backlog à son management, le fait qu'on peut changer de cap dans les limites de la vision produit... mais le plus dur à comprendre pour eux semble être le trade in / trade out.
Cette pratique qui permet de garantir un engagement cohérent de l'équipe quant à la tenue des objectifs de livraison court et moyen terme.
Il l'aborde un peu dans ces mots :
"Le fort d'une équipe agile c'est de pouvoir travailler avec des moyens finis. Si vous voulez forcément sortir une version d'un produit à une date précise, l'équipe doit être en mesure de vous dire ce qui peut ou ne peut pas rentrer dans ce délai. De fait, lorsqu'un nouveau besoin apparait et que vous souhaitez forcément le faire sortir avec la version planifiée, il faudra faire un choix : pour une quantité (estimée) d'effort à fournir pour ce nouveau besoin, il faudra enlever une quantité équivalente d'effort du backlog".
Aprés plusieurs aller-retours, le management semble avoir compris.
Que se passe-t-il ensuite?
#Un des managers a tout compris! L'équipe ayant une capacité limitée à fournir de l'effort à chaque version de leur plateforme, il propose de moduler la taille de l'équipe en fonction de la taille de la version! [[9 femmes... - DoctoChat]]
#C'est bien beau de parler de capacité de l'équipe à produire, mais on avait vendu Scrum au management comme étant un cadre permettant de favoriser l'atteinte de ROI le plus vite possible. James se propose de leur expliquer un concept de plus [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - DoctoChat]]
#Le management ne comprend pas, du fait, d'où viennent les dérives sur le projet. [[Des problèmes d'engagement chez DoctoChat]]
#Il aura fallu déployer beaucoup d'effort mais au final ils payent. Le fonctionnement de l'équipe s'assainit, la valeur produite est au rendez-vous [[Scrum ca marche pour DoctoChat]] C'est une notion difficile la valeur business, surtout chez DoctoChat!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - DoctoChat]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - DoctoChat]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - DoctoChat]]
<img src="https://picsum.photos/200/300?random=1"/>Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein de DoctoChat qui participeront aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à James de porter cette vision au sein de l'entreprise. La partie visibilité de l'entreprise vers l'extérieur sera traitée dans un second temps.
<<if setup.steps lt 12>>
Comment réagit James à cette proposition?
#Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet. [[De vision à action - DoctoChat]]
#Son interaction avec David lui fait se dire qu'il peut enfin accepter une mission qui le fasse sortir de sa zone de confiance. Un client la solicite et James accompagne la [[Démarche OKR - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Qu'il est beau ce dicton! C'est un des préférés de James.
9 femmes ne feront pas un bébé en 1 mois... y'a-t-il quelquechose de plus immuable?
James essaye de faire passer le message au management :
* Une équipe Scrum utilise l'empirisme, et notamment l'inspection et l'adaptation pour pouvoir se projeter et s'améliorer en continue. Si on change la taille de l'équipe, les données récoltées en inspection ne correspondrons pas à l'équipe qui mettra en place les adaptations validées.
* Il en est de même pour la taille du sprint.
* De plus, une équipe agile est une machine bien huilée. Chaque individu sait ce qu'il a à faire, quand il doit le faire... Augmenter la taille d'une équipe implique généralement une perte d'efficacité temporaire pour l'équipe. En effet, pour aider le ou les nouveaux arrivants à monter en compétence (et capacité) sur le produit, les anciens de l'équipe délaissent une partie de leur engagement. C'est ainsi que l'équipe réduit le temps de montée en compétence mais l'impact sur le (ou les) premier(s) sprint(s) aprés l'ajout est toujours visible.
* La taille de l'équipe est généralement optimisée par rapport au backlog produit, aux priorités du PO et à la taille des user stories (et leurs interdépendances). Ajouter une nouvelle personne dans une équipe n'est jamais anodin et peut trés bien avoir un effet négatif sur la performance sur le moyen terme. Il faudra du temps pour ré-équilibrer les forces.
James réussi à convaincre le manager en question.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#En discutant avec le manager, ils tombent d'accord sur le fait que la gestion du run doit maintenant faire partie des priorités de l'équipe. Mais comment [[Gérer le run en Scrum - DoctoChat]] ?
#James propose une [[Sensibilisation agile des PP - DoctoChat]], afin de travailler aux incompréhensions mutuelles.
#Le fait est que sur le long terme il faudra augmenter la capacité de DoctoChat à créer de la valeur. Le manager demande à James de lui faire une proposition pour [[Créer une nouvelle équipe Scrum - DoctoChat]].
#Le manager comprend mais il reste frustré. Il a l'impression que l'équipe ne se concentre pas assez sur les sujets qui lui importent à lui. James propose d'explorer[[Le WSJF - DoctoChat]] avec le PO.
<<else>>
[[Conclusion]]
<</if>>Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[9 - Eva organise un séminaire produit Indep]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[9 - Agile Games France - Eva Indep]] Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[Eva organise un séminaire produit - Indep]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[Agile Games France - Eva Indep]] <img src="https://picsum.photos/200/300?random=1"/>James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et les Rois du Ballon.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur les Rois du Ballon.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que les Rois du Ballon entant que tel ne sont que trés peu visibles sur le net, leurs créations un peu plus, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité des Rois du Ballon et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - RDB]]
#Un ami de la femme de l'ex docteur du président de VP a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - RDB]]
#Son initiative est ignorée et James le prend mal. Il ne lui en fallait pas plus pour le pousser vers l'indépendance [[James micro-entrepreneur]]
<<else>>
Impressionnés par le travail et l'engagement de James, le management lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés à James de porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
James est Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>>James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
<<if setup.steps lt 12>>
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - RDB]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[Kanban - RDB]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - RDB]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. James découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, James a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
James retourne à son bureau avec quelques questions. Il se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Il tombe sur la vidéo... Paf, c'est ce qu'il cherchait.
Il entend le terme antipatern.... Ca l'inquiète.
Il se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour James.
<<if setup.steps lt 12>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - DoctoChat]]
#L'utilisation des OKRs est revue. Maintenant James se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - DoctoChat]]
<<else>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait. Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez les Rois du Ballon. [[Valeur Business - DoctoChat]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - DoctoChat]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - DoctoChat]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James se lance avec les OKR et il a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
James propose à son une équipe test chez son client d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, James propose au départ de mettre en place une réunion bimestrielle.
Il réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat de James est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. James est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, James amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
<<if setup.steps lt 12>>
Quelle est maintenant la suite pour James?
#James est surpris par une conversation en salle de pause. [[Et toi, en quoi tu contribue aux OKRs? - DoctoChat]]
#Etant écoresponsable dans l'ame, James participe un à atelier [[La fresque du climat - DoctoChat]]
#Une des équipes client est empêtrée dans la dette technique. James tente de leur amener des pistes de réflexion. [[La dette technique et Scrum - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son activité d'indépendante il décide acheter la version éditée qui, de plus, lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
<<if setup.steps lt 12>>
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - DoctoChat]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à DoctoChat d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour DoctoChat]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - DoctoChat]]
#Y'en a marre de la vie de Scrum Master, que fait James aprés avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]]
<<else>>
James accompagne l'équipe qui se lance tête baissée dans la démarche Kanban.
James travaille avec le scrum master pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et propose au scrum master de regarder un peu aux goulots d'étranglement au sein de leur tableau. Ils se rendent compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Ils s'engagent donc dans l'identification des workflow externes à l'équipe et proposent aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. Il essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]Le manager de James lui propose un rendez-vous pour faire un petit état des lieux.
Il en ressort qu'au travers de ces différentes tâches et missions, James a peu de temps pour s'occuper réellement de faire de la veille ou de simplement prendre du recul sur les situations rencontrées. Aprés tout, l'expérience agile de James s'est entièrement construite chez les Rois du Ballon.
Entre hésitation, non dits... ils finissent par tombre d'accord sur une manière d'accompagner James au mieux.
Quelle décision prennent-ils?
#James doit impérativement faire de la veille de son coté, pour ce faire, Vertes Prairies sont OK pour lui payer sa [[8 - James participe à son premier Agi'Lille - VP]]
#James doit faire de la veille mais de son côté, il découvre alors les [[8 - Meetups de la communauté Lilloise - VP]]
#Les managers décident de faire intervenir une personne plus expérimentée pour accompagner James [[8 - Un coach agile chez VP]]James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[8 - James devient PPO - VP]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[8 - Product Box - VP]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[8 - Se former aux démarches produits - VP]].Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James découvre le Serious Gaming - VP]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - VP]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - VP]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - VP]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - VP]]
James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[9 - Un miroir coach - James Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[9 - Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[9 - James participe à son premier Agi'Lille entant qu'Indep]] Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" James se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engagé sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[9 - La fresque du climat - James Indep]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[9 - Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[9 - James se passionne pour le Serious Gaming - Indep]]
James s'est lancée. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant que James est établie entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[9 - James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[9 - James organise un séminaire produit - Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[9 - James participe à son premier Agi'Lille pour un client]]
James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[9 - James devient PPO - VP]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[9 - Product Box - VP]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[9 - Se former aux démarches produits - VP]].
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - James découvre le Serious Gaming - VP]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[9 - James rencontre des coachs inspirants - VP]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - VP]]
#Aprés l'atelier auquel il a participé, [[9 - James se passionne pour le No Estimate - VP]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - VP]]
James semble tout indiquée pour accompagner les Vertes Prairies sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Vertes Prairies.
Au bout de 3 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Vertes Prairies.
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Vertes Prairies plus en amont dans leur démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[9 - Un Scrum Master pour remplacer James - VP]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[9 - Créer une nouvelle équipe Scrum - VP]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[9 - James participe à son premier Agi'Lille - VP]]
#James décide de se lancer dans la description de la démarche agile selon les Vertes Prairies du Ballon afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[9 - Une méthode maison pour VP - Coach]] James passant coach, il faut trouver un Scrum Master pour le remplacer auprés de l'équipe existante.
En réunion avec son manager il hésite sur les préconnisations qu'il pourrait faire.
En effet, pour le remplacer, les Vertes Prairies ont le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, aprés tout le Rois du Ballon sont capables d'embaucher de nouvelles personnes, James se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et James se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
James est également tenté de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Il entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ca risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en delaissant un peu le développement.
Aprés plusieurs longues réunions, le management accepte la solution préconnisée par James : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'il amène le sujet à l'équipe, personne ne se porte volontaire directement, James leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
James est enchanté, il cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu'il est remplacé, James peut se consacrer à la suite :
#[[9 - James organise un séminaire produit - VP]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d'[[9 - Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[9 - Des problèmes d'engagement chez VP]] Premier challenge pour James : Non seulement il a du trouver un scrum master remplaçant, mais il doit aussi accompagner les Vertes Pairies dans la création d'une nouvelle équipe.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent chez les Rois du Ballon et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec les Rois du Ballon pour sa précédente équipe. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Les Vertes Prairies pourraient aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager de James a choisi l'option "Seeding".
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[9 - James organise un séminaire produit - VP - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d’[[9 - Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[9 - Des problèmes d'engagement chez VP - Coach]] Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Vertes Prairies correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Vertes Prairies. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[9 - Scrum Master et QA chez VP - Coach]]
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[9 - La Rache chez VP - Coach]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[9 - Valeur Business VP - Coach]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[9 - La dette technique et Scrum - VP - Coach]] La vision des Rois du ballon est la suivante: Scrum est un framework qui permet aux équipes d'être efficaces. Cependant, lors de la présentation du framework par un formateur bien attentionné, ils ont entendu et retenu, les choses suivantes:
* Les rôles de Scrum Master et de PO ne sont pas des nouveaux métiers.
* Etre Scrum Master ca prend pas plus de 30% du temps d'un individu en moyenne sur la durée de vie d'une équipe.
* Un PO venant du métier est plus efficace.
La situation est donc la suivante:
* Les Scrum Masters font du dev à hauteur de 70%.
* Les PO sont des personnes ayant un métier dans la fabrication des verres à pied en plus d'avoir la responsabilité du backlog d'un produit informatique.
* L'efficacité du système doit pouvoir être suivi et le point d'effort a été choisi comme unité.
James doit décider de ce qu'il fait devant cette situation:
#Il décide que la vision est trop éloignée de la sienne et met fin à sa période d'essai. [[James Quitte les rois du Ballon]]
#James n'est pas si à l'aise que ca en développement et décide cependant de tenter d'aider l'équipe du mieux de ses capacités, notamment dans le test. [[5 - James passe Scrum QA]]
#Aprés d'âpres négociations, il réussi à atteindre un compromis avec son manager et devient donc [[5 - Un Scrum Master multi équipe pour RDB]] .L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), James se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Mais il se rend compte aussi que, malgré la présence de plusieurs testeurs officiels chez les Rois du Ballon, la phase de QA reste le goulot d'étranglement du process!
James décide d'investiguer ce qui se fait sur le marché, quelle décision va-t-il prendre?
#James décide d'explorer le monde de l'assurance qualité et obtenir la prise en charge d'une [[6 - Formation ISTQB - RDB]] par les Rois du Ballon.
#James se documente et découvre [[6 - Les 3 amigos - RDB]] qu'il décide de mettre en pratique tout de suite.
#James parle à un vieux de la vieille chez les Rois du Ballon et tous les deux ils évoquent la possibilité de mettre en place [[6 - Un déversement de backlog - RDB]]James est donc nommé Scrum Master sur 2 équipes en même temps. Les deux équipes travaillent déjà de manière coordonnée car l'une se focalise sur une application de suivi de la production dans l'usine quand l'autre est organisée autour de la pise de mesures tout au long de la chaine de production.
L'application de suivi de prod se nourrit donc des données de la seconde.
James ne s'en sort pas trop mal. Les équipes sont heureuses d'avoir une personne centrale permettant de mettre en avant les interdépendances.
Aprés quelques mois, les équipes tournent bien et le manager de James vient lui proposer de prendre en charge une équipe complémentaire.
Que va faire James?
#Il va tenter d'appliquer les mêmes pratiques et méthodes avec la seconde équipe: si ca a marché pour la première, y'a pas de raison que ca foire pour la seconde quoi que... [[6 - Le Cargo Cult ca pique - RDB]]
#Il se pose quelques jours/semaines pour voir comment l'équipe fonctionne et adapte son accompagnement à cette dernière [[6 - Observation et nouvelle équipe - RDB]]
#L'équipe ne lui laisse pas le choix : ils sont autonomes et n'ont que peu besoin de lui [[6 - Une équipe autonome chez RDB]]Se former au test, quelle drôle d'idée? Pas vraiment pour James.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais James réussi à l'obtenir! Ca va faire bien sur son CV!!
James a hâte de mettre tout ca en pratique. Mais que fait-il une fois cette certification en poche?
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[7 - James participe à son premier Agi'Lille - RDB]]
#James décide de creuser un peu une pratique présentée durant sa formation, [[7 - Les 3 amigos - RDB]] Le raisonnement de James et Jean-Paul (un vieux de la vieille chez les Rois du Ballon) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez les Rois du Ballon, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[7 - Les 3 amigos - RDB]]
#James et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprés du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais[[7 - Ca peut vraiment être efficace? - RDB]]James met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Il tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'il est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il décide de revoir sa copie. Quelle est la prochaine étape?
#[[7 - Le management remet en question la capacité de James à avancer seul]]
#James se rend compte qu'il faut absolument [[7 - Accompagner le PO - RDB]]
#James entend parler de la communauté agile lloise et décide de participer à [[7 - James participe à son premier Agi'Lille - RDB]] L'observation se passe bien. James se rend compte que son accompagnement pour la nouvelle équipe ne peut pas être le même que pour la plus ancienne. Cette dernière est beaucoup plus autonome et ne lui demande que peu de choses. Entre animation de rétro et gestion des freins, James a plus de temps pour lui.
Que se passe-t-il ensuite?
#James se rend compte d'un manque côté Product Owner sur la nouvelle équipe. Il se rapproche du métier et décide d'[[7 - Accompagner le PO - RDB]].
#James s'en sort pas mal avec ses deux équipes, mais il ressent le besoin de se renouveler. Il décide de participer à des conférences pour creuser un peu plus la démarche agile et les méthodes associées. Il se rend à l'[[7 - James participe à son premier Agi'Lille - RDB]].
#James commence à envisager son futur. Il cherche une formation qui pourrait l'emmener plus loin dans son développement agile. [[7 - Une formation agile - RDB]]James s'interroge, que veut dire l'équipe quand elle se sent autonome?
De son expérience de Scrum Master, une équipe est autonome lorsqu'elle s'auto-organise. Elle n'a pas besoin d'un Scrum Master qui soit tout le temps présent mais de temps à autre, quand l'équipe rencontre des freins importants, elle est contente d'avoir un rôle dédié à ce genre de situation.
De plus, James sait ce que veut dire auto-organisé, il sait aussi qu'il arrive à certaines équipes de dériver d'une vraie démarche d'amélioration continue s'ils ne font que de l'entre soi... Ils finissent pas ne plus se remettre en question ou leur manière de travailler...
Que va-t-il se passer ensuite?
#James passe pas mal de temps avec les membres de l'équipe pour comprendre ce qui les fait se sentir autonome et sans besoin de Scrum Master. Et en effet, l'équipe est trés trés agile et autonome. Les seuls freins qu'ils rencontrent sont généralement liés aux besoins présentés en début de sprint. Il décide donc d'[[7 - Accompagner le PO - RDB]]
#Malheureusement, l'équipe n'est pas si agile que celà. Certes, elle est autonome mais principalement parcequ'elle ne demande rien à personne et se débrouille toute seule. Ca ne veut pas forcément dire qu'elle est efficace, et James le sait bien. Comment faire comprendre à son équipe qu'elle est sans doute dans un piège de rigidité? James décide de voir ce que les autres agilistes lillois peuvent lui proposer [[7 - James participe à son premier Agi'Lille - Equipe Autonome]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[8 - Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[8 - Un refinement revisité - RDB]].Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Mais pas tant de sujets testing que ca. On parle qualité logiciel mais plus du côté des développeurs. Il a cependant entendu parler d'une pratique : les 3 amigos, qu'il compte bien mettre à profit à son retour chez les Rois du Ballon
Au sortir de l'événement, James peut prendre plusieurs directions :
#James va mettre en place les [[8 - Les 3 amigos - RDB]]
#James se renseigne sur le [[8 - Le craftsmanship - RDB]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - RDB]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - RDB]]
James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[James devient PPO - RDB]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[Product Box - RDB]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[8 - Se former aux démarches produits - RDB]].
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[8 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - RDB]]
Le manager de James lui propose un rendez-vous pour faire un petit état des lieux.
Il en ressort qu'au travers de ces différentes tâches et missions, James a peu de temps pour s'occuper réellement de faire de la veille ou de simplement prendre du recul sur les situations rencontrées. Aprés tout, l'expérience agile de James s'est entièrement construite chez les Rois du Ballon.
Entre hésitation, non dits... ils finissent par tombre d'accord sur une manière d'accompagner James au mieux.
Quelle décision prennent-ils?
#James doit impérativement faire de la veille de son coté, pour ce faire, les Rois du Ballons sont OK pour lui payer sa [[8 - James participe à son premier Agi'Lille - Equipe Autonome]]
#James doit faire de la veille mais de son côté, il découvre alors les [[Meetups de la communauté Lilloise - RDB]]
James passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour James c'est sa première formation.
James passe du temps à préparer un plan, puis il le jette à la corbeille quand il commence à compiler ses slides et qu'il essaye de raconter une histoire cohérente.
Il commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Il promet de mettre à jour son cursus pour la prochaine session.
Il a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'il souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de RDB.
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour RDB. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[8 - Le ShuHaRi appliqué à Scrum - RDB]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer RDB dans le bon sens. [[8 - James organise un séminaire produit - RDB]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[8 - Un comité de transformation chez RDB]]
#Avec cette expérience complémentaire en poche, James passe indépendant. [[8 - James micro-entrepreneur]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[9 - Le principe de l'amélioration continue face au chaos - RDB]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à DoctoChat mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[9 - La démarche produit - RDB]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
Que se passe-t-il ensuite pour Eva?
#Avec le PO ils tombent d'accord : il faut travailler à la [[Valeur Business - LudiGames]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[Le WSJF chez LudiGames]]
#Maintenant que l'équipe est au fait de la vision produit, Eva s'attaque à la gestion de [[La dette technique et Scrum - LudiGames]] L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[9 - Valeur Business - VP]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[9 - Le WSJF chez VP]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[9 - La dette technique et Scrum - VP]] L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[Valeur Business - VP]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[Le WSJF - VP]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[La dette technique et Scrum - VP]] Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[8 - Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[8 - Valeur Business LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[8 - Les experts de la vision - LudiGames]]
Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[8 - Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[8 - Démarche OKR - LudiGames]].
#Personne, durant l'atelier, n'a été capable de définir ce qu'est la valeur business des différentes solutions. Avant d'avancer dans la démarche produit, ils décident de travailler à la [[8 - Valeur Business LudiGames]]
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[8 - Eva devient coach agile chez LudiGames]] Eva est plutôt avisée sur le sujet des OKRs. Elle a bien suivi les conseils qu'elle a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Elle parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Elle propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête d'Eva tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - LudiGames]]
#Le management comprend les OKR, le président de LudiGames a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à Eva d'explirer le Kanban. [[9 - LudiGames et Kanban]]
#Lançez-vous, a dit le président au manager d'Eva. Il est convenu que l'équipe va servir de pilote. Eva se lance donc et s'interroge sur [[9 - La ritualisation du suivi des OKR - LudiGames]]
#OKR check, Scrum check... et aprés? [[9 - Fast Track Scrum Master - Eva]] <img src="https://picsum.photos/200/300?random=1"/>Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[9 - Eva pilote de vision LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[9 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[Eva micro-entrepreneuse]] Eva met du temps à comprendre ce qui arrive à son équipe.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que LudiGames doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tomber dans le CargoCult pour Scrum
Lorsque Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être
agile.
De quelle pratique vont-ils s'inspirer?
#[[Kanban - LudiGames]]
#[[Shape Up - LudiGames]]
#[[DevOps - LudiGames]]Plutôt fière de sa nouvelle mission, Eva a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier LudiGames.
Ce dernier propose a Eva de commencer par identifier les différents acteurs au sein de LudiGames qui participerons aux différents ateliers vision.
Eva identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à Eva de porter cette vision au sein de l'entreprise. La partie visibilité de LudiGames vers l'extérieur sera traitée dans un second temps.
Comment réagit Eva à cette proposition?
#Emballée par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, Eva le suit sur le projet. [[De vision à action - LudiGames]]
#Le projet vision sera un succès, on a pas de doute là dessus, aprés tout VisionMaster sont les experts de la vision. Voyons plutôt comment se débrouille Eva avec son équipe. [[Eva continue avec son équipe Scrum - LudiGames]]Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[8 - La dette technique et Scrum - Eva Indep]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à un client. [[8 - Accelerate chez un client - Eva Indep]]
#Un des freins au pure Craftsmanship souvent rencontré par Eva, semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[8 - DevOps - Eva Indep]]
#Un développeur pose une question ouverte lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[8 - Developpeurs et IA - Eva Indep]]
<<else>>
* Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum.
* Elle lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. Elle va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva s'inquiète également.
[[Conclusion]]
<</if>>Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - James Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[Démarche OKR - James Indep]].
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein de l'entreprise qui participeront aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à James de porter cette vision au sein de l'entreprise. La partie visibilité de l'entreprise vers l'extérieur sera traitée dans un second temps.
<<if setup.steps lt 12>>
Comment réagit James à cette proposition?
#Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet. [[De vision à action - James Indep]]
#Son interaction avec David lui fait se dire qu'il peut enfin accepter une mission qui le fasse sortir de sa zone de confiance. Un client la solicite et James accompagne la [[Démarche OKR - James Indep]]
<<else>>
James est emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - James Indep]]
#[[Shape Up pour son client - James Indep]]
#[[DevOps - James Indep]]
<<else>>
[[Conclusion]]
<</if>>Comme beaucoup de personnes, les membres des équipes du client de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanaban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - James Indep]] pour faire découvrir, par la pratique, ces différents concepts à son client.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - James Indep]]?
#Quelque soit la manière, il réussi à déployer la démarche auprés de son client. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - James Indep]].
<<else>>
James a plusieurs chantiers devant lui :
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, il réussi à déployer la démarche auprés de son client. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>>Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la [[Démarche OKR - LudiGames]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[Eva devient coach agile chez LudiGames]] <img src="https://picsum.photos/200/300?random=1"/>Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, l'entreprise est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait elle est impliquée sur plusieurs initiatives :
<<if setup.steps lt 12>>
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[Démarche OKR - LudiGames]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[Eva devient coach agile chez LudiGames]]
<<else>>
* Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la démarche OKR.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez les Rois du Ballon. [[Valeur Business - RDB]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - RDB]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - RDB]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>>Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#James explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[8 - La dette technique et Scrum - RDB]]
#James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[8 - Accelerate chez RDB]]
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[8 - DevOps et RDB]]
#Un des développeurs de l'équipe pose une question ouverte à James lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Il explore le sujet. [[8 - Developpeurs et IA - RDB]]Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez les Rois du Ballon. [[9 - Valeur Business - RDB]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - RDB]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - RDB]]James lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Il a du mal à transformer sa lecture en actions opérationnelles. Il continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Il étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
James se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#James explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[9 - La dette technique et Scrum - RDB]]
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[9 - DevOps et RDB]]
#James se dit que pour amener toute l'entreprise à se poser les questions d'acceleration il faut avant tout que les Rois du Ballon travaillent à leur démarche produit. [[9 - James organise un séminaire produit - RDB]]
#James se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[9 - Une présentation de la démarche agile à l'équipe - RDB]]
Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[9 - Gunther - RDB]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[9 - Casino Game - RDB]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[9 - Lego, Scrum et Chocolat pour le DevOps - RDB]]
#Bon, assez de Scrum Mastering, il fait quoi ensuite James? [[9 - Fast Track Scrum Master - James]] Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
James se veut rassurant. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
#James leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Il propose alors de travailler sur le sujet RUN avec l'équipe. [[9 - Gérer le run en Scrum - RDB]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[9 - Valeur Business - RDB]]
#Arrêtons de nous prendre la tête sur les développeurs, voyons ce que fera James aprés Scrum Master. [[9 - Fast Track Scrum Master - James]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[9 - Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[9 - Un refinement revisité - RDB]].
#James a 3 amis dont un qui s'appelle SPeedy Gonzales... [[9 - Fast Track Scrum Master - James]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#James explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[9 - La dette technique et Scrum - RDB]]
#James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[9 - Accelerate chez RDB]]
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[9 - DevOps et RDB]]
#Un des développeurs de l'équipe pose une question ouverte à James lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Il explore le sujet. [[9 - Developpeurs et IA - RDB]]James lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Il a du mal à transformer sa lecture en actions opérationnelles. Il continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Il étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
James se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#James explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - RDB]]
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps et RDB]]
#James se dit que pour amener toute l'entreprise à se poser les questions d'acceleration il faut avant tout que les Rois du Ballon travaillent à leur démarche produit. [[James organise un séminaire produit - RDB]]
#James se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[Une présentation de la démarche agile à l'équipe - RDB]]
Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - RDB]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - RDB]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - RDB]]
#Bon, assez de Scrum Mastering, il fait quoi ensuite James? [[Fast Track Scrum Master - James]] Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
James se veut rassurant. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
#James leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Il propose alors de travailler sur le sujet RUN avec l'équipe. [[Gérer le run en Scrum - RDB]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[Valeur Business - RDB]]
#Arrêtons de nous prendre la tête sur les développeurs, voyons ce que fera James aprés Scrum Master. [[Fast Track Scrum Master - James]] C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - RDB]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - RDB]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - DoctoChat]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - DoctoChat]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - DoctoChat]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - DoctoChat]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - DoctoChat]]
Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez DoctoChat (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - DoctoChat]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - DoctoChat]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - DoctoChat]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - DoctoChat]]
<<else>>
* James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum.
* James se dit qu'il pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
<<if setup.steps lt 12>>
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discute avec James qui lui propose de nouvelles perspectives :
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - DoctoChat]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - DoctoChat]]
#Aprés tout ca, James décide de passer Indep! [[James micro-entrepreneur]]
<<else>>
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discute avec James qui lui propose de nouvelles perspectives :
* James se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Il cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. James et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* James propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>>Tout dans Scrum s'applique correctement chez DoctoChat!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe de James et DoctoChat, le succés est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
James n'est plus sollicité par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Il a donc du temps pour explorer des sujets complémentaires sur la toile.
Il a réussi à amener un peu de fun dans les différents rituels. En commencant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, il trouve un format ludiquer que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Il change à chaque fois le focus de l'équipe et il a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvent des anomalies, elles sont résolues séance tenante par l'équipe.
James est donc prêt pour passer à la suite.
<<if setup.steps lt 12>>
#En discutant avec un ami il découvre le No Estimate. Il se dit que c'est la prochaine étape à franchir avec son équipe!! [[James se passionne pour le No Estimate - DoctoChat]]
#Le manager de Jales l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" James change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[Le Cargo Cult ca pique - DoctoChat]]
<<else>>
* En discutant avec un ami il découvre le No Estimate. Il se dit que c'est la prochaine étape à franchir avec son équipe!!
* Le manager de James l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" James change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. Se dirige-t-il vers un cargo cult?
[[Conclusion]]
<</if>>James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - DoctoChat]]
#[[Shape Up - DoctoChat]]
#[[DevOps - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - DoctoChat]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - DoctoChat]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit des Rois du Ballon à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors il a le choix :
#Proposer au manager de créer un [[Un comité de transformation - DoctoChat]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions aprés un séminaire - DoctoChat]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - DoctoChat]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - DoctoChat]]
<<else>>
Il propose au management de créer un comité de transformation auquel il pourrait se joindre.
Il pourrait aussi animer lui même la transformation de manière itérative.
Il cherche aussi à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>>Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
<<if setup.steps lt 12>>
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - DoctoChat]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la [[Démarche OKR - DoctoChat]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à James de changer de poste. [[Eva devient coach agile chez DoctoChat]]
<<else>>
James fait partie des acteurs, et de ce fait il a la main sur plusieurs initiatives :
* Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la démarche OKR.
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à DoctoChat [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - DoctoChat]]
#James propose à son manager de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up - DoctoChat]]
#Fort des retours de son manager, James propose de créer [[Une méthode maison pour DoctoChat]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, James entend parler d'un événement Lillois autour de la démarche agile. James participe à son premier Agi'Lille.
* James trouve rapidement une réponse qu'il souhaite amener à sa direction et prépare un atelier sur le fait de se focaliser sur la création de valeur et plus sur les dépenses.
* James découvre d'autres manière d'être agiles que Scrum. Il lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue DoctoChat
[[Conclusion]]
<</if>>James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de DoctoChat de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
<<if setup.steps lt 12>>
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - DoctoChat]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[Kanban - DoctoChat]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - DoctoChat]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. James découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>>James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
<<if setup.steps lt 12>>
Il se rend compte qu'il a le choix entre :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de Vertes Prairies. James doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - DoctoChat]]
#James a envie de proposer lui même une formation aux parties prenantes. Après tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[Une formation agile - DoctoChat]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[James participe à son premier Agi'Lille - DoctoChat]]
<<else>>
Il se rend compte qu'il a le choix entre 4 manières principales de faire cette sensibilisation.
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de son client.
* James a aussi la possibilité de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? James pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* James pourrait aussi mettre l'équipe' à contribution. Aprés tout, elle est plus à même que James pour parler aux parties prenantes de leur quotidien! Il pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - DoctoChat]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[Gérer le run en Scrum - DoctoChat]]
#James décide de voler de ses propres ailes [[James micro-entrepreneur]]
<<else>>
Il devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise.
* Il devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit DoctoChat.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - DoctoChat]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - DoctoChat]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour DoctoChat]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - DoctoChat]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye de passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec James.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]] <img src="https://picsum.photos/200/300?random=1"/>Eva a fait pas mal de recherches pour proposer à LudiGames un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, elle fini par organiser un rendez-vous entre les experts et LudiGames.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur LudiGames.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que LudiGames entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement d'Eva, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[Eva pilote de vision - LudiGames]]
#Un ami de la femme de l'ex docteur du président de LudiGames a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec Eva et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'elle applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Cet excursion en dehors de sa zone de confiance l'a motivée. Eva se lance en indep. [[Eva micro-entrepreneuse]] Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[9 - Production VS Servant Leadership - LudiGames]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[9 - Le craftsmanship - LudiGames]].
#Bon, et si on avancait plus rapidement dans le temps! Que fais Eva aprés Scrum Master? [[9 - Fast Track Scrum Master - Eva]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - LudiGames]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[Accelerate chez LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[DevOps - LudiGames]]
#Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - LudiGames]]Eva met du temps à comprendre ce qui arrive.
Elle tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Elle se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'elle devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-elle correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront qu'Eva devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsqu'Eva retravaille avec l'équipe et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - LudiGames]]
#[[Shape Up - LudiGames]]
#[[DevOps - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Les Vertes Prairies décident donc de faire appel à un coach agile plus expérimenté que James.
On fait les choses bien chez les Vertes Prairies : James est inclus dans les entretiens de sélection de la personne qui va l'accompagner. Il donne son avis sur les différentes personnes et aprés quelques jours, on lui annonce que c'est Eva Yarivai qui va l'accompagner.
Eva arrive quelques jours aprés. Elle rencontre James et lui expose ce qu'elle se propose de mettre en place.
Quelle option Eva propose-t-elle à James?
#Eva a l'habitude de ne pas faire de fausse promesse, d'adapter son accompagnement aux besoins de l'organisation qu'elle accompagne. Pour se faire, elle doit passer du temps dans [[9 - Une phase d'observation - VP]] afin de faire des suggestions cohérentes.
#[[9 - Fast Track Scrum Master - James]] C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez Vertes Prairies [[Valeur Business VP - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - VP - Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - VP - Coach]]James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Il se rend compte qu'il a le choix entre plusieurs manières principales de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de VP. James doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[9 - Une formation externe pour les parties prenantes - VP]]
#James a envie de proposer lui même une formation aux parties prenantes. Après tout, il connait son sujet vu qu’il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[9 - Une formation agile - VP]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[9 - James participe à son premier Agi'Lille - VP]]James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Vertes Prairies.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - VP]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire - VP]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour VP - Coach]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Vertes Prairies demande à James de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - VP]]Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille entant qu'Indep]]
#Aprés tous ces meetups, [[James se passionne pour le Serious Gaming - Indep]]
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais James a la chance de ne pas être tout seul sur l'animation du stand et il trouve donc un peu de temps pour son apprentisage personnel.
James peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - Indep]]James passant coach, il faut trouver un Scrum Master pour le remplacer auprès de l'équipe existante.
En réunion avec son manager il hésite sur les préconisations qu'il pourrait faire.
En effet, pour le remplacer, les Vertes Prairies ont le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, après tout le Rois du Ballon sont capables d'embaucher de nouvelles personnes, James se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et James se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
James est également tenté de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Il entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ça risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en délaissant un peu le développement.
Après plusieurs longues réunions, le management accepte la solution préconisée par James : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'il amène le sujet à l'équipe, personne ne se porte volontaire directement, James leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
James est enchanté, il cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu'il est remplacé, James peut se consacrer à la suite :
#[[James organise un séminaire produit - VP]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d’[[Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez VP]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - VP]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - VP]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - VP]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - VP]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - VP]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Vertes Prairies correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Vertes Prairies. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez VP - Coach]]
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[La Rache chez VP - Coach]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business VP - Coach]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - VP - Coach]] James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héros.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héros de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héros. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapitres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ça ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Après avoir participé à ses événements et y avoir présenté ses sujets, [[9 - James rejoint Nord Agile - VP]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[9 - La fresque du climat - VP]] James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - VP]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - VP]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[James micro-entrepreneur]] Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye de passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
<<if setup.steps lt 12>>
Que se passe-t-il ensuite dans l'aventure de James?
#James se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement chez VP - Coach]]
#James se dit qu'il faut retourner aux bases et propose d'organiser [[Sensibilisation agile des PP - VP]]
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille - VP]]
#Aprés toutes ces aventures, James décide de partir de chez les Rois du Ballon [[James micro-entrepreneur]]
<<else>>
Il fini par se sortir de la capacité de l'équipe (affichée lors du planning de sprint et parfois utilisée par le PO ou le management). Au fur et à mesure des sprints, il se rend compte qu'il a un peu plus de temps pour faire d'autres choses.
Comme au départ il n'ose pas prendre d'engagement de réalisation pour l'équipe, il utilise ce temps pour de la veille, de l'évangélisation et notamment travailler avec James.
Aprés quelques mois, l'équipe devient réellement autonome. Le Scrum Master commence à trouver du relai d'animation parmi les dev et peut s'attaquer à des sujets un peu plus systémiques.
[[Conclusion]]
<</if>>James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Il essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - VP]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe aborde la notion de dette technique. [[La dette technique et Scrum - VP]]
#James voudrait parler de la notion d'appétit avec le PO. Ils se rencontrent et finalement décident de mettre en place le [[Le WSJF chez VP]]
<<else>>
Il devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise.
* Il devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* James n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Vertes Prairies (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - VP]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - VP]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans VP. Il passe donc indépendant [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>>James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
<<if setup.steps lt 12>>
Il se rend compte qu'il a le choix entre :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de Vertes Prairies. James doit négocier le déblocage de budget de formation auprés de son manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - VP]]
#James a envie de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[Une formation agile - VP]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'évément agile lillois. [[James participe à son premier Agi'Lille - VP]]
<<else>>
Il se rend compte qu'il a le choix entre 4 manières principales de faire cette sensibilisation.
* La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de son client.
* James a aussi la possibilité de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne!
* A-t-on vraiment besoin de formation pour discuter de sujets pratiques avec les parties prenantes, surtout pas par un formateur externe? James pourrait aussi organiser un atelier ludique d'introduction à la démarche agile.
* James pourrait aussi mettre l'équipe' à contribution. Aprés tout, elle est plus à même que James pour parler aux parties prenantes de leur quotidien! Il pourrait proposer d'organiser un atelier d'échange équipe / parties prenantes.
[[Conclusion]]
<</if>>James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Vertes Prairies.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'il avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décalage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prise.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - VP]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions après un séminaire - VP]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour VP]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - VP]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>L'observation se passe bien. Eva rencontre l'équipe de James, le management, les parties prenantes... sans James.
Elle lui a bien sûr expliqué pourquoi elle voulait le faire sans lui : "Les personnes que je vais rencontrer doivent pouvoir dire tout ce qu'elles pensent sur la démarche appliquée sans essayer d'aller dans le sens de James si il est dans la pièce".
Que se passe-t-il ensuite?
#Eva conclue que la plus grande problématique n'est pas liée à l'aspect opérationnel agile de l'équipe, mais de la gestion de la vision produit par LudiGames. Elle propose à James de mettre en place [[Une vraie démarche produit chez VP]]
#Eva motive James à proposer la mise en place d’un [[Un comité de transformation - VP]]
#Eva accompagne James dans son évolution, maintenant qu'elle n'est plus Scrum Master débutante, elle se lance en Indep. [[James micro-entrepreneur]] <img src="https://picsum.photos/200/300?random=1"/>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'il a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF chez VP]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - VP]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[James organise un séminaire produit - VP]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une Sensibilisation agile des PP.
* James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voie agile vertueuse.
[[Conclusion]]
<</if>>James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
<<if setup.steps lt 12>>
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - VP]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - VP]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - VP]]
<<else>>
* James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une sensibilisation agile des parties prenantes.
* Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum.
* James se dit qu'il pourrait aussi creuser Shape Up
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit à son client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation - VP]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions après un séminaire - VP]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - VP]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - VP]]Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de Vertes Prairies a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - VP]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[Démarche OKR - VP]].
Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à Vertes Prairies [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
#James propose à son manager de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up - VP]]
#Fort des retours de son manager, James propose de créer [[Une méthode maison pour VP]] tout en restant dans la démarche agile.Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - VP]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Vertes Prairies. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - VP - Coach]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - VP]]James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit Vertes Prairies.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décalage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - VP]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions après un séminaire - VP]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour VP]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - VP]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Vertes Prairies. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA - VP]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - VP]].
#James propose à l'équipe de leur présenter une notion inhérente à la ge
<<else>>
Avec son groupe de travail, James doit donc s'atteler aux chantiers suivants :
* Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business chez les Vertes Prairies.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour VP.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[James continue avec son équipe Scrum - VP]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business - VP]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision Vertes Prairies. [[Les experts de la vision - VP]]
<<else>>
* C'est pourquoi James continue avec les équipes Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Il souhaite également travailler avec le PO afin de mettre en avant la Valeur Business chez VP.
* Il proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision client.
[[Conclusion]]
<</if>>
Entant que Scrum Master, James se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, James aime aussi la technique!! Il décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-il réellement être efficace dans ces deux missions?
Il continue à se poser des questions et cherche de nouveaux sujets.
<<if setup.steps lt 12>>
#James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur). [[Production VS Servant Leadership - VP]]
#Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le [[Le craftsmanship - VP]]
#James a la chance de trouver une place pour une formation sur le Kanban. [[Une formation avec Laurent Morisseau - VP]]
<<else>>
* James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur).
* Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le craftsmanship.
[[Conclusion]]
<</if>>C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF chez VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>
James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et VP.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur VP.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que VP entant que tel ne sont que trés peu visibles sur le net, leurs créations un peu plus, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité d eVP et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - VP]]
#Un ami de la femme de l'ex docteur du président de VP a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - VP]]
<<else>>
Impressionnés par le travail et l'engagement de James, le management lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés à James de porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
James est Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>>James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillagues lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
<<if setup.steps lt 12>>
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[Et toi, en quoi tu contribue aux OKRs? - VP]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[Kanban - VP]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[La ritualisation du suivi des OKR - VP]]
<<else>>
Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. James découvre que le management a demandé à ce que les objectifs individuels soient alignés sur les KR de chaque équipe.
[[Conclusion]]
<</if>>C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF chez VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein de VP qui participeront aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à James de porter cette vision au sein de l'entreprise. La partie visibilité de l'entreprise vers l'extérieur sera traitée dans un second temps.
James est emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]] James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - VP]]
#[[Shape Up - VP]]
#[[DevOps et VP]]
<<else>>
[[Conclusion]]
<</if>>James entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, James a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
James retourne à son bureau avec quelques questions. Il se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Il tombe sur la vidéo... Paf, c'est ce qu'il cherchait.
Il entend le terme antipatern.... Ca l'inquiète.
Il se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour James.
<<if setup.steps lt 12>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - VP]]
#L'utilisation des OKRs est revue. Maintenant James se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - VP]]
<<else>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait. Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée.
[[Conclusion]]
<</if>>Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanaban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - VP]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - VP]]?
#Quelque soit la manière, il réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - VP]].
<<else>>
James a plusieurs chantiers devant lui :
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, il réussi à déployer la démarche auprés de VP. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James se lance avec les OKR et il a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
James propose à son une équipe test chez son client d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, James propose au départ de mettre en place une réunion bimestrielle.
Il réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat de James est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. James est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, James amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
[[Conclusion]] <img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit VP à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation chez VP]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions après un séminaire - VP]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - VP]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - VP]]
<<else>>
Il propose au management de créer un comité de transformation auquel il pourrait se joindre.
Il pourrait aussi animer lui même la transformation de manière itérative.
Il cherche aussi à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>>Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, VP est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
<<if setup.steps lt 12>>
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - VP]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[Démarche OKR - VP]].
<<else>>
James fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
* Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet.
* Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la démarche OKR.
[[Conclusion]]
<</if>>Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à Vertes Prairies [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
#James propose à son manager de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up - VP]]
#Fort des retours de son manager, James propose de créer [[Une méthode maison pour VP]] tout en restant dans la démarche agile.
<<else>>
* Dans sa recherche de réponses, James entend parler d'un événement Lillois autour de la démarche agile. James participe à son premier Agi'Lille.
* James trouve rapidement une réponse qu'il souhaite amener à sa direction et prépare un atelier sur le fait de se focaliser sur la création de valeur et plus sur les dépenses.
* James découvre d'autres manière d'être agiles que Scrum. Il lit le livre blanc Shape Up et se demande si ce n'est pas une solution plus interessante d'un point de vue VP
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez les Rois du Ballon. [[Valeur Business - RDB]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - RDB]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - RDB]]Eva choisi une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, Eva est assurée que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[7 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[7 - Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[7 - Un comité de transformation chez LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[7 - Fast Track Scrum Master - Eva]] Eva passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour Eva c'est sa première formation.
Elle passe du temps à préparer un plan, puis elle le jette à la corbeille quand elle commence à compiler ses slides et qu'elle essaye de raconter une histoire cohérente.
Elle commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Elle promet de mettre à jour son cursus pour la prochaine session.
Elle a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'elle souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[7 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[7 - Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[7 - Un comité de transformation chez LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[7 - Fast Track Scrum Master - Eva]] Eva choisi une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, Eva est assurée que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[9 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[9 - Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[9 - Un comité de transformation chez LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[9 - Fast Track Scrum Master - Eva]] Evapasse beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour Eva c'est sa première formation.
Elle passe du temps à préparer un plan, puis elle le jette à la corbeille quand elle commence à compiler ses slides et qu'elle essaye de raconter une histoire cohérente.
Elle commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Elle promet de mettre à jour son cursus pour la prochaine session.
Elle a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'elle souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[9 - Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[9 - Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[9 - Un comité de transformation chez LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[9 - Fast Track Scrum Master - Eva]] Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Nomal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[7 - Un refinement revisité - RDB]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[7 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[7 - James participe à son premier Agi'Lille entant que Testeur]]Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[7 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[7 - James participe à son premier Agi'Lille entant que Testeur]]
#Comme certaines gestions de priorité posent question à l'équipe et à James, ce dernier propose au PO de faire un attelier [[7 - Product Box - RDB]] afin de valider que la vision qu'ils ont tous du produit est cohérente.Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[8 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[8 - James participe à son premier Agi'Lille - RDB]]
#Comme certaines gestions de priorité posent question à l'équipe et à James, ce dernier propose au PO de faire un attelier [[Product Box - RDB]] afin de valider que la vision qu'ils ont tous du produit est cohérente.Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[8 - Un refinement revisité - RDB]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[8 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[8 - James participe à son premier Agi'Lille - RDB]]Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[9 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[9 - James participe à son premier Agi'Lille - RDB]]
#Y'en a marre du Scrum Master! [[9 - Fast Track Scrum Master - James]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps et RDB]]
#James propose à l'équipe de travailler à la notion de dette technique. [[La dette technique et Scrum - RDB]]
#Aprés toutes ses aventures chez RDB [[James micro-entrepreneur]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - James découvre le Serious Gaming - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[9 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - RDB]]
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Après plusieurs mois (ben oui, l'industrie ça réagit pas très vite) dans ce système, James se dit quand même qu'il faudrait regarder d'autres choses...
#Comme il a entendu parler du [[7 - Kanban - RDB]], James se pose la question de savoir si ça ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[7 - James participe à son premier Agi'Lille - RDB]]Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompanger un Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure de James?
#James se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement chez RDB]]
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[7 - James participe à son premier Agi'Lille - RDB]]
#Exit le Scrum Master, passons à la suite entant qu'indep! [[7 - James micro-entrepreneur]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[9 - Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[9 - Shape Up - RDB]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans les Rois du Ballons. Il passe donc indépendant [[James micro-entrepreneur]] Le manager de James prend son temps avant de valider la demande de James. En effet, il a peur que James n'ai plus suffisamment de temps à consacrer à son équipe. Au bout de quelques mois (on est dans l'industrie, souvenez vous) il propose à James d'endosser le rôle de coach agile officiellement.
James est ravi. Son premier chantier est donc de s'attaquer à la notion de Valeur Business chez RDB.
C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt - RDB - Coach]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[9 - Le WSJF chez RDB - Coach]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB - Coach]]
Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompanger un Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure de James?
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille - RDB]]
#A force de travailler à des sujets d'organisation, [[James devient coach agile chez les Rois du Ballon]]
#Exit le Scrum Master, passons à la suite entant qu'indep! [[James micro-entrepreneur]] James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi. Il engage malgré tout un chantier avec le PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#James revient sur une notion clé : la [[Valeur Business - RDB]]. Aprés tout, on a beau faire tout ce qu'on veut, tant que cette dernière n'est pas d'équerre on va nul part.
#James va galérer, mais il va y arriver, nous ce qu'on veut voir c'est l'après [[Fast Track Scrum Master - James]] Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[7 - On ne devient pas coach tout seul - James]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[7 - Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[7 - Indep c'est bien, tout seul ca craint!! - James]]
James rejoint donc Vertes Prairies, un voyagiste spécialisé dans les excursions bas carbonne (proche de chez vous).
L'équipe informatique n'est pas trés grande mais ils ont tout de même 2 grosses applications: une pour les clients et une pour les vendeurs en agence ou au téléphone.
Ces deux applications sont maison et donc maintenues en interne.
James prend en main une 20aine de personnes entant que Scrum Master.
"Ca va être simple", lui annonce le DSI. En effet, il se targue que les équipes sont déjà agiles mais sans cadre... James se rend compte que le terme agile n'est pas bien employé, il voit même des affiches "Passez votre entreprise en mode agile" qui trainent dans les bureaux.
Où allons nous à partir de là?
#James va mettre en place exactement ce qu'il a appris chez les Rois du Ballon. Il réplique à la fois les pratiques agiles mais réussi à convaincre le DSI de changer l'organisation afin de se rapprocher de celle qu'il a connu avant. [[7 - Le Cargo Cult ca pique - Vertes Prairies]]
#James analyse la situation. Certes la taille de la DSI pourrait lui permettre de lancer une initiative Scrum sur 2 à 3 équipes mais il a le sentiment qu'il y a plus à aller chercher. Il accompagne donc son entreprise vers la mise en place d'une méthode maison. [[7 - Une méthode maison pour les vertes prairies]]
#On a pas envie de voir comment James s'en sort entant que Scrum Master, ce qu'on veut voir c'est le résultat et ce qu'il fait après!! [[7 - Fast Track Scrum Master - Vertes Prairies]]
James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[8 - Un miroir coach - James]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[8 - Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[8 - James participe à son premier Agi'Lille entant qu'Indep]]Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" James se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engagé sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[8 - La fresque du climat - James]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[8 - Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[8 - James se passionne pour le Serious Gaming - Indep]]
James s'est lancée. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant que James est établie entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[8 - James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[8 - James organise un séminaire produit Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[8 - James participe à son premier Agi'Lille pour un client]]
James met du temps à comprendre ce qui arrive ches VP.
James tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe "test" ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'il est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il décide de revoir sa copie. Quelle est la prochaine étape?
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[8 - Valeur Business VP]].
#James se rend compte qu'il faut absolument [[8 - Accompagner le PO - VP]]
#James entend parler de la communauté agile Lilloise et décide de participer à son premier Agi'Lille. [[8 - James participe à son premier Agi'Lille - VP]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[8 - La Rache chez VP]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[8 - Valeur Business VP]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[8 - La dette technique et Scrum - VP]] L'expérience de Scrum Master de James se passe comme pour beaucoup de Scrum Master et James considère qu'il s'en sort plutôt bien. Certes, il rencontre quelques challenges le long du chemin mais il les gère sans grosse difficulté.
Au bout de quelques mois (voir 2 ou 3 ans) comme Scrum Master, il décide de regarder à ce qui se passe ailleurs (à la fois au sein des Rois du Ballons mais aussi en dehors).
Les opportunités semblent plutôt alléchantes, quelle direction va prendre la carrière de James?
#James décide qu'il est temps pour lui de voler de ses propres ailes et se lance entant qu'indépendant. [[8 - James micro-entrepreneur]]
#James explore ce qu'il se passe chez Vertes Prairies et se rend compte des limitations de son poste actuel. [[8 - ScrumMaster c'est bien, mais limité - VP]]
#Les réussites de James l'amènent à monter à un niveau supérieur d'abstraction [[8 - James devient coach agile chez VP]]
#La transformation de Vertes Prairies ne fait que commencer, James s'attaque maintenant à la [[8 - Démarche produit chez Vertes Prairies]]Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[9 - Prioriser en tailles de TShirt - VP]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[9 - Le WSJF chez VP]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[9 - Le craftsmanship - VP]]
#James propose à l'équipe d'explorer le [[9 - Kanban - VP]] C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[9 - Le WSJF chez VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez Vertes Prairies [[9 - Valeur Business VP - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - VP -Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - VP - Coach]]Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
James propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF - VP]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - VP]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[James organise un séminaire produit - VP - Coach]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Vertes Prairies (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - VP]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - VP]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans VP. Il passe donc indépendant [[James micro-entrepreneur]] James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[Sensibilisation agile des PP - VP]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - VP]]
#James se dit qu'il pourrait aussi creuser [[Shape Up - VP]] Chez les Vertes Prairies, le rôle de Scrum Master est maintenant bien défini, avec ses responsabilités, ses zones d'influence mais aussi ses limites et ses interdits.
De plus, l'organisation actuelle des Vertes Prairies fait que James n'a pas accés, entant que Scrum Master, aux différentes personnes d'influence de l'entreprise.
Que faire dans ce cas là?
#James pourrait se pencher sur l'aspect produit en lien avec ses équipes. C'est vrai qu'il s'est beaucoup concentré sur l'efficacité opérationnelle de l'équipe mais il pourrait peut-être atteindre d'autres personnes au travers du PO et pourquoi pas, acquérir de nouvelles expériences. [[9 - Accompagner le PO - VP]]
#Chez les Vertes Prairies c'est mort, ca sert à rien d'essayer de faire bouger les choses de l'intérieur, sans aide. Mais est-ce le cas ailleurs? James décide d'aller à la rencontre de la communauté agile Lilloise. [[9 - James participe à son premier Agi'Lille - VP]]
#Il va se battre! James décide d'aborder le sujet avec son manager. Celui-ci lui propose de monter un dossier pour expliquer son point de vue. [[9 - James devient coach agile chez VP]]Notre start-up, Vertes Prairies, a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#James propose d'évangéliser toutes les parties prenantes à la démarche agile [[9 - Sensibilisation agile des PP - VP]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[9 - James organise un séminaire produit - VP]]
#Pour James, rien de tel que d'aller à la rencontre de la communauté pour savoir se qui est disponible sur ce sujet. [[9 - James participe à son premier Agi'Lille - VP]] Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[9 - James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[9 - James participe à son premier Agi'Lille entant qu'Indep]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James interesse les participants à tous les événements auxquels il assiste.[[9 - James se lance dans l'écriture d'une conférence - Indep]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[9 - Syndrôme de l'imposteur - James Indep]] James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - James Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais James a la chance de ne pas être tout seul sur l'animation du stand et il trouve donc un peu de temps pour son apprentisage personnel.
James peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[9 - James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - Indep]]Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[9 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l'[[9 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]] Un client de James lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, James est sur ses gardes car il ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, James fini par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
James arrive donc dans un environnement qu'il ne connait pas bien, mais c'est tout de même un environnement agile donc il pense qu'il va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce que James connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour James c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, James peut avancer vers d'autres missions / explorations :
#Lors de sa mission, James a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, il décide d'y participer. [[9 - James participe à son premier Agi'Lille entant qu'Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]]
#Un manager s'approche de James et lui dit [[9 - L'agile ca coûte cher! - James Indep]]
James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[9 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]] James est contacté par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec James afin de regarder à leurs process de manière différente.
James propose à Anna un premier rendez-vous et ils s'accordent sur le fait que James peut les accompagner mais que ca ne sera pas une grosse intervention mais plutôt de petites interventions.
La première session, James rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, James sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Il rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
James passe plusieurs heures à préparer son intervention, mais il est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis il continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures de James?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[9 - Gamifier une rétrospective - James Indep]]
#Il choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[9 - Kanbanzine - James]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[9 - Scrumble - James Indep]]
#Il se dit que la communauté agile doit pouvoir l'aider [[9 - James découvre les meetups et Nord Agile entant qu'indep]] Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - VP]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - VP]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - VP]] James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projeté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? [[Le craftsmanship - VP]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - VP]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - VP]] , quelles sont ses options?Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Après quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l’intéressent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - VP]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - VP]]?
#Quelque soit la manière, il réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - VP]].Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-développement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par exemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelque chose. [[DevOps et VP]]
#James propose à l'équipe de travailler à la notion de dette technique. [[La dette technique et Scrum - VP]]
#Après toutes ses aventures chez VP, James décide de voler de ses propres ailes [[James micro-entrepreneur]] James propose à un de ces POs un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Il découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour James?
#James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[James devient PPO - VP]]
#James le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[Product Box - VP]].
#James se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Il décide alors de [[Se former aux démarches produits - VP]].
James semble tout indiquée pour accompagner les Vertes Prairies sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Vertes Prairies.
Au bout de 3 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Vertes Prairies.
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Vertes Prairies plus en amont dans leur démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[Un Scrum Master pour remplacer James - VP]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[Créer une nouvelle équipe Scrum - VP]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[James participe à son premier Agi'Lille - VP]]
#James décide de se lancer dans la description de la démarche agile selon les Vertes Prairies du Ballon afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[Une méthode maison pour VP - Coach]] James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agil et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Il se rend compte qu'il a le choix entre :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de Vertes Prairies. James doit négocier le déblocage de budget de formation auprés de son manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - VP]]
#James a envie de proposer lui même une formation aux parties prenantes. Aprés tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[Une formation agile - VP]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'évément agile lillois. [[James participe à son premier Agi'Lille - VP]]
James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Vertes Prairies.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - VP]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions après un séminaire - VP]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour VP - Coach]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Vertes Prairies demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - VP]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit à son client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation - James Indep]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions aprés un séminaire - James Indep]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - James Indep]]Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à son client [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - James Indep]]
#James propose à son client de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up pour son client - James Indep]]
#Fort des retours de son client, James propose de créer [[Une méthode maison pour son client - James Indep]] tout en restant dans la démarche agile.Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Il décide de se lancer dans cette histoire de miroir coach. [[Un miroir coach - James Indep]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - James Indep]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - Indep]]
Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les clients attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne. Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - James Indep]]
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel il a une grande marge d'amélioration : [[Le craftsmanship - James Indep]]
#James est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.[[Agile dans l'Infra? - James]] <img src="https://picsum.photos/200/300?random=1"/>Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
<<if setup.steps lt 12>>
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[La dette technique et Scrum - VP]]
#Aborder la [[Valeur Business - VP]]
#Mettre en place un mode de priorisation simple et rapide. [[Prioriser en tailles de TShirt - VP]]
#Déployer le WiSJiF [[Le WSJF chez VP]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
<<if setup.steps lt 12>>
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[Valeur Business - VP]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[Le WSJF chez VP]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[La dette technique et Scrum - VP]]
<<else>>
* Le document permet à l'ensemble des parties prenantes impliquées dans le produit de se rendre compte qu'il faut apprendre à dire Non. (Comme dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg traduite par Fred Lothon).
* Malgré une superbe product box, le produit (ou le projet) continue à ne pas répondre aux promesses. Les retours des premiers testeurs sont mauvais. James explore les méandres du droit à l'échec.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James passant coach, il faut trouver un Scrum Master pour le remplacer auprés de l'équipe existante.
En réunion avec son manager il hésite sur les préconnisations qu'il pourrait faire.
En effet, pour le remplacer, les Vertes Prairies ont le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, aprés tout le Rois du Ballon sont capables d'embaucher de nouvelles personnes, James se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et James se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
James est également tenté de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Il entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ca risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en delaissant un peu le développement.
Aprés plusieurs longues réunions, le management accepte la solution préconnisée par James : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'il amène le sujet à l'équipe, personne ne se porte volontaire directement, James leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
James est enchanté, il cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
<<if setup.steps lt 12>>
Maintenant qu'il est remplacé, James peut se consacrer à la suite :
#[[James organise un séminaire produit - VP - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d'[[Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez VP - Coach]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Vertes Prairies correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Vertes Prairies. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
<<if setup.steps lt 12>>
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez VP - Coach]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business VP - Coach]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - VP - Coach]]
<<else>>
Avec son groupe de travail, James doit donc s'atteler aux chantiers suivants :
* Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.
* Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la Valeur Business chez les Vertes Prairies.
* James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique.
Troll : Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement : La Rache
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - VP]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - VP]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - VP]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - VP]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet
<<else>>
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James se propose de lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgré sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
<<if setup.steps lt 12>>
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez Vertes Prairies [[Valeur Business - VP]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - VP]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - VP]]
<<else>>
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>>James choisit une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de VP.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour VP. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - VP]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer Vertes Prairies dans le bon sens. [[James organise un séminaire produit - VP]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation chez VP]]
#James se lance tout seul. [[James micro-entrepreneur]]
<<else>>
Au retour de leur formation, les parties prenantes veulent absolument se lancer : les promesses de Scrum sont géniales et en plus, les exemples donnés par le formateur donnent envie... il faut tout faire comme il a dit.
Donc ils se lancent, l'équipe se recentre sur ses basiques (by the book) :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'ils sont apparemment entrés en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il lui faut revoir sa copie. Il décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>James passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour James c'est sa première formation.
James passe du temps à préparer un plan, puis il le jette à la corbeille quand il commence à compiler ses slides et qu'il essaye de raconter une histoire cohérente.
Il commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Il promet de mettre à jour son cursus pour la prochaine session.
Il a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'il souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de VP.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour VP. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - VP]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer VP dans le bon sens. [[James organise un séminaire produit - VP]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation chez VP]]
#Avec cette expérience complémentaire en poche, James passe indépendant. [[James micro-entrepreneur]]
<<else>>
* James se retrouve rapidement confronté au ShuHaRi quand il s'agit du déploiement de Scrum.
* Aprés quelques temps, il se rend compte que la notion même de produit mériterait d'être définie pour VP.
* Il réfléchit à proposer la mise en place d'un comité de transformation.
James restera-t-il longtemps chez VP ou franchira-t-il le cap de l'indépendance?
[[Conclusion]]
<</if>>
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
<<if setup.steps lt 12>>
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[Valeur Business - VP]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - VP]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - VP]]
<<else>>
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discuter avec james qui lui propose de nouvelles perspectives :
* James se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Il cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. James et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* James propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James et l'équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
<<if setup.steps lt 12>>
Qu'allons nous observer ensuite?
#Le manager de James l'interpelle car ils considèrent que les progrès certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - VP]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[La démarche produit - VP]]
#De Kanban à Scrum c'est très beau tout ça, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles chez VP]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Entant que Scrum Master, James se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, James aime aussi la technique!! Il décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-il réellement être efficace dans ces deux missions?
<<if setup.steps lt 12>>
Il continue à se poser des questions et cherche de nouveaux sujets.
#James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur). [[Production VS Servant Leadership - James Indep]]
#Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le [[Le craftsmanship - James Indep]]
#James a la chance de trouver une place pour une formation sur le Kanban. [[Une formation avec Laurent Morisseau - James Indep]]
<<else>>
Il continue à se poser des questions et cherche de nouveaux sujets.
* James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur).
* Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le craftsmanship.
[[Conclusion]]
<</if>>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - VP]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business VP - Coach]] ?
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - VP]]
<<else>>
[[Conclusion]]
<</if>>Notre start-up, Vertes Prairies, a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
<<if setup.steps lt 12>>
James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - VP]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[James découvre les meetups et Nord Agile - VP]]
#Rien de tel qu'une grand messe pour lancer une re-fondation de la manière de travailler. Après quelques négociations, [[James organise un séminaire produit - VP]]
<<else>>
* Il va lui falloir évangéliser toutes les parties prenantes à la démarche agile.
* James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et il s'inscrit donc à un Meetup produit.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations,James organise un séminaire produit.
[[Conclusion]]
<</if>>Durant ses différentes explorations en ligne, dans les conférences, etc. , James a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors James ne s'offusque pas.
Il a maintenant acquis un réflex : à chaque fois qu'il arrive dans un nouveau contexte, même si c'est pour une équipe qu'il connait déjà, il revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, il sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#James est assez fréquement, de ces temps-ci, touché par le [[Syndrôme de l'imposteur - VP]]
#James travaille avec beaucoup d'équipe ces derniers temps et il aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - VP]]
#James pourrait se lancer tout seul [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
<<if setup.steps lt 12>>
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - VP]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - VP]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - VP]]
<<else>>
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF
* Un manager vient voir James avec la fameuse rengaine : L'agile ça coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetée, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - VP]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - VP]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - VP]] , quelles sont ses options?
<<else>>
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à James. Après s'être renseigné sur guntehr-le-jeu.fr, il a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
James est conquis.
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - VP]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - VP]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance et explore l’[[Agile Hors IT - James]]
<<else>>
Après avoir découvert Gunther, et c'est du lourd, il s’intéresse au serious gaming encore plus. Il fini par en faire sa spécialité. Il aimerait pouvoir, un jour, en créer un pour VP. Peut-être aura-t-il la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]]
<</if>>Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
James trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais James est persuadé qu'il pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-il l'atelier "Roule ta bille" ;)
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - VP]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - VP]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance et explore l’ [[Agile Hors IT - James]]
<<else>>
[[Conclusion]]
<</if>>James a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
James profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - VP]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - VP]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance est explore l’[[Agile Hors IT - James]]
<<else>>
Maintenant, James réfléchit au chemin possible pour accompagner VP sur la voie du DevOps.
Il pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour VP.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de VP, il a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[James continue avec son équipe Scrum - VP]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - VP]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision RDB. [[Les experts de la vision - VP]]
<<else>>
* C'est pourquoi James continue avec une équipe Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Il souhaite également travailler avec le PO afin de mettre en avant la Valeur Business VP.
* Il proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision VP.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand on regarde la manière dont VP gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bétises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Aprés tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - VP]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - VP]]
#Le Scrum Master propose la mise en place d'[[Un déversement de backlog - VP]]
<<else>>
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
<<if setup.steps lt 12>>
#Travailler à la Valeur Business chez Vertes Prairies [[Valeur Business - VP]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - VP]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - VP]]
<<else>>
#Travailler à la Valeur Business.
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel.
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[Gamifier une rétrospective - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Kanbanzine - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Scrumble - VP]]
#Il se dit qu'il doit acquérir plus d'expérience et [[James découvre les meetups et Nord Agile - VP]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'une de ces équipes.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
<<if setup.steps lt 12>>
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - VP]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - VP]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - VP]]
<<else>>
A partir de là, il continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'il a des questionnements...
* Il décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. James se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui :
James rejoint Nord Agile.
[[Conclusion]]
<</if>>
Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les équipes attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - VP]]
#James propose de travailler à la [[Valeur Business - VP]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[On ne devient pas coach tout seul chez VP]]
<<else>>
Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Une des choses qui l'aide beaucoup c'est sa relation de miroir coach avec Yulie!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
<<if setup.steps lt 12>>
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF - VP]]
#James propose au management VP d'investiguer la notion de [[Valeur Business - VP]].
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[Shape Up - VP]]
<<else>>
* James propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* James propose à VP de travailler d'abord à la valeur Business.
* James a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec lui.
[[Conclusion]]
<</if>>James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Après avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - VP]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - VP]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez VP il ne le font pas).
<<if setup.steps lt 12>>
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[DevOps et VP]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - VP]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[Kanban - VP]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
James attaque le sujet sur plusieurs flancs :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le devOps avec son équipe préférée.
* James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. Il lance donc une expérimentation WSJF avec son PO.
* James comprend que c'est un changement de culture important, il se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]]
<</if>>Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client de James lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - Indep]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - James Indep]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[James se lance dans l'écriture d'une conférence - Indep]] James est contacté par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec James afin de regarder à leurs process de manière différente.
James propose à Anna un premier rendez-vous et ils s'accordent sur le fait que James peut les accompagner mais que ca ne sera pas une grosse intervention mais plutôt de petites interventions.
La première session, James rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, James sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Il rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
James passe plusieurs heures à préparer son intervention, mais il est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis il continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures de James?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]] Un client de James lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, James est sur ses gardes car il ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, James fini par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
James arrive donc dans un environnement qu'il ne connait pas bien, mais c'est tout de même un environnement agile donc il pense qu'il va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce que James connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour James c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, James peut avancer vers d'autres missions / explorations :
#Lors de sa mission, James a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, il décide d'y participer. [[James participe à son premier Agi'Lille entant qu'Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
#Un manager s'approche de James et lui dit [[L'agile ca coûte cher! - James Indep]]
https://docs.google.com/presentation/d/e/2PACX-1vSTPgQ7kTmRDeh8Nan6fkmCzSZ_QzWnNRwUJCOI4v_vvDyNMYGIzvI7inS7X59hLhNHvXpUxVjnauwL/pub?start=true&loop=true&delayms=10000James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - James Indep]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile entant qu'indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - James Indep]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - James Indep]] quand on parle de rétrospective.
En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
James est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, il propose à son commanditaire d'animer l'atelier avec une des équipes qu'il accompagne.
L'atelier se passe bien. L'équipe de DoctoChat comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - James Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour son client - James Indep]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - James Indep]] Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - James Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - James Indep]]
#James a pris goût aux outils gamifiés, il se lance dans[[Kanbanzine - James Indep]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - James Indep]] James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
<<if setup.steps lt 12>>
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - James Indep]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile entant qu'indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - James Indep]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - James Indep]] quand on parle de rétrospective.
<<else>>
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
<<if setup.steps lt 12>>
James est tout de suite emballé par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, il propose à son commanditaire d'animer l'atelier avec une des équipes qu'il accompagne.
L'atelier se passe bien. L'équipe de son client comprend les principes de limite de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - James Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour son client - James Indep]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - James Indep]]
<<else>>
Pour son activité d'indépendante il décide acheter la version éditée qui, de plus, lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
James accompagne l'équipe qui se lance tête baissée dans la démarche Kanban.
James travaille avec le scrum master pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et propose au scrum master de regarder un peu aux goulots d'étranglement au sein de leur tableau. Ils se rendent compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Ils s'engagent donc dans l'identification des workflow externes à l'équipe et proposent aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le teste avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - James Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - James Indep]]
#James a pris goût aux outils gamifiés, il se lance dans[[Kanbanzine - James Indep]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - James Indep]]
<<else>>
* Afin de faire évoluer ses accompagnements, James se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* James a pris goût aux outils gamifiés, il se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. Il est touché par le syndrôme de l'imposteur.
[[Conclusion]]
<</if>>Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
<<if setup.steps lt 12>>
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - VP]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - VP]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - VP]]
<<else>>
Il liste quelques outils interessants :
* Il pourrait demander à TechSys de venir lui présenter Gunther.
* Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le Lego, Scrum et Chocolat pour le DevOps.
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>>Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James décide de se lancer dans l’[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
<<else>>
[[Conclusion]]
<</if>>Un client de James lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, James est sur ses gardes car il ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, James fini par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
James arrive donc dans un environnement qu'il ne connait pas bien, mais c'est tout de même un environnement agile donc il pense qu'il va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce que James connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour James c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
<<if setup.steps lt 12>>
Aprés plusieurs mois d'accompagnement des équipes, James peut avancer vers d'autres missions / explorations :
#Lors de sa mission, James a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, il décide d'y participer. [[James participe à son premier Agi'Lille entant qu'Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
#Un manager s'approche de James et lui dit [[L'agile ca coûte cher! - James Indep]]
<<else>>
[[Conclusion]]
<</if>>James est contacté par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec James afin de regarder à leurs process de manière différente.
James propose à Anna un premier rendez-vous et ils s'accordent sur le fait que James peut les accompagner mais que ca ne sera pas une grosse intervention mais plutôt de petites interventions.
La première session, James rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, James sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Il rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
James passe plusieurs heures à préparer son intervention, mais il est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis il continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
<<if setup.steps lt 12>>
Quelle est la suite des aventures de James?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
<<else>>
[[Conclusion]]
<</if>>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - James Indep]]
#Il choisit un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[Kanbanzine - James Indep]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[Scrumble - James Indep]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile entant qu'indep]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'un de ces clients.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client de James lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - Indep]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - James Indep]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - VP]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - VP]]
<<else>>
Il propose d'organiser un séminaire pour discuter de la vision produit et déploie une démarche adaptée à leur contexte.
[[Conclusion]]
<</if>>Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez la plupart de ces clients semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps - James Indep]]
#James commence a voir de l'expérience maintenant, un de ses amis lui propose de les partager lors d'une rencontre agile. [[James se lance dans l'écriture d'une conférence - Indep]]
#Aprés toutes ses explorations, [[James se passionne pour le Serious Gaming - Indep]]
<<else>>
* James explore les différentes possibilités de gestion de la dette technique, tout en essayant de comprendre la compatibilité, ou pas avec le cadre Scrum.
* James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à son client.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadée qu'il faut y changer quelquechose. James va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? James s'inquiète également.
[[Conclusion]]
<</if>>Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
<<if setup.steps lt 12>>
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - James Indep]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - James Indep]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - James Indep]]
<<else>>
Il liste quelques outils interessants :
* Il pourrait demander à TechSys de venir lui présenter Gunther.
* Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le Lego, Scrum et Chocolat pour le DevOps.
[[Conclusion]]
<</if>>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels il pourrait s'améliorer:
#James propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - James Indep]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business Client - James Indep]]
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Durant ses différentes missions, James a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors James ne s'offusque pas.
Il a maintenant acquis un réflex : à chaque fois qu'il arrive dans un nouveau contexte, même si c'est pour un client qu'il connait déjà, il revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, il sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#James est assez fréquement, de ces temps-ci, touché par le [[Syndrôme de l'imposteur - James Indep]]
#James travaille avec beaucoup d'équipe ces derniers temps et il aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James accepte une mission dans un cabinet d'architectes [[Agile Hors IT - James]]
#James est contacté pour accompagner des équipes [[Agile dans l'Infra? - James]]
<<else>>
[[Conclusion]]
<</if>>Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les équipes attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne. Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Une des choses qui l'aide beaucoup c'est sa relation de miroir coach avec Yulie!
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - James Indep]]
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - James Indep]]
#James est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.[[Agile dans l'Infra? - James]]
<<else>>
[[Conclusion]]
<</if>>Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place.
<<if setup.steps lt 12>>
Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[Le WSJF - James Indep]]
#James travaille le craftsmanship avec une équipe relativement jeune [[Le craftsmanship - James Indep]]
#Une équipe au top de sa force est limitée par l'accés aux environnements de test et de production. Il leur parle du [[DevOps - James Indep]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - James Indep]]
<<else>>
[[Conclusion]]
<</if>>Tout le monde en parle, et les agilistes expérimentés autour de James n'arrêtent pas de lui en parler: passer indep c'est super facile!!
Quelques minutes sur internet (Inpi, Ursaff...) et le tour est joué! Le plus dur c'est de choisir un nom de société (et oui car on peut avoir des surprises, demandez à Stephane D ;)).
Maintenant le plus dur c'est de trouver des clients et de lancer son activité.
Mais comment va s'orienter l'expérience entrepreneuriale de James?
#Une chose est certaine pour James : il veut être coach agile. Et donc il n'acceptera que des missions de cet ordre. [[5 - On ne devient pas coach tout seul - James Indep]]
#Ces copains lui ont dit : le plus dur au départ, c'est de faire ta clientèle. Il décide donc de chercher des missions, n'importe quelles missions, du moment qu'elles se déroulent dans un contexte agile. [[5 - Engranger des missions - James]]
#Au bout de quelques temps James commence à subir les effets secondaires du lancement en indépendant. Il a plein d'envies mais son statut va-t-il lui permettre de toutes les concrétiser? [[5 - Indep c'est bien, tout seul ca craint!! - James]]
Comme disait Alfred de Musset : "Qu'importe le flacon, pourvu qu'on ait l'ivresse!" James se dit que pour se lancer, qu'importe la mission, pourvu qu'elle soit agile!
James n'est donc pas trés regardant quant à l'intitulé des postes qui lui sont proposés à condition que les actions qu'il devra engagé sont dans ses domaines de compétence.
Il se retrouve donc à faire de petites interventions au départ : remplacement de Scrum Master en congé maternité, accompagnement d'équipes débutantes en vue d'atteindre une autonomie. Il reprend même, le temps d'une mission de 3 mois, le développement pour intégrer une équipe qui fonctionne au format lab (CF Conférence de Julien Roynette de chez Kiabi).
Pendant tout ce temps, James n'hésite pas à partager ses réflexions, ses expériences... Il est donc actif sur les réseaux sociaux, il crée son propre site internet, et se demande si il ne pourrait pas participer à des initiatives communes avec d'autres coachs.
Tous ces efforts finissent par payer : James recoit de plus en plus de propositions de mission directement (sans passer par son apporteur d'affaire) et s'est même fait un réseau professionnel interessant.
Une des remarques qu'il recoit de temps en temps, cependant, c'est le fait qu'en allant dans plusieurs directions, la première lecture de son CV peut faire penser qu'il ne maitrise pas tous ces sujets.
James est sur le point de terminer une mission super interessante au sein d'une équipe multi-coachs dans l'industrie. Il va devoir choisir sa prochaine mission. Que trouve-t-il dans sa bannette (boite mail)?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[6 - Agile dans l'Infra? - James]]
#James est investi, comme la plupart d'entre nous, dans l'éco-responsabilité. Il entend parler de "La maison dans les arbres" et souhaiterait pouvoir devenir animateur de la "Fresque du numérique". Avant cela, il participe à un atelier sur [[6 - La fresque du climat - James Indep]]
#Son apporteur d'affaire a trouvé une mission plutôt interessante dans l'acompagnement d'un gros cabinet d'architectes (ceux des maisons hein, pas ceux des réseaux). Il a l'opportunité de travailler sur l'[[6 - Agile Hors IT - James]]
#Lors de sa dernière mission, il a travaillé avec un coach qui n'arrêtait pas de sortir des outils gamifiés pour ses accompagnements. Il a même eu l'occasion de participer à la co-création d'un outil de facilitation des Gembas. (Cf Gemb'Activ : https://www.hacoeur.biz/hacktivite-gembactive/). Du fait, [[6 - James se passionne pour le Serious Gaming - Indep]]
James s'est lancé. Il savait qu'être indépendant lui demanderait de faire des sacrifices. Mais il n'avait pas forcément calculé l'ampleur de ces derniers.
Non seulement, il comprend que toute journée passée hors mission ne lui rapporte pas (mais en plus potentiellement lui coûte), mais en plus, toutes les formations sont à sa charge.
Il décide de se donner une première année de pleine mission, sans temps morts mis à part pour les congés, histoire de se constituer un coussin de sécurité.
Durant sa première année, il en profite cependant pour regarder ce qui se passe dans la communauté bénévole (gratuite ou HNO au moins).
Un autre point auquel il n'avait pas non plus pensé, réside dans le fait qu'il rêvait de pouvoir collaborer avec d'autres indépendants sur des initiatives communes, cependant aligner les agendas de chacun est trés compliqué. Personne n'est jamais vraiment disponible en même temps, surtout si c'est pour "investir" du temps sur une création, écriture, échange ou veille.
La vie n'est pas toute noire non plus, James réussi à acquérir de nouvelles compétences et connaissances, notamment en ligne ou via de la lecture d'écrits (livres, articles...) et son réseau fourmille de pépites... mais c'est toujours sur son temps perso. Rares sont les clients prêts à laisser du temps d'amélioration personnelle aux indépendants qu'ils payent (à prix d'or d'aprés leurs dires).
Maintenant que James est établie entant qu'agiliste indépendant (coach), quel aspect de sa vie professionnelle allons nous explorer?
#Via ses temps d'exploration HNO, il découvre la communauté lilloise, les différents événements et notament [[6 - James découvre les meetups et Nord Agile entant qu'indep]]
#C'est bien beau de devoir gérer sa montée en compétences tout seule, aprés tout c'est la vie d'indep, mais lorsq'un client vient le voir avec un challenge d'organisation d'événement interne à grande échelle, James doit explorer de nouveaux domaines. [[6 - James organise un séminaire produit Indep]]
#Un des clients de James est sponsor de l'Agi'Lille cette année! Et, chance rare, il compte sur lui pour participer à l'organisation du stand et à son animation. Le tout sur du temps facturé! [[6 - James participe à son premier Agi'Lille pour un client]]
James a une jolie expérience chez les Rois du Ballon. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[6 - Un miroir coach James]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[6 - Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[6 - James participe à son premier Agi'Lille - RDB]] Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[7 - James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[7 - James participe à son premier Agi'Lille entant qu'Indep]]
#Aprés tous ces meetups, [[7 - James se passionne pour le Serious Gaming - Indep]]
James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[7 - Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[7 - Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[7 - Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[7 - L'agile ca coûte cher! - James Indep]]Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Animer un stand et participer à des ateliers ou conférences sont parfois incompatibles, mais James a la chance de ne pas être tout seul sur l'animation du stand et il trouve donc un peu de temps pour son apprentisage personnel.
James peut donc participer à un atelier qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[7 - James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[7 - James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[7 - Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[7 - James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[7 - James se lance dans l'écriture d'une conférence - Indep]]Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[7 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[7 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[7 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[7 - James organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financié mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l'[[9 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]]
Un client de James lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, James est sur ses gardes car il ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, James fini par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
James arrive donc dans un environnement qu'il ne connait pas bien, mais c'est tout de même un environnement agile donc il pense qu'il va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce que James connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour James c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, James peut avancer vers d'autres missions / explorations :
#Lors de sa mission, James a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, il décide d'y participer. [[7 - James participe à son premier Agi'Lille entant qu'Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[7 - James organise un séminaire produit - Indep]]
#Un manager s'approche de James et lui dit [[7 - L'agile ca coûte cher! - James Indep]]
James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[7 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[7 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[7 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[7 - James organise un séminaire produit - Indep]] James est contacté par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec James afin de regarder à leurs process de manière différente.
James propose à Anna un premier rendez-vous et ils s'accordent sur le fait que James peut les accompagner mais que ca ne sera pas une grosse intervention mais plutôt de petites interventions.
La première session, James rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, James sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Il rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
James passe plusieurs heures à préparer son intervention, mais il est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis il continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures de James?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[7 - Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[7 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[7 - James organise un séminaire produit - Indep]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[7 - Gamifier une rétrospective - James Indep]]
#Il choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[7 - Kanbanzine - James]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[7 - Scrumble - James]]
#Il se dit que la communauté agile doit pouvoir l'aider [[7 - James découvre les meetups et Nord Agile entant qu'indep]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[8 - Gamifier une rétrospective - James Indep]]
#Il choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[8 - Kanbanzine - James Indep]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[8 - Scrumble - James Indep]]
#Il se dit que la communauté agile doit pouvoir l'aider [[8 - James découvre les meetups et Nord Agile entant qu'indep]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Il décide de se lancer dans cette histoire de miroir coach. [[8 - Un miroir coach - James]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[8 - James se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[8 - Agile Games France - James Indep]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[8 - James rejoint Nord Agile - Indep]]
Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les clients attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne. Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[8 - Un miroir coach - James]]
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[8 - Le craftsmanship - James Indep]]
#James est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.[[8 - Agile dans l'Infra? - James]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[8 - Le WSJF - James Indep]]
#James propose à un de ses clients, débutant en démarche agile, de travailler d'abord à la [[Valeur Business Client - James Indep]] avant d'avancer sur le chemin de l'agilisation.
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - James]]
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[8 - Shape Up pour son client - James Indep]] James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[8 - James rejoint Nord Agile - Indep]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[8 - La fresque du climat - James Indep]]
#James se lance dans l'étude de [[8 - Shape Up pour son client - James Indep]] Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[8 - James se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client de James lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais James se lance. [[8 - James organise un séminaire produit - Indep]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[8 - Agile Games France - James Indep]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[8 - James se lance dans l'écriture d'une conférence - Indep]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[8 - James se passionne pour le Serious Gaming - Indep]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[8 - James rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - James Indep]]
#Aprés l'atelier auquel il a participé, [[8 - James se passionne pour le No Estimate - Indep]]
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!! [[8 - James se lance dans l'écriture d'une conférence - Indep]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit à son client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors il a le choix :x
#Proposer au client de créer un [[8 - Un comité de transformation - James Indep]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[8 - Faire vivre les actions aprés un séminaire - James Indep]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[8 - Se former aux démarches produits - James Indep]]
#S'enfermer chez lui et se prendre un méga [[8 - Syndrôme de l'imposteur - James Indep]]Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[8 - Les experts de la vision - James Indep]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la[[8 - Démarche OKR - James Indep]].
#Personne, durant l'atelier, n'a été capable de définir ce qu'est la valeur business des différentes solutions. Avant d'avancer dans la démarche produit, ils décident de
travailler à la [[Valeur Business Client - James Indep]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner ses clients correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez le client de James. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent toujours en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Il faut que la plateforme de développement soit toujours optimiser car ils ont l'habitude d'avoir des produits au top (même si de ces derniers temps ca laisse un peu à désirer).
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact du client (et c'est pas le cas partout, croyez moi).
Avec l'équipe, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leur solution, l'assurance qualité est essentielle. Cependant il n'y a qu'un seul testeur au sein de l'entreprise. James propose donc que les Scrum Master deviennent ScrumQA.[[Scrum Master et QA - James Indep]]
#Un des membres de l'équipe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[8 - La Rache - James Indep]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business Client - James Indep]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[8 - La dette technique et Scrum - James Indep]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à son client [[8 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - James Indep]]
#James propose à son client de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[8 - Shape Up pour son client - James Indep]]
#Fort des retours de son client, James propose de créer [[8 - Une méthode maison pour son client - James Indep]] tout en restant dans la démarche agile.Un client de James lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, James est sur ses gardes car il ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, James finit par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
James arrive donc dans un environnement qu'il ne connait pas bien, mais c'est tout de même un environnement agile donc il pense qu'il va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce que James connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour James c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, James peut avancer vers d'autres missions / explorations :
#Lors de sa mission, James a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, il décide d'y participer. [[8 - James participe à son premier Agi'Lille entant qu'Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - Indep]]
#Un manager s'approche de James et lui dit [[8 - L'agile ca coûte cher! - James Indep]]
James est contacté par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec James afin de regarder à leurs process de manière différente.
James propose à Anna un premier rendez-vous et ils s'accordent sur le fait que James peut les accompagner mais que ca ne sera pas une grosse intervention mais plutôt de petites interventions.
La première session, James rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, James sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Il rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
James passe plusieurs heures à préparer son intervention, mais il est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis il continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures de James?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[8 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - Indep]] James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[8 - Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[8 - Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[8 - Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[8 - L'agile ca coûte cher! - James Indep]]James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[8 - Le principe de l'amélioration continue face au chaos - James Indep]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[8 - James découvre les meetups et Nord Agile entant qu'indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[8 - Kanbanzine - James Indep]]
#James se rend compte que [[8 - Peu importe le format, seuls les résultats comptent - James Indep]] quand on parle de rétrospective.
En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
James est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, il propose à son commanditaire d'animer l'atelier avec une des équipes qu'il accompagne.
L'atelier se passe bien. L'équipe de DoctoChat comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[8 - Le Kanban ca marche, mais ca prend du temps! - James Indep]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. James propose alors de créer [[8 - Une méthode maison pour son client - James Indep]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[8 - Shape Up - James Indep]] Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[8 - Le craftsmanship - James Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[8 - La dette technique et Scrum - James Indep]]
#James a pris goût aux outils gamifiés, il se lance dans[[9 - Kanbanzine - James]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[8 - Syndrôme de l'imposteur - James Indep]] James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - James Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire - James Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour son client - James Indep]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à James de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - James Indep]]James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais il n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu'il voudrait tester, les projets... Il rempli un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[9 - James se lance dans l'écriture d'une conférence - Indep]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[9 - James organise un séminaire produit - Indep]]
#James se dit qu'aprés ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[9 - Agile Hors IT - James]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Il décide de se lancer dans cette histoire de miroir coach. [[9 - Un miroir coach - James]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[9 - James se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[9 - Agile Games France - James Indep]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[9 - James rejoint Nord Agile - Indep]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[9 - Le WSJF - James Indep]]
#James propose à un de ses clients, débutant en démarche agile, de travailler d'abord à la [[Valeur Business Client - James Indep]] avant d'avancer sur le chemin de l'agilisation.
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[Shape Up pour son client - James Indep]] Super, le client l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est qu'externe
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de son client, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[9 - James continue avec son équipe Scrum - Indep]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business Client - James Indep]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision client. [[9 - Les experts de la vision - James Indep]]
James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez son client. Il lui propose de mettre à plat le workflow de création de valeur.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez le client il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[9 - DevOps - James Indep]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[9 - Le WSJF - James Indep]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[9 - Kanban - James Indep]] en espérant prouver par l'exemple que le workflow actuel est saturé.Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les clients attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne. Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[9 - Un miroir coach - James]]
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[9 - Le craftsmanship - James Indep]]
#James est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.[[9 - Agile dans l'Infra? - James]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez la plupart de ces clients semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[9 - DevOps - James Indep]]
#James commence a voir de l'expérience maintenant, un de ses amis lui propose de les partager lors d'une rencontre agile. [[9 - James se lance dans l'écriture d'une conférence - Indep]]
#Aprés toutes ses explorations, [[9 - James se passionne pour le Serious Gaming - Indep]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec l'équipe client.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et celui-ci se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James propose au Scrum Master de lui en parler ensemble. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez son client. [[Valeur Business Client - James Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - James Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - James Indep]]Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels il pourrait s'améliorer:
#James propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[9 - Le WSJF - James Indep]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business Client - James Indep]]
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[9 - James se lance dans l'écriture d'une conférence - Indep]]Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[9 - Le WSJF - James Indep]]
#James travaille le craftsmanship avec une équipe relativement jeune [[9 - Le craftsmanship - James Indep]]
#Une équipe au top de sa force est limitée par l'accés aux environnements de test et de production. Il leur parle du [[9 - DevOps - James Indep]]
#Ne jamais oublier [[9 - Le principe de l'amélioration continue face au chaos - James Indep]] James et l'équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le client de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[9 - Le principe de l'amélioration continue face au chaos - James Indep]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[9 - Une méthode maison pour son client - James Indep]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[9 - Des noms de rôles en agile - James Indep]]
#L'aventure de James interpèle à chaque fois qu'il en parle dans ses réseaux, du fait il se dit qu'il pourrait en faire une histoire à raconter... [[9 - James se lance dans l'écriture d'une conférence - Indep]] James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi. Il engage malgré tout un chantier avec le PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[9 - James participe à son premier Agi'Lille entant qu'Indep]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[9 - Gérer le run en Scrum - James Indep]]
#James continue à explorer les alternatives à Scrum et se renseigne sur le[[9 - Kanban - James Indep]] James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[9 - Le principe de l'amélioration continue face au chaos - James Indep]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[9 - James découvre les meetups et Nord Agile entant qu'indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[9 - Kanbanzine - James]]
#James se rend compte que [[9 - Peu importe le format, seuls les résultats comptent - James Indep]] quand on parle de rétrospective.
Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[9 - Le craftsmanship - James Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[9 - La dette technique et Scrum - James Indep]]
#James a pris goût aux outils gamifiés, il se lance dans[[9 - Kanbanzine - James]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[9 - Syndrôme de l'imposteur - James Indep]] Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - James se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client de James lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais James se lance. [[9 - James organise un séminaire produit - Indep]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[9 - Agile Games France - James Indep]]
#James se rend compte qu'il a des choses interessantes à dire et les personnes avec lesquelles il échange dans la communauté lilloise le motive à les partager avec un maximum de gens. [[9 - James se lance dans l'écriture d'une conférence - Indep]] James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et son client.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur le client.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que l'entreprise entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[9 - James pilote de vision - Indep]]
#Un ami de la femme de l'ex docteur du président de son client a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[9 - Le ShuHaRi appliqué à Scrum - James Indep]]
#Le projet vision se lance. James fait partie des groupes de travail et influence ce projet avec sa vision agile de la partie delivery. Aprés plusieurs rencontres de ces
groupes de travail, et une première version de la vision du client, on propose à James de s'occuper de [[9 - James organise un séminaire produit - Indep]] James est plutôt avisé sur le sujet des OKRs. Il a bien suivi les conseils qu'il a recu d'Anne Gabrillaques lors d'un échange en ligne : Ne pas présenter les OKR comme une solution miracle, ni comme une boite à outil pour faire avancer les équipes vers des objectifs dictés par le management.
Il parle de la démarche, explique la différence entre Ambition, Résultats clé et objectifs individuels ou financiers.
Il propose même de faire intervenir un expert sur le sujet (Anne ou Laurent Morisseau) pour qu'il parle du sujet mieux qu'elle.
Dans la tête de James tout est clair :
#Définir les ambitions de l'entreprise de manière trés brute
#Faire descendre ces ambitions à travers tous les niveaux de l'entreprise pour que chaque niveau puisse s'identifier à celles-ci ou proposer des amendements.
#Depuis les équipes faire remonter les contributions de chaque niveau à l'atteinte des ambitions
#Valider les OKR au niveau le plus haute ou lancer un second round de discussion
#Repeat
Mais est-ce que tous ses efforts d'explication ont servi?
#Le management embrasse la démarche et se lance avec le système des OKR. Tout semble bien aller jusqu'au moment des entretiens annuels. [[9 - Et toi, en quoi tu contribue aux OKRs? - James Indep]]
#Le management comprend les OKR, le président a même lu plusieurs écrits sur le sujet. Ils tombent d'accord pour essayer cette nouvelle manière de voir leurs ambitions. Cependant, le président a bien retenu que les premières années les OKR ne seraient sans doute pas bons. Durant ses lectures, il a parcouru certains articles de Laurent Morisseau et, en attendant de voir si les OKR fonctionnent, il propose à James d'explorer le Kanban. [[9 - Kanban - James Indep]]
#Lancez-vous, a dit le président à ces N-1. Il est convenu qu'une équipe va servir de pilote. James les accompagne donc et s'interroge sur [[9 - La ritualisation du suivi des OKR - James Indep]]Le développeur présente la méthode, trés sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ca n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[9 - Prioriser en tailles de TShirt - James Indep]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[9 - Le WSJF - James Indep]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[9 - Le craftsmanship - James Indep]]
#James propose à l'équipe d'explorer le [[9 - Kanban - James Indep]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez son client (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant accompagner un nouveau Scrum Master, il doit lui expliquer la notion de [[9 - Production VS Servant Leadership - James Indep]]
#James décide d'explorer encore un nouveau sujet. [[9 - Shape Up - James Indep]]
#Maintenant que la priorisation est correcte, et que donc la production de valeur est maximisée d'un point de vue backlog, il se renseigne sur l'amélioration technique [[9 - Le craftsmanship - James Indep]] James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi. Il engage malgré tout un chantier avec le PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[Meetups de la communauté Lilloise - James Indep]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe se souci du run en Scrum. [[9 - Gérer le run en Scrum - James Indep]]
#James continue à explorer les alternatives à Scrum et se renseigne sur le[[9 - Kanban - James Indep]] James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[9 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - Indep]] James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[9 - Sensibilisation agile des PP - James Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[James se passionne pour le No Estimate - Indep]]
#James se dit qu'il pourrait aussi creuser [[9 - Shape Up - James Indep]] Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - James Indep]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - James Indep]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - James Indep]]
Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - James Indep]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - James Indep]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - James Indep]]James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Aprés refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute trés fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d'aprés.
Aprés 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint aprés refactorisation... mais ca n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - James Indep]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - James Indep]]
#Le client de James lui demande comment faire pour [[Créer une nouvelle équipe Scrum - James Indep]].Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez son client (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant accompagner un nouveau Scrum Master, il doit lui expliquer la notion de [[Production VS Servant Leadership - James Indep]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - James Indep]]
#Maintenant que la priorisation est correcte, et que donc la production de valeur est maximisée d'un point de vue backlog, il se renseigne sur l'amélioration technique [[Le craftsmanship - James Indep]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels il pourrait s'améliorer:
#James propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - James Indep]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business Client - James Indep]]
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - Indep]]Durant ses différentes missions, James a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors James ne s'offusque pas.
Il a maintenant acquis un réflex : à chaque fois qu'il arrive dans un nouveau contexte, même si c'est pour un client qu'il connait déjà, il revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, il sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#James est assez fréquement, de ces temps-ci, touché par le [[Syndrôme de l'imposteur - James Indep]]
#James travaille avec beaucoup d'équipe ces derniers temps et il aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James accepte une mission dans un cabinet d'architectes [[Agile Hors IT - James]]
#James est contacté pour accompagner des équipes [[Agile dans l'Infra? - James]] Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[Le WSJF - James Indep]]
#James travaille le craftsmanship avec une équipe relativement jeune [[Le craftsmanship - James Indep]]
#Une équipe au top de sa force est limitée par l'accés aux environnements de test et de production. Il leur parle du [[DevOps - James Indep]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - James Indep]] Entant que Scrum Master, James se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, James aime aussi la technique!! Il décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-il réellement être efficace dans ces deux missions?
Il continue à se poser des questions et cherche de nouveaux sujets.
#James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur). [[Production VS Servant Leadership - James Indep]]
#Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le [[Le craftsmanship - James Indep]]
#James a la chance de trouver une place pour une formation sur le Kanban. [[Une formation avec Laurent Morisseau - James Indep]] Comme beaucoup de personnes, les membres des équipes du client de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanaban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - James Indep]] pour faire découvrir, par la pratique, ces différents concepts à son client.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - James Indep]]?
#Quelque soit la manière, il réussi à déployer la démarche auprés de son client. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - James Indep]].Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez la plupart de ces clients semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps - James Indep]]
#James commence a voir de l'expérience maintenant, un de ses amis lui propose de les partager lors d'une rencontre agile. [[James se lance dans l'écriture d'une conférence - Indep]]
#Aprés toutes ses explorations, [[James se passionne pour le Serious Gaming - Indep]] Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#James explore le Kanban car il a entendu que le terme FastLane vient de là. [[Kanban - James Indep]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - James Indep]]
#James se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - James]]
#James commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[James se lance dans l'écriture d'une conférence - Indep]]
James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais il n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu'il voudrait tester, les projets... Il rempli un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - Indep]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - Indep]]
#James se dit qu'aprés ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]] Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompanger un Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure de James?
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille entant qu'Indep]]
#James se rend compte du souci d'engagement avec une des équipes qu'il accompagne et travaille sur ce sujet [[Des problèmes d'engagement - James Indep]]
#A force d'avancer dans les missions, et de progresser dans des missions de coach, James se rend compte qu'[[On ne devient pas coach tout seul - James Indep]]
#James se demande comment gérer [[La dette technique en temps réel - James Indep]] Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein de l'entreprise qui participeront aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à James de porter cette vision au sein de l'entreprise. La partie visibilité de l'entreprise vers l'extérieur sera traitée dans un second temps.
Comment réagit James à cette proposition?
#Emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet. [[De vision à action - James Indep]]
#Son interaction avec David lui fait se dire qu'il peut enfin accepter une mission qui le fasse sortir de sa zone de confiance. Un client la solicite et James accompagne la [[Démarche OKR - James Indep]]
#James rentre chez lui et est touché par le [[Syndrôme de l'imposteur - James Indep]] James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
De quelle pratique vont-ils s'inspirer?
#[[Kanban - James Indep]]
#[[Shape Up pour son client - James Indep]]
#[[DevOps - James Indep]]
James entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, James a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
James retourne à son bureau avec quelques questions. Il se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Il tombe sur la vidéo... Paf, c'est ce qu'elle cherchait.
Il entend le terme antipatern.... Ca l'inquiète.
Il se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour James.
Fort de ces arguments il en parle à son client. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - James Indep]]
#L'utilisation des OKRs est revue. Maintenant James se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - James Indep]]
#James commence à apprécier les accompagnements qui sortent de l'aspect opérationnel des organisations, il se lance dans [[Une formation certifiante Coach - James Indep]] James se lance avec les OKR et il a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
James propose à son une équipe test chez son client d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, James propose au départ de mettre en place une réunion bimestrielle.
Il réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat de James est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. James est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, James amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour James?
#James est surpris par une conversation en salle de pause. [[Et toi, en quoi tu contribue aux OKRs? - James Indep]]
#Etant écoresponsable dans l'ame, James participe un à atelier [[La fresque du climat - James Indep]]
#Une des équipes client est empêtrée dans la dette technique. James tente de leur amener des pistes de réflexion. [[La dette technique et Scrum - James Indep]]
Se former au test, quelle drôle d'idée? Pas vraiment pour James, ni pour le Scrum Master qu'il a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ca va faire bien sur son CV!!
James a hâte de l'aider à mettre tout ca en pratique. Mais que font-ils une fois cette certification en poche?
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[James participe à son premier Agi'Lille entant qu'Indep]]
#Avec le Scrum Master, James se lance dans la mise en place des [[Les 3 amigos - James Indep]]
#Le test géré, James s'interesse à [[La dette technique et Scrum - James Indep]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - James Indep]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - James Indep]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille entant qu'Indep]]
Le raisonnement du Scrum Master est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez son client, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et le Scrum Master devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - James Indep]]
#James et le Scrum Master montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprés du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - James Indep]]
Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
James propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'il a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF - James Indep]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - James Indep]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son client, [[James organise un séminaire produit - Indep]] <img src="https://picsum.photos/200/300?random=1"/>Nouveau challenge pour James : il doit accompagner son client dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le client de James a choisi l'option "Seeding".
<<if setup.steps lt 12>>
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[James organise un séminaire produit - Indep]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, James propose la mise en place d'[[Un comité de transformation - James Indep]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement - James Indep]]
<<else>>
Il est aussi possible que le client ne lui laisse pas le choix et qu'il doive composer avec une équipe de 15 personnes. Si c'est cette solution qui est choise, il se demande si le modèle Scrum chez son client ne va pas exploser...
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en armonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à James. Aprés s'être renseigné sur guntehr-le-jeu.fr, il a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprenent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
James est conquis.
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - Indep]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - James]]
#James rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - James]]
<<else>>
Aprés avoir découvert Gunther, et c'est du lourd, il s'interesse au serious gaming encore plus. Il finit par en faire sa spécialité. Il aimerait pouvoir, un jour, en créer un pour VP. Peut-être aura-t-il la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]]
<</if>>Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
James trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais James est persuadé qu'il pourrait aller encore plus loin dans la démonstration...
<<if setup.steps lt 12>>
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - Indep]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - James]]
#James rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - James]]
<<else>>
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
Peut-être explorera-t-il l'atelier "Roule ta bille" ;)
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
James profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - James Indep]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - Indep]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - James]]
#James rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - James]]
<<else>>
Maintenant, James réfléchit au chemin possible pour accompagner VP sur la voie du DevOps.
Il pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discuter avec James qui lui propose de nouvelles perspectives :
<<if setup.steps lt 12>>
#James a l'impression que la partie test de l'application pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. [[Scrum Master et QA - James Indep]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - James Indep]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - James Indep]]
<<else>>
* James se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadée que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Il cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. James et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* James propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a une jolie expérience maintenant. Il a passé plusieurs années au sein des équipes et les challenges de ces dernières lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - James Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille entant qu'Indep]]
<<else>>
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - James Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - James Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille entant qu'Indep]] James a une jolie expérience avec ses différentes équipes. Il a passé presque 2 ans au sein de la dernière et les challenges de celle-ci lui ont forgé certaines convictions.
Entant qu'indep, James veut trouver des missions interessantes, cependant, il comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Cependant, il a plusieurs possibilités devant lui.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James prévoit de s'inscrire dés que ses finances lui permettront à un cursus de formation "coach progessionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James se promet de participer à l'événement le plus proche de chez lui pour commencer : Agi'Lille
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
<<if setup.steps lt 12>>
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - James Indep]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - James Indep]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - James Indep]]
<<else>>
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF à un de ses clients.
* Un manager vient voir James avec la fameuse rengaine : L'agile ca coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financié mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
<<if setup.steps lt 12>>
#James décide de se lancer dans l'[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
<<else>>
* James décide de se lancer dans l'Agile Hors IT.
* James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création.
* Il a même acquis des outils d'animation de grands groupe et il pourrait organiser un séminaire produit pour un de ses clients.
[[Conclusion]]
<</if>>
James en est persuadé. Le seul moyen de réussir une transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ca induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Les choix qui se présentent devant lui sont :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité du client. James doit négocier le déblocage de budget de formation auprés d'un manager. Ca n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - James Indep]]
#Utiliser [[Scrumble - James Indep]] pour la sensibilisation à Scrum
#Proposer de mettre en place [[Une nouvelle communauté agile nationale - James Indep]] <img src="https://picsum.photos/200/300?random=1"/>Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
<<if setup.steps lt 12>>
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[Un refinement revisité - James Indep]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - James Indep]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille entant qu'Indep]]
<<else>>
Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
<<if setup.steps lt 12>>
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - James Indep]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille entant qu'Indep]]
0 . James se demande si le [[DevOps - James Indep]] ne serait pas aussi une solution à la perte de qualité.
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Aprés refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute trés fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d'aprés.
Aprés 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint aprés refactorisation... mais ca n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - James Indep]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - James Indep]]
#Le client de James lui demande comment faire pour [[Créer une nouvelle équipe Scrum - James Indep]].
<<else>>
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]]
<</if>>Quand on regarde la manière dont VP gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bétises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Aprés tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - James Indep]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - James Indep]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - James Indep]]
<<else>>
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>>Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
<<if setup.steps lt 12>>
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#James explore le Kanban car il a entendu que le terme FastLane vient de là. [[Kanban - James Indep]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - James Indep]]
#James se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - James]]
#James commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
James va ensuite poursuivre avec :
* Le Kanban car il a entendu que le terme FastLane vient de là.
* Le Craftsmanship car pour garantir un run constant, rien de tel que l'excellence technique ;)
[[Conclusion]]
<</if>>
Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Elle lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[8 - Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]] Un client d'Eva lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, Eva est sur ses gardes car elle ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, Eva finit par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
Eva arrive donc dans un environnement qu'elle ne connait pas bien, mais c'est tout de même un environnement agile donc elle pense qu'elle va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce qu'Eva connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour Eva c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, Eva peut avancer vers d'autres missions / explorations :
#Lors de sa mission, Eva a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, elle décide d'y participer. [[8 - Eva participe à son premier Agi'Lille entant qu'Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]]
#Un manager s'approche d'Eva et lui dit [[8 - L'agile ca coûte cher! - Eva Indep]]
Un client d'Eva lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, Eva est sur ses gardes car elle ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, Eva finit par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
Eva arrive donc dans un environnement qu'elle ne connait pas bien, mais c'est tout de même un environnement agile donc elle pense qu'elle va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce qu'Eva connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour Eva c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, Eva peut avancer vers d'autres missions / explorations :
#Lors de sa mission, Eva a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, elle décide d'y participer. [[9 - Eva participe à son premier Agi'Lille entant qu'Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - Eva organise un séminaire produit - Indep]]
#Un manager s'approche d'Eva et lui dit [[9 - L'agile ca coûte cher! - Eva Indep]]
Eva est contactée par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec Eva afin de regarder à leurs process de manière différente.
Eva propose à Anna un premier rendez-vous et ils s'accordent sur le fait qu'Eva peut les accompagner mais que ca ne sera pas une grosse intervention, plutôt de petites interventions.
La première session, Eva rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, Eva sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Elle rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
Eva passe plusieurs heures à préparer son intervention, mais elle est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis elle continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures d'Eva?
#Elle est contacté via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - Eva organise un séminaire produit - Indep]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Eva propose au Scrum Master de lui en parler ensemble. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez son client. [[9 - Valeur Business Client - Eva Indep]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - Eva Indep]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - Eva Indep]]Eva lit le livre De Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec une équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[9 - La dette technique et Scrum - Eva Indep]]
#Un des freins au pure Craftsmanship, souvent rencontré, semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[9 - DevOps - Eva Indep]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d'acceleration il faut avant tout que le client travaille à sa démarche produit. [[9 - Eva organise un séminaire produit - Indep]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[Une présentation de la démarche agile à l'équipe - Eva Indep]]
Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener les équipes à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[9 - Gunther - Eva Indep]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[9 - Casino Game - Eva Indep]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[9 - Lego, Scrum et Chocolat pour le DevOps - Eva Indep]]
Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
Eva se veut rassurante. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
#Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe. [[9 - Gérer le run en Scrum - Eva Indep]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[9 - Valeur Business Client - Eva Indep]]
Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prises.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - Indep]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - Eva Indep]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour son client - Eva Indep]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le client demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - Eva Indep]]Un client d'Eva lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, Eva est sur ses gardes car elle ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, Eva finit par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
Eva arrive donc dans un environnement qu'elle ne connait pas bien, mais c'est tout de même un environnement agile donc elle pense qu'elle va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce qu'Eva connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour Eva c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
Aprés plusieurs mois d'accompagnement des équipes, Eva peut avancer vers d'autres missions / explorations :
#Lors de sa mission, Eva a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, elle décide d'y participer. [[Eva participe à son premier Agi'Lille - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
#Un manager s'approche d'Eva et lui dit [[L'agile ca coûte cher! - Eva Indep]]
Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener les équipes à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[Gunther - Eva Indep]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - Eva Indep]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - Eva Indep]]
Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[Le craftsmanship - Eva Indep]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[Le WSJF - Eva Indep]]
#Un manager vient voir Eva avec la fameuse rengaine : [[L'agile ca coûte cher! - Eva Indep]]Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Aprés refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute trés fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d'aprés.
Aprés 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint aprés refactorisation... mais ca n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - Eva Indep]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Le client d'Eva lui demande comment faire pour [[Créer une nouvelle équipe Scrum - Eva Indep]].La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en armonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Aprés s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprenent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise.
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]] Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]] Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]]Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[Kanban - Eva Indep]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - Eva Indep]]
#Eva se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - Eva]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[Eva se lance dans l'écriture d'une conférence - Indep]] <img src="https://picsum.photos/200/300?random=1"/>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - Eva Indep]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business Client - Eva Indep]]
#Plusieurs personnes semblent interessées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>>Eva est contactée par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inéfficaces et ses membres souhaiteraient travailler avec Eva afin de regarder à leurs process de manière différente.
Eva propose à Anna un premier rendez-vous et ils s'accordent sur le fait qu'Eva peut les accompagner mais que ca ne sera pas une grosse intervention, plutôt de petites interventions.
La première session, Eva rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, Eva sent que quelquechose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Elle rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
Eva passe plusieurs heures à préparer son intervention, mais elle est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis elle continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
<<if setup.steps lt 12>>
Quelle est la suite des aventures d'Eva?
#Elle est contacté via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
<<else>>
[[Conclusion]]
<</if>>Un client d'Eva lui propose d'intervenir au sein d'une de ses entités entant que "Scrum Master".
Au départ, Eva est sur ses gardes car elle ne souhaite pas vraiment repartir faire du Scrum Mastering.
A force de discuter avec le client, oui, c'est ca qui est bien entant qu'indep, tu peux discuter avec ton client directement et dimensionner la mission avec lui directement, Eva finit par accepter une mission de coach agile pour aider les équipes à l'autonomisation.
En effet, plusieurs des équipes du client sont sans Scrum Master, même si une seule avait marqué le besoin d'un vrai remplacant.
Eva arrive donc dans un environnement qu'elle ne connait pas bien, mais c'est tout de même un environnement agile donc elle pense qu'elle va s'en sortir.
Et en effet, même si la notion de produit est diffuse dans l'organisation client, les équipes ont des fonctionnements s'approchant de ce qu'Eva connait.
Sprint, planning, revue, rétro, daily... le langage est similaire... ce qui n'est pas habituel pour Eva c'est, d'une part, que les backlogs ne soient pas réellement basés sur des produits mais sur des services et, d'autre part, que les équipes sont utltra investies sans cette notion de produit.
<<if setup.steps lt 12>>
Aprés plusieurs mois d'accompagnement des équipes, Eva peut avancer vers d'autres missions / explorations :
#Lors de sa mission, Eva a croisé un autre coach agile qui lui a parlé de l'Agi'Lille, elle décide d'y participer. [[Eva participe à son premier Agi'Lille - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
#Un manager s'approche d'Eva et lui dit [[L'agile ca coûte cher! - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Nouveau challenge pour Eva : elle doit accompagner son client dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le client d'Eva a choisi l'option "Seeding".
<<if setup.steps lt 12>>
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[Eva organise un séminaire produit - Indep]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d'[[Un comité de transformation - Eva Indep]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement - Eva Coach Indep]]
<<else>>
[[Conclusion]]
<</if>>Eva lit le livre de Nicolas Forsgren, Jez Humble et Gene Kim sur leurs recherches.
Elle a du mal à transformer sa lecture en actions opérationnelles. Elle continue ses recherches et tombe sur un article de coach agile (https://coach-agile.com/2021/01/decouvrez-accelerate-devops/) qui traite du sujet et propose un OpenSeriousGame sur le sujet (par Geoffrey Graveaud.
Elle étudie le guide de l'animateur et tente l'animation avec son équipe.
L'équipe se prête au jeu mais au sortir de l'atelier ils trouvent que beaucoup des choses qu'ils devraient mettre en place ne dépendent pas d'eux.
Eva se rend compte que l'équipe n'a pas complètement tord.
<<if setup.steps lt 12>>
Quelle est sa prochaine action?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - Eva Indep]]
#Un des freins au pure Craftsmanship, souvent rencontré, semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelque chose. [[DevOps - Eva Indep]]
#Eva se dit que pour amener toute l'entreprise à se poser les questions d’accélération il faut avant tout que le client travaille à sa démarche produit. [[Eva organise un séminaire produit - Indep]]
#Eva se dit qu'avant d'accélérer en agile il faut peut-être travailler avec l'équipe pour revenir aux bases de la démarche. [[Une présentation de la démarche agile à l'équipe - Eva Indep]]
<<else>>
Eva explore ensuite les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum.
Un autre des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. Le DevOps dont tout le monde parle pourrait-il être une solution?
Eva se dit que pour amener toute l'entreprise à se poser les questions d'acceelration il faut avant tout que son client travaille à sa démarche produit.
Eva se demande enfin, si avant d'accélérer en agile il ne faudrait pas plutôt revenir aux bases de la démarche.
[[Conclusion]]
<</if>>Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener les équipes à s'y interesser.
Elle liste quelques outils interessants :
<<if setup.steps lt 12>>
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[Gunther - Eva Indep]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - Eva Indep]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - Eva Indep]]
<<else>>
* Elle pourrait demander à TechSys de venir lui présenter Gunther.
* Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le Lego, Scrum et Chocolat pour le DevOps.
[[Conclusion]]
<</if>>
Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
Eva se veut rassurante. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
<<if setup.steps lt 12>>
#Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe. [[Gérer le run en Scrum - Eva Indep]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[Valeur Business Client - Eva Indep]]
<<else>>
Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe.
En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la valeur Business.
[[Conclusion]]
<</if>>
Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
<<else>>
[[Conclusion]]
<</if>>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financié mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, nous seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
Eva s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
<<if setup.steps lt 12>>
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
<<else>>
* Eva décide de se lancer dans l'Agile Hors IT.
* Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création.
* Elle a même acquis des outils d'animation de grands groupe et elle pourrait organiser un séminaire produit pour un de ses clients.
[[Conclusion]]
<</if>>
Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troubleé... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi elle s'est lancée en indep...
<<if setup.steps lt 12>>
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Elle lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
<<else>>
[[Conclusion]]
<</if>>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est parée, elle se lance. Elle a plein de choix possibles!!
<<if setup.steps lt 12>>
#Elle décide de [[Gamifier une rétrospective - Eva Indep]]
#Elle choisit un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[Kanbanzine - Eva Indep]]
#Lors d'un accompagnement d'équipe débutante, elle utilise[[Scrumble - Eva Indep]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[Eva découvre les meetups et Nord Agile entant qu’Indep]]
<<else>>
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'un de ces clients.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>Eva en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Elle réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Elle prépare son matos, les ateliers qu'elle voudrait tester, les projets... Elle rempli un sac de jeux de sociétés et elle décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
Eva passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Elle y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Elle partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, Eva retourne à son quotidien.
#Suite aux échange qu'elle a eu durant l'événement, [[Eva se lance dans l'écriture d'une conférence - Indep]]
#Elle décide de sortir de sa zone de confiance et accepte une mission qu'elle n'aurait même pas considéré quelques semaines auparavant. [[Eva organise un séminaire produit - Indep]]
#Eva se dit qu'aprés ce qu'elle a vécu pendant 2 jours, et la diversité des origines des participants, elle peut se lancer avec l'[[Agile Hors IT - Eva]] Eva en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Elle réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Elle prépare son matos, les ateliers qu'elle voudrait tester, les projets... Elle rempli un sac de jeux de sociétés et elle décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
Eva passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Elle y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Elle partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
<<if setup.steps lt 12>>
Fort de cette expérience, Eva retourne à son quotidien.
#Suite aux échange qu'elle a eu durant l'événement, [[Eva se lance dans l'écriture d'une conférence - Indep]]
#Elle décide de sortir de sa zone de confiance et accepte une mission qu'elle n'aurait même pas considéré quelques semaines auparavant. [[Eva organise un séminaire produit - Indep]]
#Eva se dit qu’après ce qu'elle a vécu pendant 2 jours, et la diversité des origines des participants, elle peut se lancer avec l’[[Agile Hors IT - Eva]]
<<else>>
Fort de cette expérience, Eva retourne à son quotidien.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva choisit une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de son client.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour son client. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - Eva Indep]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer son client dans le bon sens. [[Eva organise un séminaire produit - Indep]]
#Maintenant que tout le monde est formé, Eva propose à son client de mettre en place [[Un comité de transformation - Eva Indep]]
<<else>>
Au retour de leur formation, les parties prenantes veulent absolument se lancer : les promesses de Scrum sont géniales et en plus, les exemples donnés par le formateur donnent envie... il faut tout faire comme il a dit.
Donc ils se lancent, l'équipe se recentre sur ses basiques (by the book) :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu'ils sont apparemment entrés en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il lui faut revoir sa copie. Elle décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ca fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[Le craftsmanship - Eva Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - Eva Indep]]
#Eva a pris goût aux outils gamifiés, elle se lance dans [[Kanbanzine - Eva Indep]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais Eva se demande souvent si elle est légitime. [[Syndrôme de l'imposteur - Eva Indep]]
<<else>>
* Afin de faire évoluer ses accompagnements, Eva se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* Eva a pris goût aux outils gamifiés, elle se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais Eva se demande souvent si elle est légitime. Elle est touchée par le syndrôme de l'imposteur.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'idée lancée par Eva va évoluer au fil du temps.
La première chose qu'Eva organise c'est un kick off de la communauté. Elle invite toutes les personnes du client qui ont montré une appétence sur le sujet agile, ainsi que celles qui occupent des rôles systémiques agiles (Product Owner, Scrum Master...).
Ce collectif se réuni donc pendant 2 heures la première fois afin de définir ensemble les objectifs de la communauté, sa raison d'être. Basée sur les aspirations de chacun et sur ce qu'ils ont compris des volontés agiles de l'entreprise, les objectifs restent trés opérationnels pour la première version :
"S'améliorer entant que groupe dans l'utilisation des pratiques agiles et s'entraider sur les différents challenges de l'entreprise".
Ils discutent ensuite de la forme.
Au départ, ils proposent de créer un rendez-vous récurrent ouvert à tous les agilistes, et utilisent les Agile Topics Cards de Jimmy Janlën
<img src="https://i0.wp.com/agilewithjimmy.com/wp-content/uploads/2020/06/Cards.png?w=600&ssl=1">
Source : https://agilewithjimmy.com
Mais ils se rendent compte qu'au fur et à mesure des sessions, ces rencontres au format "Lean Coffee" ont de moins en moins de succès.
Ils essayent ensuite de proposer un ordre du jour défini à l'avance, cependant, les intervenants sont peu nombreux a proposer des sujets et en plus n'ont que peu de temps à
consacrer à la préparation de leurs rendez-vous.
Les internes considère que la gestion du jour le jour est plus importante que la communauté. Eva propose de s'investir, de faire venir des externes pour présenter des sujets... Au final, c'est elle, entant qu'externe (et seule coach de la structure) qui insufle toute l'énergie nécessaire à maintenir la communauté à flot. Mais le ROTI reste élevé et c'est sa principale motivation
* Un des problèmes communément remonté lors des Q&R se situe dans la gestion du RUN
* Au bout de quelques rencontres, Eva et la communauté proposent la mise en place du rôle de Scrum Master et QA
[[Conclusion]] <img src="https://picsum.photos/200/300?random=1"/>Super, le client l'a entendue. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été recue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est qu'externe
Qu'à celà ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de son client, elle a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[Eva continue avec son équipe Scrum - Indep]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business Client - Eva Indep]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision client. [[Les experts de la vision - Eva Indep]]
<<else>>
* C'est pourquoi Eva continue avec les équipes Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Elle souhaite également travailler avec le PO afin de mettre en avant la Valeur Business chez le client.
* Elle proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision client.
[[Conclusion]]
<</if>>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discute avec Eva qui lui propose de nouvelles perspectives :
* Eva se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé, Eva est persuadée que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Elle cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. Eva et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* Eva propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]] Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ca fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
* Afin de faire évoluer ses accompagnements, Eva se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* Eva a pris goût aux outils gamifiés, elle se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais Eva se demande souvent si elle est légitime. Elle est touchée par le syndrôme de l'imposteur.
[[Conclusion]] Eva consulte les ressources qu'elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples qu'Eva voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
<<if setup.steps lt 12>>
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#En recherchant des formats de rétrospectives, Eva est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[Eva découvre les meetups et Nord Agile entant qu’Indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - Eva Indep]]
#Eva se rend compte que [[Peu importe le format, seuls les résultats comptent - Eva Indep]] quand on parle de rétrospective.
<<else>>
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>
Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
<<if setup.steps lt 12>>
Maintenant que nous avons évoqué le run, quel sujet nous intéresse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[Kanban - Eva Indep]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - Eva Indep]]
#Eva se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - Eva]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
Eva va ensuite poursuivre avec :
* Le Kanban car il a entendu que le terme FastLane vient de là.
* Le Craftsmanship car pour garantir un run constant, rien de tel que l'excellence technique ;)
[[Conclusion]]
<</if>>
Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[8 - Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[8 - Kanbanzine - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[8 - Scrumble - RDB]]
#Il se dit qu'il doit acquerir plus d'expérience et [[8 - James découvre les meetups et Nord Agile - RDB]]Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[8 - James se passionne pour le Serious Gaming - RDB]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[8 - Agile Games France - RDB]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[8 - James rejoint Nord Agile - RDB]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[8 - On ne devient pas coach tout seul chez RDB]]
Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent auprés d'équipes différentes, ils attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[8 - Le craftsmanship - RDB]]
#James propose de travailler à la [[8 - Valeur Business - RDB]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[8 - On ne devient pas coach tout seul chez RDB]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[8 - Le WSJF chez RDB]]
#James propose à un débutant en démarche agile, de travailler d'abord à la [[8 - Valeur Business - RDB]]
avant d'avancer sur le chemin de l'agilisation.
#James a entendu parler d'une nouvelle tendance et propose à un de ses POs de l'investiguer avec lui. [[8 - Shape Up - RDB]] James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi. Il engage malgré tout un chantier avec le PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[9 - James participe à son premier Agi'Lille - RDB]]
#James revient sur une notion clé : la [[9 - Valeur Business - RDB]]. Aprés tout, on a beau faire tout ce qu'on veut, tant que cette dernière n'est pas d'équerre on va nul part.
#James va galérer, mais il va y arriver, nous ce qu'on veut voir c'est l'après [[9 - Fast Track Scrum Master - James]] James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec son équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[9 - Le principe de l'amélioration continue face au chaos - RDB]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[9 - James découvre les meetups et Nord Agile - RDB]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[9 - Kanbanzine - RDB]]
#James se rend compte que [[9 - Peu importe le format, seuls les résultats comptent - RDB]] quand on parle de rétrospective.
En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, il décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais il se dit que si il doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[9 - Le Kanban ca marche, mais ca prend du temps! - RDB]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à RDB d'entrer dans les cases. James propose alors de créer [[9 - Une méthode maison pour RDB]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[9 - Shape Up - RDB]]
#Y'en a marre de la vie de Scrum Master, que fait James aprés avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[9 - Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage et l'anime auprés d'un de ces clients. Ils testent [[9 - Kanbanzine - RDB]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[9 - Scrumble - RDB]]
#Il se dit que la communauté agile doit pouvoir l'aider [[9 - James découvre les meetups et Nord Agile - RDB]] James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais il n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu'il voudrait tester, les projets... Il rempli un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[9 - James se lance dans l'écriture d'une conférence - RDB]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[9 - James organise un séminaire produit - RDB]]
#James quitte les Rois du Ballon et passe indep. Quand vient l'heure de trouver une mission il se dit qu'aprés ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[9 - Agile Hors IT - James]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - RDB]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - RDB]] ?
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - RDB]]Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - RDB]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James intéresse les participants à tous les événements auxquels il assiste.[[James se lance dans l'écriture d'une conférence - RDB]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - RDB]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, il décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais il se dit que si il doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - RDB]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à RDB d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour RDB]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - RDB]]
#Y'en a marre de la vie de Scrum Master, que fait James aprés avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]] Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[Le WSJF - RDB]]
#James travaille le craftsmanship avec son équipe [[Le craftsmanship - RDB]]
#La performance de l'équipe est limitée par l'accés aux environnements de test et de production. Il leur parle du [[DevOps et RDB]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - RDB]] James et son équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - RDB]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[La démarche produit - RDB]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles chez RDB]]
Etre agile, et donc produire de la valeur en s'adaptant au contexte... ou plutôt s'adapter au contexte pour produire de la valeur.
C'est une des convictions de James. Il voit Scrum et toutes les autres méthodologies ou frameworks comme des boîtes à outils.
Plus il en connaitra, plus il pourra accompagner les Rois du Ballon correctement et les aider à traverser leurs challenges.
James réunit un groupe de travail motivé, constitué de développeurs de la première heure, de parties prenantes et de développeurs juniors. A eux tous, ils connaissent le contexte, le produit et les utilisateurs mais aussi ont une expérience autre que chez les Rois du Ballon. Trouver une manière agile de travailler à la valeur ne devrait pas poser trop de soucis.
Ils tombent d'accords sur plusieurs aspects de leur contexte :
* Les anomalies et retours clients passent souvent en premier.
* Bloquer les priorités de création de nouveauté pendant 2 semaines n'est pas un problème.
* Les plateformes de développement sont rarement à jour.
* Pas besoin d'un PO pantin qui serve de passe plat entre les développeurs et les utilisateurs. L'équipe n'a pas peur d'aller au contact des utilisateurs (et c'est pas le cas partout, croyez moi).
Avec son groupe de travail, James doit donc décider de la première action d'évolution à mettre en place :
#Pour garantir le bon fonctionnement à tout moment de leurs produits, l'assurance qualité est essentielle. Cependant il y a une équipe centrale de testeurs au sein de l'entreprise. James propose donc que les ScrumMaster deviennent ScrumQA.[[Scrum Master et QA chez RDB]]
#Un des membres du groupe propose à James de se renseigner sur cette méthode en ligne sur laquelle il est tombé dernièrement.[[La Rache chez RDB]]
#Pour favoriser la production de valeur, il est indispensable de passer par une vraie définition de la [[Valeur Business - RDB]].
#James propose à l'équipe de leur présenter une notion inhérente à la gestion de backlog: la dette technique. [[La dette technique et Scrum - RDB]] James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de rétrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelque part et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parce qu'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec son équipe. Le SHC leur montre le delta entre les préconisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - RDB]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile - RDB]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - RDB]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - RDB]] quand on parle de rétrospective.
Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ça fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - RDB]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - RDB]]
#James a pris goût aux outils gamifiés, il se lance dans[[Kanbanzine - RDB]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - RDB]] Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[9 - James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[9 - James participe à son premier Agi'Lille - RDB]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James interesse les participants à tous les événements auxquels il assiste.[[9 - James se lance dans l'écriture d'une conférence - RDB]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[9 - Syndrôme de l'imposteur - RDB]] Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent auprés d'équipes différentes, ils attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - RDB]]
#James propose de travailler à la [[Valeur Business - RDB]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[On ne devient pas coach tout seul chez RDB]] Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est trés étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Il liste quelques outils interessants :
<<if setup.steps lt 12>>
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - RDB]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - RDB]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - RDB]]
<<else>>
* Il pourrait demander à TechSys de venir lui présenter Gunther
* Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Il s'intéresse également au Lego, Scrum et Chocolat pour le DevOps
[[Conclusion]]
<</if>>Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO qu'il accompagne de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
<<if setup.steps lt 12>>
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB]]
#James est suffisamment aguéri maintenant pour se lancer tout seul [[James micro-entrepreneur]]
<<else>>
Il propose d'organiser un séminaire pour discuter de la vision produit et déploie une démarche adaptée à leur contexte.
[[Conclusion]]
<</if>>James se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'il a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Il motive même une amie, Yulie, qui hésite à se lancer. Il lui dit que tant qu'elle parle de ce qu'elle a vécu, de ce qu'elle pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, elle ne peut pas se tromper... c'est ce que lui même s'applique à faire.
Puis un jour, James a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), il a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intrigué et il été ressorti de la conférence frustré par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Il n'avait pas été le héro de sa conférence!
Alors il entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour lui, il ne se rend pas compte de la quantité de travail devant lui!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, il s'est retrouvé devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Il y passe se journées, ses nuits et ses weekends!!! Mais il ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement il s'en était tenu à ce qu'il savait faire...
Mais il persévère, il écrit, il corrige, il réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire James?
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[James rejoint Nord Agile - RDB]]
#James est profondément écoresponsable, il souhaite devenir animateur de [[La fresque du climat - James RDB]]
#Aprés tout ca, James se dit qu'il pourrait se mettre à son compte. [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James et l'équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
<<if setup.steps lt 12>>
Qu'allons nous observer ensuite?
#Le management de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - RDB]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[La démarche produit - RDB]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles chez RDB]]
<<else>>
[[Conclusion]]
<</if>>Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente formation.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Il quitte RDB et se lance en Freelance. [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa formation, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - RDB]]
#Un manger lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - RDB]]
<<else>>
[[Conclusion]]
<</if>>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
<<if setup.steps lt 12>>
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l’[[Agile Hors IT - James]], il passe indep et c’est parti!!
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - RDB]]
#Un manager lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
<<else>>
Maintenant James peut s'orienter où il veut.
* James décide de se lancer dans l'Agile Hors IT avec des équipes métier de chez RDB.
* James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création.
* Il a même acquis des outils d'animation de grands groupe et il pourrait organiser un séminaire produit pour un des managers RDB.
[[Conclusion]]
<</if>>
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[James se lance dans l'écriture d'une conférence - RDB]]
<<else>>
Au sortir de l'événement, James décide d'explorer les sujets suivants
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau.
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros syndrôme de l'imposteur. Heureusement, il s'y été préparé et avait acheté le rupture douce sur le sujet!
#Aprés l'atelier auquel il a participé, James se tente au No Estimate
#Pour lui c'est sur, l'année prochaine il tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>>Le développeur présente la méthode, trés sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ca n'est pas si loin de certaines réalités...
<<if setup.steps lt 12>>
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - RDB]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF - RDB]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - RDB]]
#James propose à l'équipe d'explorer le [[Kanban - RDB]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - RDB]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - RDB]] ?
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - RDB]]
<<else>>
[[Conclusion]]
<</if>>RDB a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
<<if setup.steps lt 12>>
James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - RDB]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[James découvre les meetups et Nord Agile - RDB]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[James organise un séminaire produit - RDB]]
<<else>>
* Il va lui falloir évangéliser toutes les parties prenantes à la démarche agile.
* James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et il s'inscrit donc à un Meetup produit.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations,James organise un séminaire produit.
[[Conclusion]]
<</if>>Durant ses différentes explorations en ligne, dans les conférences, etc. , James a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors James ne s'offusque pas.
Il a maintenant acquis un réflex : à chaque fois qu'il arrive dans un nouveau contexte, même si c'est pour une équipe qu'il connait déjà, il revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, il sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#James est assez fréquement, de ces temps-ci, touché par le [[Syndrôme de l'imposteur - RDB]]
#James travaille avec beaucoup d'équipe ces derniers temps et il aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - RDB]]
#James pourrait se lancer tout seul [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>>Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - RDB]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Rois du Ballon. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - RDB]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - RDB]]
<<else>>
[[Conclusion]]
<</if>>Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les équipes attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - RDB]]
#James propose de travailler à la [[Valeur Business - RDB]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[On ne devient pas coach tout seul chez RDB]]
<<else>>
Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Une des choses qui l'aide beaucoup c'est sa relation de miroir coach avec Yulie!
[[Conclusion]]
<</if>>James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Réussira-t-il à faire bouger les choses chez RDB? Une chose est sûre, il s'est porté volontaire pour intégrer le groupe de discussion RSE!!
[[Conclusion]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener James à partir de là?
#James explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - RDB]]
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps et RDB]]
#James propose à l'équipe de travailler à la notion de dette technique. [[La dette technique et Scrum - RDB]]
#Aprés toutes ses aventures chez RDB [[James micro-entrepreneur]]
<<else>>
* James explore les différentes possibilités de gestion de la dette technique, tout en essayant de comprendre la compatibilité, ou pas avec le cadre Scrum.
* James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadée qu'il faut y changer quelquechose. James va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? James s'inquiète également.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a une jolie expérience avec ses différentes équipes. Il a passé presque 2 ans au sein de la dernière et les challenges de celle-ci lui ont forgé certaines convictions.
James comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - RDB]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - RDB]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille - RDB]]
<<else>>
Cependant, il a plusieurs possibilités devant lui.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James prévoit de s'inscrire, enfin si son manager valide le budget, à un cursus de formation "coach progessionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James se promet de participer à l'événement le plus proche de chez lui pour commencer : Agi'Lille
[[Conclusion]]
<</if>>Se former au test, quelle drôle d'idée? Pas vraiment pour James, ni pour le Scrum Master qu'il a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ca va faire bien sur son CV!!
<<if setup.steps lt 12>>
James a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[James participe à son premier Agi'Lille - RDB]]
#Avec le Scrum Master, James se lance dans la mise en place des [[Les 3 amigos - RDB]]
#Le test géré, James s’intéresse à [[La dette technique et Scrum - RDB]]
<<else>>
Le Scrum Master parle à James des 3 Amigos...
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
[[Conclusion]]
<</if>>Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
<<if setup.steps lt 12>>
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - RDB]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille - RDB]]
<<else>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>
Le raisonnement de James et Jean-Paul (un vieux de la vieille chez les Rois du Ballon) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez les Rois du Ballon, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - RDB]]
#James et le Scrum Master montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprés du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - RDB]]
#James en a marre de la vie d'entreprise, il se lance seul [[James micro-entrepreneur]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inéfficace d'un point de vue rapidité de déploiement. Cependant, ca porte ses fruits au niveau qualitatif et ca rend le système relativement pévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>>Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanaban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - RDB]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - RDB]]?
#Quelque soit la manière, il réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - RDB]].
<<else>>
James a plusieurs chantiers devant lui :
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, il réussit à déployer la démarche auprés de RDB. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>>Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - RDB]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James interesse les participants à tous les événements auxquels il assiste.[[James se lance dans l'écriture d'une conférence - RDB]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - RDB]]
<<else>>
Il revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et il se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, il développe l'envie de rendre à la communauté à hauteur de ce qu'il y a récupéré depuis quelques mois. Il commence à rédiger une conférence. Peut-être le croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>
Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[8 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[8 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l'[[8 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[8 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - Indep]]
James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[8 - Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[8 - James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - Indep]] James semble tout indiquée pour accompagner les Rois du Ballon sur leur prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation mais n'est pas sur au départ que James soit la personne indiquée. James doit donc à la fois convaincre qu'il est la bonne personne mais aussi monter un dossier en interne avec X powerpoints pour présenter ses idées et ambitions agile pour les Rois du Ballon.
Au bout de 9 mois (beau bébé), il réussit à faire valoir son point de vue et devient officiellement coach agile chez les Rois du Ballon!
Quelle victoire!!
La première chose à laquelle James doit maintenat s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment déployer ses promesses d'accompagnement des Rois du Ballon plus en amont dans leur démarche agile.
Pleins de gros projets, lequel voulez-vous explorer avec James?
#James doit décider comment trouver quelqu'un pour le remplacer au mieux auprés de son équipe. Il se pose énormément de questions quant à la démarche à proposer [[8 - Un Scrum Master pour remplacer James - RDB Coach]]
#James va devoir accompagner la nouvelle équipe formée. Il a un impact potentiel sur la création de cette dernière. Quelles sont les options à sa disposition? [[8 - Créer une nouvelle équipe Scrum - RDB Coach]]
#James ne veut pa se précipiter. Pour trouver de l'aide on lui conseille de prendre contact avec la communauté agile lilloise. [[James participe à son premier Agi'Lille - RDB Coach]]
#James décide de se lancer dans la description de la démarche agile selon les Rois du Ballon afin de créer la pierre fondatrice de la suite de l'aventure agile de son entreprise préférée. [[Une méthode maison pour RDB - Coach]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James a eu la chance d'utiliser beaucoup de serious games durant sa formation, de fait il veut essayer de se prêter au jeu de la création [[8 - James se passionne pour le Serious Gaming - RDB]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - James organise un séminaire produit - RDB]]
#James se lance tout seul [[8 - James micro-entrepreneur]]
Premier challenge pour James : Non seulement il a du trouver un scrum master remplacant, mais il doit aussi accompagner les Vertes Pairies dans la création d'une nouvelle équipe.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent chez les Rois du Ballon et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec les Rois du Ballon pour sa précédente équipe. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Les Vertes Prairies pourraient aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager de James a choisi l'option "Seeding".
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[9 - James organise un séminaire produit - RDB - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d'[[9 - Un comité de transformation chez RDB]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez RDB - Coach]] James passant coach, il faut trouver un Scrum Master pour le remplacer auprés de l'équipe existante.
En réunion avec son manager il hésite sur les préconnisations qu'il pourrait faire.
En effet, pour le remplacer, les Vertes Prairies ont le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, aprés tout le Rois du Ballon sont capables d'embaucher de nouvelles personnes, James se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et James se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
James est également tenté de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Il entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ca risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en delaissant un peu le développement.
Aprés plusieurs longues réunions, le management accepte la solution préconnisée par James : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu'il amène le sujet à l'équipe, personne ne se porte volontaire directement, James leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
James est enchanté, il cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu'il est remplacé, James peut se consacrer à la suite :
#[[9 - James organise un séminaire produit - RDB - Coach]]
#Afin de pouvoir faire changer les choses chez RDB, James proposer la mise en place d'[[9 - Un comité de transformation chez RDB]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez RDB - Coach]] James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - RDB]]James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - RDB]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été reçue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à cela ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour RDB.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[James continue avec son équipe Scrum - RDB]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - RDB]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision RDB. [[Les experts de la vision - RDB]]
Le développeur présente la méthode, trés sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ca n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache.
<<if setup.steps lt 12>>
Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - RDB]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF - RDB]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - RDB]]
#James propose à l'équipe d'explorer le [[Kanban - RDB]]
<<else>>
[[Conclusion]]
<</if>>Quand on regarde la manière dont RDB gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bétises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Aprés tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - RDB]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - RDB]]
#Le Scrum Master propose la mise en place d'[[Un déversement de backlog - RDB]]Le développeur présente la méthode, trés sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ca n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - RDB]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF - RDB]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - RDB]]
#James propose à l'équipe d'explorer le [[Kanban - RDB]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez les Rois du Ballon. [[Valeur Business RDB - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - RDB - Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - RDB - Coach]]<img src="https://picsum.photos/200/300?random=1"/>James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'il avait vu passer sur son fil Facebook il y a quelques années).
<<if setup.steps lt 12>>
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'il a prises.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - RDB]]
<<else>>
Au sortir de cet événement il se retrouve avec beaucoup de contenu. Il n'est pas tombé dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambitieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels il aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie James aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flatté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ça le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[9 - James se passionne pour le Serious Gaming - RDB]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[9 - Agile Games France - RDB]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[9 - James rejoint Nord Agile - RDB]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[9 - Le WSJF chez RDB]]
#James propose à un débutant en démarche agile, de travailler d'abord à la [[9 - Valeur Business - RDB]]
avant d'avancer sur le chemin de l'agilisation.
#James a entendu parler d'une nouvelle tendance et propose à un de ses POs de l'investiguer avec lui. [[9 - Shape Up - RDB]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Kanbanzine - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Scrumble - RDB]]
#Il se dit qu'il doit acquerir plus d'expérience et [[James découvre les meetups et Nord Agile - RDB]]Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - RDB]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - RDB]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - RDB]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF - RDB]]
#James propose à un débutant en démarche agile, de travailler d'abord à la [[Valeur Business - RDB]]
avant d'avancer sur le chemin de l'agilisation.
#James a entendu parler d'une nouvelle tendance et propose à un de ses POs de l'investiguer avec lui. [[Shape Up - RDB]] <img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement James redescend vite.
Il est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais il n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Il retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant il doit transformer tout ca en actions.
Première chose : est-il la bonne personne pour lister les actions? Non, il ne le pense pas. Il n'a pas toutes les réponses. Mais il peut animer un groupe de travail (ou en faire partie).
Il peut aussi proposer une formulation de la démarche produit à son client à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors il a le choix :
#Proposer au client de créer un [[Un comité de transformation - RDB]] auquel il pourrait se joindre.
#Animer lui même la transformation. [[Faire vivre les actions aprés un séminaire - RDB]]
#Se former aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - RDB]]
#S'enfermer chez lui et se prendre un méga [[Syndrôme de l'imposteur - RDB]]Pour suivre les actions, James s'inspire de ce qu'il connait bien : Scrum.
Il propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, le client est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
James anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
James fait partie des acteurs, et de ce fait nous pouvons le suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. James, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[Les experts de la vision - RDB]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. James investigue la [[Démarche OKR - RDB]].
#James va réussir son défi, maintenant il passe indep [[James micro-entrepreneur]]
Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
James se documente, ne trouve pas énormément de litérature sur le sujet... il décide de creuser un peu plus.
Quelle est sa prochaine action?
#James trouve rapidement une réponse qu'il souhaite amener à RDB [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
#James propose à son manager de découvrir d'autres manière d'être agiles que Scrum. Il lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[Shape Up - RDB]]
#Fort des retours de son manager, James propose de créer [[Une méthode maison pour RDB]] tout en restant dans la démarche agile.<img src="https://picsum.photos/200/300?random=1"/>Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inéfficace d'un point de vue rapidité de déploiement. Cependant, ca porte ses fruits au niveau qualitatif et ca rend le système relativement pévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Aprés plusieurs mois (ben oui, l'industrie ca réagit pas trés vite) dans ce système, James se dit quand même qu'il faudrait regarder d'autres choses...
<<if setup.steps lt 12>>
#Comme il a entendu parler du [[Kanban - RDB]], James se pose la question de savoir si ça ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[James participe à son premier Agi'Lille - RDB]]
#Y'en a marre du Scrum Master! [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ça reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
<<if setup.steps lt 12>>
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[Un refinement revisité - RDB]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - RDB]]
<<else>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
<<if setup.steps lt 12>>
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#Y'en a marre du Scrum Master! [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - RDB]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - RDB]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - RDB]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage et l'anime auprès d'une de ces équipes . Ils testent [[Kanbanzine - RDB]]
#Lors d'un accompagnement d'équipe débutante, il utilise [[Scrumble - RDB]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile - RDB]] James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais il n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu'il voudrait tester, les projets... Il rempli un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois après il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - RDB]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - RDB]]
#James quitte les Rois du Ballon et passe indep. Quand vient l'heure de trouver une mission il se dit qu’après ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]] Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent auprès d'équipes différentes, ils attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel a une grande marge d'amélioration : [[9 - Le craftsmanship - RDB]]
#James propose de travailler à la [[9 - Valeur Business - RDB]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[9 - On ne devient pas coach tout seul chez RDB]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans les Rois du Ballons. Il passe donc indépendant [[James micro-entrepreneur]] Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein de RDB qui participeront aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yahourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yahourt" pour commencer à définir ce qui correspond à une bonne vision
** Aprés midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Aprés midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Aprés ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge aprés, à James de porter cette vision au sein de l'entreprise. La partie visibilité de l'entreprise vers l'extérieur sera traitée dans un second temps.
<<if setup.steps lt 12>>
Comment réagit James à cette proposition?
#Emballé par le programme, après tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet. [[De vision à action - RDB]]
#Son interaction avec David lui fait se dire qu'il peut enfin proposer une démarche qui le fasse sortir de sa zone de confiance. [[Démarche OKR - RDB]]
#James rentre chez lui et est touché par le [[Syndrôme de l'imposteur - RDB]]
<<else>>
James est emballé par le programme, aprés tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>>James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tombre dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
<<if setup.steps lt 12>>
De quelle pratique vont-ils s'inspirer?
#[[Kanban - RDB]]
#[[Shape Up - RDB]]
#[[DevOps et RDB]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été convié à ce comité de transformation. Faut dire... il n'est que coach agile / scrum master
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[James continue avec son équipe Scrum - RDB]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business - RDB]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision Vertes Prairies. [[Les experts de la vision - RDB]]
<<else>>
* C'est pourquoi James continue avec les équipes Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Il souhaite également travailler avec le PO afin de mettre en avant la Valeur Business chez RDB.
* Il proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision client.
[[Conclusion]]
<</if>>James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez RDB. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez RDB il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[DevOps et RDB]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - RDB]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[Kanban - RDB]] en espérant prouver par l'exemple que le workflow actuel est saturé.
James attaque le sujet sur plusieurs flancs :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le devOps avec son équipe préférée.
* James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. Il lance donc une expérimentation WSJF avec son PO.
* James comprend que c'est un changement de culture important, il se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son activité d'indépendante il décide acheter la version éditée qui, de plus, lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
<<if setup.steps lt 12>>
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - RDB]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à RDB d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour RDB]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - RDB]]
#Y'en a marre de la vie de Scrum Master, que fait James aprés avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]]
<<else>>
James accompagne l'équipe qui se lance tête baissée dans la démarche Kanban.
James travaille avec le scrum master pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et propose au scrum master de regarder un peu aux goulots d'étranglement au sein de leur tableau. Ils se rendent compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Ils s'engagent donc dans l'identification des workflow externes à l'équipe et proposent aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réelsa
* ...
<<if setup.steps lt 12>>
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[Le WSJF - RDB]]
#James travaille le craftsmanship avec son équipe [[Le craftsmanship - RDB]]
#La performance de l'équipe est limitée par l'accés aux environnements de test et de production. Il leur parle du [[DevOps et RDB]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - RDB]]
<<else>>
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour James, son équipe a besoin d'un retour aux bases. Il se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, il se propose de les tester avec un LegoScrum mais qu'il adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Il adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Il a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Il se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. James a gagné son pari même si il ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux me direz vous?
<<if setup.steps lt 12>>
#James reste persuadé que Scrum est la solution. Il se dit que c'est le contexte qui doit changer, il se propose donc de mettre en place une [[Sensibilisation agile des PP - RDB]]
#James et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes de RDB (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ca, [[James se passionne pour le Serious Gaming - RDB]]
<<else>>
James s'attaque au sujet via 2 pans: l'équipe et le contexte.
Il propose aux parties prenantes de l'équipe de leur faire une présentation de la démarche agile. Au travers de cette présentation, il espère leur faire comprendre que chacun des points du fonctionnement de l'équipe a pour unique but de créer de la valeur (ou d'aider à cette création).
En paralèlle il propose à l'équipe de modifier leur fonctionnement. Au départ en gardant un process proche de Scrum (certains diront ScrumBan) puis au fur et à mesure de ses découvertes sur les alternatives à Scrum de continuer à faire de l'amélioration continue en format Kaizen.
D'un point de vue personnel, James s'interesse de prêt aux serious games. Il décide de rejoindre la communauté locale lors d'un meetup organisé par Nord Agile... le reste il l'écrira lui même.
[[Conclusion]]
<</if>>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
<<if setup.steps lt 12>>
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[8 - Valeur Business - RDB]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[8 - Le WSJF chez RDB]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[8 - Fast Track Scrum Master - James]]
<<else>>
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discuter avec james qui lui propose de nouvelles perspectives :
* James se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Il cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. James et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* James propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour James, son équipe a besoin d'un retour aux bases. Il se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, il se propose de les tester avec un LegoScrum mais qu'il adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Il adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Il a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Il se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. James a gagné son pari même si il ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux me direz vous?
<<if setup.steps lt 12>>
#James reste persuadé que Scrum est la solution. Il se dit que c'est le contexte qui doit changer, il se propose donc de mettre en place une [[Sensibilisation agile des PP - RDB]]
#James et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes de RDB (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ca, [[James se passionne pour le Serious Gaming - RDB]]
<<else>>
James s'attaque au sujet via 2 pans: l'équipe et le contexte.
Il propose aux parties prenantes de l'équipe de leur faire une présentation de la démarche agile. Au travers de cette présentation, il espère leur faire comprendre que chacun des points du fonctionnement de l'équipe a pour unique but de créer de la valeur (ou d'aider à cette création).
En paralèlle il propose à l'équipe de modifier leur fonctionnement. Au départ en gardant un process proche de Scrum (certains diront ScrumBan) puis au fur et à mesure de ses découvertes sur les alternatives à Scrum de continuer à faire de l'amélioration continue en format Kaizen.
D'un point de vue personnel, James s'interesse de prêt aux serious games. Il décide de rejoindre la communauté locale lors d'un meetup organisé par Nord Agile... le reste il l'écrira lui même.
[[Conclusion]]
<</if>>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[9 - Le principe de l'amélioration continue face au chaos - RDB]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à RDB mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[9 - La démarche produit - RDB]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]James et son équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management de James l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[9 - Le principe de l'amélioration continue face au chaos - RDB]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[9 - La démarche produit - RDB]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[9 - Des noms de rôles chez RDB]]
<img src="https://picsum.photos/200/300?random=1"/>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné
<<if setup.steps lt 12>>
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - RDB]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à DoctoChat mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[La démarche produit - RDB]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]
<<else>>
Au sortir de cette formation James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. Il essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]
<</if>>James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
<<if setup.steps lt 12>>
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - RDB]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile - RDB]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - RDB]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - RDB]] quand on parle de rétrospective.
<<else>>
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>
Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le teste avec quelques volontaires un midi sur l'heure du repas. Il voit comment ça fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - RDB]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - RDB]]
#James a pris goût aux outils gamifiés, il se lance dans[[Kanbanzine - RDB]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - RDB]]
<<else>>
* Afin de faire évoluer ses accompagnements, James se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* James a pris goût aux outils gamifiés, il se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent s'il est légitime. Il est touché par le syndrome de l'imposteur.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - DoctoChat]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - DoctoChat]] ?
#Plusieurs personnes semblent interessées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>DoctoChat a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
<<if setup.steps lt 12>>
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - DoctoChat]]
#James espère pouvoir s'inspirer de la communauté sur ce sujet. [[James découvre les meetups et Nord Agile - DoctoChat]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Après quelques négociations, [[9 - James organise un séminaire produit - DoctoChat]]
<<else>>
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
* Il va lui falloir évangéliser toutes les parties prenantes à la démarche agile.
* James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et il s'inscrit donc à un Meetup produit.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations,James organise un séminaire produit.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Nouveau challenge pour James : il doit accompagner RDB dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le client de James a choisi l'option "Seeding".
<<if setup.steps lt 12>>
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[James organise un séminaire produit - RDB]]
#Afin de pouvoir faire changer les choses chez RDB, James proposer la mise en place d'[[Un comité de transformation - RDB]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez RDB]]
<<else>>
Il est aussi possible que le client ne lui laisse pas le choix et qu'il doive composer avec une équipe de 15 personnes. Si c'est cette solution qui est choisie, il se demande si le modèle Scrum chez son client ne va pas exploser...
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Entant que Scrum Master, James se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, James aime aussi la technique!! Il décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-il réellement être efficace dans ces deux missions?
Il continue à se poser des questions et cherche de nouveaux sujets.
<<if setup.steps lt 12>>
#James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur). [[Production VS Servant Leadership - RDB]]
#Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le [[Le craftsmanship - RDB]]
#James a la chance de trouver une place pour une formation sur le Kanban. [[Une formation avec Laurent Morisseau - RDB]]
<<else>>
* James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur).
* Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le craftsmanship.
[[Conclusion]]
<</if>>C'est une notion difficile la valeur business, surtout chez les Rois du Ballons!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - RDB]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF chez RDB]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - RDB]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>James entend deux collègues discuter dans la salle de pause. L'un d'eux mentionne le fait que son manager lui a mis des objectifs annuels liés aux OKRs. Il n'a pas l'air d'être troublé sur le sujet. Il a trouvé ça plutôt cool! Ben ouais, du fait j'ai pas eu à me creuser la tête cette année et en plus j'ai rien de chiant comme "Apprendre à maitriser ma communication en réunion"...
Sans se méler à la conversation, James a tendu l'oreille. Le second collègue est plus dubitatif sur le sujet. Est-ce juste de te donner des objectifs personnels sur des résultats qui dépendent de l'engagement collectif, voir même qui ne dépendent pas du tout de toi?
James retourne à son bureau avec quelques questions. Il se souvient d'avoir vu une restranscription de conférence qui abordait le sujet. Il tombe sur la vidéo... Paf, c'est ce qu'il cherchait.
Il entend le terme antipatern.... Ca l'inquiète.
Il se documente un peu plus et comprend pourquoi. De un, les OKR sont souvent mauvais la première année, donc objectiver les collaborateurs de manière individuelle à leur sujet n'est pas juste s'ils sont rendus caduc lors d'une revue. De deux, si les OKR servent aux ambitions de l'entreprise, se baser uniquement sur eux pour de l'objectivation individuelle exclu toute démarche humaine d'amélioration des compétences personnelles.
Bref, c'est pas une bonne idée pour James.
<<if setup.steps lt 12>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait.
#Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée. On lui propose de lancer une [[Une nouvelle communauté agile nationale - RDB]]
#L'utilisation des OKRs est revue. Maintenant James se refocalise sur son accompagnement et l'utilisation que son client va faire des OKR. [[La ritualisation du suivi des OKR - RDB]]
<<else>>
Fort de ces arguments il en parle à son manager. Impressionné, il lui propose d'amener le sujet lors d'une réunion avec les dirigeants, ce qu'il fait. Ils acceptent ces arguments et proposent aux managers de revoir leurs copies sur les objectifs individuels. James gagne en notoriété et son initiative est remarquée.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James se lance avec les OKR et il a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
James propose à son une équipe test chez son client d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, James propose au départ de mettre en place une réunion bimestrielle.
Il réunie donc l'équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat de James est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. James est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, James amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour James : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
<<if setup.steps lt 12>>
Quelle est maintenant la suite pour James?
#James est surpris par une conversation en salle de pause. [[Et toi, en quoi tu contribue aux OKRs? - RDB]]
#Une des équipes client est empêtrée dans la dette technique. James tente de leur amener des pistes de réflexion. [[La dette technique et Scrum - RDB]]
<<else>>
[[Conclusion]]
<</if>>RDB a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - RDB]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[James découvre les meetups et Nord Agile - RDB]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[James organise un séminaire produit - RDB]]Durant ses différentes recherches, James a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors James ne s'offusque pas.
Il a maintenant acquis un réflex : à chaque fois qu'il arrive dans un nouveau contexte, même si c'est pour une équipe ou un domaine qu'il connait déjà, il revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, il sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#James est assez fréquement, de ces temps-ci, touché par le [[Syndrôme de l'imposteur - RDB]]
#James travaille avec beaucoup d'équipe ces derniers temps et il aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - RDB]]
#James pourrait se lancer tout seul [[James micro-entrepreneur]] Eva a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
Eva opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, elle demande un entretien avec le responsable des chefs de projets de chez VP. Elle lui propose de mettre à plat le workflow de création de valeur chez LudiGames.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
Eva a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, elle a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez LudiGames il ne le font pas).
Que va faire Eva?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le [[8 - DevOps et LudiGames]]
#Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[8 - Le WSJF - LudiGames]]
#Eva comprend que c'est un changement de culture important, elle se lance dans la démarche [[8 - Kanban - LudiGames]] en espérant prouver par l'exemple que le workflow actuel est saturé.Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprés d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[8 - Un miroir coach - LudiGames]]
#Eva se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel elle a une grande marge d'amélioration : [[8 - Le craftsmanship - LudiGames]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva passe indep et se lance dans [[8 - Agile dans l'Infra? - Eva]] Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[8 - Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la[[8 - Démarche OKR - LudiGames]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[8 - Eva devient coach agile chez LudiGames]] Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Aprés avoir mis en place plusieurs action d'amélioration d'envergure, le manager d'Eva lui propose de prendre un rôle de coach. [[9 - Eva devient coach agile chez LudiGames]]
#Eva est maintent armée pour se lancer seule. [[Eva micro-entrepreneuse]]
Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[9 - La dette technique et Scrum - LudiGames]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[9 - Accelerate chez LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[9 - DevOps - LudiGames]]
#Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - LudiGames]]Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[9 - Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[9 - Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[9 - Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
#Bon, assez de Scrum Mastering, elle fait quoi ensuite Eva? [[9 - Fast Track Scrum Master - Eva]] Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[9 - Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[9 - Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[9 - Le Kanban ca marche, mais ca prend du temps! - LudiGames]].Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - LudiGames]]Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est paré, elle se lance. Que fait-elle en premier?
#Elle décide de [[Gamifier une rétrospective - LudiGames]]
#Elle choisi un outil d'apprentissage et l'anime auprès de son équipe. Ils testent [[10 - Kanbanzine - LudiGames]]
#Lors d'un accompagnement d'équipe débutante, elle utilise[[10 - Scrumble - LudiGames]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[Eva découvre les meetups et Nord Agile - LudiGames]] La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Aprés s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprenent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise.
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[8 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[8 - Eva micro-entrepreneuse]] Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[8 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[8 - Eva micro-entrepreneuse]] Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[8 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[8 - Eva micro-entrepreneuse]] La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en armonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Aprés s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprenent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise.
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]]Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]] Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]] Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[9 - Eva se passionne pour le Serious Gaming - LudiGames]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[9 - Eva organise un séminaire produit - LudiGames]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[9 - Agile Games France - LudiGames]]
#Eva se rend compte qu'elle a des choses interessantes à dire et les personnes avec lesquelles elle échange dans la communauté lilloise la motive à les partager avec un maximum de gens. [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[9 - Le WSJF - LudiGames]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[9 - Valeur Business - LudiGames]]
#Plusieurs personnes semblent interessées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]]Eva et l'équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[Une méthode maison pour LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles en agile - LudiGames]]
#L'aventure d'Eva interpèle à chaque fois qu'elle en parle dans ses réseaux, du fait elle se dit qu'elle pourrait en faire une histoire à raconter... [[Eva se lance dans l'écriture d'une conférence - LudiGames]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Eva est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, elle propose à son commanditaire d'animer l'atelier avec une des équipes qu'elle accompagne.
L'atelier se passe bien. L'équipe de chez LudiGames comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[Shape Up - LudiGames]] Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[Un miroir coach - Eva Indep]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[Une formation certifiante Coach - Eva Indep]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[Eva rejoint Nord Agile - Indep]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[La fresque du climat - Eva Indep]] C'est une notion difficile la valeur business!! Comment comparer la création de valeur d'un nouveau produit vs l'ajout de fonctionnalités sur une application existante?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet chez le client d'Eva, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - LudiGames]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[Le WSJF - LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]] Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[Un miroir coach - LudiGames]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[Une formation certifiante Coach - LudiGames]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[Eva rejoint Nord Agile - LudiGames]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[La fresque du climat - LudiGames]] Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - LudiGames]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management de LudiGames demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - LudiGames]]Eva en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Elle réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Elle prépare son matos, les ateliers qu'elle voudrait tester, les projets... Elle rempli un sac de jeux de sociétés et elle décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
Eva passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Elle y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Elle partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, Eva retourne à son quotidien.
#Suite aux échange qu'elle a eu durant l'événement, [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
#Elle décide de sortir de sa zone de confiance et accepte une mission qu'elle n'aurait même pas considéré quelques semaines auparavant. [[Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'aprés ce qu'elle a vécu pendant 2 jours, elle a besoin de voir de nouveaux horizons. [[Eva micro-entrepreneuse]] <img src="https://picsum.photos/200/300?random=1"/>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
Eva est paré, elle se lance. Que fait-elle en premier?
#Elle décide de [[Gamifier une rétrospective - LudiGames]]
#Elle choisi un outil d'apprentissage et l'anime auprés de son équipe. Ils testent [[Kanbanzine - LudiGames]]
#Lors d'un accompagnement d'équipe débutante, elle utilise[[Scrumble - LudiGames]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[Eva découvre les meetups et Nord Agile - LudiGames]]
<<else>>
Eva est parée, elle se lance. Elle a plein de choix possibles!!
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'un de ces clients.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail de cette envergure, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de son client.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
<<if setup.steps lt 12>>
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[Faire vivre les actions aprés un séminaire - LudiGames]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management de LudiGames demande à Eva de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - LudiGames]]
<<else>>
Au sortir de cet événement elle se retrouve avec beaucoup de contenu. Elle n'est pas tombée dans un piège commun qui est de sortir de là sans action. Au contraire, le plan d'action validé par les participants est plutôt complet et ambicieux mais laisse aussi la place à l'évolution logique des équipes.
Ils ont décidé de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Quels sont les pièges dans lesquels elle aurait pu tomber alors?
* Ne pas réellement dégager d'actions concrêtes de toutes leurs discussions.
* Une liste d'actions conséquente mais sans acteur identifié, sans même des délais ou indicateurs de succès (ne parlons même pas de SMART).
* De bonnes actions, bien documentées, mais peu d'engagement post événement et pas de mise en place de suivi particulier.
* Un management qui remercie Eva aprés sa prestation, stocke le résultat et repart comme si de rien n'était mais avec l'argument que eux ils ont essayés de faire bouger les choses!!!
[[Conclusion]]
<</if>>Eva en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Elle réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Elle prépare son matos, les ateliers qu'elle voudrait tester, les projets... Elle remplit un sac de jeux de sociétés et elle décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
Eva passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Elle y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Elle partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, Eva retourne à son quotidien.
<<if setup.steps lt 12>>
#Suite aux échange qu'elle a eu durant l'événement, [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
#Elle décide de sortir de sa zone de confiance et accepte une mission qu'elle n'aurait même pas considéré quelques semaines auparavant. [[Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'aprés ce qu'elle a vécu pendant 2 jours, elle a besoin de voir de nouveaux horizons. [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
<<if setup.steps lt 12>>
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[Un miroir coach - LudiGames]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[Une formation certifiante Coach - LudiGames]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[Eva rejoint Nord Agile - LudiGames]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[La fresque du climat - LudiGames]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
<<if setup.steps lt 12>>
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[Kanban - LudiGames]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - LudiGames]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
<<if setup.steps lt 12>>
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[Le craftsmanship - LudiGames]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[Le WSJF - LudiGames]]
#Un manager vient voir Eva avec la fameuse rengaine : [[L'agile ca coûte cher! - LudiGames]]
<<else>>
* Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser le WSJF chez LudiGames
* Un manager vient voir Eva avec la fameuse rengaine : L'agile ca coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Aprés refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute trés fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d'aprés.
Aprés 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint aprés refactorisation... mais ca n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - LudiGames]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Le manager d'Eva lui demande comment faire pour [[Créer une nouvelle équipe Scrum - LudiGames]].
<<else>>
[[Conclusion]]
<</if>>Eva consulte les ressources qu'elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec son équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, elle se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#En recherchant des formats de rétrospectives, Eva est tombée sur plusieurs articles mentionnants la communauté agile Lillois. [[Eva découvre les meetups et Nord Agile - LudiGames]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, Eva teste [[Kanbanzine - LudiGames]]
#Eva se rend compte que [[Peu importe le format, seuls les résultats comptent - LudiGames]] quand on parle de rétrospective.
Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ca fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[Le craftsmanship - LudiGames]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - LudiGames]]
#Eva a pris goût aux outils gamifiés, elle se lance dans[[Kanbanzine - LudiGames]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais Eva se demande souvent si elle est légitime. [[Syndrôme de l'imposteur - LudiGames]] Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Aprés tous ces meetups, [[Eva se passionne pour le Serious Gaming - LudiGames]]
Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
<<if setup.steps lt 12>>
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[Gérer le run en Scrum - Eva Indep]]
#Eva va galérer, mais elle va y arriver, nous ce qu'on veut voir c'est l'après [[Eva micro-entrepreneuse]]
<<else>>
Eva devra ensuite explorer d'autres pistes :
* Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise.
* Elle devrait également aider les équipes à mieux gérer le run en Scrum.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand il s'agit de mettre en place des rétrospectives, Eva est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, elle arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand elle le peut, elle préfère amener des rétrospectives imagées, ludiques.. Mais elle commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, elle a exploré le SMART de font en comble. Elle en est arrivée à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, Eva voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, elle arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus.
<<if setup.steps lt 12>>
C'est à ce moment là que nous arrivons.
#Eva est devant une équipe dont le PO a de gros soucis de priorisation. Eva propose d'explorer [[Le WSJF - LudiGames]]
#Eva travaille le craftsmanship avec son équipe [[Le craftsmanship - LudiGames]]
#La performance de l'équipe est limitée par l'accés aux environnements de test et de production. Elle leur parle du [[DevOps - LudiGames]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - LudiGames]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idées, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Aprés tous ces meetups, [[Eva se passionne pour le Serious Gaming - LudiGames]]
<<else>>
Elle revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et elle se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, elle développe l'envie de rendre à la communauté à hauteur de ce qu'elle y a récupéré depuis quelques mois. Elle commence à rédiger une conférence. Peut-être la croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>
Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]].
<<else>>
Quels sujets va-t-elle explorer ensuite?
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, elle réussit à déployer la démarche auprés de LudiGames. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
<<if setup.steps lt 12>>
Alors elle a le choix :
#Proposer au management de créer un [[Un comité de transformation - LudiGames]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[Faire vivre les actions aprés un séminaire - LudiGames]]
#Demander à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[9 - Se former aux démarches produits - LudiGames]]
#S'enfermer chez elle et se prendre un méga [[Syndrôme de l'imposteur - LudiGames]]
<<else>>
Elle propose au management de créer un comité de transformation chez LudiGames auquel elle pourrait se joindre.
Elle pourrait aussi animer elle même la transformation de manière itérative.
Elle demande aussi à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser).
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Après s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise.
<<if setup.steps lt 12>>
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]]
<<else>>
Après avoir découvert Gunther, et c'est du lourd, elle s’intéresse au serious gaming encore plus. Elle finit par en faire sa spécialité. Elle aimerait pouvoir, un jour, en créer un pour LudiGames. Peut-être aura-t-elle la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]]
<</if>>Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bonne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
<<if setup.steps lt 12>>
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]]
<<else>>
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'elle en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
<<if setup.steps lt 12>>
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]]
<<else>>
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>Pour Eva, son équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux me direz vous?
<<if setup.steps lt 12>>
#Eva accompagne son client dans la création d'une démarche maison. [[Une méthode maison pour LudiGames]]
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une [[Sensibilisation agile des PP - LudiGames]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes client (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ça, [[Eva se passionne pour le Serious Gaming - LudiGames]]
<<else>>
Eva s'attaque au sujet via 2 pans: l'équipe et le contexte.
Elle propose aux parties prenantes de l'équipe de leur faire une présentation de la démarche agile. Au travers de cette présentation, elle espère leur faire comprendre que chacun des points du fonctionnement de l'équipe a pour unique but de créer de la valeur (ou d'aider à cette création).
En paralèlle elle propose à l'équipe de modifier leur fonctionnement. Au départ en gardant un process proche de Scrum (certains diront ScrumBan) puis au fur et à mesure de ses découvertes sur les alternatives à Scrum de continuer à faire de l'amélioration continue en format Kaizen.
D'un point de vue personnel, Eva s'interesse de prêt aux serious games. Elle décide de rejoindre la communauté locale lors d'un meetup organisé par Nord Agile... le reste elle l'écrira elle même.
[[Conclusion]]
<</if>>Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprés d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[7 - Un miroir coach - Eva]]
#Eva se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - Eva]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva passe indep et se lance dans [[7 - Agile dans l'Infra? - Eva]]
<<else>>
[[Conclusion]]
<</if>>Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprés d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - LudiGames]]
#Eva se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - LudiGames]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva passe indep et se lance dans [[Agile dans l'Infra? - Eva]]
<<else>>
[[Conclusion]]
<</if>>Eva a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
Eva opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, elle demande un entretien avec le responsable des chefs de projets de chez LudiGames. Elle lui propose de mettre à plat le workflow de création de valeur chez LudiGames.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
Eva a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, elle a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez LudiGames il ne le font pas).
Que va faire Eva?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le [[DevOps - LudiGames]]
#Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - LudiGames]]
#Eva comprend que c'est un changement de culture important, elle se lance dans la démarche [[Kanban - LudiGames]] en espérant prouver par l'exemple que le workflow actuel est saturé.Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprés d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - LudiGames]]
#Eva se dit que pour se soigner un peu du syndrôme il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - LudiGames]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva passe indep et se lance dans [[Agile dans l'Infra? - Eva]] <img src="https://picsum.photos/200/300?random=1"/>Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
<<if setup.steps lt 12>>
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - LudiGames]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - LudiGames]]
#Plusieurs personnes semblent interessées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Durant ses différentes explorations, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu'elle arrive dans un nouveau contexte, même si c'est pour un client qu'elle connait déjà, elle revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquement, de ces temps-ci, touchée par le [[Syndrôme de l'imposteur - LudiGames]]
#Eva travaille avec beaucoup d'équipe ces derniers temps et elle aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Aprés toutes ses aventures chez LudiGames, Eva décide de voler de ses propres ailes. [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flatée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
<<if setup.steps lt 12>>
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[Un miroir coach - LudiGames]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[Agile Games France - LudiGames]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[Eva rejoint Nord Agile - LudiGames]]
<<else>>
* Elle décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour Eva. Eva se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
Eva rejoint Nord Agile.
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
<<if setup.steps lt 12>>
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[Le WSJF chez LudiGames]]
#Eva propose à VP de travailler d'abord à la [[Valeur Business - LudiGames]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[Shape Up - LudiGames]]
<<else>>
* Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* Eva propose à VP de travailler d'abord à la valeur Business.
* Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle.
[[Conclusion]]
<</if>>Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Aprés avoir mis en place plusieurs action d'amélioration d'envergure, le manager d'Eva lui propose de prendre un rôle de coach. [[Eva devient coach agile chez LudiGames]]
#Eva est maintent armée pour se lancer seule. [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>>Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - LudiGames]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[Eva organise un séminaire produit - LudiGames]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[Agile Games France - LudiGames]]
#Eva se rend compte qu'elle a des choses interessantes à dire et les personnes avec lesquelles elle échange dans la communauté lilloise la motive à les partager avec un maximum de gens. [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - LudiGames]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
<<else>>
Au sortir de l'événement, Eva peut prendre plusieurs directions :
* Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...
* Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau.
* Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros Syndrôme de l'imposteur
* Aprés l'atelier auquel elle a participé, Eva se passionne pour le No Estimate
* Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!!
[[Conclusion]]
<</if>>Eva consulte les ressources qu'elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples qu'Eva voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
<<if setup.steps lt 12>>
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, elle se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#En recherchant des formats de rétrospectives, Eva est tombée sur plusieurs articles mentionnants la communauté agile Lillois. [[Eva découvre les meetups et Nord Agile - LudiGames]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, Eva teste [[Kanbanzine - LudiGames]]
#Eva se rend compte que [[Peu importe le format, seuls les résultats comptent - LudiGames]] quand on parle de rétrospective.
<<else>>
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, elle décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ca ira bien mais elle se dit que si elle doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
<<if setup.steps lt 12>>
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[Shape Up - LudiGames]]
<<else>>
Eva et son équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ca fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[Le craftsmanship - LudiGames]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - LudiGames]]
#Eva a pris goût aux outils gamifiés, elle se lance dans [[Kanbanzine - LudiGames]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais Eva se demande souvent si elle est légitime. [[Syndrôme de l'imposteur - LudiGames]]
<<else>>
* Afin de faire évoluer ses accompagnements, Eva se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* Eva a pris goût aux outils gamifiés, elle se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais Eva se demande souvent si elle est légitime. Elle est touchée par le syndrôme de l'imposteur.
[[Conclusion]]
<</if>>Ca vous prend par hazard, quand ca frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrôme (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprés d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ca?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - Eva Indep]]
#Eva se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - Eva Indep]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
<<else>>
[[Conclusion]]
<</if>>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
<<if setup.steps lt 12>>
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Que fait Eva avec la [[Démarche OKR - LudiGames]]?
#Maintenant qu'elle est certifiée, Eva peut devenir [[Eva micro-entrepreneuse]]
<<else>>
* Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création, elle se passionne pour le Serious Gaming.
* Elle continue à déployer la démarche OKR chez LudiGames
[[Conclusion]]
<</if>>
Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troubleé... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
Réussira-t-elle à faire bouger les choses chez LudiGames? Une chose est sûre, elle s'est porté volontaire pour intégrer le groupe de discussion RSE!!
<<if setup.steps lt 12>>
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva décide de passer indep et se lance dans l'[[Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Un manager de LudiGames lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[Eva organise un séminaire produit - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[9 - Le craftsmanship - RDB]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[9 - La dette technique et Scrum - RDB]]
#James a pris goût aux outils gamifiés, il se lance dans[[9 - Kanbanzine - RDB]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. [[9 - Syndrôme de l'imposteur - RDB]] Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[8 - Kanban - LudiGames]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[8 - Le craftsmanship - LudiGames]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[8 - Eva se lance dans l'écriture d'une conférence - LudiGames]]
Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héro.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l'héroine de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héro. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapîtres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ca ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d'[[9 - Un miroir coach - LudiGames]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[9 - Une formation certifiante Coach - LudiGames]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[9 - Eva rejoint Nord Agile - LudiGames]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[9 - La fresque du climat - LudiGames]] Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Aprés avoir mis en place plusieurs action d'amélioration d'envergure, le manager d'Eva lui propose de prendre un rôle de coach. [[Eva devient coach agile chez LudiGames]]
#Eva est maintent armée pour se lancer seule. [[Eva micro-entrepreneuse]]
Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financié mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Que fait Eva avec la [[Démarche OKR - LudiGames]]?
#Maintenant qu'elle est certifiée, Eva peut devenir [[Eva micro-entrepreneuse]]
Comme elle a participé à un meetup, Eva recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Aprés cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - LudiGames]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ca sort un peu de sa zone de confort mais Eva se lance. [[Eva organise un séminaire produit - LudiGames]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l'[[Agile Games France - LudiGames]]
#Eva se rend compte qu'elle a des choses interessantes à dire et les personnes avec lesquelles elle échange dans la communauté lilloise la motive à les partager avec un maximum de gens. [[Eva se lance dans l'écriture d'une conférence - LudiGames]] Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troubleé... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
Réussira-t-elle à faire bouger les choses chez LudiGames? Une chose est sûre, elle s'est porté volontaire pour intégrer le groupe de discussion RSE!!
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva décide de passer indep et se lance dans l'[[Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Un manager de LudiGames lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[Eva organise un séminaire produit - LudiGames]] Nouveau challenge pour Eva : elle doit accompagner LudiGames dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager d'Eva a choisi l'option "Seeding".
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[8 - Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d'[[8 - Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[8 - Des problèmes d'engagement - LudiGames]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ca n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ca?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrêtes de toutes leurs discussions. Eva se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut[[9 - Faire vivre les actions aprés un séminaire]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management de LudiGames demande à Eva de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher!]]<img src="https://picsum.photos/200/300?random=1"/>L'enthousiasme était grand, les félicitations aussi... Mais au lendemain de l'événement Eva redescend vite.
Elle est devant une tonne de photos, de post-its géants barbouillés, de rouleaux de papiers blancs remplis de photos et de flêches... mais elle n'a pas vraiment d'action.
Alors certes, tout le monde était d'accord sur le fait que la manière actuelle de travailler n'est pas en adéquation avec les volontées agiles de l'entreprise. Tout le monde a dit : il faut changer ca, aller vers une démarche orientée produit.
Ils ont bien identifié la différence de fonctionnement entre le mode projet et le mode produit, surtout d'un point de vue budgétaire. Ben oui, on ne gère pas les deux de la même manière!
Elle retrouve le post-it posé par un certain Lionel qui dit : "La force de l'agilité c'est de pouvoir fonctionner à budget fini!!"
Maintenant elle doit transformer tout ca en actions.
Première chose : est-elle la bonne personne pour lister les actions? Non, elle ne le pense pas. Elle n'a pas toutes les réponses. Mais elle peut animer un groupe de travail (ou en faire partie).
Elle peut aussi proposer une formulation de la démarche produit LudiGames à partir de tous les rendus... Mais ca ne les transformera pas en actions...
Alors elle a le choix :
#Proposer au management de créer un [[Un comité de transformation - LudiGames]] auquel elle pourrait se joindre.
#Animer elle même la transformation. [[Faire vivre les actions aprés un séminaire - LudiGames]]
#Demander à être formée aux démarches produits afin d'aller chercher les outils nécessaires à la transformation (et les maitriser). [[Se former aux démarches produits - LudiGames]]
#S'enfermer chez elle et se prendre un méga [[Syndrôme de l'imposteur - LudiGames]]Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[8 - Des problèmes d'engagement chez LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[8 - Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[8 - Eva participe à son premier Agi'Lille]]
#C'est bien beau tout ca mais ce sont des problématiques de Scrum Master, nous ce qu'on veut c'est voir la suite. [[8 - Fast Track Scrum Master - Eva]]C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[9 - Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[9 - Le WSJF chez LudiGames]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[9 - Fast Track Scrum Master - Eva]] Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous intéresse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[9 - Kanban - LudiGames]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[9 - Le craftsmanship - LudiGames]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]]
Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[9 - Eva organise un séminaire produit - LudiGames]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[9 - Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[9 - Eva devient coach agile chez LudiGames]]
Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
Eva a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, elle a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#Eva explore le Kanban car elle a entendu que le terme FastLane vient de là. [[Kanban - LudiGames]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - LudiGames]]
#Eva commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[Eva se lance dans l'écriture d'une conférence - LudiGames]]
Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[Eva devient coach agile chez LudiGames]]
Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Aprés quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[8 - Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[8 - Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[8 - Le Kanban ca marche, mais ca prend du temps! - LudiGames]].Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[8 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[8 - Gérer le run en Scrum - LudiGames]]
#Eva va galérer, mais elle va y arriver, nous ce qu'on veut voir c'est l'après [[8 - Eva micro-entrepreneuse]] En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, Eva tombe sur Kanbanzine. Elle a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Eva est tout de suite emballée par la description de l'atelier et, malgré le prix de l'outil, décide d'investir dans la version officielle. En plus, cette version lui donne accès à l'animation en ligne de l'atelier.
Lors d'une de ses missions, elle propose à son commanditaire d'animer l'atelier avec une des équipes qu'elle accompagne.
L'atelier se passe bien. L'équipe de chez LudiGames comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite Eva?
#Avec cette équipe, ils décident de déployer la démarche Kanban. [[9 - Le Kanban ca marche, mais ca prend du temps! - LudiGames]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment leur permettre d'entrer dans les cases. Eva propose alors de créer [[9 - Une méthode maison pour LudiGames]]
#Eva se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Elle continue ses recherches et explore [[9 - Shape Up - LudiGames]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, Eva ne connait pas bien Laurent.
Elle entame donc la formation sans à priori et se rend compte rapidement qu'elle est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui la marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau d'Eva car elle espère les utiliser à un moment donné.
Au sortir de cette formation Eva est pleine de nouvelles informations et envies! Comment les exploite-t-elle?
#Eva se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva décide d'explorer [[9 - Kanbanzine - LudiGames]]
#Eva se dit que toutes ces nouvelles informations vont pouvoir servir à LudiGames mais pas directement en passant par la démarche Kanban. Elle propose de commencer par [[9 - La démarche produit - LudiGames]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour Eva après [[9 - Fast Track Scrum Master - Eva]] Eva et l'équipe se lancent tête baissée dans la démarche Kanban.
Eva travaille avec l'équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutôt que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
Eva sent que l'équipe pourrait être encore plus efficace et décide de les accompagner dans l'identification des goulots d'étranglement au sein de leur tableau. Elle se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Elle accompagne donc le scrum master dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... Eva réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le management d'Eva l'interpelle car ils considèrent que les progrés certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. Eva leur explique [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Maintenant que la démarche Kanban est en place, Eva propose de mettre en place [[9 - Une méthode maison pour LudiGames]]
#De Kanban à Scrum c'est trés beau tout ca, mais comment doivent s'appeler les rôles systémiques du coup? [[9 - Des noms de rôles en agile - LudiGames]]
#L'aventure d'Eva interpèle à chaque fois qu'elle en parle dans ses réseaux, du fait elle se dit qu'elle pourrait en faire une histoire à raconter... [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[9 - Eva rencontre des coachs inspirants - LudiGames]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - LudiGames]]
#Aprés l'atelier auquel elle a participé, [[9 - Eva se passionne pour le No Estimate - LudiGames]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]]Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[Gérer le run en Scrum - LudiGames]]
#Eva va galérer, mais elle va y arriver, nous ce qu'on veut voir c'est l'après [[Eva micro-entrepreneuse]] La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en armonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Aprés s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprenent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise. Gunther est... mouais, c'est Gunther ;)
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[9 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]] Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[9 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]] Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[9 - Eva rejoint Nord Agile - LudiGames]]
#Les sirènes de l'indépendance chantent dans les oreilles d'Eva [[Eva micro-entrepreneuse]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - LudiGames]]
#L'amélioration continue sert à accélerer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - LudiGames]]
#Plusieurs personnes semblent interessées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[Eva se lance dans l'écriture d'une conférence - LudiGames]]Durant ses différentes explorations, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu'elle arrive dans un nouveau contexte, même si c'est pour un client qu'elle connait déjà, elle revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquement, de ces temps-ci, touchée par le [[Syndrôme de l'imposteur - LudiGames]]
#Eva travaille avec beaucoup d'équipe ces derniers temps et elle aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Aprés toutes ses aventures chez LudiGames, Eva décide de voler de ses propres ailes. [[Eva micro-entrepreneuse]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flatée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[Un miroir coach - LudiGames]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour Eva. [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[Agile Games France - LudiGames]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[Eva rejoint Nord Agile - LudiGames]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[Le WSJF chez LudiGames]]
#Eva propose à VP de travailler d'abord à la [[Valeur Business - LudiGames]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[Shape Up - LudiGames]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est paré, elle se lance. Que fait-elle en premier?
#Elle décide de [[9 - Gamifier une rétrospective - LudiGames]]
#Elle choisi un outil d'apprentissage et l'anime auprés de son équipe. Ils testent [[9 - Kanbanzine - LudiGames]]
#Lors d'un accompagnement d'équipe débutante, elle utilise[[9 - Scrumble - LudiGames]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[9 - Eva découvre les meetups et Nord Agile - LudiGames]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flattée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[9 - Un miroir coach - LudiGames]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[9 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[9 - Agile Games France - LudiGames]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[9 - Eva rejoint Nord Agile - LudiGames]]
Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprès d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[9 - Un miroir coach - LudiGames]]
#Eva se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel elle a une grande marge d'amélioration : [[9 - Le craftsmanship - LudiGames]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva passe indep et se lance dans [[9 - Agile dans l'Infra? - Eva]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[9 - Le WSJF chez LudiGames]]
#Eva propose à VP de travailler d'abord à la [[9 - Valeur Business - LudiGames]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[9 - Shape Up - LudiGames]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[8 - Le WSJF chez LudiGames]]
#Eva propose à VP de travailler d'abord à la [[8 - Valeur Business - LudiGames]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[8 - Shape Up - LudiGames]] Eva met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Elle tente d'appliquer les mêmes principes que ceux appliqués chez LudiGames:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu’elle est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, elle décide de revoir sa copie. Quelle est la prochaine étape?
#[[8 - Le management LudiGames remet en question la capacité d’Eva à avancer seul]]
#Eva se rend compte qu'il faut absolument [[8 - Accompagner le PO - LudiGames]]
#Eva entend parler de la communauté agile Lilloise et décide de participer à [[8 - Son premier forum ouvert - LudiGames]]
#Avançons un peu dans le temps. [[8 - Fast Track Scrum Master - Eva]] C'est une notion difficile la valeur business, surtout chez LudiGames!! Comment comparer la création de valeur d'un nouveau jeu en ligne vs l'ajout de fonctionnalités sur un jeu existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[9 - Le WSJF - LudiGames]]
#Eva abandonne ce sujet et préfère se concerntrer sur un autre sujet auprés du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses]]
#Oublions un peu l'expérience Scrum Master, passons à la suite [[9 - Fast Track Scrum Master - Eva]] Eva comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Elle apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Elle aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, elle manque de recul sur le sujet, et elle a l'impression que la communauté aussi.
Elle essaye d'engager malgré tout un chantier avec un PO autour des appétits.
Elle propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, elle lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Elle propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Aprés un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec Eva ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, Eva devrait se rapprocher de la communauté agile Lilloise. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que les équipes se soucient du run en Scrum. [[9 - Gérer le run en Scrum - LudiGames]]
#Eva va galérer, mais elle va y arriver, nous ce qu'on veut voir c'est l'après [[Eva micro-entrepreneuse]] Le manager d'Eva lui propose un rendez-vous pour faire un petit état des lieux.
Eva déploie énormément d'efforts à tenter de faire évoluer son équipe et ses parties prenantes mais sans gros succès. Comment faire pour maximiser son retour sur investissement?
Quelle décision prennent-ils?
#Eva doit impérativement faire de la veille de son coté, pour ce faire, LudiGames est OK pour lui payer sa participation à l'Agi'Lille [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#LudiGames décide de faire intervenir une personne plus expérimentée pour accompagner Eva [[9 - Un coach agile chez LudiGames]]
#Eva prend la mouche et se lance en indep [[Eva micro-entrepreneuse]] Eva propose au PO un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Elle découvre que le PO a été catapulté là uniquement parcequ'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
Quelle est la prochaine étape pour Eva?
#Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[9 - Eva devient PPO - LudiGames]]
#Eva le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[9 - Product Box - LudiGames]].
#Eva se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Elle décide alors de [[9 - Se former aux démarches produits - LudiGames]].
Un premier événement agile c'est toujours une expérience!! Surtout quand il s'agit d'un forum ouvert.
Ce type de rencontre agile est interessant :
* les participants ne savent pas à l'avance le contenu de l'événement.
* l'organisation est libre
* ce qu'il se passe dans le forum est ce qu'il doit se passer
* au sortir de l'événement, les agilistes sont généralement ravi de ce qui se passe.
Eva n'est en effet pas déçue. Au début, elle s'est sentie un peu perdue dans cet événement non organisé. Elle ne savait pas par où commencer. Puis, grâce à la facilitation de quelques participants des éditions précédentes et à l'esprit agile des participants, les sujets passionnants se développent.
Eva participe à plusieurs échanges. Pour commencer, un coach expérimenté propose de refléchir à la suite de l'agilité, ensuite une autre personne se demande si on peut être agile sans Scrum Master et PO, puis elle teste un outil créé par un groupe de collègues autour de la gestion de la dette technique.
Durant ce rendez-vous agile, Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#En discutant avec plusieurs participants, Eva a découvert le mouvement Agnostic Agile et se demande si elle ne peut pas s'en inspirer avec son équipe [[9 - Agnostic Agile - L'agilité LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[9 - Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#La vie de Scrum Master c'est bien mais on voudrait voir ce qu'il y a après [[9 - Fast Track Scrum Master - Eva]] LudiGames décide donc de faire appel à un coach agile plus expérimenté que'Eva.
Esprit StartUp oblige, Eva est incluse dans les entretiens de sélection de la personne qui va l'accompagner. Elle donne son avis sur les différentes personnes et après quelques jours, elle recontacte James Huyvre pour qu'il les accompagne
James arrive quelques jours après. Il rencontre Eva et lui expose ce qu'il se propose de mettre en place.
Quelle option James propose-t-il à Eva?
#James a l'habitude de ne pas faire de fausse promesse, d'adapter son accompagnement aux besoins de l'organisation qu'elle accompagne. Pour se faire, il doit passer du temps dans [[Une phase d'observation - LudiGames]] afin de faire des suggestions cohérentes.
#James va accompagner Eva dans son évolution jusqu'à ce qu'elle ne soit plus une scrum master débutante. [[Fast Track Scrum Master - Eva]] Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Elle reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Elle réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, Eva a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projetter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, Eva se rend compte des difficultés rencontrées par le PO. Elle se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[La dette technique et Scrum - LudiGames]]
#Aborder la [[Valeur Business - LudiGames]]
#Mettre en place un mode de priorisation simple et rapide. [[Prioriser en tailles de TShirt - LudiGames]]
#Déployer le WiSJiF [[Le WSJF chez LudiGames]] Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de LudiGames et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[LudiGames et Kanban]]
#Au final, Scrum reste une proposition interessante, il leur faudra s'adapter aux contraintes mais ils décident d'essayer de rentrer dans le cadre. [[LudiGames et Scrum]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[Une méthode maison pour LudiGames]]
<img src="https://picsum.photos/200/300?random=1"/>L'observation se passe bien. James rencontre l'équipe d'Eva, le management, les parties prenantes... sans Eva.
Il lui a bien sûr expliqué pourquoi il voulait le faire sans elle : "Les personnes que je vais rencontrer doivent pouvoir dire tout ce qu'elles pensent sur la démarche appliquée sans essayer d'aller dans le sens d'Eva si elle est dans la pièce".
<<if setup.steps lt 12>>
Que se passe-t-il ensuite?
#James conclue que la plus grande problématique n'est pas liée à l'aspect opérationnel agile de l'équipe, mais de la gestion de la vision produit par LudiGames. Il propose à Eva de mettre en place [[Une vraie démarche produit chez LudiGames]]
#James motive Eva à proposer la mise en place d’un [[Un comité de transformation - LudiGames]]
#James accompagne Eva dans son évolution, maintenant qu'elle n'est plus Scrum Master débutante, elle se lance en Indep. [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Rentrer dans un cadre, quand on est une StartUp, ça pourrait paraître antinomique.
Et pourtant, c'est ce à quoi s'attèle Eva.
Revenir aux bases, expliquer pourquoi Scrum. Le fait qu'une équipe c'est comme une mêlée au rugby...
Revenir aux bases, reposer le cadre. Des sprints de 2 semaines, des rituels toujours à la même heure, au même moment du sprint.
Faire du lean même : éliminer le superflu (notamment toutes ces réunions qui ne produisent pas de valeur). Revoir le tableau scrum, enlever ces étapes dictées par leur outil de ticketting. Ajuster le process dans l'outil de ticketting pour qu'il s'adapte à Scrum (et pas l'inverse).
Puis retravailler l'empirisme. Travailler aux bons indicateurs (burn up, burn down). Utiliser les données pour aider l'équipe à s'engager. Challenger l'équipe sur son engagement (vers le haut ou vers le bas). Faire en sorte qu'ils se synchronisent correctement en vue de la tenue de cet engagement.
Retourner aux bases... de Scrum.
Au final, Eva dépense énormément d'énergie pour ce retour dans le cadre. L'équipe est souvent frustrée de devoir se conformer à un cadre... "Scrum c'est pas flexible" s'entend-t-elle critiquée parfois... Scrum c'est pas flexible... Scrum c'est pas agile?
Mais elle tient bon...
<<if setup.steps lt 12>>
#Et le résultat est à la hauteur de l'investissement d'Eva et des frustrations de l'équipe. [[Scrum ca marche pour LudiGames]]
#L'équipe a bneau être rentrée dans le cadre, rien n'y fait, ils continuent à ne pas livrer l'attendu. [[Des problèmes d'engagement chez LudiGames]]
#Rentrer dans le cadre oui, mais pour combien de temps? Doit-on y rester longtemps? Eva explore [[Le ShuHaRi appliqué à Scrum - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Tout dans Scrum s'applique correctement chez LudiGames!
L'engagement de l'équipe est tenu à chaque sprint et les challenge un peu quand même ;)
Le produit est mis en ligne à chaque fin de sprint.
La priorisation par la valeur fonctionne.
Bref, tout va bien.
Pour l'équipe d'Eva et LudiGames, le succès est au rendez-vous. A tel point que le PO n'est plus sollicité que pour dire non et porter le produit, l'équipe se charge de discuter avec les parties prenantes et a tous les outils à sa disposition pour évaluer la valeur. On se croirait dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg (traduite par Fred Lothon).
Eva n'est plus sollicitée par l'équipe que lorsque les blocages rencontrés demandent de l'implication forte (en temps) pour être levés.
Elle a donc du temps pour explorer des sujets complémentaires sur la toile.
Elle a réussi à amener un peu de fun dans les différents rituels. En commençant par des ice breaker et energizer bien appréciés par l'équipe!
A chaque rétrospective, elle trouve un format ludique que l'équipe n'a pas encore (ou rarement, faut pas déconner) utilisé. Elle change à chaque fois le focus de l'équipe et elle a même réussi à mettre en place de vrais slack days.
Tout va bien je vous dit!! Même le run ne pose pas de problème. Faut dire, la qualité de code produite par l'équipe est telle qu'il n'y a que peu d'anomalies en production. En plus, même lorsqu'ils découvrent des anomalies, elles sont résolues séance tenante par l'équipe.
Eva est donc prête pour passer à la suite.
<<if setup.steps lt 12>>
#En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!! [[Eva se passionne pour le No Estimate - LudiGames]]
#Le manager d'Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. [[Le Cargo Cult ca pique - LudiGames]]
#Forte de ce succés, Eva se dit qu'elle aimerait changer un peu d'horizon et se lancer dans le coaching agile. [[Eva devient coach agile chez LudiGames]]
<<else>>
* En discutant avec un ami elle découvre le No Estimate. Elle se dit que c'est la prochaine étape à franchir avec son équipe!!
* Le manager d’Eva l'approche : "Tu es super efficace avec ton équipe. On a une autre équipe scrum en perdition, tu voudrais pas leur apporter un peu de ta magie?" Eva change donc d'équipe et applique avec la nouvelle les mêmes pratiques qu'avec la première. Se dirige-t-elle vers un cargo cult?
[[Conclusion]]
<</if>>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
<<if setup.steps lt 12>>
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF chez LudiGames]]
<<else>>
* Eva se demande si ce n'est pas la partie test de l'application qui pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé, Eva est persuadée que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. Elle cherche à responsabiliser toute l'équipe sur l'aspect QA.
* Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. Eva et le Scrum Master vont se confronter à la gestion de run en Scrum ;)
* Eva propose de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. Ils vont explorer le WiSJiF ensemble
[[Conclusion]]
<</if>>LudiGames a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
<<if setup.steps lt 12>>
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
#James propose à Eva d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[Eva découvre les meetups et Nord Agile - LudiGames]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, James propose qu' [[Eva organise un séminaire produit - LudiGames]]
<<else>>
Mais pour se lancer dans une démarche produit, James a du pain sur la planche :
* James propose à Eva d'évangéliser toutes les parties prenantes à la démarche agile.
* En même, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, James propose qu' Eva organise un séminaire produit.
[[Conclusion]]
<</if>>Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[8 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[8 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[8 - Prouver l'impact de la dette technique - Eva]]Eva n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais elle est débrouillarde.
Elle se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Elle met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit de LudiGames.
Elle déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et Eva a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ça n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Elle a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Elle a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'elle avait choisi avaient le bon niveau de décalage par rapport aux personnes présentes et elle a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Elle se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-elle de tout ça?
#Elle s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. Eva se pose alors la question de comment [[8 - Dégager des actions d'un séminaire - LudiGames]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut [[8 - Faire vivre les actions aprés un séminaire - LudiGames]]!
#La conclusion de leur séminaire est qu'il leur faut [[8 - Une méthode maison pour LudiGames]]. Eva a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management de LudiGames demande à Eva de justifier les investissements passés et futurs : [[8 - L'agile ca coûte cher! - LudiGames]]Pour Eva, l'équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que l'équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modification (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une après midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#Eva accompagne son client dans la création d'une démarche maison. [[8 - Une méthode maison pour LudiGames]]
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une [[8 - Sensibilisation agile des PP - LudiGames]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes client (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ça, [[8 - Eva se passionne pour le Serious Gaming - LudiGames]] Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[9 - Le craftsmanship - LudiGames]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[9 - Le WSJF - LudiGames]]
#Un manager vient voir Eva avec la fameuse rengaine : [[9 - L'agile ca coûte cher! - LudiGames]]Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projeté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[9 - Le craftsmanship - LudiGames]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Le manager d'Eva lui demande comment faire pour [[9 - Créer une nouvelle équipe Scrum - LudiGames]].Eva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre plusieurs manières principales de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ca n'est pas facile mais c'est finalement validé [[9 - Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[9 - Une formation agile - LudiGames]]
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de littérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[LudiGames et Shape Up]]
#Forte des retours, Eva propose de créer [[Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Nouveau challenge pour Eva : elle doit accompagner LudiGames dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager d'Eva a choisi l'option "Seeding".
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d’[[Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement - LudiGames]]Eva choisi une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, Eva est assurée que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[Un comité de transformation - LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[Fast Track Scrum Master - Eva]] Eva passe beaucoup de temps à préparer la formation. On l'avait prévenu : l’ingénierie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour Eva c'est sa première formation.
Elle passe du temps à préparer un plan, puis elle le jette à la corbeille quand elle commence à compiler ses slides et qu'elle essaye de raconter une histoire cohérente.
Elle commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Elle promet de mettre à jour son cursus pour la prochaine session.
Elle a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'elle souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[Eva organise un séminaire produit - LudiGames]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[Un comité de transformation - LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[Fast Track Scrum Master - Eva]] Et oui, produire en agile coûte plus cher que de produire dans une méthode plus "traditionnelle".
Eva se documente, ne trouve pas énormément de littérature sur le sujet... elle décide de creuser un peu plus.
Quelle est sa prochaine action?
#Eva trouve rapidement une réponse qu'elle souhaite amener à ses clients [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - LudiGames]]
#Eva propose à son client de découvrir d'autres manière d'être agiles que Scrum. Elle lui propose de lire le livre blanc Shape Up et ils se demandent ensemble si ce n'est pas une solution plus interessante pour les équipes. [[9 - LudiGames et Shape Up]]
#Forte des retours, Eva propose de créer [[9 - Une méthode maison pour LudiGames]] tout en restant dans la démarche agile.Pour suivre les actions, Eva s'inspire de ce qu'elle connait bien : Scrum.
Elle propose de fonctionner en itérations de transformation, avec des acteurs identifiés à chaque itération. Au début de chacune d'entre elle, une grosse réunion de lancement. Puis chacun travaille sur ses actions avec des points de synchronisation réguliers et à la fin de chaque itération ils organisent une revue avec toutes les personnes de l'entreprise si elles le souhaitent.
Ce fonctionnement est plutôt efficace. Il faut juste comprendre que l'itération dans ce cas peut-être de plusieurs semaines à plusieurs mois.
Le constat du séminaire est qu'entant que startup, LudiGames est déjà en mode produit... en fait, c'est l'essence même de la création de l'entreprise qui s'est constituée autour de leur plateforme d'animation en ligne. Les sujets validés sont donc de nature différente.
Eva anime l'aspect itératif et doit régulièrement remettre de l'énergie dans la machine. Toute cette implication lui prend énormément de temps.
Eva fait partie des acteurs, et de ce fait nous pouvons la suivre sur plusieurs initiatives :
#Le sujet de la vision de l'entreprise a été mis sur le tapis. Eva, et son groupe de travail, doit trouver comment travailler sur ce sujet. [[9 - Les experts de la vision - LudiGames]]
#Le sujet de l'objectivation des équipes a été au centre des discussions. Actuellement, chaque manager a la possibilité de choisir les objectifs qu'il propose à son équipe. Eva investigue la [[9 - Démarche OKR - LudiGames]].
#Devant son engagement sur les sujets plus centraux de l'entreprise, le management propose à Eva de changer de poste. [[9 - Eva devient coach agile chez LudiGames]] Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[8 - Le craftsmanship - LudiGames]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[8 - Le WSJF - LudiGames]]
#Un manager vient voir Eva avec la fameuse rengaine : [[8 - L'agile ca coûte cher! - LudiGames]]Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[8 - Le craftsmanship - LudiGames]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Le manager d'Eva lui demande comment faire pour [[8 - Créer une nouvelle équipe Scrum - LudiGames]].Nouveau challenge pour Eva : elle doit accompagner LudiGames dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant elle se profilent différentes solutions.
Elle peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
Eva repense à un échange qu'elle a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ça que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager d'Eva a choisi l'option "Seeding".
Maintenant qu'elle est en place, Eva peut se consacrer à la suite :
#[[9 - Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez son client, et aller plus loin dans leur transformation agile, Eva propose la mise en place d’[[9 - Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[9 - Des problèmes d'engagement - LudiGames]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été reçue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à cela ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[Les experts de la vision - LudiGames]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - LudiGames]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[Fast Track Scrum Master - Eva]] Pas facile de transformer une vision en action.
Mais Eva a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être Eva les animera-t-elle en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. Eva en parle à son manager qui devra faire son choix.
Que voulez-vous voir ensuite?
#On a envie d'en s'avoir plus sur la [[8 - Démarche OKR - LudiGames]]
#Le manager d’Eva lui demande d'animer un séminaire autour de la notion de produit. [[8 - Eva organise un séminaire produit - LudiGames]]
#Une vision nouvelle, des actions qui animent cette vision, ça fait beaucoup de chaos tout ça non? [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]] Eva se lance avec les OKR et elle a bien compris, et fait comprendre, que travailler avec cet outil demande à ce qu'ils soient revus régulièrement.
Elle propose à son équipe d'être exemplaire sur le sujet.
L'équipe est plutôt fière de son travail de préparation, en effet, elle a pu répondre à 2 des 3 ambitions de l'entreprise via 3 KR sur chaque. Ils ont même poussé et ajouté une ambition interne à l'équipe pour favoriser la rétention et l'amélioration des prouesses technique de celle-ci.
Au niveau de la revue des KR, Eva propose au départ de mettre en place une réunion bimestrielle.
Elle réunie donc son équipe aprés le premier cycle et ils se lance dans la revue. Au sortir de cette réunion le constat d'Eva est sans appel :
* 2/3 des KR n'ont pas évolué. Pire, pour la grande majorité aucune action n'a avancé ou été lancée.
* Le tier des KR qui ont évolués, l'ont fait le jour d'avant la réunion. Eva est persuadée que son petit rappel en daily à propos de la revue n'y est pas pour rien.
Fort de ces informations, Eva amène le sujet lors de la rétrospective de Sprint, qui, par chance, a lieu deux jours aprés.
L'équipe discute du sujet, avoue ses écarts et décide de changer de ritualisation.
Maintenant, les KRs seront suivis (revus) a chaque fin de sprint. Ils décident que ca se passera durant la rétrospective et, qu'à chaque Sprint Planning, ils doivent considérer les actions relatives aux KRs (lorsque spécifiques) et que ces dernières vont, de fait, intégrer le backlog
Double succès pour Eva : Non seulement les KRs sont suivis et évoluent, mais en plus l'impact sur l'activité (temps disponible à produire) de l'équipe est négligeable.
Quelle est maintenant la suite pour Eva?
#Eva a vraiment apprécié travailler sur les OKR ainsi que sur des sujets qui sortent un peu de l'opérationnel de son équipe. [[8 - Eva devient coach agile chez LudiGames]]
#Eva se dit qu'elle a acquis suffisamment d'expérience avec LudiGames pour pouvoir se lancer toute seule. [[8 - Eva micro-entrepreneuse]]
#Les OKR c'est bien, couplé à une démarche agile c'est top, mais il y a encore au moins une étape dans la transformation de LudiGames. [[8 - La démarche produit chez LudiGames ]] .
#Eva souhaite faire évoluer LudiGames sur la voix vertueuse de la démarche agile. Cependant, son manager n'est pas persuadé qu'elle peut y arriver seule. [[8 - Le management remet en question la capacité d'Eva à avancer seule]] Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[8 - Production VS Servant Leadership - LudiGames]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[8 - Le craftsmanship - LudiGames]].
#Bon, et si on avancait plus rapidement dans le temps! Que fais Eva aprés Scrum Master? [[8 - Fast Track Scrum Master - Eva]] Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[9 - Des problèmes d'engagement - LudiGames]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[9 - Une présentation de la démarche agile à l'équipe - LudiGames]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#C'est bien beau tout ça mais ce sont des problématiques de Scrum Master, nous ce qu'on veut c'est voir la suite. [[9 - Fast Track Scrum Master - Eva]]Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est paré, elle se lance. Que fait-elle en premier?
#Elle décide de [[8 - Gamifier une rétrospective - LudiGames]]
#Elle choisi un outil d'apprentissage et l'anime auprès de son équipe. Ils testent [[8 - Kanbanzine - LudiGames]]
#Lors d'un accompagnement d'équipe débutante, elle utilise[[8 - Scrumble - LudiGames]]
#Elle se dit que la communauté agile doit pouvoir l'aider [[8 - Eva découvre les meetups et Nord Agile - LudiGames]] <img src="https://picsum.photos/200/300?random=1"/>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flattée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[8 - Un miroir coach - LudiGames]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[8 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[8 - Agile Games France - LudiGames]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour ellle : [[8 - Eva rejoint Nord Agile - LudiGames]]
Eva se lance... d'abord un petit retour d'expérience sur une phase d'observation qu'elle a fait avec une équipe... puis une conférence qui remonte sa réflexion sur le système de "définition de terminé" et le fait qu'il ne faut pas considérer que le travail est terminé à l'US...
Elle motive même un ami, Cameron, qui hésite à se lancer. Elle lui dit que tant qu'il parle de ce qu'il a vécu, de ce qu'il pense, sans essayer d'amener sa vérité comme absolue devant l'auditoire, il ne peut pas se tromper... c'est ce qu'elle même s'applique à faire.
Puis un jour, Eva a une idée folle : écrire une conférence qui, sous couvert de raconter l'histoire d'un personnage, raconte certaines de ses expériences, de ses questionnements, de ses convictions.
Lors d'une visite à Grenoble (Agile Grenoble forever!!), elle a la chance de voir une keynote dont le titre ressemble à "Rendez l'agilité aux developpeur(se)s ! " de Fanny Klauk. Sauf que, Fanny l'avait sous-titré : la conférence dont vous êtes le héros.
Ce titre l'avait intriguée et elle été ressortie de la conférence frustrée par rapport à ce dernier : Fanny proposait en effet au public de voter pour donner des réponses à certaines questions sauf qu'à chaque question il y avait forcément une bonne réponse (et des mauvaises)... Elle n'avait pas été l’héroïne de sa conférence!
Alors elle entreprend d'écrire une conférence dont le public est réellement le héros. Avec des choix d'orientation de l'aventure pour le public et un système de vote en ligne.
Malheureusement pour elle, elle ne se rend pas compte de la quantité de travail devant elle!! En effet, le nombre de chapitre de départ n'était pas effrayant mais à force d'essayer de raconter des histoires cohérentes, elle s'est retrouvée devant une montagne de chapitres à rédiger / dupliquer / adapter. Plus de 1500!!
Elle y passe se journées, ses nuits et ses weekends!!! Mais elle ne peut plus reculer : sa conférence a été retenue comme Keynote à l'Agi'Lille....
Si seulement elle s'en était tenue à ce qu'elle savait faire...
Mais elle persévère, elle écrit, elle corrige, elle réoriente... Ça ne sera pas beau, avec des images partout et des ptits chats, mais au moins il y aura du contenu...
Maintenant que cette conférence est écrite, et en attendant qu'elle soit présentée, que va faire Eva?
#Eva se dit qu'avancer toute seule entant que coach c'est pas facile, elle a besoin d’[[8 - Un miroir coach - LudiGames]]
#Ca fait quelques temps qu'elle se dit qu'elle aimerait suivre [[8 - Une formation certifiante Coach - LudiGames]]
#Aprés avoir participé à ses événements et y avoir présenté ses sujets, [[8 - Eva rejoint Nord Agile - LudiGames]]
#Eva est profondément écoresponsable, elle souhaite devenir animatrice de [[8 - La fresque du climat - LudiGames]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Que fait Eva avec la [[9 - Démarche OKR - LudiGames]]?
#Maintenant qu'elle est certifiée, Eva peut devenir [[Eva micro-entrepreneuse]]
Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troublée... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
Réussira-t-elle à faire bouger les choses chez LudiGames? Une chose est sûre, elle s'est porté volontaire pour intégrer le groupe de discussion RSE!!
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva décide de passer indep et se lance dans l’[[9 - Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Un manager de LudiGames lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[9 - Eva organise un séminaire produit - LudiGames]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Que fait Eva avec la [[8 - Démarche OKR - LudiGames]]?
#Maintenant qu'elle est certifiée, Eva peut devenir [[8 - Eva micro-entrepreneuse]]
Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Aprés avoir mis en place plusieurs action d'amélioration d'envergure, le manager d'Eva lui propose de prendre un rôle de coach. [[8 - Eva devient coach agile chez LudiGames]]
#Eva est maintent armée pour se lancer seule. [[8 - Eva micro-entrepreneuse]]
Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troublée... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
Réussira-t-elle à faire bouger les choses chez LudiGames? Une chose est sûre, elle s'est porté volontaire pour intégrer le groupe de discussion RSE!!
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Eva décide de passer indep et se lance dans l’[[8 - Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - LudiGames]]
#Un manager de LudiGames lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[8 - Eva organise un séminaire produit - LudiGames]] Eva est contactée par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inefficaces et ses membres souhaiteraient travailler avec Eva afin de regarder à leurs process de manière différente.
Eva propose à Anna un premier rendez-vous et ils s'accordent sur le fait qu'Eva peut les accompagner mais que ça ne sera pas une grosse intervention, plutôt de petites interventions.
La première session, Eva rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, Eva sent que quelque chose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Elle rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
Eva passe plusieurs heures à préparer son intervention, mais elle est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis elle continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures d'Eva?
#Elle est contacté via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]] Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, apaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[8 - Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva décide de se lancer dans l’[[8 - Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa formation, de fait elle veut essayer de se prêter au jeu de la création [[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[8 - Eva organise un séminaire produit - Indep]]
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des legos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres…[[8 - Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[8 - Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[8 - Syndrôme de l'imposteur - Eva Indep]]
#Après l'atelier auquel elle a participé, [[8 - Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[8 - Eva se lance dans l'écriture d'une conférence - Indep]]Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[8 - Le WSJF - Eva Indep]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[8 - Valeur Business Client - Eva Indep]]
#Plusieurs personnes semblent intéressées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[8 - Eva se lance dans l'écriture d'une conférence - Indep]]Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[8 - Le WSJF - LudiGames]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[8 - Valeur Business - LudiGames]]
#Plusieurs personnes semblent intéressées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[8 - Eva se lance dans l'écriture d'une conférence - LudiGames]]Durant ses différentes recherches, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais Eva sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu’elle ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu’elle arrive dans un nouveau contexte, même si c'est pour une équipe ou un domaine qu’elle connait déjà, elle revalide son glossaire et s'assure qu'au travers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquemment, de ces temps-ci, touchée par le [[8 - Syndrôme de l'imposteur - LudiGames]]
#Eva échange avec plusieurs équipes ces derniers temps et elle aime à explorer avec elles [[8 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva pourrait se lancer tout seul [[8 - Eva micro-entrepreneuse]] Eva en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Elle réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Elle prépare son matos, les ateliers qu'elle voudrait tester, les projets... Elle rempli un sac de jeux de sociétés et elle décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
Eva passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Elle y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Elle partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, Eva retourne à son quotidien.
#Suite aux échange qu'elle a eu durant l'événement, [[9 - Eva se lance dans l'écriture d'une conférence - LudiGames]]
#Elle décide de sortir de sa zone de confiance et accepte une mission qu'elle n'aurait même pas considéré quelques semaines auparavant. [[9 - Eva organise un séminaire produit - LudiGames]]
#Eva se dit qu'aprés ce qu'elle a vécu pendant 2 jours, elle a besoin de voir de nouveaux horizons. [[Eva micro-entrepreneuse]] Eva consulte les ressources qu'elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec son équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, elle se demande pourquoi. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#En recherchant des formats de rétrospectives, Eva est tombée sur plusieurs articles mentionnants la communauté agile Lillois. [[9 - Eva découvre les meetups et Nord Agile - LudiGames]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, Eva teste [[9 - Kanbanzine - LudiGames]]
#Eva se rend compte que [[9 - Peu importe le format, seuls les résultats comptent - LudiGames]] quand on parle de rétrospective.
Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ça fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[9 - Le craftsmanship - LudiGames]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[9 - La dette technique et Scrum - LudiGames]]
#Eva a pris goût aux outils gamifiés, elle se lance dans[[9 - Kanbanzine - LudiGames]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais Eva se demande souvent si elle est légitime. [[9 - Syndrôme de l'imposteur - LudiGames]] Un premier meetup c'est toujours une expérience!! Eva n'est pas déçue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[9 - Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#Après tous ces meetups, [[Eva se passionne pour le Serious Gaming - LudiGames]]
Quand il s'agit de mettre en place des rétrospectives, Eva est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, elle arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand elle le peut, elle préfère amener des rétrospectives imagées, ludiques.. Mais elle commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, elle a exploré le SMART de font en comble. Elle en est arrivée à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ça fonctionne très bien comme ça.
De manière générales, Eva voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, elle arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#Eva est devant une équipe dont le PO a de gros soucis de priorisation. Eva propose d'explorer [[Le WSJF - LudiGames]]
#Eva travaille le craftsmanship avec son équipe [[Le craftsmanship - LudiGames]]
#La performance de l'équipe est limitée par l’accès aux environnements de test et de production. Elle leur parle du [[DevOps - LudiGames]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - LudiGames]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flattée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ça la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[Un miroir coach - Eva Indep]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[Eva se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[Agile Games France - Eva Indep]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[Eva rejoint Nord Agile - Indep]]
Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprès d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - Eva Indep]]
#Eva se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - Eva Indep]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d’après les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[Le WSJF - Eva Indep]]
#Eva propose à VP de travailler d'abord à la [[Valeur Business Client - Eva Indep]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[Shape Up - Eva Indep]] Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flattée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ça la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[9 - Un miroir coach - Eva Indep]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[9 - Agile Games France - Eva Indep]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[9 - Eva rejoint Nord Agile - Indep]]
Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprès d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[9 - Un miroir coach - Eva Indep]]
#Eva se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel elle a une grande marge d'amélioration : [[9 - Le craftsmanship - Eva Indep]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - Eva]]
Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d’après les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[9 - Le WSJF - Eva Indep]]
#Eva propose à VP de travailler d'abord à la [[9 - Valeur Business Client - Eva Indep]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[9 - Shape Up - Eva Indep]] Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]] Comme elle a participé à un meetup, Eva reçoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ça chez les Ch'tis).
Elle se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ça lui rappelle quelque chose.
Elle apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Elle découvre avec plaisir que des rétrospectives sont organisées après chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents la passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ça te dirait de devenir membre?
Elle demande plus de précision, c'est quoi être membre? Elle obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Elle s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais elle promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
Après cette pub mal déguisée, où souhaitons nous emmener Eva?
#Eva goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[Eva se passionne pour le Serious Gaming - Indep]]
#C'est bien beau de parler de Nord Agile, mais un client d'Eva lui demande d'organiser un séminaire pour parler produit avec ses équipes. Ça sort un peu de sa zone de confort mais Eva se lance. [[Eva organise un séminaire produit - Indep]]
#Eva veut en voir toujours plus au niveau des communautés. Elle s'inscrit à l’[[Agile Games France - Eva Indep]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre développement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-développement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par exemple, pose quelques soucis à l'équipe.
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - Eva Indep]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à un client. [[Accelerate chez un client - Eva Indep]]
#Un des freins au pure Craftsmanship souvent rencontré par Eva, semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelque chose. [[DevOps - Eva Indep]]
#Un développeur pose une question ouverte lors d'une rétrospective : est-ce que ça vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - Eva Indep]]<img src="https://picsum.photos/200/300?random=1"/>Pour Eva, son équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modification (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une après midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
<<if setup.steps lt 12>>
Les conclusions de l'atelier sont sans appel : dans le contexte actuel faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#Eva accompagne son client dans la création d'une démarche maison. [[Une méthode maison pour son client - Eva Indep]]
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une [[Sensibilisation agile des PP - Eva Indep]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes client (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ca, [[Eva se passionne pour le Serious Gaming - Indep]]
<<else>>
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux me direz vous?
Eva s'attaque au sujet via 2 pans: l'équipe et le contexte.
Elle propose aux parties prenantes de l'équipe de leur faire une présentation de la démarche agile. Au travers de cette présentation, elle espère leur faire comprendre que chacun des points du fonctionnement de l'équipe a pour unique but de créer de la valeur (ou d'aider à cette création).
En parallèle elle propose à l'équipe de modifier leur fonctionnement. Au départ en gardant un process proche de Scrum (certains diront ScrumBan) puis au fur et à mesure de ses découvertes sur les alternatives à Scrum de continuer à faire de l'amélioration continue en format Kaizen.
D'un point de vue personnel, Eva s’intéresse de prêt aux serious games. Elle décide de rejoindre la communauté locale lors d'un meetup organisé par Nord Agile... le reste elle l'écrira elle même.
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à Eva. Après s'être renseigné sur gunther-le-jeu.fr, elle a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
Eva est conquise.
<<if setup.steps lt 12>>
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]]
<<else>>
Après avoir découvert Gunther, et c'est du lourd, elle s’intéresse au serious gaming encore plus. Elle finit par en faire sa spécialité. Elle aimerait pouvoir, un jour, en créer un pour un client. Peut-être aura-t-elle la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]]
<</if>>Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bonne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
Eva trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais Eva est persuadée qu'elle pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-elle l'atelier "Roule ta bille" ;)
<<if setup.steps lt 12>>
Eva a exploré le DevOps, elle fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
Eva profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
<<if setup.steps lt 12>>
Eva a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Elle tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[Eva rejoint Nord Agile - Indep]]
#Eva est contactée par un cabinet d'architectes pour les aider à être agile? [[Agile Hors IT - Eva]]
#Eva rencontre un client pour travailler dans l'infra. [[Agile dans l'Infra? - Eva]]
<<else>>
Maintenant, Eva réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Elle pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ça n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Après avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez le client (au moins pour les équipes accompagnées par Eva) quelle pourrait-être la prochaine étape pour notre héroïne?
#Eva doit maintenant accompagner un nouveau Scrum Master, elle doit lui expliquer la notion de [[Production VS Servant Leadership - Eva Indep]]
#Eva décide d'explorer encore un nouveau sujet. [[Shape Up - Eva Indep]]
Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ça n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Après avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez le client (au moins pour les équipes accompagnées par Eva) quelle pourrait-être la prochaine étape pour notre héroïne?
#Eva doit maintenant accompagner un nouveau Scrum Master, elle doit lui expliquer la notion de [[9 - Production VS Servant Leadership - Eva Indep]]
#Eva décide d'explorer encore un nouveau sujet. [[9 - Shape Up - Eva Indep]]
C'est une notion difficile la valeur business!! Comment comparer la création de valeur d'un nouveau produit vs l'ajout de fonctionnalités sur une application existante?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet chez le client d'Eva, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
Eva a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga Excel que lui seul sait lire (même si tout le monde y a accès, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
Eva est perplexe...
Elle lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais elle n'est pas satisfaite de la matrice.
Quelle solution propose-t-elle à Yvan?
#Et si on essaye de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt - Eva Indep]]?
#Eva se renseigne encore un peu et tombe sur la notion de WiSJiF. Elle lui propose de se lancer [[9 - Le WSJF - Eva Indep]]
#Eva abandonne ce sujet et préfère se concentrer sur un autre sujet auprès du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - Eva Indep]] Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
Eva a compris le principe de servant leader, elle essaye d'être dans ce mode à 100%, en laissant l'équipe s'auto-organiser, mais elle passe rapidement tout de même en mode scrum mom, surtout lorsqu'elle comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors d'elle).
De fait, elle est monopolisée par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'elle prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure d'Eva?
#Eva se rend compte du souci d'engagement et travaille sur ce sujet [[9 - Des problèmes d'engagement - Eva Scrum Master Indep]]
#Eva se dit qu'il faut retourner aux bases et propose d'organiser [[Une présentation de la démarche agile à l'équipe - Eva Indep]]
#Eva se dit qu'elle a besoin de confronter son expérience à celle d'autres personnes. [[9 - Eva participe à son premier Agi'Lille entant qu'Indep]] C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Eva a l'impression que la partie test de l'application pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé, Eva est persuadée que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. [[Scrum Master et QA - Eva Indep]]
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - Eva Indep]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - Eva Indep]]Se former au test, quelle drôle d'idée? Pas vraiment pour Eva, ni pour le Scrum Master qu’elle a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ça va faire bien sur son CV!!
Eva a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
<<if setup.steps lt 12>>
#Le test c'est super, mais Eva a l'impression que le monde agile n'est pas trop versé à ce langage. Elle décide d'aller voir ce qu'en dit la communauté. [[Eva participe à son premier Agi'Lille - Indep]]
#Eva se lance dans la mise en place des [[Les 3 amigos - Eva Indep]]
#Le test géré, Eva s’intéresse à [[La dette technique et Scrum - Eva Indep]]
<<else>>
Le Scrum Master parle à Eva des 3 Amigos...
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu’elle doit en parler autour d'elle et la mettre en action.
[[Conclusion]]
<</if>>Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
<<if setup.steps lt 12>>
Eva se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-elle?
#Elle discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - Eva Indep]].
#Elle se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Elle décide donc, unilatéralement, de mettre en place [[Un refinement revisité - Eva Indep]].
#Les 3 amigos on connait! Maintenant, que fait Eva? [[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
Eva se dit que cette pratique est formidable et qu’elle doit en parler autour de lui et la mettre en action.
Dans l'équipe accompagnée par Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, le Scrum Master et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec elle durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le raisonnement du Scrum Master est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez son client, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! Eva et le Scrum Master devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#Eva décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - Eva Indep]]
#Eva et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais[[Ca peut vraiment être efficace? - Eva Indep]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, Eva se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>>Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre développement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-développement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par exemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - Eva Indep]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à un client. [[Accelerate chez un client - Eva Indep]]
#Un des freins au pure Craftsmanship souvent rencontré par Eva, semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[DevOps - Eva Indep]]
#Un développeur pose une question ouverte lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - Eva Indep]]
<<else>>
* Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum.
* Elle lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à son client.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelque chose. Elle va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva s'inquiète également.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ça engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF. [[Le WSJF - Eva Indep]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[Sensibilisation agile des PP - Eva Indep]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son client, [[Eva organise un séminaire produit - Indep]] Eva tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
Eva utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, Eva leur fait un topo complet, avec schéma et tout...
#Eva semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. Eva propose une [[Sensibilisation agile des PP - Eva Indep]]
#Pour aller encore plus loin sur le sujet de la production de valeur, Eva aimerait pouvoir explorer le No Estimate dont elle a entendu parler sur un forum. [[Eva se passionne pour le No Estimate - Indep]]
#Eva se dit qu'elle pourrait aussi creuser [[Shape Up - Eva Indep]] Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été reçue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est que Scrum Master!
Qu'à cela ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour LudiGames.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[8 - Eva continue avec son équipe Scrum - LudiGames]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant [[8 - Valeur Business LudiGames]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision LudiGames. [[8 - Les experts de la vision - LudiGames]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Eva a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon Eva) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint Eva entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors Eva manque d'abandonner ce sujet plusieurs fois. Puis, un lundi elle arrive avec une nouvelle perspective.
Quelle est cette dernière?
#Elle ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant elle n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[8 - Gérer le run en Scrum - LudiGames]]
#Eva décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[8 - Le WSJF - LudiGames]]
#Après tout ça, Eva décide de passer Indep! [[8 - Eva micro-entrepreneuse]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
Eva s'en rend vite compte. D'abord, il faut faire comprendre le concept à l'équipe (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
Eva se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec l'équipe.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, elle a le choix.
Elle décide d'utiliser le DTC, on va pas se mentir, parce que le nom l'a fait sourire et qu'elle sait qu'il aura le même effet avec l'équipe.
L'atelier est un succès, l'équipe a tout compris!
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Après 3 sprints Eva s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Elle se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
Elle lui en parle. Elle se rend compte que pour le PO c'est super compliqué, malgré sa compréhension des besoins DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
Eva continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez LudiGames. [[9 - Valeur Business - LudiGames]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[9 - La dette technique en temps réel - LudiGames]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[9 - Prouver l'impact de la dette technique - LudiGames]]Pour Eva, l'équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que l'équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modification (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une après midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#Eva accompagne son client dans la création d'une démarche maison. [[9 - Une méthode maison pour LudiGames]]
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une [[9 - Sensibilisation agile des PP - LudiGames]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes client (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ça, [[9 - Eva se passionne pour le Serious Gaming - LudiGames]] Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[Le craftsmanship - LudiGames]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[Le WSJF - LudiGames]]
#Un manager vient voir Eva avec la fameuse rengaine : [[L'agile ca coûte cher! - LudiGames]]Eva en est persuadée. Le seul moyen de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Elle fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Elle se rend compte qu'elle a le choix entre 4 manières principales de faire cette sensibilisation.
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de LudiGame. Eva doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - LudiGames]]
#Eva a envie de proposer elle même une formation aux parties prenantes. Après tout, elle connait son sujet vu qu'elle l'a beaucoup potassé en ligne! Elle décide donc de proposer à son manager cette alternative. Celui-ci accepte et Eva se lance! [[Une formation agile - LudiGames]]
#Un ami d'Eva lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[Eva participe à son premier Agi'Lille - LudiGames]]Comme beaucoup de personnes, les membres de l'équipe d'Eva appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne d'Eva lui propose d'explorer le kanaban, elle ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, elle ne voit pas de quoi il parle.
Après quelques recherches, elle trouve quelques renseignements complémentaires. Elle comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Elle se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l’intéressent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#Eva devrait explorer l'atelier [[Kanbanzine - LudiGames]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - LudiGames]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - LudiGames]].Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - LudiGames]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Le manager d'Eva lui demande comment faire pour [[Créer une nouvelle équipe Scrum - LudiGames]].Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
<<if setup.steps lt 12>>
Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[Eva découvre les meetups et Nord Agile - LudiGames]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[Eva organise un séminaire produit - LudiGames]]
<<else>>
* Il va lui falloir évangéliser toutes les parties prenantes à la démarche agile.
* Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un Meetup produit.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Après quelques négociations, Eva organise un séminaire produit.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ça engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF. [[9 - Le WSJF - LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[9 - Sensibilisation agile des PP - LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son management, [[9 - Eva organise un séminaire produit - LudiGames]] Durant ses différentes recherches, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais Eva sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu’elle ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu’elle arrive dans un nouveau contexte, même si c'est pour une équipe ou un domaine qu’elle connait déjà, elle revalide son glossaire et s'assure qu'au travers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquemment, de ces temps-ci, touchée par le [[9 - Syndrôme de l'imposteur - LudiGames]]
#Eva échange avec plusieurs équipes ces derniers temps et elle aime à explorer avec elles [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva pourrait se lancer tout seul [[Eva micro-entrepreneuse]] Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, apaisé parfois, sur les situations rencontrées pas l'autre.
Eva choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Eva a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où elle hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
Eva a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Elle est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - Eva]]
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - Eva organise un séminaire produit - Indep]] Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troublée... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[9 - Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Un manager client lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[9 - Eva organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva décide de se lancer dans l’[[9 - Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[9 - Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - Eva organise un séminaire produit - Indep]]
Eva est contactée par une de ces connaissances Linked In : Anna Putroltan.
Anna travaille avec un gros cabinet d'architectes. Celui-ci aimerait améliorer sa manière de créer de la valeur avec les clients car ils se trouvent inefficaces et ses membres souhaiteraient travailler avec Eva afin de regarder à leurs process de manière différente.
Eva propose à Anna un premier rendez-vous et ils s'accordent sur le fait qu'Eva peut les accompagner mais que ça ne sera pas une grosse intervention, plutôt de petites interventions.
La première session, Eva rencontre les différentes personnes du cabinet, en se concentrant sur les personnes en relation directe avec les clients.
Au bout de quelques réunions, Eva sent que quelque chose peut-être fait, non seulement d'un point de vue administratif (mais ce n'est pas vraiment sa mission), mais aussi d'un point de vue des architectes directement.
Elle rédige un rapport d'étonnement et propose d'organiser un séminaire avec les architectes pour travailler sur une manière "agile" d'aborder les plans.
Eva passe plusieurs heures à préparer son intervention, mais elle est satisfait de son plan de journée. Tout commence par un ice breaker avec des Kapla (ben oui, on est avec des architectes) puis elle continue sur différents ateliers de partage en utilisant autant de matériaux différents possibles (Lego, papier, carton, cartes...)
A la fin du séminaire, les architectes sont tombés d'accord sur la suite à donner à leur approche agile :
* Ils ont à leur disposition un grand nombre de plans "types" pour les maisons individuelles.
* A partir de ces plans types, ils vont identifier des cartes de "personnalisation".
* Lorsqu'un client leur demandera de faire le plan d'une maison, ils appliqueront la démarche suivante
** Identifier le plan type applicable au client
** Valider le budget du client sur la partie architecture et personnalisation
** Proposer au client de classer les cartes de personnalisation (Salle à manger, Salle de bain, Chambre, Jardin..) en fonction de ses priorités / valeurs.
** Travailler aux personnalisation de manière itérative en fonction du budget. Si le client est satisfait d'une personnalisation et que le budget le permet, on passe à la suivante.
** Une fois le budget terminé, le client a le choix de prendre les pièces type non personnalisées ou d'ajouter du budget s'il le souhaite...
C'est un vrai succès. Non seulement les clients (particuliers) sont ravis, mais les architectes génèrent plus de satisfaction dans leurs interactions avec les clients.
Quelle est la suite des aventures d'Eva?
#Elle est contacté via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]] Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top? [[9 - Le craftsmanship - LudiGames]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[9 - Le principe de l'amélioration continue face au chaos - LudiGames]]
#Le manager d'Eva lui demande comment faire pour [[9 - Créer une nouvelle équipe Scrum - LudiGames]].Pour Eva, le terme Devops est un peu obscure. De prim abord, elle pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Elle est trés étonnée lorsqu'elle apprend que ce n'est pas ca.
En résumé, elle comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Elle interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
Eva n'est pas sur qu'elle est tout à fait d'accord avec son affirmation.
Elle se renseigne sur les outils qu'elle a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
Elle liste quelques outils interessants :
#Elle pourrait demander à TechSys de venir lui présenter [[9 - Gunther - LudiGames]]
#Elle apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[9 - Casino Game - LudiGames]]
#Elle se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[9 - Lego, Scrum et Chocolat pour le DevOps - LudiGames]]
#Bon, assez de Scrum Mastering, elle fait quoi ensuite Eva? [[9 - Fast Track Scrum Master - Eva]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ça n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Après avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[9 - Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[9 - Shape Up - RDB]]
#James est suffisamment aguéri maintenant pour se lancer tout seul [[James micro-entrepreneur]] Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Après quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l’intéressent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[9 - Kanbanzine - RDB]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[9 - Une formation avec Laurent Morisseau - RDB]]?
#Quelque soit la manière, il réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[9 - Le Kanban ca marche, mais ca prend du temps! - RDB]].James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit des Rois du Ballon.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ça n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décallage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ca?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. James se pose alors la question de comment [[9 - Dégager des actions d'un séminaire - RDB]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut [[9 - Faire vivre les actions aprés un séminaire - RDB]]!
#La conclusion de leur séminaire est qu'il leur faut [[9 - Une méthode maison pour RDB]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[9 - L'agile ca coûte cher! - RDB]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour VP.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[9 - James continue avec son équipe Scrum - RDB]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant [[9 - Valeur Business - RDB]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision RDB. [[9 - Les experts de la vision - RDB]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
James a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ca ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint James entend :
* Bon, là ca va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[9 - Valeur Business - RDB]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[9 - Gérer le run en Scrum - RDB]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[9 - Le WSJF chez RDB]]
#On sait comment ca va finir (ou on a pas envie de savoir), fini le boulot de Scrum Master! [[9 - Fast Track Scrum Master - James]] Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - RDB]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à RDB mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[La démarche produit - RDB]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#James explore le Kanban car il a entendu que le terme FastLane vient de là. [[Kanban - RDB]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - James Indep]]
#James se lance en freelance et se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - James]]
#James commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[James se lance dans l'écriture d'une conférence - RDB]]
Entant que Scrum Master, James se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ca tombe bien, James aime aussi la technique!! Il décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-il réellement être efficace dans ces deux missions?
Il continue à se poser des questions et cherche de nouveaux sujets.
#James se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur). [[Production VS Servant Leadership - RDB]]
#Dans le même temps, Il décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Il explore alors le [[Le craftsmanship - RDB]]
#James a la chance de trouver une place pour une formation sur le Kanban. [[Une formation avec Laurent Morisseau - RDB]] James a fait pas mal de recherches pour proposer à son management un organisme qui leur permette d'avancer vers une vision d'entreprise.
Aprés plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et Vertes Prairies.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur VP.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que VP entant que tel n'est que trés peu visible sur le net, ses créations un peu moins, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de l'entreprise et de ses créations sur la toile.
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - RDB]]
#Un ami de la femme de l'ex docteur du président de VP a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - RDB]]
#Son initiative est ignorée et James le prend mal. Il ne lui en fallait pas plus pour le pousser vers l'indépendance [[James micro-entrepreneur]] Pas facile de transformer une vision en action.
Mais il a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être James les animera-t-il en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. James en parle à son manager qui devra faire son choix.
[[Conclusion]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ça engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
James propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[9 - Le WSJF chez RDB]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[9 - Sensibilisation agile des PP - RDB]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son management, [[9 - James organise un séminaire produit - RDB]] James en est persuadé. Le seul moyen pour son client de réussir leur transformation est de faire en sorte que les personnes qui collaborent avec les équipes (les parties prenantes), soient toutes au fait de ce qu'est la démarche agile et de ce que ça induit pour elles et pour les équipes.
Il fait donc quelques recherches sur les différentes méthodes à sa disposition pour "Evangéliser" cette démarche.
Il se rend compte qu'il a le choix entre :
#La formation par un intervenant externe permet au discours d'être apporté au travers d'expériences et manipulations décorellées de la réalité de Vertes Prairies. James doit négocier le déblocage de budget de formation auprès de son manager. Ça n'est pas facile mais c'est finalement validé [[Une formation externe pour les parties prenantes - RDB]]
#James a envie de proposer lui même une formation aux parties prenantes. Après tout, il connait son sujet vu qu'il l'a beaucoup potassé en ligne! Il décide donc de proposer à son manager cette alternative. Celui-ci accepte et James se lance! [[Une formation agile - RDB]]
#Un ami de James lui suggère de se voir ce qui se passe du côté de l'événement agile lillois. [[James participe à son premier Agi'Lille - RDB]]
James met du temps à comprendre ce qui arrive à l'équipe.
James tente d'appliquer tous les principes du guide :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Il se souvient avoir lu quelquepart la notion de ShuHaRi et se dit que son client doit encore être au stade Shu de son évolution Scrum / Agile et qu'il devrait peut-être laisser un peu de temps au framework pour faire son effet.
Mais applique-t-il correctement ce principe de montée en compétence?
Certains diront: "Bien sur, il faut attendre que l'équipe maitrise Scrum avant de commencer à réfléchir à d'autres moyens d'être efficaces."
D'autre vous diront que James devrait regarder plutôt l'aspect ShuHaRi sur chaque pratique car l'appliquer à tout Scrum pourrait être comparé à tomber dans le CargoCult pour Scrum
Lorsque James retravaille avec le client et se rend compte que le contexte n'est pas 100% compatible avec Scrum et ils décident de mettre en place leur propre manière d'être agile.
De quelle pratique vont-ils s'inspirer?
#[[9 - Kanban - RDB]]
#[[9 - Shape Up - RDB]]
#[[9 - DevOps et RDB]]
Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour RDB.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[9 - James continue avec son équipe Scrum - RDB]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[9 - Valeur Business - RDB]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision Vertes Prairies. [[9 - Les experts de la vision - RDB]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
Le Scrum Master que James accompagne a pourtant essayer beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est pourtant correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint le Scrum Master entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors il manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il discuter avec James qui lui propose de nouvelles perspectives :
#James a l'impression que la partie test de l'application pose soucis. Non seulement le testeur de l'entreprise n'est pas toujours dispo et cause du retard mais comme il est surchargé James est persuadé que beaucoup d'anomalies arrivent en production alors qu'elles pourraient être évitées. [[9 - Scrum Master et QA - RDB]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[9 - Gérer le run en Scrum - RDB]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. [[9 - Le WSJF - RDB]]
Quand on regarde la manière dont son client gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - RDB]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - RDB]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - RDB]]Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ça n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* James n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Après avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - RDB]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - RDB]]
#James est suffisamment aguerri maintenant pour se lancer tout seul [[James micro-entrepreneur]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
<<if setup.steps lt 12>>
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - James Indep]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - James Indep]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille entant qu'Indep]]
<<else>>
Dans l'équipe accompagnée par James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, le Scrum Master et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec elle durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inéfficace d'un point de vue rapidité de déploiement. Cependant, ca porte ses fruits au niveau qualitatif et ca rend le système relativement pévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Aprés plusieurs mois (ben oui, l'industrie ca réagit pas trés vite) dans ce système, James se dit quand même qu'il faudrait regarder d'autres choses...
<<if setup.steps lt 12>>
#Comme il a entendu parler du [[Kanban - James Indep]], James se pose la question de savoir si ca ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[James participe à son premier Agi'Lille entant qu'Indep]]
#James commence a engranger de l'expérience, et les gens semblent apprécier l'écouter en parler [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>>Quand on regarde la manière dont RDB gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#James propose au Scrum Master de suivre une formation ISTQB. [[9 - Formation ISTQB SM - RDB]]
#James propose la mise en place des 3 amigos [[9 - Les 3 amigos - RDB]]
#Le Scrum Master propose la mise en place d’[[9 - Un déversement de backlog - RDB]]Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[9 - Prioriser en tailles de TShirt - RDB]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[9 - Le WSJF - RDB]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[9 - Le craftsmanship - RDB]]
#James propose à l'équipe d'explorer le [[9 - Kanban - RDB]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ça engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF chez RDB]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - RDB]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son management, [[James organise un séminaire produit - RDB]] Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Après quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l’intéressent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - RDB]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - RDB]]?
#Quelque soit la manière, il réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - RDB]].Se former au test, quelle drôle d'idée? Pas vraiment pour James, ni pour le Scrum Master qu'il a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ca va faire bien sur son CV!!
James a hâte de l'aider à mettre tout ca en pratique. Mais que font-ils une fois cette certification en poche?
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[James participe à son premier Agi'Lille - RDB]]
#Avec le Scrum Master, James se lance dans la mise en place des [[Les 3 amigos - RDB]]
#Le test géré, James s'interesse à [[La dette technique et Scrum - RDB]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - RDB]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - RDB]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille - RDB]]
Le raisonnement du Scrum Master est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez son client, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et le Scrum Master devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - RDB]]
#James et le Scrum Master montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprés du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - RDB]]
#James en a marre de la vie d'entreprise, il se lance seul [[James micro-entrepreneur]]
James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Il passe indep et se lance dans l'[[9 - Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[9 - James se passionne pour le Serious Gaming - RDB]]
#Un manager RDB lui demande d'organiser un séminaire pour définir une démarche agile commune. [[9 - James organise un séminaire produit - RDB]] Un premier événement agile c'est toujours une expérience!! Surtout quand il s'agit d'un forum ouvert.
Ce type de rencontre agile est interessant :
* les participants ne savent pas à l'avance le contenu de l'événement.
* l'organisation est libre
* ce qu'il se passe dans le forum est ce qu'il doit se passer
* au sortir de l'événement, les agilistes sont généralement ravi de ce qui se passe.
James n'est en effet pas déçu. Au début, il s'est sentie un peu perdu dans cet événement non organisé. Il ne savait pas par où commencer. Puis, grâce à la facilitation de quelques participants des éditions précédentes et à l'esprit agile des participants, les sujets passionnants se développent.
James participe à plusieurs échanges. Pour commencer, un coach expérimenté propose de réfléchir à la suite de l'agilité, ensuite une autre personne se demande si on peut être agile sans Scrum Master et PO, puis il teste un outil créé par un groupe de collègues autour de la gestion de la dette technique.
Durant ce rendez-vous agile, James échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ce premier événement James a plusieurs possibilités devant lui:
#En discutant avec plusieurs participants, James a découvert le mouvement Agnostic Agile et se demande si il ne peut pas s'en inspirer avec son équipe [[9 - Agnostic Agile - L'agilité DoctoChat]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - DoctoChat]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille. [[9 - James participe à son premier Agi'Lille - DoctoChat]]James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit DoctoChat.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ça n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décalage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - DoctoChat]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut [[Faire vivre les actions aprés un séminaire - DoctoChat]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour DoctoChat]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - DoctoChat]]Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
James propose donc à son équipe un petit atelier de retour aux sources. Il choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. James a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de DoctoChat et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[Kanban - DoctoChat]]
#Au final, Scrum reste une proposition interessante, il leur faudra s'adapter aux contraintes mais ils décident d'essayer de rentrer dans le cadre. [[DoctoChat et Scrum]]
#James avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[Shape Up - DoctoChat]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[Une méthode maison pour DoctoChat]]
<img src="https://picsum.photos/200/300?random=1"/>Rentrer dans un cadre, quand on est une StartUp, ça pourrait paraître antinomique.
Et pourtant, c'est ce à quoi s'attèle James.
Revenir aux bases, expliquer pourquoi Scrum. Le fait qu'une équipe c'est comme une mêlée au rugby...
Revenir aux bases, reposer le cadre. Des sprints de 2 semaines, des rituels toujours à la même heure, au même moment du sprint.
Faire du lean même : éliminer le superflu (notamment toutes ces réunions qui ne produisent pas de valeur). Revoir le tableau scrum, enlever ces étapes dictées par leur outil de ticketting. Ajuster le process dans l'outil de ticketting pour qu'il s'adapte à Scrum (et pas l'inverse).
Puis retravailler l'empirisme. Travailler aux bons indicateurs (burn up, burn down). Utiliser les données pour aider l'équipe à s'engager. Challenger l'équipe sur son engagement (vers le haut ou vers le bas). Faire en sorte qu'ils se synchronisent correctement en vue de la tenue de cet engagement.
Retourner aux bases... de Scrum.
Au final, James dépense énormément d'énergie pour ce retour dans le cadre. L'équipe est souvent frustrée de devoir se conformer à un cadre... "Scrum c'est pas flexible" s'entend-t-il critiquée parfois... Scrum c'est pas flexible... Scrum c'est pas agile?
Mais il tient bon...
<<if setup.steps lt 12>>
#Et le résultat est à la hauteur de l'investissement de James et des frustrations de l'équipe. [[Scrum ca marche pour DoctoChat]]
#L'équipe a beau être rentrée dans le cadre, rien n'y fait, ils continuent à ne pas livrer l'attendu. [[Des problèmes d'engagement chez DoctoChat]]
#Rentrer dans le cadre oui, mais pour combien de temps? Doit-on y rester longtemps? James explore [[Le ShuHaRi appliqué à Scrum - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James choisi une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de DoctoChat.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour VP. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - DoctoChat]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer DoctoChat dans le bon sens. [[James organise un séminaire produit - DoctoChat]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation - DoctoChat]]
#James se lance tout seul. [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour James c'est sa première formation.
James passe du temps à préparer un plan, puis il le jette à la corbeille quand il commence à compiler ses slides et qu'il essaye de raconter une histoire cohérente.
Il commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Il promet de mettre à jour son cursus pour la prochaine session.
Il a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'il souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de DoctoChat.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour DoctoChat. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - DoctoChat]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer DoctoChat dans le bon sens. [[James organise un séminaire produit - DoctoChat]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation - DoctoChat]]
#Avec cette expérience complémentaire en poche, James passe indépendant. [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>>Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!! James n'est pas déçue!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadée qu'[[On ne devient pas coach tout seul - DoctoChat]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - DoctoChat]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
James va ensuite poursuivre avec :
* Le Kanban car il a entendu que le terme FastLane vient de là.
* Le Craftsmanship car pour garantir un run constant, rien de tel que l'excellence technique ;)
[[Conclusion]]
Quand on regarde la manière dont DoctoChat gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]] C'est une notion difficile la valeur business, surtout chez DoctoChgat!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga Excel que lui seul sait lire (même si tout le monde y a accès, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes il réussi à lui faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
<<if setup.steps lt 12>>
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - DoctoChat]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - DoctoChat]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprès du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - DoctoChat]]
<<else>>
James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer.
[[Conclusion]]
<</if>>
James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de rétrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelque part et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parce qu'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le teste avec quelques volontaires un midi sur l'heure du repas. Il voit comment ça fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - DoctoChat]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - DoctoChat]]
#James a pris goût aux outils gamifiés, il se lance dans [[Kanbanzine - DoctoChat]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent si il est légitime. [[Syndrôme de l'imposteur - DoctoChat]]
<<else>>
* Afin de faire évoluer ses accompagnements, James se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* James a pris goût aux outils gamifiés, il se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent s'il est légitime. Il est touché par le syndrome de l'imposteur.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idées, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - DoctoChat]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James intéresse les participants à tous les événements auxquels il assiste.[[James se lance dans l'écriture d'une conférence - DoctoChat]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - DoctoChat]]
<<else>>
Il revient régulièrement sur les deux meetups, s’intéresse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et il se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Après quelques événements, il développe l'envie de rendre à la communauté à hauteur de ce qu'il y a récupéré depuis quelques mois. Il commence à rédiger une conférence. Peut-être le croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre développement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-développement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
* James explore les différentes possibilités de gestion de la dette technique, tout en essayant de comprendre la compatibilité, ou pas avec le cadre Scrum.
* James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à DoctoChat.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadée qu'il faut y changer quelque chose. James va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? James s'inquiète également.
[[Conclusion]] James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez DoctoChat. Il lui propose de mettre à plat le workflow de création de valeur chez DoctoChat.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez DoctoChat ils ne le font pas).
<<if setup.steps lt 12>>
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[DevOps - DoctoChat]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - DoctoChat]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[Kanban - DoctoChat]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
James attaque le sujet sur plusieurs flancs :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le devOps avec son équipe préférée.
* James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ça fonctionne à l'échelle d'une équipe. Il lance donc une expérimentation WSJF avec son PO.
* James comprend que c'est un changement de culture important, il se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]]
<</if>>Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent entant que coach, les équipes attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
<<if setup.steps lt 12>>
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - DoctoChat]]
#James propose de travailler à la [[Valeur Business - DoctoChat]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[On ne devient pas coach tout seul - DoctoChat]]
<<else>>
Il a mis en place un miroir coach, qui l'aide beaucoup, et il reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Une des choses qui l'aide beaucoup c'est sa relation de miroir coach avec Yulie!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a fait pas mal de recherches pour proposer à son client un organisme qui leur permette d'avancer vers une vision d'entreprise.
Après plusieurs démarchages, il fini par organiser un rendez-vous entre les experts et DoctoChat.
Comme tous bons experts, la société en question (VisionMaster), a fait des recherches sur DoctoChat.
Ils arrivent en entretien avec le résultat de ces dernières. Il s'avère que DoctoChat entant que tel ne sont que très peu visibles sur le net, leurs créations un peu plus, mais la vision même de l'entreprise est illisible de l'extérieur. VisionMaster se propose de lancer un chantier orienté sur 2 axes: La vision de l'entreprise par ses collaborateurs et dirigeants et la visibilité de DoctoChat et de ses créations sur la toile.
<<if setup.steps lt 12>>
Comment réagit le management?
#Impressionnés par le travail et l'engagement de James, ils lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise. [[James pilote de vision - DoctoChat]]
#Un ami de la femme de l'ex docteur du président de DoctoChat a aussi une société d'accompagnement d'entreprise, cette dernière va intervenir à la place de VisionMaster. Ce dernier est assez sec avec James et lui dit qu'avant de se méler des sujets de gouvernance de l'entreprise, il vaudrait mieux qu'il applique Scrum à la lettre avec ses équipe car il ne lui semble pas que toutes les promesses agiles soient répondues [[Le ShuHaRi appliqué à Scrum - DoctoChat]]
<<else>>
Impressionnés par le travail et l'engagement de James, le management lui proposent de piloter le projet vision (en plus de son métier normal, il va sans dire) et d'être le contact/relais direct de VisionMaster au sein de l'entreprise.
Plutôt fière de sa nouvelle mission, James a une première réunion avec David, l'expert de chez VisionMaster affecté sur le dossier.
Ce dernier propose a James de commencer par identifier les différents acteurs au sein du client qui participerons aux différents ateliers vision.
James identifie une vingtaine de personnes, de la direction au développeur.
David organise ensuite un séminaire "au vert", de deux jours, avec le groupe vision.
Au programme du séminaire :
* Premier jour:
** Matin, visite d'une entreprise de fabrication de yaourts, rencontre avec les dirigeants et discussion autour de leur vision.
** Midi, déjeuner gastronomique et session de travail autour de l'expérience "Yaourt" pour commencer à définir ce qui correspond à une bonne vision
** Après midi, visite d'une micro-brasserie et rencontre avec le propriétaire pour qu'il parle de sa passion.
** After work, apéro dinatoire et jeux d'arcade
* Second jour:
** Matin, retour sur la vision idéale et comparaison vision / passion, puis premier workshop sur la vision LudiGames (prisme individuel)
** Midi, déjeuner local et visite d'une salon de thé "hors du commun"
** Après midi, second workshop vision (prisme équipe et direction) puis rédaction de propositions de vision
** After work, soirée disco
Après ce séminaire, David prévoit d'organiser une soirée restit avec l'ensemble des collaborateurs puis d'exposer dans les locaux les différentes visions et de faire un vote en ligne pour valider la vision commune.
Charge après à James de porter cette vision au sein de l'entreprise. La partie visibilité du client vers l'extérieur sera traitée dans un second temps.
James est Emballé par le programme, après tout David est un expert, il doit savoir ce qu'il fait, James le suit sur le projet.
[[Conclusion]]
<</if>>James semble tout indiquée pour accompagner DoctoChat sur sa prochaine étape agile.
Le management a de grandes ambitions pour la suite de sa transformation et semble tout faire reposer sur les épaules de James.
La première chose à laquelle James doit s'atteler c'est de trouver un nouveau Scrum Master pour le remplacer. Puis, il devra accompagner la création d'une nouvelle équipe agile. Il devra également trouver comment accompagner DoctoChat plus en amont dans sa démarche agile.
James va d'abord devoir explorer les différentes possibilités pour trouver quelqu'un pour le remplacer au mieux auprès de son équipe. Va-t-il proposer de prendre un Scrum Master externe, avec ou sans expérience? Ou va-t-il essayer de pousser pour faire monter quelqu'un de l'équipe actuelle au rôle de Scrum Master? Peut-être que le jeune Antoine, le stagiaire en alternance qui doit signer avec DoctoChat une fois son diplôme en poche, est-il le candidat idéal?
James va ensuite devoir accompagner la nouvelle équipe formée. En plus de proposer également un moyen d'identifier un Scrum Master, il sait que l'impact de la création d'une nouvelle équipe n'est pas à négliger. Va-t-il proposer de créer une toute nouvelle équipe, avec son propre backlog ou avec un backlog commun? Ou utilisera-t-il le principe de seeding en créant 2 équipes à partir de celle existante?
Entant que coach, il va aussi avoir plus de temps pour faire de la veille (enfin elle espère) et compte bien sur la communauté agile lilloise pour l'aider. Il participera entre autre à l'Agi'Lille et aux différents meetups qui sont à sa disposition sur Lille.
Pour fini, James devra aussi décider de comment accompagner DoctoChat dans son évolution agile. Voudra-t-il pousser pour une démarche agile maison? Poussera-t-il pour avancer sur la démarche produit?
[[Conclusion]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour VP.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
* C'est pourquoi James continue avec une équipe Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Il souhaite également travailler avec le PO afin de mettre en avant la Valeur Business VP.
* Il proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision DoctoChat.
[[Conclusion]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
Eva a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels elle pourrait s'améliorer:
#Eva propose à un client de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - Eva Indep]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business Client - Eva Indep]]
#Plusieurs personnes semblent intéressées par les récits d'Eva quant à son approche avec les équipes. Du coup, [[Eva se lance dans l'écriture d'une conférence - Indep]]Quand il s'agit de mettre en place des rétrospectives, Eva est maintenant rodée. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, elle arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand elle le peut, elle préfère amener des rétrospectives imagées, ludiques.. Mais elle commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, elle a exploré le SMART de font en comble. Elle en est arrivée à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ça fonctionne très bien comme ça.
De manière générales, Eva voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
A force, elle arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#Eva est devant une équipe dont le PO a de gros soucis de priorisation. Eva propose d'explorer [[Le WSJF - Eva Indep]]
#Eva travaille le craftsmanship avec une équipe relativement jeune [[Le craftsmanship - Eva Indep]]
#Une équipe au top de sa force est limitée par l'accés aux environnements de test et de production. Elle leur parle du [[DevOps - Eva Indep]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - Eva Indep]] Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
Eva le teste avec quelques volontaires un midi sur l'heure du repas. Elle voit comment ça fonctionne mais est frustrée de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'elle parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour Eva!
Elle pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, Eva se renseigne sur [[Le craftsmanship - Eva Indep]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - Eva Indep]]
#Eva a pris goût aux outils gamifiés, elle se lance dans[[Kanbanzine - Eva Indep]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais Eva se demande souvent si elle est légitime. [[Syndrôme de l'imposteur - Eva Indep]] Eva consulte les ressources qu’elle trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de rétrospective à sa disposition.
Les premiers exemples qu’Eva voudrait explorer :
* Scrum Health Check, il faut bien commencer quelque part et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parce qu'on vit pas au pays des bisounours
Eva déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait Eva?
#Eva se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#En recherchant des formats de rétrospectives, Eva est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[Eva découvre les meetups et Nord Agile entant qu’Indep]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - Eva Indep]]
#Eva se rend compte que [[Peu importe le format, seuls les résultats comptent - Eva Indep]] quand on parle de rétrospective.
Eva passant coach, il faut trouver un Scrum Master pour la remplacer auprès de l'équipe existante.
En réunion avec son manager elle hésite sur les préconisations qu'elle pourrait faire.
En effet, pour la remplacer LudiGames a le choix entre faire venir quelqu'un de nouveau, de l'extérieur, ou demander à quelqu'un déjà en place de prendre ce rôle.
Toute considération budgétaire mise à part, après tout LudiGames est capable d'embaucher de nouvelles personnes, Eva se pose la question du bien de l'équipe et du "produit".
Faire venir quelqu'un de l'extérieur aurait l'avantage d'amener un point de vue neuf sur l'équipe, surtout s'ils recrutent un Scrum Master ayant déjà un peu d'expérience.
Cependant, prendre quelqu'un d'expérience pourrait amener l'inconvénient qu'il tente de faire entre l'équipe dans un moule qu'il a déjà rencontré et Eva se demande si le risque n'est pas trop élevé.
Quid de prendre un externe nouvellement formé à Scrum? Cette personne pourrait grandir dans son expertise mais serait peut-être moins formatée par ses expériences précédentes. Certes, mais dans ce cas, quelle légitimité ce nouveau venu portera-t-il? Devant les anciens de l'équipe n'aura-t-il pas trop de difficulté à se faire entendre, à faire bouger les choses?
Eva est également tentée de proposer de faire monter quelqu'un de l'équipe en compétence Scrum Master afin que le rôle reste en interne. Elle entrevoit des difficultés potentielles, notamment dans le fait que chaque Dev de l'équipe est super impliqué dans la création de valeur et que ça risque d'être difficile pour l'un d'entre eux de se lancer dans le Scrum Mastering en délaissant un peu le développement.
Après plusieurs longues réunions, le management accepte la solution préconisée par Eva : faire monter quelqu'un de l'équipe sur le rôle de Scrum Master. Lorsqu’elle amène le sujet à l'équipe, personne ne se porte volontaire directement, Eva leur laisse le temps de réfléchir. 2 jours plus tard, c'est l'alternant de l'équipe (qui devrait être embauché à la fin de son année scolaire) qui se porte volontaire.
Eva est enchantée, elle cumule 2 de ses possibilités : Quelqu'un de l'équipe mais qui amène aussi du sang neuf.
Antoine s'avère être à la hauteur du challenge et James peut entamer sereinement sa nouvelle vie de coach.
Maintenant qu’elle est remplacée, Eva peut se consacrer à la suite :
#[[Eva organise un séminaire produit - LudiGames]]
#Afin de pouvoir faire changer les choses chez LudiGames, Eva proposer la mise en place d’ [[Un comité de transformation - LudiGames]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez LudiGames]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), Eva a plusieurs options pour se former.
Elle décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais Eva s'y retrouve. En effet, non seulement elle peut maintenant se lancer dans des accompagnements vraiment interessants, mais elle est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors Eva commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de LudiGames
Eva s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant Eva peut s'orienter où elle veut.
#Eva décide de se lancer dans l'[[Agile Hors IT - Eva]].
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un client d'Eva lui demande d'organiser un séminaire pour définir une démarche agile commune. [[Eva organise un séminaire produit - Indep]]
Eva se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
Eva a adoré l'atelier, elle en est ressortie toute troublée... Mais maintenant elle veut l'animer elle même! Alors elle se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, elle ira peut-être jusqu'à la fresque du numérique...
#Elle est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
#Eva a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait elle veut essayer de se prêter au jeu de la création [[Eva se passionne pour le Serious Gaming - Indep]]
#Un manager client lui demande d'organiser un séminaire pour définir une démarche agile commune à toutes les équipes de son domaine. [[Eva organise un séminaire produit - Indep]] Eva met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Elle tente d'appliquer les mêmes principes que ceux appliqués chez LudiGames:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu’elle est apparemment entré en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, elle décide de revoir sa copie. Quelle est la prochaine étape?
#[[Le management remet en question la capacité d'Eva à avancer seule - LudiGames]]
#Eva se rend compte qu'il faut absolument [[Accompagner le PO - LudiGames]]
#Eva entend parler de la communauté agile Lilloise et décide de participer à [[Son premier forum ouvert - LudiGames]]
#Avançons un peu dans le temps. [[Fast Track Scrum Master - Eva]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour Eva, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Elle propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
Eva propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
Eva se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire Eva?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. Eva lui propose d'expérimenter le WSJF. [[Le WSJF - LudiGames]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. Eva se propose d'organiser une [[Sensibilisation agile des PP - LudiGames]]
#Eva a grandement apprécié de travailler avec le PO, elle se dit qu'elle pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son management, [[Eva organise un séminaire produit - LudiGames]] Super, le client l'a entendue. Ils lancent un comité de transformation... en embauchant des externes...
Eva est surprise d'apprendre que son idée a été reçue mais qu'elle n'a pas été conviée à ce comité de transformation. Faut dire... elle n'est qu'externe
Qu'à cela ne tienne! Elle ne va pas se laisser faire ;)
Elle provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... Eva propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
Eva a l'impression d'entendre de beaux discours mais la seule chose qu'elle voulait entendre et qu'elle n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, elle comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si elle compte bien garder un oeil sur la suite, elle imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
Eva se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de son client, elle a tout intérêt a poser des bases solides.
#C'est pourquoi [[Eva continue avec son équipe Scrum - Indep]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Elle souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business Client - Eva Indep]]
#Elle propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision client. [[Les experts de la vision - Eva Indep]] Eva a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
Eva opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, elle demande un entretien avec le responsable des chefs de projets de son client. Elle lui propose de mettre à plat le workflow de création de valeur.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
Eva a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, elle a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez LudiGames il ne le font pas).
Que va faire Eva?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le [[DevOps - Eva Indep]]
#Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ça fonctionne à l'échelle d'une équipe. [[Le WSJF - Eva Indep]]
#Eva comprend que c'est un changement de culture important, elle se lance dans la démarche [[Kanban - Eva Indep]] en espérant prouver par l'exemple que le workflow actuel est saturé.Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et Eva n'y est pas immunisée. Plus elle avance dans ses apprentissages, plus elle apprend de choses, plus elle se rend compte de la quantité de choses qu'elle ne connait pas..
En plus, comme elle intervient souvent auprès d'autres équipes que la sienne, elles attendent souvent d'elle qu'elle ait les réponses à leurs questions et maux... mais Eva n'a elle même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais elle n'a pas la solution unique, ou même idéale...
Alors elle apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme elle ne produit pas elle même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, elle n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Elle a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'elle n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors elle se soigne. Elle a mis en place un miroir coach, qui l'aide beaucoup, et elle reste sur son positionnement de questionnement, histoire de ne pas être vu comme apporteur de vérité..
Que voulez-vous explorer maintenant?
#C'est quoi ce principe de miroir coach? [[Un miroir coach - Eva Indep]]
#Eva se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel elle a une grande marge d'amélioration : [[Le craftsmanship - Eva Indep]]
#Eva est contactée via Linked In par une de ses relations. Elle n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler d'elle. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - Eva]]
Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
Eva se propose d'étudier les points de concordance entre LudiGames et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - LudiGames]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[Le WSJF - LudiGames]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - LudiGames]]
#Eva propose à l'équipe d'explorer le [[Kanban - LudiGames]]Quand on regarde la manière dont LudiGames gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#Eva propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - LudiGames]]
#Eva propose la mise en place des 3 amigos [[Les 3 amigos - LudiGames]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - LudiGames]]Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
Eva se propose d'étudier les points de concordance entre l’équipe et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - Eva Indep]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[Le WSJF - Eva Indep]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - Eva Indep]]
#Eva propose à l'équipe d'explorer le [[Kanban - Eva Indep]]Eva a une jolie expérience avec son équipe. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[Eva participe à son premier Agi'Lille - LudiGames]]
Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, Eva arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
Eva découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
Eva est parée, elle se lance. Elle a plein de choix possibles pour se lancer.
#Elle décide de [[Gamifier une rétrospective - LudiGames]]
#Elle choisit un outil d'apprentissage qu’elle présente à son équipe. Ils testent [[Kanbanzine - LudiGames]]
#Elle choisit un outil d'apprentissage qu’elle présente à son équipe. Ils testent [[Scrumble - LudiGames]]
#Elle se dit qu’elle doit acquérir plus d'expérience et [[9 - Eva découvre les meetups et Nord Agile - LudiGames]]LudiGames a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
#James propose à Eva d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[Eva découvre les meetups et Nord Agile - LudiGames]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, James propose qu' [[Eva organise un séminaire produit - LudiGames]]Durant ses différentes recherches, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais Eva sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu’elle ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu’elle arrive dans un nouveau contexte, même si c'est pour une équipe ou un domaine qu’elle connait déjà, elle re-valide son glossaire et s'assure qu'au travers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquemment, de ces temps-ci, touchée par le [[Syndrôme de l'imposteur - LudiGames]]
#Eva échange avec plusieurs équipes ces derniers temps et elle aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva pourrait se lancer tout seul [[Eva micro-entrepreneuse]] Pas facile de transformer une vision en action.
Mais Eva a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être Eva les animera-t-elle en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. Eva en parle à son manager qui devra faire son choix.
Que voulez-vous voir ensuite?
#On a envie d'en s'avoir plus sur la [[Démarche OKR - LudiGames]]
#Le manager d’Eva lui demande d'animer un séminaire autour de la notion de produit. [[Eva organise un séminaire produit - LudiGames]]
#Une vision nouvelle, des actions qui animent cette vision, ça fait beaucoup de chaos tout ça non? [[Le principe de l'amélioration continue face au chaos - LudiGames]] <img src="https://picsum.photos/200/300?random=1"/>Le manager d'Eva lui propose un rendez-vous pour faire un petit état des lieux.
Eva déploie énormément d'efforts à tenter de faire évoluer son équipe et ses parties prenantes mais sans gros succès. Comment faire pour maximiser son retour sur investissement?
<<if setup.steps lt 12>>
Quelle décision prennent-ils?
#Eva doit impérativement faire de la veille de son coté, pour ce faire, LudiGames est OK pour lui payer sa participation à l'Agi'Lille [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva doit faire de la veille mais de son côté, elle découvre alors les [[Meetups de la communauté Lilloise - LudiGames]]
#Eva prend la mouche et se lance en indep [[Eva micro-entrepreneuse]]
<<else>>
* Eva doit impérativement faire de la veille de son coté, pour ce faire, LudiGames est OK pour lui payer sa participation à l'Agi'Lille.
* Eva doit également faire de la veille de son côté, elle découvre alors les meetups de la communauté Lilloise.
* Si tout ca ne fonctionne pas, ils tombent d'accord pour faire intervenir un coach agile expérimenté pour l'accompagner.
Aprés toute cette veille, Eva décidera-t-elle de poursuivre sa carrière dans l'agilité ou décidera-t-elle de se lancer entant que micro-entrepreneuse dans l'UpCycling???
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier événement agile c'est toujours une expérience!! Surtout quand il s'agit d'un forum ouvert.
Ce type de rencontre agile est interessant :
* les participants ne savent pas à l'avance le contenu de l'événement.
* l'organisation est libre
* ce qu'il se passe dans le forum est ce qu'il doit se passer
* au sortir de l'événement, les agilistes sont généralement ravi de ce qui se passe.
Eva n'est en effet pas déçue. Au début, elle s'est sentie un peu perdue dans cet événement non organisé. Elle ne savait pas par où commencer. Puis, grâce à la facilitation de quelques participants des éditions précédentes et à l'esprit agile des participants, les sujets passionnants se développent.
Eva participe à plusieurs échanges. Pour commencer, un coach expérimenté propose de refléchir à la suite de l'agilité, ensuite une autre personne se demande si on peut être agile sans Scrum Master et PO, puis elle teste un outil créé par un groupe de collègues autour de la gestion de la dette technique.
Durant ce rendez-vous agile, Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ce premier événement Eva a plusieurs possibilités devant elle:
#En discutant avec plusieurs participants, Eva a découvert le mouvement Agnostic Agile et se demande si elle ne peut pas s'en inspirer avec son équipe [[Agnostic Agile - L'agilité LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
[[Conclusion]]
<</if>>Se former au test, quelle drôle d'idée? Pas vraiment pour Eva.
Dans sa formation, elle a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, elle est ravie.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais Eva réussit à l'obtenir! Ça va faire bien sur son CV!!
Eva a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
#Le test c'est super, mais Eva a l'impression que le monde agile n'est pas trop versé à ce langage. Elle décide d'aller voir ce qu'en dit la communauté. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se lance dans la mise en place des [[9 - Les 3 amigos - LudiGames]]
#Le test géré, Eva s’intéresse à [[9 - La dette technique et Scrum - LudiGames]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-elle?
#Elle discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[9 - Un rituel en dehors du refinement - LudiGames]].
#Elle se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Elle décide donc, unilatéralement, de mettre en place [[9 - Un refinement revisité - LudiGames]].
#Les 3 amigos on connait! Maintenant, que fait Eva? [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
Le raisonnement d’Eva et Jean-Paul (un vieux de la vieille chez les Rois du Ballon) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! Eva et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#Eva décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[9 - Les 3 amigos - LudiGames]]
#Eva et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais[[Ca peut vraiment être efficace? - LudiGames]]Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-elle?
#Elle discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - LudiGames]].
#Elle se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Elle décide donc, unilatéralement, de mettre en place [[Un refinement revisité - LudiGames]].
#Les 3 amigos on connait! Maintenant, que fait Eva? [[Eva participe à son premier Agi'Lille - LudiGames]]
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
<<if setup.steps lt 12>>
Comment s'y prend-t-elle?
#Elle discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - LudiGames]].
#Elle se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Elle décide donc, unilatéralement, de mettre en place [[Un refinement revisité - LudiGames]].
#Les 3 amigos on connait! Maintenant, que fait Eva? [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Dans l'équipe accompagnée par Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, le Scrum Master et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec elle durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Se former au test, quelle drôle d'idée? Pas vraiment pour Eva, ni pour le Scrum Master qu’elle a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ça va faire bien sur son CV!!
Eva a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
<<if setup.steps lt 12>>
#Le test c'est super, mais Eva a l'impression que le monde agile n'est pas trop versé à ce langage. Elle décide d'aller voir ce qu'en dit la communauté. [[Eva participe à son premier Agi'Lille - LudiGames]]
#Eva se lance dans la mise en place des [[Les 3 amigos - LudiGames]]
#Le test géré, Eva s’intéresse à [[La dette technique et Scrum - LudiGames]]
<<else>>
Le Scrum Master parle à Eva des 3 Amigos...
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu’elle doit en parler autour d'elle et la mettre en action.
[[Conclusion]]
<</if>>Le raisonnement du Scrum Master est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez son client, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! Eva et le Scrum Master devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#Eva décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - LudiGames]]
#Eva et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - LudiGames]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, Eva se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, Eva se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ca rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Après plusieurs sprints dans ce système, Eva se dit quand même qu'il faudrait regarder d'autres choses...
<<if setup.steps lt 12>>
#Comme elle a entendu parler du [[Kanban - Eva Indep]], Eva se pose la question de savoir si ça ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[Eva participe à son premier Agi'Lille - Indep]]
#Eva commence a engranger de l'expérience, et les gens semblent apprécier l'écouter en parler [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>>Pour mettre en place les 3 amigos, Eva propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit Eva, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#Eva se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, elle décide, unilatéralement, de mettre en place [[Un refinement revisité - LudiGames]].
#Eva comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Elle propose à cette dernière d'explorer [[Le craftsmanship - LudiGames]]
#Afin de trouver de l'inspiration, Eva décide d'aller à la rencontre de la communauté Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]Dans l'équipe d’Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, Eva et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à Eva?
#Eva comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Elle propose à cette dernière d'explorer [[Le craftsmanship - LudiGames]]
#Afin de trouver de l'inspiration, Eva décide d'aller à la rencontre de la communauté Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
0 . Eva se demande si le [[DevOps - LudiGames]] ne serait pas aussi une solution à la perte de qualité.<img src="https://picsum.photos/200/300?random=1"/>Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit Eva, sauf que du coup les 3 amigos on refait leur travail...
<<if setup.steps lt 12>>
Quelle suite on donne à cette histoire?
#Eva se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, elle décide, unilatéralement, de mettre en place [[Un refinement revisité - LudiGames]].
#Eva comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Elle propose à cette dernière d'explorer [[Le craftsmanship - LudiGames]]
#Afin de trouver de l'inspiration, Eva décide d'aller à la rencontre de la communauté Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Dans l'équipe d'Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Dans l'équipe d’Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, Eva et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
<<if setup.steps lt 12>>
Quelle nouvelle phase propose-t-on à Eva?
#Eva comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Elle propose à cette dernière d'explorer [[Le craftsmanship - LudiGames]]
#Afin de trouver de l'inspiration, Eva décide d'aller à la rencontre de la communauté Lilloise. [[Eva participe à son premier Agi'Lille - LudiGames]]
0 . Eva se demande si le [[DevOps - LudiGames]] ne serait pas aussi une solution à la perte de qualité.
<<else>>
[[Conclusion]]
<</if>>James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James décide de se lancer dans l’[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[7 - James organise un séminaire produit - Indep]] Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - James Indep]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF - James Indep]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - James Indep]]
#James propose à l'équipe d'explorer le [[Kanban - James Indep]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[9 - Le WSJF - RDB]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[9 - Valeur Business - RDB]] ?
#Plusieurs personnes semblent intéressées par les récits de James quant à son approche avec les équipes. Du coup, [[9 - James se lance dans l'écriture d'une conférence - RDB]]RDB a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - RDB]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[9 - James découvre les meetups et Nord Agile - RDB]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Après quelques négociations, [[9 - James organise un séminaire produit - RDB]]Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
James s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l’[[Agile Hors IT - James]], il passe indep et c’est parti!!
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - RDB]]
#Un manager lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, apaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Il quitte RDB et se lance en Freelance. [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa formation, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - RDB]]
#Un manger lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - RDB]] James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Il passe indep et se lance dans l’[[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - RDB]]
#Un manager RDB lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - RDB]] Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! James n'est pas déçue!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadée qu'[[On ne devient pas coach tout seul - DoctoChat]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - DoctoChat]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - DoctoChat]]
Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projetter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[La dette technique et Scrum - DoctoChat]]
#Aborder la [[Valeur Business - DoctoChat]]
#Mettre en place un mode de priorisation simple et rapide. [[Prioriser en tailles de TShirt - DoctoChat]]
#Déployer le WiSJiF [[Le WSJF - DoctoChat]] L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[Valeur Business - DoctoChat]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[Le WSJF - DoctoChat]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[La dette technique et Scrum - DoctoChat]] Super, le client l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été reçue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est qu'externe
Qu'à cela ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de son client, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[James continue avec son équipe Scrum - Indep]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business Client - James Indep]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision client. [[Les experts de la vision - James Indep]]
Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[8 - Prioriser en tailles de TShirt - VP]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[8 - Le WSJF chez VP]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[8 - Le craftsmanship - VP]]
#James propose à l'équipe d'explorer le [[8 - Kanban - VP]] C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[8 - Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[8 - Le WSJF chez VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprès du management [[8 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parceque le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Aprés 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgrés sa compréhension des besions DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez Vertes Prairies [[8 - Valeur Business VP - Coach]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[8 - La dette technique en temps réel - VP -Coach]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[8 - Prouver l'impact de la dette technique - VP - Coach]]Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[9 - Un rituel en dehors du refinement - VP]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[9 - Un refinement revisité - VP]].
#Les 3 amigos on connait! Maintenant, que fait James? [[9 - James participe à son premier Agi'Lille - VP]] Le raisonnement de James et Jean-Paul (un vieux de la vieille chez VP) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[9 - Les 3 amigos - VP]]
#James et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - VP]]Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[9 - Gamifier une rétrospective - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[9 - Kanbanzine - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[9 - Scrumble - VP]]
#Il se dit qu'il doit acquérir plus d'expérience et [[9 - James découvre les meetups et Nord Agile - VP]]Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flatté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ça le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[9 - James se passionne pour le Serious Gaming - VP]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[9 - Agile Games France - VP]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[9 - James rejoint Nord Agile - VP]]
Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent auprès d'équipes différentes, ils attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel a une grande marge d'amélioration : [[9 - Le craftsmanship - VP]]
#James propose de travailler à la [[9 - Valeur Business - VP]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[9 - On ne devient pas coach tout seul chez VP]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d’après les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[9 - Le WSJF - VP]]
#James propose au management VP d'investiguer la notion de [[9 - Valeur Business - VP]].
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[9 - Shape Up - VP]] Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadé qu'[[9 - On ne devient pas coach tout seul chez VP]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[9 - James rejoint Nord Agile - VP]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[9 - James participe à son premier Agi'Lille - VP]]
Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[9 - La dette technique et Scrum - VP]]
#Aborder la [[9 - Valeur Business - VP]]
#Mettre en place un mode de priorisation simple et rapide. [[9 - Prioriser en tailles de TShirt - VP]]
#Déployer le WiSJiF [[9 - Le WSJF chez VP]] James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez VP il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[9 - DevOps et VP]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[9 - Le WSJF - VP]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[9 - Kanban - VP]] en espérant prouver par l'exemple que le workflow actuel est saturé.James n'a pas beaucoup d'expérience dans l'organisation d'événements de travail, mais il est débrouillard.
Il se renseigne, cherche des idées et tombe sur un article qui décrit les étapes à déployer pour bien se préparer.
Il met donc à plat un filage qui va décrire les différents temps forts de ce séminaire, ainsi que les objectifs primaires et secondaires de ces derniers.
Objectif : Définir la démarche produit VP.
Il déploie des ateliers issues des liberating structures (https://www.liberatingstructures.fr) mais pas que.
Son événement rencontre un vrai succès. Les participants sont contents d'avoir passer du temps ensemble et James a réussi à générer de l'adhésion et de la cohésion durant ce séminaire. Ça n'a cependant pas été de tout repos. Il a fallu les motiver avant même l'événement pour qu'ils se libèrent et soient présents.
Il a rencontré quelques challenges, notamment pour trouver un icebreaker pour 30 personnes. Mais rien de tel que de chercher en ligne pour ce genre de chose. Il a utilisé le "Qui a déjà" (inspiré d'une vidéo qu'elle avait vu passer sur son fil Facebook il y a quelques années).
Les ateliers qu'il avait choisi avaient le bon niveau de décalage par rapport aux personnes présentes et il a réussi à garder le niveau d'énergie des participants élevé tout au long de la journée (merci les pauses fréquentes et les bonbons acidulés!)
Il se retrouve maintenant au lendemain de l'événement avec tout le matériel créé et les dizaines de photos qu'elle a prise.
Que fait-il de tout ça?
#Il s'en était rendu compte durant l'événement mais ils n'ont pas réellement dégagé d'actions concrètes de toutes leurs discussions. James se pose alors la question de comment [[Dégager des actions d'un séminaire - VP]]?
#La liste d'actions suite à l'événement est conséquente. Maintenant il faut [[Faire vivre les actions après un séminaire - VP]]!
#La conclusion de leur séminaire est qu'il leur faut [[Une méthode maison pour VP]]. James a beaucoup d'éléments pour déployer cette méthode.
#Devant le résultat du séminaire et l'investissement en temps qui a été fait, le management des Rois du Ballon demande à James de justifier les investissements passés et futurs : [[L'agile ca coûte cher! - VP]]Super, le management l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été reçue mais qu'il n'a pas été conviée à ce comité de transformation. Faut dire... il n'est que Scrum Master!
Qu'à cela ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour RDB.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de Ludigames, il a tout intérêt a poser des bases solides.
#C'est pourquoi [[James continue avec son équipe Scrum - VP]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant [[Valeur Business - VP]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision RDB. [[Les experts de la vision - VP]]
C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
James a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint James entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[Valeur Business - VP]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - VP]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - VP]]Quand on regarde la manière dont VP gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - VP]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - VP]]
#Le Scrum Master propose la mise en place d'[[Un déversement de backlog - VP]]Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - VP]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF chez VP]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - VP]]
#James propose à l'équipe d'explorer le [[Kanban - VP]] C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
James a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint James entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors James manque d'abandonner ce sujet plusieurs fois. Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[Valeur Business - VP]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation. [[Le WSJF - VP]]
#On sait comment ça va finir (ou on a pas envie de savoir), fini le boulot d'esclave [[James micro-entrepreneur]] Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisit une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
James a d'ailleurs profité de son miroir plusieurs fois, notamment cette fois où il hésitait entre 2 missions et que son miroir lui a simplement dit :
"Tu me dis que tu hésite à cause de l'investissement que va te demander la mission X et le fait que la mission Y est mieux payée. Mais tu m'as aussi dit qu'à taux journalier égal tu n'hésiterais pas... "
James a du coup compris quelle mission prendre...
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James décide de se lancer dans l’[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]] Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
#James décide de se lancer dans l’[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]] Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[La dette technique et Scrum - VP]]
#Aborder la [[Valeur Business - VP]]
#Mettre en place un mode de priorisation simple et rapide. [[Prioriser en tailles de TShirt - VP]]
#Déployer le WiSJiF [[Le WSJF - VP]] James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez VP il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[DevOps et VP]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ça fonctionne à l'échelle d'une équipe. [[Le WSJF - VP]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[Kanban - VP]] en espérant prouver par l'exemple que le workflow actuel est saturé.Premier challenge pour James : Non seulement il a du trouver un scrum master remplaçant, mais il doit aussi accompagner les Vertes Pairies dans la création d'une nouvelle équipe.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent chez les Rois du Ballon et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec les Rois du Ballon pour sa précédente équipe. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Les Vertes Prairies pourraient aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ça que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le manager de James a choisi l'option "Seeding".
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[James organise un séminaire produit - VP - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d’[[Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez VP - Coach]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[Gamifier une rétrospective - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Kanbanzine - VP]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Scrumble - VP]]
#Il se dit qu'il doit acquérir plus d'expérience et [[James découvre les meetups et Nord Agile - VP]]Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première expérience agile chez un géant de la téléphonie. L'autre a son diplôme en d’ingénierie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flatté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ça le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - VP]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - VP]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - VP]]
Ça vous prend par hasard, quand ça frappe on voudrait se planquer dans un coin et ne plus en bouger... le syndrome (ou complexe) de l'imposteur.
Et James n'y est pas immunisé. Plus il avance dans ses apprentissages, plus il apprend de choses, plus il se rend compte de la quantité de choses qu'il ne connait pas..
En plus, comme il intervient souvent auprès d'équipes différentes, ils attendent souvent de lui qu'il ait les réponses à leurs questions et maux... mais James n'a lui même que des questions... c'est en quelque sorte sa spécialité, poser les questions qui piquent... mais il n'a pas la solution unique, ou même idéale...
Alors il apporte son ou ses expériences, ses réflexions, parfois ses convictions... mais jamais comme des injonctions, toujours sous forme de "Pourquoi?", "As-tu tenté ça?"...
Comme il ne produit pas lui même, et que la nature même de la démarche agile c'est de maximiser la production de valeur, or il n'a pas l'impression de participer à cette création de valeur à la hauteur de ce que les équipes font.
Il a donc l'impression, souvent, d'être à une place qui n'est pas la sienne, d'être écouté alors qu'il n'a pas la science infuse.
Heureusement, un ami lui avait offert "RUPTURE DOUCE #06 : Libérez l'imposteur agile qui est en vous" compilé par Laurent Sarrazin.
Alors il se soigne.
Que voulez-vous explorer maintenant?
#James se dit que pour se soigner un peu du syndrome il y a un domaine dans lequel a une grande marge d'amélioration : [[Le craftsmanship - VP]]
#James propose de travailler à la [[Valeur Business - VP]]
#James souhaiterait évoluer dans son métier. Il en parle à son manager et celui-ci est d'accord : James a l'étoffe d'un coach, cependant [[On ne devient pas coach tout seul chez VP]] Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d’après les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF - VP]]
#James propose au management VP d'investiguer la notion de [[Valeur Business - VP]].
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[Shape Up - VP]] Gros sujet que celui de la dette technique! Surtout quand une équipe est lancée et qu'elle n'a jamais pris cet aspect en considération!
James s'en rend vite compte. D'abord, il faut faire comprendre le concept aux équipes (et surtout au PO), puis il faut faire comprendre la nécessité d'y travailler. Pour finir, il faut trouver le bon moyen, adapté au contexte, pour la suivre correctement (et agir dessus).
James se renseigne et découvre qu'il existe plusieurs ateliers disponibles pour aborder le sujet avec les équipes.
Entre le Dette Technique Challenge d'Alexandre Boutin, le Scrumble de chez Pyxis et l'anti dette dont un de ses potes lui a parlé, il a le choix.
Il décide d'utiliser le DTC, on va pas se mentir, parce que le nom l'a fait sourire et qu'il sait qu'il aura le même effet avec les équipes.
L'atelier de test est un succès, les participants ont tout compris!
Au sorti de là l'équipe a décider d'avancer sur le sujet.
Ils décident de commencer petit et d'identifier les gros sujets de dette entant que PBI (Product Backlog Items), pour ensuite les incorporer dans les sprints.
Après 3 sprints James s'interroge car aucun sujet de dette n'a été embarqué par l'équipe. Il travaille avec le Scrum Master et ce dernier se repasse le film des plannifs et se rend compte qu'à chaque fois que l'équipe a proposé d'avancer sur une des US de DT, le PO a priorisé autre chose.
James va lui en parler. Il se rend compte que pour le PO c'est super compliqué, malgré sa compréhension des besoins DT, de les prioriser par rapport aux US de création de valeur, d'autant que l'équipe est souvent incapable de lui fournir des informations sur la valeur liée à la dette.
James continue à travailler sur le sujet et propose plusieurs pistes.
#Travailler à la Valeur Business chez Vertes Prairies [[Valeur Business - VP]]
#Mettre en place des indicateurs de Dette Technique et le process dans le cadre Scrum qui leur permettra de la gérer en temps réel. [[La dette technique en temps réel - VP]]
#Travailler avec l'équipe sur une double estimation pour mettre en avant l'impact de la dette actuelle. [[Prouver l'impact de la dette technique - VP]]C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[Le WSJF - VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprés du management [[Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
Pour James, le terme Devops est un peu obscure. De prim abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est très étonné lorsqu'il apprend que ce n'est pas ca.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y intéresser.
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - VP]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - VP]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - VP]]Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ça n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* James n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Après avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Rois du Ballon (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[Production VS Servant Leadership - VP]]
#James décide d'explorer encore un nouveau sujet. [[Shape Up - VP]]
#James est suffisamment aguerri maintenant pour se lancer tout seul [[James micro-entrepreneur]] <img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
<<if setup.steps lt 12>>
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - VP]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - VP]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - VP]]
<<else>>
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF
* Un manager vient voir James avec la fameuse rengaine : L'agile ça coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projeté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - VP]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - VP]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - VP]] , quelles sont ses options?
<<else>>
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]]
<</if>>James a une jolie expérience. Il a passé plusieurs années au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
De plus, il lui semble que le métier de coach, enfin les missions qu'il voit passer dans les offres auxquelles il a accès, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - VP]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - VP]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille - VP]] Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ca engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ca peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ca marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
James propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'elle a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[9 - Le WSJF chez VP]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[9 - Sensibilisation agile des PP - VP]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Après quelques négociations avec son management, [[9 - James organise un séminaire produit - VP]] Ce n'est pas le première fois que James entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du délai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à James la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à James amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, James propose au PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
Maintenant que le WSJF est adopté chez les Vertes Prairies (au moins pour les sujets qui touchent les équipes accompagnées par lui) James continue son accompagnement de la transformation.
#James doit maintenant se pencher sur la notion de [[9 - Production VS Servant Leadership - VP]]
#James décide d'explorer encore un nouveau sujet. [[9 - Shape Up - VP]]
#James décide qu'il est tout à fait à même de poursuivre sa carrière sans VP. Il passe donc indépendant [[James micro-entrepreneur]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-développement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par exemple, pose quelques soucis à l'équipe.
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez les Rois du Ballon semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelque chose. [[9 - DevOps et VP]]
#James propose à l'équipe de travailler à la notion de dette technique. [[9 - La dette technique et Scrum - VP]]
#Après toutes ses aventures chez VP, James décide de voler de ses propres ailes [[James micro-entrepreneur]] Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Après quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l’intéressent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[9 - Kanbanzine - VP]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[9 - Une formation avec Laurent Morisseau - VP]]?
#Quelque soit la manière, il réussi à déployer la démarche auprès de son équipe. Maintenant il lui faut expliquer au management que [[9 - Le Kanban ca marche, mais ca prend du temps! - VP]].James tente d'expliquer qu'avec la démarche agile l'équipe va naturellement se tourner vers une production de valeur accrue.
Si on considère la production de valeur avant tout, on va s'occuper de générer de la satisfaction utilisateurs (surtout dans l'IT). Plus nos utilisateurs sont satisfaits, plus ils génèrent de la valeur.
Cette notion de valeur varie en fonction du produit mais dans le cas d'un site web avec abonnement, plus les utilisateurs sont satisfaits, plus ils utilisent le produit longtemps et plus l'abonnement qu'ils payent est rentable pour eux. Plus l'abonnement est rentable, plus ils sont fidèles à l'éditeur...
Donc, plutôt que de se concentrer sur le coût d'une équipe, on se concentre sur la valeur qu'elle produit. Si on est satisfait de cette valeur, il n'y a pas de raison de remettre en question le coût (ni les estimations).
James utilise la métaphore de l'artisan pour parler d'une équipe agile. Lorsqu'on fait venir un artisan pour une tâche précise dans sa maison, par exemple repeindre la pièce, il nous fait une estimation de ce que le chantier va nous coûter. Une fois le devis signé, il s'engage à terminer ce chantier, quel que soit le temps réel qu'il passe dessus.
La plupart des gens sont prêts à payer la somme valider pour avoir leur salon repeint. Même si l'artisan estime dans son devis qu'il lui faudra 6h alors qu'en réalité il en met 5, personne ne va dire, au moment de payer, "Hey monsieur l'artisan, vous avez mis moins de temps que prévu donc je vous paye moins!". Tout comme on ne le paye pas plus cher s'il s'est trompé dans son estimation.
Pour une équipe agile (Scrum), c'est pareil: l'équipe s'engage, à chaque Sprint, à livrer le maximum de valeur possible dans la liste des besoins identifiés. Comme le PO valide cet engagement, il est prêt à "payer" un sprint pour la valeur promise.
Bien sur, on met tout en place (avec l'équipe, le PO et le Scrum) pour maximiser cette création de valeur. Mais au final, dans le contexte de l'équipe à l'instant T, la valeur produite à chaque sprint est optimisée.
En plus, si on pousse le produit vers les clients régulièrement (à chaque sprint), on diminue le risque financier lié à cette valeur. Plus on met en production régulièrement, plus le risque est réduit...
Bref, James leur fait un topo complet, avec schéma et tout...
#James semble avoir convaincu les grands chefs. Ils lui demandent comment faire comprendre ce point de vue à toutes les strates de l'entreprise. James propose une [[9 - Sensibilisation agile des PP - VP]]
#Pour aller encore plus loin sur le sujet de la production de valeur, James aimerait pouvoir explorer le No Estimate dont il a entendu parler sur un forum. [[9 - James se passionne pour le No Estimate - VP]]
#James se dit qu'il pourrait aussi creuser [[9 - Shape Up - VP]] C'est une notion difficile la valeur business, surtout chez les Vertes Prairies!! Comment comparer la création de valeur d'un nouvel outil vs l'ajout de fonctionnalités sur un produit existant?
De plus, a chaque fois qu'un PO a essayé de s'atteler à ce sujet, il est tombé sur un os. Comment comparer des poires et des pommes? Comment donner une valeur business à un produit qui n'existe pas encore?
James a l'occasion de travailler aux priorités avec son PO préféré et, tombe sur un os aussi... enfin sur une méga matrice! Yvan, le PO, est sans doute celui qui réussi le mieux à prioriser les travaux pour l'équipe mais au prix d'un effort conséquent, qu'il matérialise dans un méga excel que lui seul sait lire (même si tout le monde y a accés, Yvan a bien compris le principe de transparence ;))
Yvan y factorise: les ventes projetées de licences, le gain en temps projeté pour les utilisateurs, le taux projeté de rétention, le NPS projeté, l'effet Wahou!, le cout projeté en taille de tshirt, l'effet Papillon...
James est perplexe...
Il lui propose un premier exercice pour essayer de passer sa notion "absolue" de la valeur à une notion "relative".
Sur les différentes colonnes elle réussi à le faire sortir des données sans "unité de valeur" (principalement des $$) mais il n'est pas satisfait de la matrice.
Quelle solution propose-t-il à Yvan?
#Et si on essayait de mettre des tailles de Tshirt partout plutôt que des valeurs chiffrées [[9 - Prioriser en tailles de TShirt - VP]]?
#James se renseigne encore un peu et tombe sur la notion de WiSJiF. Il lui propose de se lancer [[9 - Le WSJF - VP]]
#James abandonne ce sujet et préfère se concentrer sur un autre sujet auprès du management [[9 - Il faut se focaliser sur la création de valeur et plus sur les dépenses - VP]]
Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[9 - Le craftsmanship - VP]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[9 - Le WSJF - VP]]
#Un manager vient voir James avec la fameuse rengaine : [[9 - L'agile ca coûte cher! - VP]] James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projeté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? [[9 - Le craftsmanship - VP]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[9 - Le principe de l'amélioration continue face au chaos - VP]]
#Le manager de James lui indique qu'il faut [[9 - Créer une nouvelle équipe Scrum - VP]] , quelles sont ses options?James choisi une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de VP.
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour VP. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - VP]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer Vertes Prairies dans le bon sens. [[James organise un séminaire produit - VP]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation chez VP]]
#James se lance tout seul. [[James micro-entrepreneur]] James passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour James c'est sa première formation.
James passe du temps à préparer un plan, puis il le jette à la corbeille quand il commence à compiler ses slides et qu'il essaye de raconter une histoire cohérente.
Il commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Il promet de mettre à jour son cursus pour la prochaine session.
Il a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'il souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de VP.
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour VP. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - VP]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer VP dans le bon sens. [[James organise un séminaire produit - VP]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation chez VP]]
#Avec cette expérience complémentaire en poche, James passe indépendant. [[James micro-entrepreneur]] James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de rétrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelque part et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parce qu'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec son équipe. Le SHC leur montre le delta entre les préconisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - VP]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile - VP]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - VP]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - VP]] quand on parle de rétrospective.
En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en français l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns après les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son animation unique avec son équipe, il décide de télécharger la version Creative Commons plutôt que d'acheter la version éditée. Pour son équipe ça ira bien mais il se dit que si il doit animer l'atelier plus tard avec d'autres personnes il sera sans doute nécessaire d'investir dans une version officielle qui en plus lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - VP]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à DoctoChat d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour VP]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ça ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - VP]]
#Y'en a marre de la vie de Scrum Master, que fait James après avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]] Un jeu de l'oie Scrum... C'est un peu comme cela que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le test avec quelques volontaires un midi sur l'heure du repas. Il voit comment ça fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont très long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélérer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses future cursus de formation.
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - VP]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - VP]]
#James a pris goût aux outils gamifiés, il se lance dans[[Kanbanzine - VP]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - VP]] Un premier meetup c'est toujours une expérience!! James n'est pas déçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - VP]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - VP]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James intéresse les participants à tous les événements auxquels il assiste.[[James se lance dans l'écriture d'une conférence - VP]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - VP]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - VP]]
#Il choisi un outil d'apprentissage et l'anime auprès d'une de ces équipes . Ils testent [[Kanbanzine - VP]]
#Lors d'un accompagnement d'équipe débutante, il utilise [[Scrumble - VP]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile - VP]] James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais il n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu'il voudrait tester, les projets... Il rempli un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois après il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - VP]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - VP]]
#James quitte VP et passe indep. Quand vient l'heure de trouver une mission il se dit qu’après ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]] James comprend les bases de Shape Up :
* Des cycles de 6 semaines
* Donner forme au besoin avant de le mettre dans les mains de l'équipe.
* Responsabiliter l'équipe
* Comprendre et cibler les risques
Il apprécie particulièrement l'idée de mettre en place une vraie relation de confiance entre le demandeur et l'équipe. Il aime aussi le fait que, dans son essence, Shape Up ne demande pas à l'équipe de construire une solution mais de répondre à un besoin, en un temps limité.
Cependant, il manque de recul sur le sujet, et il a l'impression que la communauté aussi. Il engage malgré tout un chantier avec le PO autour des appétits.
Il propose au PO d'arrêter de demander des US spécifiques à chaque sprint et de se focaliser sur les objectifs qu'il voudrait voir atteints à la fin du sprint (un peu ce qu'on pourrait aller chercher avec Scrum lorsqu'on travaille réellement avec les objectifs de sprint). Cependant, il lui propose de décomposer son objectif en plusieurs sous objectifs et de leur assigner à chacun un appétit (ou un demi appétit).
Il propose ensuite que l'équipe utilise le sprint planning pour proposer un découpage en "étapes" de leur réponse au besoin, en restant dans l'appétit.
Après un premier atelier avec l'équipe et le PO, ils décident de commencer avec 3 appétits par sprint.
L'équipe se lance. Le premier sprint se passe bien mais ils rencontrent, lors du second, un souci de gestion du RUN...
Quelle voie allons nous suivre avec James ensuite?
#Afin de récupérer plus d'informations sur Shape Up et notamment des retours d'expérience, James devrait se rapprocher de la communauté agile Lilloise. [[James participe à son premier Agi'Lille - VP]]
#James se dit, qu'avant de plonger plus en profondeur il faudrait peut être déjà que l'équipe aborde la notion de dette technique. [[La dette technique et Scrum - VP]]
#James voudrait parler de la notion d'appétit avec le PO. Ils se rencontrent et finalement décident de mettre en place le [[Le WSJF - VP]]
<img src="https://picsum.photos/200/300?random=1"/>C'est invariable : à chaque sprint l'équipe s'engage sur un backlog de sprint et ne tient pas son engagement!
James a pourtant essayé beaucoup de choses :
* Réduire la capacité d'effort de l'équipe en sprint planning
* Analyse des causes de ce "sur engagement"
* Travail avec le PO pour qu'il propose des besoins ultra détaillés
* Sprint de stabilisation tous les 3 sprints
* ...
Rien n'y fait, rien ne change.
L'équipe est correctement outillée (selon James) :
* Burn down
* Projection de capacitif à chaque sprint (prenant en compte les congés de chacun)
* Une réunion d'affinage du backlog toutes les semaines
* Une définition de prêt qui respecte non seulement l'INVEST mais aussi qui est aussi revue régulièrement par l'équipe (avec une notion d'évolution de cette dernière)
* Des daily correctement animés et avec remontée d'alerte
Pourtant, a chaque fois, on entend des :
* Cette US prend du retard mais je vais réussir à rattraper.
* J'ai bossé sur du run hier mais ça ne devrait pas influer sur le sprint.
* Ce sujet est côté QA, en attente de validation.
* Euh, finalement ce sujet n'est plus prioritaire, on peut prendre autre chose? (PO)
* Alors en fait pour faire cette US, il faut aussi faire celle-ci qui n'était pas prévue. Donc je l'embarque hein?
* ...
Et vers l'antépénultième jour du sprint James entend :
* Bon, là ça va pas le faire.
* On dépriorise quoi pour la fin de sprint?
* Qui peut m'aider, je suis grave à la bourre?
Alors James manque d'abandonner ce sujet plusieurs fois.
<<if setup.steps lt 12>>
Puis, un lundi il arrive avec une nouvelle perspective.
Quelle est cette dernière?
#James propose à son manager de s'attaquer à un problème de fond : La [[Valeur Business - VP]]
#Il ne voulait pas s'y atteler, ne voyant pas de solution facile mais maintenant il n'a plus le choix! Il faut poser une manière de gérer le run qui change ce qui est fait jusqu'à maintenant. [[Gérer le run en Scrum - VP]]
#James décide de reprendre ses travaux avec le PO et lui propose de regarder à une manière différente de gérer la priorisation.[[Le WSJF - VP]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>VP a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, Eva a du pain sur la planche.
<<if setup.steps lt 12>>
#Eva propose à James d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - VP]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[James découvre les meetups et Nord Agile - VP]]
#Rien de tel qu'une grand messe pour lancer une re-fondation de la manière de travailler. Après quelques négociations, Eva propose que [[James organise un séminaire produit - VP]]
<<else>>
[[Conclusion]]
<</if>>Comme il a participé à un meetup, James recoit une invitation à l'Assemblée Générale de Nord Agile (bin oui, on est comme ca chez les Ch'tis).
Il se rend donc au rendez-vous et participe à sa première AG! Présentation de l'association pour les nouveaux, des bilans moraux, financiers... rien n'est laissé de côté. Ouverture et transparence sont de mise dans cette asso... tient, ca lui rappelle quelquechose.
Il apprend aussi qu'ils organisent différents événements dont l'Agi'Lille et les Agile Games Hauts de France. Il découvre avec plaisir que des rétrospectives sont organisées aprés chaque Agi'Lille et découvre ce que veut dire que de non-organiser un événement.
Les gens présents le passionnent aussi. Il semble qu'ils soient de tous les horizons agiles, du scrum master débutant au coach confirmé.
Durant le pot de l'amitié une question lui arrive dans le coin de l'oreille: ca te dirait de devenir membre?
Il demande plus de précision, c'est quoi être membre? Il obtient des réponses faciles et rapides (que vous pourrez obtenir sur le stand Nord Agile de l'Agi'Lille, sur le slack, bientôt sur le nouveau site de l'association ? , ou en demandant à un des membres actuel).
Il s'engage, et se retrouve au sein d'une équipe dynamique, qui se veut auto-organisée. Son agenda personnel ne lui permet pas de s'investir énormément mais il promet de trouver du temps pour participer à l'organisation de l'Agi'Lille de l'année prochaine.
<<if setup.steps lt 12>>
Aprés cette pub mal déguisée, où souhaitons nous emmener James?
#James goute au Serious Gaming lors de l'Agile Games Hauts de France et se passionne pour le sujet [[James se passionne pour le Serious Gaming - VP]]
#C'est bien beau de parler de Nord Agile, mais le manager de James lui demande d'organiser un séminaire pour parler produit avec les équipes des Vertes Prairies. Ca sort un peu de sa zone de confort mais James se lance. [[James organise un séminaire produit - VP - Coach]]
#James veut en voir toujours plus au niveau des communautés. Il s'inscrit à l'[[Agile Games France - VP]]
<<else>>
[[Conclusion]]
<</if>>Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
<<if setup.steps lt 12>>
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - VP]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - VP]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille - VP]]
<<else>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>
Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ça reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[Un refinement revisité - VP]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - VP]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - VP]]Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - VP]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - VP]]
#Y'en a marre du Scrum Master! [[Fast Track Scrum Master - James]] Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
Comment s'y prend-t-il?
#Il discute avec le PO et les développeurs et se disent que c'est une superbe idée mais pour commencer ils décident d'en faire un [[Un rituel en dehors du refinement - VP]].
#Il se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant que l'équipe ne s'engage. Il décide donc, unilatéralement, de mettre en place [[Un refinement revisité - VP]].
#Les 3 amigos on connait! Maintenant, que fait James? [[James participe à son premier Agi'Lille - VP]] Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, James voit une multitude de chemins à suivre.
Il commence avec une équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener James à partir de là?
#Un des freins au pure Craftsmanship chez VP semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadé qu'il faut y changer quelquechose. [[DevOps et VP]]
#James commence a voir de l'expérience maintenant, un de ses amis lui propose de les partager lors d'une rencontre agile. [[James se lance dans l'écriture d'une conférence - VP]]
#Aprés toutes ses aventures chez VP [[James micro-entrepreneur]]
<<else>>
* James explore les différentes possibilités de gestion de la dette technique, tout en essayant de comprendre la compatibilité, ou pas avec le cadre Scrum.
* James lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. James est persuadée qu'il faut y changer quelquechose. James va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? James s'inquiète également.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Nouveau challenge pour James : il doit accompagner VP dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ça que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le client de James a choisi l'option "Seeding".
<<if setup.steps lt 12>>
Maintenant qu'elle est en place, James peut se consacrer à la suite :
#[[James organise un séminaire produit - VP - Coach]]
#Afin de pouvoir faire changer les choses chez VP, James proposer la mise en place d'[[Un comité de transformation chez VP]]
#Les équipes ne délivrent pas suffisamment de valeur. Il semble qu'il y ait [[Des problèmes d'engagement chez VP - Coach]]
<<else>>
Il est aussi possible que le client ne lui laisse pas le choix et qu'il doive composer avec une équipe de 15 personnes. Si c'est cette solution qui est choisie, il se demande si le modèle Scrum chez son client ne va pas exploser...
[[Conclusion]]
<</if>>Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
James se propose d'étudier les points de concordance entre VP et la rache.
<<if setup.steps lt 12>>
Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - VP]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF chez VP]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - VP]]
#James propose à l'équipe d'explorer le [[Kanban - VP]]
<<else>>
[[Conclusion]]
<</if>>James consulte les ressources qu'il trouve en ligne, notamment coach-agile.com, openseriousgames.org et hacoeur.biz pour trouver des idées de rétrospective agile à lancer avec son équipe.
Il y a moult possibilités de formats et de types de réstrospective à sa disposition.
Les premiers exemples que James voudrait explorer :
* Scrum Health Check, il faut bien commencer quelquepart et un retour aux bases ne peut pas faire de mal.
* Speedboat, retour aux classiques
* KISS, parcequ'on vit pas au pays des bisounours
James déploie les 3 d'affilé avec une équipe. Le SHC leur montre le delta entre les préconnisations de Scrum et la méthodo appliquée par l'équipe.
Le speedboat et le KISS utilisent tous les deux le principe des axes (4 ou 5) pour aller chercher ce qui fonctionne, ne fonctionne pas, qu'on devrait arrêter, qu'on devrait commencer à faire et où qu'on devrait améliorer.
Il n'est pas toujours facile de sortir des actions d'amélioration continue cohérentes, mais l'équipe réussi à en générer quelques unes à chaque fois.
<<if setup.steps lt 12>>
Maintenant, que fait James?
#James se rend compte que certaines actions manquent d'efficacité... enfin, ne semblent pas efficaces, il se demande pourquoi. [[Le principe de l'amélioration continue face au chaos - VP]]
#En recherchant des formats de rétrospectives, James est tombé sur plusieurs articles mentionnants la communauté agile Lillois. [[James découvre les meetups et Nord Agile - VP]]
#L'équipe a accroché au format, pour aller encore plus loin et leur faire découvrir quelques pratiques liées au Kanban, James teste [[Kanbanzine - VP]]
#James se rend compte que [[Peu importe le format, seuls les résultats comptent - VP]] quand on parle de rétrospective.
<<else>>
Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>>En faisant quelques recherches d'ateliers pour présenter le Kanban sur internet, James tombe sur Kanbanzine. Il a hésité un moment entre cet atelier et GetKanban mais le fait que Kanbanzine soit en francais l'a poussé à le choisir.
Dans cet atelier, les participants endossent des rôles au sein d'une équipe d'édition d'un magazine et doivent faire sortir les numéros de ce dernier les uns aprés les autres en maximisant la valeur apportée aux lecteurs à chaque publication.
L'équipe arrive en remplacement d'une autre, en plein milieu de la publication d'un numéro et doit avancer coûte que coûte.
Pour son activité d'indépendante il décide acheter la version éditée qui, de plus, lui donne accès à l'animation en ligne.
L'atelier se passe bien. L'équipe comprend les principes de limit de WIP, d'entraide entre équipier, de production de valeur...
<<if setup.steps lt 12>>
Que fait ensuite James?
#Avec son équipe, ils décident de déployer la démarche Kanban. [[Le Kanban ca marche, mais ca prend du temps! - VP]]
#L'équipe se rend compte que Kanban ou Scrum, rien ne semble vraiment permettre à DoctoChat d'entrer dans les cases. James propose alors de créer [[Une méthode maison pour VP]]
#James se dit qu'avec Kanban l'équipe pourrait être plus sereine dans son avancée mais ca ne répond pas tout à fait aux problématiques plus globale. Il continue ses recherches et explore [[Shape Up - VP]]
#Y'en a marre de la vie de Scrum Master, que fait James après avoir tout tenté avec son équipe agile? [[James micro-entrepreneur]]
<<else>>
James accompagne l'équipe qui se lance tête baissée dans la démarche Kanban.
James travaille avec le scrum master pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ca leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et propose au scrum master de regarder un peu aux goulots d'étranglement au sein de leur tableau. Ils se rendent compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Ils s'engagent donc dans l'identification des workflow externes à l'équipe et proposent aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Aprés 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Il faut pouvoir tenir sur ce temps relativement long et notamment expliquer au management que lorsqu'on dit amélioration continue on ne va pas forcément sur des voie expresses!
[[Conclusion]]
<</if>>Un jeu de l'oie Scrum... C'est un peu comme celà que l'on pourrait décrire Scrumble.
Créé par Pyxis, l'outil répond aux objectifs suivants :
* Revoir les bases de Scrum avec les joueurs.
* Appuyer sur les principes de la priorisation par la valeur.
* Montrer l'impact de la dette technique sur la capacité de l'équipe à délivrer de la valeur.
James le teste avec quelques volontaires un midi sur l'heure du repas. Il voit comment ca fonctionne mais est frustré de sa première expérience avec l'outil. En effet, suivant la description du tour de jeu indiquée dans les règles, les tours sont trés long. Sur la session d'essai ils ont à peine le temps de faire leur premier sprint.
C'est alors qu'il parle avec Eric sur Linked in... celui-ci lui donne quelques trucs pour accélerer les tours de jeu, notamment le fait de faire jouer tout le monde en même temps et pas chacun leur tour.
Une belle découverte pour James!
Il pense intégrer l'outil dans tous ces accompagnements de débutants et dans ses futur cursus de formation.
<<if setup.steps lt 12>>
Quelle aventure pour la suite?
#Afin de faire évoluer ses accompagnements, James se renseigne sur [[Le craftsmanship - VP]]
#Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique? [[La dette technique et Scrum - VP]]
#James a pris goût aux outils gamifiés, il se lance dans [[Kanbanzine - VP]]
#Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ça c'est bien beau mais James se demande souvent s'il est légitime. [[Syndrôme de l'imposteur - VP]]
<<else>>
* Afin de faire évoluer ses accompagnements, James se renseigne sur le craftsmanship.
* Scrumble met en avant l'impacte de la mauvaise gestion de la dette technique sur la capacité de l'équipe à produire de la valeur... KEZAKO la dette technique?
* James a pris goût aux outils gamifiés, il se lance dans Kanbanzine
* Faire jouer les gens, les accompagner, être conseil (si on veut)... tout ca c'est bien beau mais James se demande souvent s'il est légitime. Il est touché par le syndrôme de l'imposteur.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idées, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - VP]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[ [11 - James participe à son premier Agi'Lille - VP]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James intéresse les participants à tous les événements auxquels il assiste. [[James se lance dans l'écriture d'une conférence - VP]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - VP]]
<<else>>
Il revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et il se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, il développe l'envie de rendre à la communauté à hauteur de ce qu'il y a récupéré depuis quelques mois. Il commence à rédiger une conférence. Peut-être le croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>Quand on regarde la manière dont VP gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bétises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Aprés tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - VP]]
#James propose la mise en place des 3 amigos [[8 - Les 3 amigos - VP]]
#Le Scrum Master propose la mise en place d’[[8 - Un déversement de backlog - VP]]
<<else>>
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Se former au test, quelle drôle d'idée? Pas vraiment pour James, ni pour le Scrum Master qu'il a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ca va faire bien sur son CV!!
James a hâte de l'aider à mettre tout ca en pratique. Mais que font-ils une fois cette certification en poche?
<<if setup.steps lt 12>>
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[9 - James participe à son premier Agi'Lille - VP]]
#Avec le Scrum Master, James se lance dans la mise en place des [[9 - Les 3 amigos - VP]]
#Le test géré, James s’intéresse à [[9 - La dette technique et Scrum - VP]]
Le Scrum Master parle à James des 3 Amigos...
<<else>>
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu'il doit en parler autour de lui et la mettre en pratique.
[[Conclusion]]
<</if>>Le raisonnement de James et Jean-Paul (un vieux de la vieille chez VP) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - VP]]
#James et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - VP]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inéfficace d'un point de vue rapidité de déploiement. Cependant, ca porte ses fruits au niveau qualitatif et ca rend le système relativement pévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>>James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
<<if setup.steps lt 12>>
Maintenant, il ne faut pas non plus oublier ce pourquoi il s'est lancé en indep...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James décide de se lancer dans l'[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - Indep]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - Indep]]
<<else>>
Réussira-t-il à faire bouger les choses chez ses clients?
[[Conclusion]]
<</if>>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - VP]]
#Il choisi un outil d'apprentissage et l'anime auprès d'une de ces équipes . Ils testent [[Kanbanzine - VP]]
#Lors d'un accompagnement d'équipe débutante, il utilise [[Scrumble - VP]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile - VP]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'un de ces clients.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu’il voudrait tester, les projets... Il remplit un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
<<if setup.steps lt 12>>
Fort de cette expérience, James retourne à son quotidien.
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - VP]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - VP]]
#James quitte VP et passe indep. Quand vient l'heure de trouver une mission il se dit qu’après ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]]
<<else>>
[[Conclusion]]
<</if>>Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Après plusieurs mois (ben oui, l'industrie ça réagit pas très vite) dans ce système, James se dit quand même qu'il faudrait regarder d'autres choses...
#Comme il a entendu parler du [[8 - Kanban - RDB]], James se pose la question de savoir si ça ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[8 - James participe à son premier Agi'Lille - RDB]]Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Nomal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[9 - Un refinement revisité - RDB]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[9 - Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[9 - James participe à son premier Agi'Lille - RDB]]Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - VP]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à Vertes Prairies mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[La démarche produit - VP]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]James et son équipe se lancent tête baissée dans la démarche Kanban.
James travaille avec son équipe pour identifier toutes les étapes relatives à leur mandat d'intervention sur les applications. Ils en sortent un modèle de processus qui répond à 87% de leur travaux.
Dans ce tableau, ils mettent en place les bonnes colonnes, notamment le Done plutot que le ToDo!
Ils décident d'essayer de lancer les limites de WIP, ça leur prend plusieurs mois pour les régler correctement. L'entraide fonctionne bien, ils intègrent un expert en test, qui vient s'ajouter dans le workflow.
Au départ, ils conservent tout de même un rythme presque identique à Scrum, avec des daily, des lancements de période, des clotures de période...
James sent que l'équipe pourrait être encore plus efficace et décide de regarder un peu aux goulots d'étranglement au sein de leur tableau. Il se rend compte que la plupart de ces derniers sont liés à ce qui se passe en dehors de l'équipe. Soit la prod n'est pas au rendez-vous, soit les sujets se retrouvent en attente d'informations complémentaires, soit le backlog n'est pas correctement alimenté.
Il s'engage donc dans l'identification des workflow externes à l'équipe et propose aux différentes parties prenantes d'utiliser également des tableaux Kanban.
Après 1 an, l'équipe commence enfin à voir le résultat de ses efforts. Le cycle time est relativement court, le lead time commence à se réduire... James réfléchie même à investiguer les classes de service....
Qu'allons nous observer ensuite?
#Le manager de James l'interpelle car ils considèrent que les progrès certes sont là mais qu'ils prennent beaucoup de temps à se mettre en place. James leur explique [[Le principe de l'amélioration continue face au chaos - VP]]
#Maintenant que la démarche Kanban est en place, James propose de mettre en place [[La démarche produit - VP]]
#De Kanban à Scrum c'est très beau tout ça, mais comment doivent s'appeler les rôles systémiques du coup? [[Des noms de rôles chez VP]]
<img src="https://picsum.photos/200/300?random=1"/>Mise à part le fait qu'on lui ai recommandé de participer à une de ces formations, James ne connait pas bien Laurent.
Il entame donc la formation sans à priori et se rend compte rapidement qu'il est tombé devant un puit de savoir.
La formation est pleine de retours d'expériences et d'informations ultra pertinentes.
Ce qui le marque surtout, c'est la mise en pratique finale avec le GetKanban (https://getkanban.com) et l'appui qui y est fait sur le focus à faire avancer le sujet entre membre d'une même équipe.
Ils ont même le temps d'évoquer les classes de service, et bien que lointain, le sujet restera dans le cerveau de James car il espère les utiliser à un moment donné.
<<if setup.steps lt 12>>
Au sortir de cette formation James est plein de nouvelles informations et envies! Comment les exploite-t-il?
#James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. [[Le principe de l'amélioration continue face au chaos - VP]]
#James se dit que toutes ces nouvelles informations vont pouvoir servir à Vertes Prairies mais pas directement en passant par la démarche Kanban. Il propose de commencer par [[La démarche produit - VP]]
#C'est bien beau tous ces changements au sein de l'équipe, mais on voudrait savoir ce qui se passe pour James après et notamment ce qu'il pourrait faire en Indep [[James micro-entrepreneur]]
<<else>>
Au sortir de cette formation James se lance dans le Kanban mais commence par expliquer à son management que cette démarche va prendre du temps. Il essaye de leur faire comprendre le principe de l'amélioration continue face au chaos.
[[Conclusion]]
<</if>>Un servant leader se doit d'être au service de l'équipe, lorsque celle-ci en a besoin.
Il montre la direction et accompagne l'équipe dans son atteinte, sans pour autant être devant à tirer toute l'équipe à bout de bras.
On a l'habitude de dire d'un scrum master qu'il se doit d'être le servant leader de l'équipe. Mais on va pas se mentir, au lancement d'une équipe un Scrum Master doit souvent être plus chef d'orchestre, animateur et parfois ordonnanceur que servant leader.
Il commence en mode scrum mom et fait tout pour autonomiser l'équipe de manière à ce que l'auto-organisation se déploie.
James a compris le principe de servant leader, il essaye d'accompanger un Scrum Master à passer dans ce mode, en laissant l'équipe s'auto-organiser, mais il passe rapidement tout de même en mode scrum mom, surtout lorsqu'il comprend que personne dans l'équipe n'a réellement eu de formation agile (en dehors de lui).
De fait, il est monopolisé par les aspects d'organisation, d'accompagnement du PO... et se retrouve à avoir peu de temps réel pour faire de la production de code... Cette situation semble problématique, d'autant qu'il prend en compte sa disponibilité théorique dans la capacité à créer de la valeur à chaque sprint...
Que se passe-t-il ensuite dans l'aventure de James?
#James se rend compte du souci d'engagement et travaille sur ce sujet [[Des problèmes d'engagement chez VP - Coach]]
#James se dit qu'il faut retourner aux bases et propose d'organiser [[Sensibilisation agile des PP - VP]]
#James se dit qu'il a besoin de confronter son expérience à celle d'autres personnes. [[James participe à son premier Agi'Lille - VP]]
#Aprés toutes ces aventures, James décide de partir de chez les Rois du Ballon [[James micro-entrepreneur]] Quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a pris conscience de ces différents paramètres et a identifié quelques domaines dans lesquels VP pourraient s'améliorer:
#James propose de mettre en place une manière plus efficace de prioriser les travaux à lancer. [[Le WSJF - VP]]
#L'amélioration continue sert à accélérer la production de valeur, ou à mieux la focaliser, mais comment identifier la [[Valeur Business - VP]] ?
#Plusieurs personnes semblent intéressées par les récits de James quant à son approche avec les équipes. Du coup, [[James se lance dans l'écriture d'une conférence - VP]]Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisi une coach croisée lors d'une précédente mission.
Cette relation lui sauve plusieurs fois les cheveux (au lieu de se les arracher!!).
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliquer de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. Il quitte VP et se lance en Freelance. [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa formation, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - VP]]
#Un manger lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - VP]]
<<else>>
[[Conclusion]]
<</if>>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, nous seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillé pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans une entreprise de l'industrie mais également la mise en place d'une démarche OKR dans une structure qui se veut déjà agile.
James s'inscrit même à l'ICF pour côtoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
<<if setup.steps lt 12>>
#James décide de se lancer dans le Freelance et explore l'[[Agile Hors IT - James]].
#James a eu la chance d'utiliser beaucoup de serious games dans sa formation, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - VP]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - VP]]
<<else>>
* James décide de se lancer dans l'Agile Hors IT avec des équipes métier de chez RDB.
* James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création.
* Il a même acquis des outils d'animation de grands groupe et il pourrait organiser un séminaire produit pour un des managers VP.
[[Conclusion]]
<</if>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - RDB]]
#Y'en a marre du Scrum Master! [[Fast Track Scrum Master - James]] Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[Un refinement revisité - RDB]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - RDB]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - RDB]]<img src="https://picsum.photos/200/300?random=1"/>Quand il s'agit de mettre en place des rétrospectives, James est maintenant rodé. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, il arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand il le peut, il préfère amener des rétrospectives imagées, ludiques.. Mais il commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, il a exploré le SMART de font en comble. Il en est arrivé à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, James voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réelsa
* ...
<<if setup.steps lt 12>>
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#James est devant une équipe dont le PO a de gros soucis de priorisation. James propose d'explorer [[Le WSJF - VP]]
#James travaille le craftsmanship avec son équipe [[Le craftsmanship - VP]]
#La performance de l'équipe est limitée par l’accès aux environnements de test et de production. Il leur parle du [[DevOps et VP]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - VP]]
<<else>>
A force, il arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inéfficace d'un point de vue rapidité de déploiement. Cependant, ca porte ses fruits au niveau qualitatif et ca rend le système relativement pévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Aprés plusieurs mois (ben oui, l'industrie ca réagit pas trés vite) dans ce système, James se dit quand même qu'il faudrait regarder d'autres choses...
<<if setup.steps lt 12>>
#Comme il a entendu parler du [[Kanban - VP]], James se pose la question de savoir si ça ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[James participe à son premier Agi'Lille - VP]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour mettre en place les 3 amigos, James propose au PO, au tech lead et à un testeur "officiel" d'organiser une réunion récurrente.
Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ça reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit James, sauf que du coup les 3 amigos on refait leur travail...
<<if setup.steps lt 12>>
Quelle suite on donne à cette histoire?
#James se dit qu'il a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, il décide, unilatéralement, de mettre en place [[Un refinement revisité - VP]].
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - VP]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - VP]]
<<else>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Dans l'équipe de James, on a compris que la plannification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parceque l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
James n'est pas tombé dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
James décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
<<if setup.steps lt 12>>
Quelle nouvelle phase propose-t-on à James?
#James comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Il propose à cette dernière d'explorer [[Le craftsmanship - VP]]
#Afin de trouver de l'inspiration, James décide d'aller à la rencontre de la communauté Lilloise. [[James participe à son premier Agi'Lille - VP]]
#Y'en a marre de l’esclavage… [[James micro-entrepreneur]]
<<else>>
[[Conclusion]]
<</if>>James se prend une claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. James passe Freelance et débute une mission [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - VP]]
#Un manager lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - VP]] James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
<img src="https://picsum.photos/200/300?random=1"/>Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
<<if setup.steps lt 12>>
Maintenant que nous avons évoqué le run, quel sujet nous intéresse?
#James explore le Kanban car il a entendu que le terme FastLane vient de là. [[Kanban - VP]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - VP]]
#James se lance en freelance et se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - James]]
#James commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[James se lance dans l'écriture d'une conférence - VP]]
<<else>>
James va ensuite poursuivre avec :
* Le Kanban car il a entendu que le terme FastLane vient de là.
* Le Craftsmanship car pour garantir un run constant, rien de tel que l'excellence technique ;)
[[Conclusion]]
<</if>>
La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en armonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à James. Après s'être renseigné sur guntehr-le-jeu.fr, il a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
James est conquis.
<<if setup.steps lt 12>>
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - RDB]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - RDB]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance et explore l’[[Agile Hors IT - James]]
<<else>>
Après avoir découvert Gunther, et c'est du lourd, il s’intéresse au serious gaming encore plus. Il fini par en faire sa spécialité. Il aimerait pouvoir, un jour, en créer un pour RDB. Peut-être aura-t-il la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]]
<</if>>Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
James trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais James est persuadé qu'il pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-il l'atelier "Roule ta bille" ;)
<<if setup.steps lt 12>>
<<else>>
[[Conclusion]]
<</if>>James a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
James profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, James réfléchit au chemin possible pour accompagner VP sur la voie du DevOps.
<<if setup.steps lt 12>>
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - RDB]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - RDB]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance est explore l’[[Agile Hors IT - James]]
<<else>>
Il pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelquechose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelquechose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu'aprés une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ca prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour celà, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à celà, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
<<if setup.steps lt 12>>
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - RDB]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - RDB]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - RDB]]
<<else>>
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF
* Un manager vient voir James avec la fameuse rengaine : L'agile ça coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetée, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - RDB]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - RDB]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - RDB]] , quelles sont ses options?
<<else>>
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]]
<</if>>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage et l'anime auprés d'une des équipes. Ils testent [[Kanbanzine - RDB]]
#Lors d'un accompagnement d'équipe débutante, il utilise[[Scrumble - RDB]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile - RDB]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'une de ces équipes.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu’il voudrait tester, les projets... Il remplit un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
<<if setup.steps lt 12>>
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - RDB]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - RDB]]
#James quitte les Rois du Ballon et passe indep. Quand vient l'heure de trouver une mission il se dit qu'aprés ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]]
<<else>>
[[Conclusion]]
<</if>>James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
Réussira-t-il à faire bouger les choses chez DoctoChat? Quoi qu'il est arrive il s'est déjà inscrit dans le groupe de refléxion RSE.
[[Conclusion]] Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Que fait-il en premier?
#Il décide de [[Gamifier une rétrospective - DoctoChat]]
#Il choisi un outil d'apprentissage et l'anime auprès d'une des équipes. Ils testent [[Kanbanzine - DoctoChat]]
#Lors d'un accompagnement d'équipe débutante, il utilise [[Scrumble - DoctoChat]]
#Il se dit que la communauté agile doit pouvoir l'aider [[James découvre les meetups et Nord Agile - DoctoChat]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'un de ces clients.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>>James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu’il voudrait tester, les projets... Il remplit un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
<<if setup.steps lt 12>>
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - DoctoChat]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - DoctoChat]]
#James quitte DoctoChat et passe indep. Quand vient l'heure de trouver une mission il se dit qu’après ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
<<if setup.steps lt 12>>
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF chez RDB]]
#James propose à un débutant en démarche agile, de travailler d'abord à la [[Valeur Business - RDB]]
avant d'avancer sur le chemin de l'agilisation.
#James a entendu parler d'une nouvelle tendance et propose à un de ses POs de l'investiguer avec lui. [[Shape Up - RDB]]
<<else>>
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, il va pouvoir choisir son ou ses prochains challenges.
* James propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* James propose à un de ses clients, débutant en démarche agile, de travailler d'abord à la valeur Business avant d'avancer sur le chemin de l'agilisation.
* Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.
* James a entendu parler d'une nouvelle tendance, Shape Up, et propose à un de ses clients de l'investiguer avec lui.
[[Conclusion]]
<</if>>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
<<if setup.steps lt 12>>
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF - DoctoChat]]
#James propose au management DoctoCaht d'investiguer la notion de [[Valeur Business - DoctoChat]].
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[Shape Up - DoctoChat]]
<<else>>
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, il va pouvoir choisir son ou ses prochains challenges.
* James propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* James propose à un de ses clients, débutant en démarche agile, de travailler d'abord à la valeur Business avant d'avancer sur le chemin de l'agilisation.
* Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra.
* James a entendu parler d'une nouvelle tendance, Shape Up, et propose à un de ses clients de l'investiguer avec lui.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[Gamifier une rétrospective - DoctoChat]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Kanbanzine - DoctoChat]]
#Il choisit un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Scrumble - DoctoChat]]
#Il se dit qu'il doit acquérir plus d'expérience et [[James découvre les meetups et Nord Agile - DoctoChat]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'une de ces équipes.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
<<if setup.steps lt 12>>
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - DoctoChat]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - DoctoChat]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - DoctoChat]]
<<else>>
A partir de là, il continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'il a des questionnements...
* Il décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. James se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui :
James rejoint Nord Agile.
[[Conclusion]]
<</if>>
James se prend un claque pendant l'atelier, une vraie claque je vous dis... et le rendu!! pow pow pow...
Comprendre les effets primaires, secondaires, tertiaires du changement climatique et espérer identifier les gestes qui aident!!
James a adoré l'atelier, il en est ressorti tout troublé... Mais maintenant il veut l'animer lui même! Alors il se rapproche de l'association pour se lancer dans le cursus d'apprentissage... et qui sait, il ira peut-être jusqu'à la fresque du numérique...
<<if setup.steps lt 12>>
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. James passe Freelance et débute une mission [[Agile dans l'Infra? - James]]
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - VP]]
#Un manager lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - VP]]
<<else>>
Réussira-t-il à faire bouger les choses chez VP? Quoi qu'il est arrive il s'est déjà inscrit dans le groupe de refléxion RSE.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James a une jolie expérience avec ses différentes équipes. Il a passé presque 2 ans au sein de la dernière et les challenges de celle-ci lui ont forgé certaines convictions.
James comprend rapidement qu'avoir une expérience ne fait pas de lui quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider James à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James devrait mettre en place un [[Un miroir coach - VP]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James devrait suivre [[Une formation certifiante Coach - VP]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James devrait participer à l'événement le plus proche de chez elle pour commencer! [[James participe à son premier Agi'Lille - VP]]
<<else>>
Cependant, il a plusieurs possibilités devant lui.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. James prévoit de s'inscrire, enfin si son manager valide le budget, à un cursus de formation "coach progessionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et James se promet de participer à l'événement le plus proche de chez lui pour commencer : Agi'Lille
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à James. Après s'être renseigné sur gunther-le-jeu.fr, il a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
James est conquis.
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - RDB]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - RDB]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance et explore l’[[Agile Hors IT - James]] Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bonne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
James trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais James est persuadé qu'il pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-il l'atelier "Roule ta bille" ;)
James a exploré le DevOps, il fait avancer son équipe sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - RDB]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - RDB]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance et explore l’ [[Agile Hors IT - James]] James a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
James profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, James réfléchit au chemin possible pour accompagner son client sur la voie du DevOps.
Il pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
James a exploré le DevOps, il fait avancer son client sur ce chemin. Quelle est la prochaine étape?
#Il tente de déployer cette pratique en mode amélioration continue mais ce n'est pas si simple ;) [[Le principe de l'amélioration continue face au chaos - RDB]]
#James participe à plusieurs Meetups et manifestations agile de Nord Agile et décide de se joindre à l'association. [[James rejoint Nord Agile - RDB]]
#James est contacté par un cabinet d'architectes pour les aider à être agile? Il passe Freelance est explore l’[[Agile Hors IT - James]] Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - RDB]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - RDB]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - RDB]] James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Aprés refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute trés fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d'aprés.
Aprés 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint aprés refactorisation... mais ca n'aurait sans doute pas fait mouche avec le PO.
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - RDB]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été ebarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - RDB]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - RDB]] , quelles sont ses options?Pour James, son équipe a besoin d'un retour aux bases. Il se penche sur le manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et finit par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Il adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Il a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Il se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. James a gagné son pari même si il ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#James reste persuadée que Scrum est la solution. Il se dit que c'est le contexte qui doit changer, il se propose donc de mettre en place une [[Sensibilisation agile des PP - RDB]]
#James et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes de RDB (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ça, [[James se passionne pour le Serious Gaming - RDB]] L'idée lancée par James va évoluer au fil du temps.
La première chose que James organise c'est un kick off de la communauté. Il invite toutes les personnes du client qui ont montré une appétence sur le sujet agile, ainsi que celles qui occupent des rôles systémiques agiles (Product Owner, Scrum Master...).
Ce collectif se réuni donc pendant 2 heures la première fois afin de définir ensemble les objectifs de la communauté, sa raison d'être. Basée sur les aspirations de chacun et sur ce qu'ils ont compris des volontés agiles de l'entreprise, les objectifs restent trés opérationnels pour la première version :
"S'améliorer entant que groupe dans l'utilisation des pratiques agiles et s'entraider sur les différents challenges de l'entreprise".
Ils discutent ensuite de la forme.
Au départ, ils proposent de créer un rendez-vous récurrent ouvert à tous les agilistes, et utilisent les Agile Topics Cards de Jimmy Janlën
<img src="https://i0.wp.com/agilewithjimmy.com/wp-content/uploads/2020/06/Cards.png?w=600&ssl=1">
Source : https://agilewithjimmy.com
Mais ils se rendent compte qu'au fur et à mesure des sessions, ces rencontres au format "Lean Coffee" ont de moins en moins de succès.
Ils essayent ensuite de proposer un ordre du jour défini à l'avance, cependant, les intervenants sont peu nombreux a proposer des sujets et en plus n'ont que peu de temps à
consacrer à la préparation de leurs rendez-vous.
Les internes considère que la gestion du jour le jour est plus importante que la communauté. James propose de s'investir, de faire venir des externes pour présenter des sujets... Au final, c'est lui, entant que seul coach de la structure qui insuffle toute l'énergie nécessaire à maintenir la communauté à flot. Mais le ROTI reste élevé et c'est sa principale motivation
[[Conclusion]]Pour Eva, son équipe a besoin d'un retour aux bases. Elle se penche sur la manifeste, consulte les différentes tendances (Heart of Agile, FAST Agile...) et fini par trouver une activité qui parlera à l'équipe.
Etant donné que son équipe a déjà une expérience en Scrum, elle se propose de les tester avec un LegoScrum mais qu'elle adapte. C'est d'ailleurs son premier essai à la modificatin (et l'animation?) d'un Serious Game.
Elle adapte le concept afin de vraiment remettre en perspective pour l'équipe qu'ils font de l'agile au lieu d'être agiles. Elle a souvent l'impression qu'ils n'ont pas compris les besoins auxquels répondent les différents rituels et pratiques de Scrum.
Elle se lance donc dans l'animation de son LegoScrum (de batard comme elle l'a appelé). L'animation se passe bien, l'équipe se plie au jeu. Ils travaillent sur les Lego pendant une aprés midi. Forcément, ils échouent beaucoup (d'où le terme de batard) mais finissent par se mettre dans une vraie optique Scrum de création de valeur (avec des Legos, je vous l'ai déjà dit?).
Les conclusions de l'atelier sont sans appel : dans le contexte actuel de LudiGames, faire du pure Scrum n'est pas efficace. Eva a gagné son pari même si elle ne s'attendait pas vraiment à cette conclusion là. Maintenant que l'équipe est convaincue, que faire de cet état des lieux?
#Eva reste persuadée que Scrum est la solution. Elle se dit que c'est le contexte qui doit changer, elle se propose donc de mettre en place une[[Sensibilisation agile des PP - LudiGames]]
#Eva et l'équipe mettent en place un fonctionnement inspiré de Scrum mais qui permet de prendre en compte les contraintes de LudiGames (notamment le besoin de reprioriser plus souvent que les Sprints). D'aucun diront qu'ils se lancent dans du ScrumBan. A côté de ca, [[Eva se passionne pour le Serious Gaming - LudiGames]]
#Déjà 8 étapes de la vie d'une Scrum Master, et si on regardait plus loin?[[Fast Track Scrum Master - Eva]] <img src="https://picsum.photos/200/300?random=1"/>Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva se rend compte qu'elle s'inscrit complètement dans ce mouvement.
Elle propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
<<if setup.steps lt 12>>
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de son client et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[LudiGames et Kanban]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[Une méthode maison pour LudiGames]]
#Eva, se rendant compte de ce qu'elle vaut, se dit que partir sur un rôle de coach pourrait être sa prochaine évolution professionnelle! Cependant [[On ne devient pas coach tout seul chez LudiGames]]
<<else>>
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Eva a une jolie expérience avec son équipe. Elle a passé presque 2 ans au sein de l'équipe et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[Un miroir coach - LudiGames]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[Une formation certifiante Coach - LudiGames]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Cependant, elle a plusieurs possibilités devant elle.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, apaiser parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva prévoit de s'inscrire, enfin si son manager valide le budget, à un cursus de formation "coach professionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva se promet de participer à l'événement le plus proche de chez elle pour commencer : Agi'Lille
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Durant ses différentes missions, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais James sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu'il ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, alors Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu'elle arrive dans un nouveau contexte, même si c'est pour un client qu'elle connait déjà, elle revalide son glossaire et s'assure qu'au tavers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquement, de ces temps-ci, touchée par le [[Syndrôme de l'imposteur - Eva Indep]]
#Eva travaille avec beaucoup d'équipe ces derniers temps et elle aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Eva accepte une mission dans un cabinet d'architectes [[Agile Hors IT - Eva]]
#Eva est contactée pour accompagner des équipes [[Agile dans l'Infra? - Eva]]
<<else>>
[[Conclusion]]
<</if>>Eva a une jolie expérience Maintenant. Elle a passé presque 2 ans au sein des équipes et les challenges de cette dernière lui ont forgé certaines convictions.
Maintenant qu'elle doit accompagner plus de monde, elle comprend rapidement qu'avoir une expérience ne fait pas d'elle quelqu'un d'expérimenté! (Merci Benji).
De plus, il lui semble que le métier de coach, enfin les missions qui semblent s'inscrir dans sa fiche de poste, demande souvent de sortir de l'opérationnel. Ca demande aussi parfois d'aller dans des domaines qui peuvent sortir de la vie même de l'équipe agile "Management", "Transformation de l'organisation"...
C'est pas facile de s'y retrouver!
<<if setup.steps lt 12>>
Comment pouvons nous aider Eva à s'en sortir?
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva devrait mettre en place un [[Un miroir coach - Eva Indep]]
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva devrait suivre [[Une formation certifiante Coach - Eva Indep]]
#En fait, rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva devrait participer à l'événement le plus proche de chez elle pour commencer! [[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
Cependant, elle a plusieurs possibilités devant elle.
#Quand on est coach, l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. Eva va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, apaiser parfois, sur les situations rencontrées pas l'autre.
#Rien de tel que d'acquérir des outils spécifique à l'accompagnement de l'humain et au coaching de manière générale. Eva prévoit de s'inscrire, enfin si son manager valide le budget, à un cursus de formation "coach professionnel" afin d'acquérir de la légitimité en plus de l'outillage humain et méthodologique spécifique à ces accompagnements.
#Rien de tel que de voir ce qu'il se passe chez les autres. Pour cela il existe un grand nombre d'événements agiles et Eva se promet de participer à l'événement le plus proche de chez elle pour commencer : Agi'Lille
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand il s'agit de mettre en place des rétrospectives, Eva est maintenant rodée. De la rétrospective la plus classique à celle qui sorte réellement de l'ordinaire des équipes, elle arrive toujours à s'adapter à la maturité des équipes et au contexte.
Bien sur, quand elle le peut, elle préfère amener des rétrospectives imagées, ludiques.. Mais elle commence à comprendre que l'important c'est que les choses avancent.
Pour faire avancer les choses, elle a exploré le SMART de font en comble. Elle en est arrivée à réduire la définition des actions à 4 informations :
* Quoi
* Qui
* Quand pourra-t-on mesurer le résultat
* Quel indicateur de réussite
Et ca fonctionne trés bien comme ca.
De manière générales, Eva voit passer des équipes qui ont des problèmes :
* De gestion de la priorité
* De détail dans les US
* De définition de prêt ou de terminé
* D'environnement de développement non fiables
* D'environnement de test non iso prod voir inexistants
* D'absence de tests réels
* ...
<<if setup.steps lt 12>>
A force, elle arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place. Cependant parfois il faut creuser un peu plus. C'est à ce moment là que nous arrivons.
#Eva est devant une équipe dont le PO a de gros soucis de priorisation. Eva propose d'explorer [[Le WSJF - Eva Indep]]
#Eva travaille le craftsmanship avec une équipe relativement jeune [[Le craftsmanship - Eva Indep]]
#Une équipe au top de sa force est limitée par l'accés aux environnements de test et de production. Elle leur parle du [[DevOps - Eva Indep]]
#Ne jamais oublier [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
<<else>>
A force, elle arrive à emmener les équipes vers des expérimentations de solutions rapides à mettre en place.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Quand on regarde la manière dont LudiGames gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#Eva propose au Scrum Master de suivre une formation ISTQB. [[8 - Formation ISTQB SM - LudiGames - Coach]]
#Eva propose la mise en place des 3 amigos [[Les 3 amigos - LudiGames]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - LudiGames - Coach]]
<<else>>
C'est alors qu’elle propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Notre start-up, LudiGames, a lancé plusieurs jeux en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Maintenant que plusieurs jeux sont en ligne, qu'ils ont une vision globale de l'entreprise, que les produits vivent chacun leur vie et ont chacun leur base d'utilisateurs (et donc leur liste de demandes en attente), il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
<<if setup.steps lt 12>>
Mais pour se lancer dans une démarche produit, que faut-il explorer en premier?
#Eva propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - LudiGames]]
#Avant tout, Eva veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et elle s'inscrit donc à un [[Eva découvre les meetups et Nord Agile - LudiGames]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Après quelques négociations, [[Eva organise un séminaire produit]] pour LudiGames
<<else>>
[[Conclusion]]
<</if>>Eva propose au PO un accompagnement ciblé. Son objectif est de faciliter la vie de l'équipe en permettant au PO de produire de meilleurs entrants pour l'équipe.
Elle découvre que le PO a été catapulté là uniquement parce qu'il connait bien le métier mais n'a eu aucune formation ou introduction au métier de PO.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour Eva?
#Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. [[Eva devient PPO - LudiGames]]
#Eva le rassure, lui dit qu'il fait déjà un super boulot et lui propose de retravailler les basics. Ils se lancent alors dans une animation d'un atelier de [[Product Box - LudiGames]].
#Eva se rend compte qu'il ne connait pas non plus grand chose au métier de PO. Elle décide alors de [[Se former aux démarches produits - LudiGames]].
<<else>>
Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines tâches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Elle reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Elle réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, Eva a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permis de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
En prenant ces responsabilités de "rédaction", Eva se rend compte que certains basics sont à revoir. Elle propose au PO d'animer un atelier Product Box pour être sur qu'ils sont sur la même longueur d'onde au niveau de la vision du produit.
[[Conclusion]]
<</if>>
Durant ses différentes recherches, Eva a entendu des termes de tout poils, dans tous les contextes :
* Un Scrum Master dans un environnement non Scrum!
* Un PO qui n'a pas la main sur les décisions à propos de son produit, normal, c'est le PM qui les a!
* Des Flow Master
* Des Agile Master
* Des PPO, APO
* Des ScrumDev, ScrumAna, ScrumQA
* Des PMO qui travaillent à des portfolios de projets sans liens avec la vie des produits
* Des PI Planning, dans des contextes non SAFe qui sont en fait des synchros de portfolio dédiées aux chefs de projets
* Des chefs de projets agiles
* Des PM métiers qui n'ont pas la même fiche de poste, mais alors pas du tout, que des PM IT
* ...
Tout accompagnateur des transformations a ce genre de catalogue de termes. Certains y ont même sans doute participé. Mais Eva sait que l'important ce n'est pas le titre mais la responsabilisation des personnes.
Le pire qu’elle ait rencontré, ce n'est pas un titre, mais une attitude, celle du "ce n'est pas dans ma fiche de poste donc je ne le fais pas!".
Alors tant que les choses avancent, tant que la valeur est produite, tant que les individus sont épanouis, Eva ne s'offusque pas.
Elle a maintenant acquis un réflex : à chaque fois qu’elle arrive dans un nouveau contexte, même si c'est pour une équipe ou un domaine qu’elle connait déjà, elle re-valide son glossaire et s'assure qu'au travers des différentes responsabilités il n'y a pas de trou dans la raquette.
Quand tel est le cas, elle sort un outil gamifié, soit le "Delegation poker", soit le "RA Poker" en fonction des personnes en face et des éléments à clarifier.
<<if setup.steps lt 12>>
On en a fini avec la sémantique, repartons dans l'aventure :
#Eva est assez fréquemment, de ces temps-ci, touchée par le [[Syndrôme de l'imposteur - LudiGames]]
#Eva échange avec plusieurs équipes ces derniers temps et elle aime à explorer avec elles [[Le principe de l'amélioration continue face au chaos - LudiGames]]
#Eva pourrait se lancer tout seul [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>>Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
<<if setup.steps lt 12>>
Eva se propose d'étudier les points de concordance entre l’équipe et la rache. Et ensemble, ils décident de s'attaquer à :
#Eva propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - Eva Indep]]
#Eva essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, elle tombe sur [[Le WSJF - Eva Indep]]
#Eva propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - Eva Indep]]
#Eva propose à l'équipe d'explorer le [[Kanban - Eva Indep]]
<<else>>
[[Conclusion]]
<</if>>Le développeur présente la méthode, très sérieusement au début puis ne peut s'empêcher de pouffer... bien sur que c'est un troll!!
<img src="https://www.la-rache.com/img/process.jpg">
Source www.la-rache.com
Mais mine de rien ça n'est pas si loin de certaines réalités...
<<if setup.steps lt 12>>
James se propose d'étudier les points de concordance entre VP et la rache. Et ensemble, ils décident de s'attaquer à :
#James propose de travailler avec le PO et de mettre en place une véritable priorisation par la valeur. [[Prioriser en tailles de TShirt - James Indep]]
#James essaye de se renseigner sur de nouvelles manières d'aborder la priorisation, il tombe sur [[Le WSJF - James Indep]]
#James propose à l'équipe de se concentrer sur la qualité technique (ainsi qu'aux compétences liées). [[Le craftsmanship - James Indep]]
#James propose à l'équipe d'explorer le [[Kanban - James Indep]]
<<else>>
[[Conclusion]]
<</if>>Que ce soit une formation spécifique coaching par un organisme spécialisé, ou un DU dans l'accompagnement des personnes(coaching professionnel), James a plusieurs options pour se former.
Il décide de partir pour une formation format "Bootcamp" de plusieurs sessions de 2 jours à chaque fois.
Alors certes, l'investissement à la fois financier mais aussi en temps n'est pas anodin, mais James s'y retrouve. En effet, non seulement il peut maintenant se lancer dans des accompagnements vraiment interessants, mais il est aussi outillée pour mieux se positionner dans ses missions existantes.
Alors James commence des accompagnements nouveaux. On lui propose d'accompagner un manager junior dans un autre domaine de l'entreprise, mais également la mise en place d'une démarche OKR au sein de DoctoChat
James s'inscrit même à l'ICF pour cotoyer d'autres coachs, de spécialités différentes.
Maintenant James peut s'orienter où il veut.
* James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création, il se passionne pour le Serious Gaming.
* il continue à déployer la démarche OKR chez DoctoChat
[[Conclusion]]
Quand on est coach (ou scrum master), l'important c'est de savoir dire quand on ne sait pas. Il ne faut pas hésiter à se faire accompagner par un autre coach dans les situations qui sortent de notre expérience. James va mettre en place un miroir agile: une relation de confiance avec un autre coach. Chacun se rend disponible pour l'autre afin d'apporter un point de vue extérieur, appaisé parfois, sur les situations rencontrées pas l'autre.
James choisit une coach croisée lors d'une précédente mission.
Quand on est coach, il faut souvent être en "représentation"... laisser transpirer la confiance... il est parfois compliqué de laisser les personnes en face douter de vous, surtout quand on est indep.
Certes, comme dit avant, quand on ne sait pas, on ne sait pas... mais quand on hésite, avant de l'aborder avec le client, on peut appeler son miroir.
De plus, on se retrouve parfois dans des situations délicates, humaines, politiques, hiérarchiques... et le fait d'avoir une personne externe qui aide à prendre du recul est primordial.
<<if setup.steps lt 12>>
Maintenant que nous avons exploré, un peu, le principe de miroir, que va faire notre coach agile?
#James a eu la chance d'utiliser beaucoup de serious games dans sa carrière, de fait il veut essayer de se prêter au jeu de la création [[James se passionne pour le Serious Gaming - DoctoChat]]
#Un client de James lui demande d'organiser un séminaire pour définir une démarche agile commune. [[James organise un séminaire produit - DoctoChat]]
<<else>>
[[Conclusion]]
<</if>>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
<<if setup.steps lt 12>>
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - RDB]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - RDB]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - RDB]]
<<else>>
A partir de là, il continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'il a des questionnements...
* Il décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. James se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui :
James rejoint Nord Agile.
[[Conclusion]]
<</if>>
Le serious gaming, souvent associé à la "Ludopédagogie", consiste à utiliser des pratiques ludiques dans le monde du travail (sérieux).
En se renseignant un peu plus, James arrive à la conclusion qu'il existe plusieurs types de serious games :
* Les serious games d'apprentissage (ludopédagogie), qui servent à apprendre ou faire apprendre des notions / pratiques... aux participants.
* Les serious games d'analyse, qui permettent de faire un état des lieux d'une pratique, d'un fonctionnement, d'un process pour mettre en évidence ce qui marche et ce qui ne marche pas.
* Les serious games de pratique, qui sont des outils ludiques utilisés dans le monde professionnel pour faciliter une pratique donnée. (ex Les chapeaux de Bono pour la prise de décision).
James découvre en ligne plusieurs sites bourrés de ressources :
* Openseriousgames.org
* Hacoeur.biz (Humain Au Coeur)
* Serious Games : Le recueil du coach agile! sur coach-agile.com
* ...
<<if setup.steps lt 12>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
#Il décide de [[Gamifier une rétrospective - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Kanbanzine - RDB]]
#Il choisi un outil d'apprentissage qu'il présente à son équipe. Ils testent [[Scrumble - RDB]]
#Il se dit qu'il doit acquérir plus d'expérience et [[James découvre les meetups et Nord Agile - RDB]]
<<else>>
James est paré, il se lance. Il a plein de choix possibles pour se lancer.
* Gamifier une rétrospective
* Choisir un outil d'apprentissage, Kanbanzine, et l'animer auprés d'une de ces équipes.
* Lors d'un accompagnement d'équipe débutante, utiliser Scrumble
* Découvrir d'autres outils dans les meetups et Nord Agile
[[Conclusion]]
<</if>><<if setup.steps lt 12>>
James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez VP il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[9 - DevOps et VP]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[9 - Le WSJF - VP]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[9 - Kanban - VP]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
James se focalise sur les attentes de son équipe. Il décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Il prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Il reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Il réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, James a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
Au bout de quelques temps, James se rend compte des difficultés rencontrées par le PO. Il se propose donc de :
* Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO.
* Aborder la Valeur Business
* Déployer le WiSJiF
[[Conclusion]]
<</if>>L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
<<if setup.steps lt 12>>
Que se passe-t-il ensuite pour James?
#Avec le PO ils tombent d'accord : il faut travailler à la [[9 - Valeur Business - RDB]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[9 - Le WSJF chez RDB]]
#Maintenant que l'équipe est au fait de la vision produit, James s'attaque à la gestion de [[9 - La dette technique et Scrum - RDB]]
<<else>>
* Le document permet à l'ensemble des parties prenantes impliquées dans le produit de se rendre compte qu'il faut apprendre à dire Non. (Comme dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg traduite par Fred Lothon).
* Malgré une superbe product box, le produit (ou le projet) continue à ne pas répondre aux promesses. Les retours des premiers testeurs sont mauvais. James explore les méandres du droit à l'échec.
[[Conclusion]]
<</if>>Quand on regarde la manière dont RDB gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - RDB]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - RDB]]
#Le Scrum Master propose la mise en place d'[[Un déversement de backlog - RDB]]
<<else>>
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>L'idée lancée par James va évoluer au fil du temps.
La première chose que James organise c'est un kick off de la communauté. Il invite toutes les personnes du client qui ont montré une appétence sur le sujet agile, ainsi que celles qui occupent des rôles systémiques agiles (Product Owner, Scrum Master...).
Ce collectif se réuni donc pendant 2 heures la première fois afin de définir ensemble les objectifs de la communauté, sa raison d'être. Basée sur les aspirations de chacun et sur ce qu'ils ont compris des volontés agiles de l'entreprise, les objectifs restent trés opérationnels pour la première version :
"S'améliorer entant que groupe dans l'utilisation des pratiques agiles et s'entraider sur les différents challenges de l'entreprise".
Ils discutent ensuite de la forme.
Au départ, ils proposent de créer un rendez-vous récurrent ouvert à tous les agilistes, et utilisent les Agile Topics Cards de Jimmy Janlën
<img src="https://i0.wp.com/agilewithjimmy.com/wp-content/uploads/2020/06/Cards.png?w=600&ssl=1">
Source : https://agilewithjimmy.com
Mais ils se rendent compte qu'au fur et à mesure des sessions, ces rencontres au format "Lean Coffee" ont de moins en moins de succès.
Ils essayent ensuite de proposer un ordre du jour défini à l'avance, cependant, les intervenants sont peu nombreux a proposer des sujets et en plus n'ont que peu de temps à
consacrer à la préparation de leurs rendez-vous.
Les internes considère que la gestion du jour le jour est plus importante que la communauté. James propose de s'investir, de faire venir des externes pour présenter des sujets... Au final, c'est lui, entant que seul coach de la structure qui insuffle toute l'énergie nécessaire à maintenir la communauté à flot. Mais le ROTI reste élevé et c'est sa principale motivation
<<if setup.steps lt 12>>
#Un des problèmes communément remonté lors des Q&R se situe dans la gestion du RUN, James cherche des réponses. [[Gérer le run en Scrum - James Indep]]
#Au bout de quelques rencontres, James et la communauté proposent la mise en place du rôle de [[Scrum Master et QA - James Indep]]
#Aprés autant d'aventure, James se cherche [[Une formation certifiante Coach - James Indep]]
#Il sait maintenant comment présenter des sujets du fait [[James se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>James choisit une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de ces client.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour LudiGames. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - James Indep]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son client d'organiser un séminaire afin de continuer à faire avancer Vertes Prairies dans le bon sens. [[James organise un séminaire produit - Indep]]
#Maintenant que tout le monde est formé, James propose à son sponsor de mettre en place [[Un comité de transformation - James Indep]]
<<else>>
Au retour de leur formation, les parties prenantes veulent absolument se lancer : les promesses de Scrum sont géniales et en plus, les exemples donnés par le formateur donnent envie... il faut tout faire comme il a dit.
Donc ils se lancent, l'équipe se recentre sur ses basiques (by the book) :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'ils sont apparemment entrés en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il lui faut revoir sa copie. Il décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quitte à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le client de James a lancé plusieurs initiatives en même temps. Jusqu'à maintenant, chaque lancement a été pris comme un projet par les dirigeants et les "sachants".
Il semble qu'il est grand temps de mettre en place une démarche plus proche de la vie des applications et des équipes.
Mais pour se lancer dans une démarche produit, James a du pain sur la planche.
<<if setup.steps lt 12>>
James propose d'évangéliser toutes les parties prenantes à la démarche agile [[Sensibilisation agile des PP - James Indep]]
#Avant tout, James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise [[James découvre les meetups et Nord Agile - Indep]]
#Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations, [[James organise un séminaire produit - Indep]]
<<else>>
* Il va lui falloir évangéliser toutes les parties prenantes à la démarche agile.
* James veut se familiariser avec les différents sujets de la product-o-sphère Lilloise, et il s'inscrit donc à un Meetup produit.
* Rien de tel qu'une grand messe pour lancer une refondation de la manière de travailler. Aprés quelques négociations,James organise un séminaire produit.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pas facile de transformer une vision en action.
Mais il a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être James les animera-t-il en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. James en parle à son manager qui devra faire son choix.
<<if setup.steps lt 12>>
Que voulez-vous voir ensuite?
#On a envie d'en s'avoir plus sur la[[Démarche OKR - James Indep]]
#Le client de James lui demande d'animer un séminaire autour de la notion de produit. [[James organise un séminaire produit - Indep]]
#Une vision nouvelle, des actions qui animent cette vision, ca fait beaucoup de chaos tout ca non? [[Le principe de l'amélioration continue face au chaos - James Indep]]
<<else>>
[[Conclusion]]
<</if>>James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez VP. Il lui propose de mettre à plat le workflow de création de valeur chez VP.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez VP il ne le font pas).
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[9 - DevOps et VP]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[9 - Le WSJF - VP]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[9 - Kanban - VP]] en espérant prouver par l'exemple que le workflow actuel est saturé.James en a beaucoup entendu parlé de l'Agile Games France. Dans les meetups et conférences agiles, lors de discussions avec d'autres coach / serious gamers, mais elle n'a pas encore eu l'occasion d'y participer.
Cette année bingo! Il réussi à obtenir sa place (ben oui, y'en a qu'une petite centaine chaque année). Il prépare son matos, les ateliers qu’il voudrait tester, les projets... Il remplit un sac de jeux de sociétés et il décolle pour la destination de l'année (l'événement change de lieu chaque année).
Arrivé là bas c'est le grand choc!! Choc culturel d'abord : tout le monde sourie, tout le monde est content, tout le monde semble connaître tout le monde et même si on te connaît pas tu fais partie de la famille. Choc organisationnel ensuite : y'a pas d'organisation!
Les "non organisateurs" ont négocié un lieu, un tarif, du couchage, des repas et c'est tout.
Durant l'événement du fait, c'est un grand forum ouvert... et il arrive ce qu'il devait arriver (les adeptes des forums ouverts sauront de quoi je parle).
James passe 2 jours formidables, hors du temps. Deux jours à apprendre, échanger, rigoler, pleurer parfois... mais 2 jours riches en émotions, expériences, découvertes et introspection.
Il y croise les grands noms du serious gaming agile francais, tout comme les débutants ou les simples "consommateurs" de serious games.
Il partage avec Dom, qui lui raconte que c'est grace à cet événement qu'il a changé de société il y a quelques années. La différence entre ce qu'il avait vécu avec le groupe pendant deux jours et ce qu'il vivait à l'époque dans sa société était tel qu'il avait eu une grosse remise en question en rentrant... 3 mois aprés il avait quitté sa société pour une plus proche de ses valeurs.
Fort de cette expérience, James retourne à son quotidien.
<<if setup.steps lt 12>>
#Suite aux échange qu'il a eu durant l'événement, [[James se lance dans l'écriture d'une conférence - Indep]]
#James décide de sortir de sa zone de confiance et accepte une mission qu'il n'aurait même pas considéré quelques semaines auparavant. [[James organise un séminaire produit - Indep]]
#James se dit qu'aprés ce qu'il a vécu pendant 2 jours, et la diversité des origines des participants, il peut se lancer avec l'[[Agile Hors IT - James]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! James n'est pas décu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadé qu'[[On ne devient pas coach tout seul - James Indep]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille entant qu'Indep]]
<<else>>
[[Conclusion]]
<</if>>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
<<if setup.steps lt 12>>
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - James Indep]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - Indep]]
<<else>>
A partir de là, il continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'il a des questionnements...
* Il décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. James se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui :
James rejoint Nord Agile.
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quel est le prochain challenge de James?
<<if setup.steps lt 12>>
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF - James Indep]]
#James propose à un de ses clients, débutant en démarche agile, de travailler d'abord à la [[Valeur Business Client - James Indep]] avant d'avancer sur le chemin de l'agilisation.
#Il est contacté via Linked In par une de ses relations. Il n'a jamais réellement travaillé avec lui mais ce dernier a beaucoup entendu parler de lui. Il lui propose une rencontre car il cherche un Scrum Master pour plusieurs de ses équipes dans l'Infra. [[Agile dans l'Infra? - James]]
#James a entendu parler d'une nouvelle tendance et propose à un de ses clients de l'investiguer avec lui. [[Shape Up pour son client - James Indep]]
<<else>>
* James propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* James propose à VP de travailler d'abord à la valeur Business.
* James a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec lui.
[[Conclusion]]
<</if>>La légende raconte que Gunther, en se rendant à la PMU (Porcherie Mutuelle Urbaine), rencontre Dave Ops, une licorne qui lui parle d'un monde merveilleux, dans lequel les développeurs et les Ops vivent en harmonie, voir ne font qu'un...
C'est ainsi qu'on a présenté Gunther à James. Après s'être renseigné sur guntehr-le-jeu.fr, il a eu la chance de participer à présentation de l'atelier lors d'un événement agile.
L'outil est interessant : au travers d'itérations catastrophiques d'un point de vue création de valeur, les participants apprennent ce qui fait du DevOps une solution efficace, humaine et pratique.
L'atelier présente la vison de l'entreprise Techsys de ce que représente le DevOps.
Le plateau évolue en fonction des expériences vécues par les utilisateurs et l'entreprise a même prévu de pouvoir faire évoluer leur jeu en fonction des nouvelles pratiques, technos...
James est conquis.
Après avoir découvert Gunther, et c'est du lourd, il s’intéresse au serious gaming encore plus. Il fini par en faire sa spécialité. Il aimerait pouvoir, un jour, en créer un pour DoctoChat. Peut-être aura-t-il la chance d'obtenir un budget pour se faire accompagner...
[[Conclusion]] Cet atelier, créé par Alexandre Boutin, permet de vivre un workflow de production peu efficace. Au travers d'une chaine de transmission de mission de dés, chaque joueur ayant des set de dés différents, l'équipe chercher à produire un maximum de valeur.
D'abord le système est peu efficace, car chacun reste dans son pré carré, puis, à force de discussion, et ou, de direction de la part de l'animateur, les participants mettent en place des actions d'aide au franchissement des étapes (goulots d'étranglement).
Souvent utilisé pour montrer l'impact de la bnne ou mauvaise gestion du WIP, ainsi que de la nécessité de se responsabiliser, en équipe, au bon fonctionnement du process (comme la démarche Kanban le préconnise), l'atelier peut également être utilisé pour mettre en avant l'impact du déploiement d'une démarche DevOps, ou du moins de ses prémices, au sein d'une entreprise / équipe.
James trouve l'atelier facile à animer et propose d'organiser une session avec son équipe.
L'équipe est emballée mais James est persuadé qu'il pourrait aller encore plus loin dans la démonstration... Peut-être explorera-t-il l'atelier "Roule ta bille" ;)
[[Conclusion]] James a du s'y reprendre à plusieurs fois pour comprendre les règles de cet atelier.
En gros, ce qu'il en a retenu : Au travers de constructions Lego, les participants vivent un workflow de mise en production traditionnel, avec sa documentation ou son manque de documentation (représentée par des barres de chocolat), ainsi que les évolutions du process lorsque le DevOps se déploie.
James profite d'un meetup pour tester l'atelier avec quelqu'un qui l'a déjà animé. L'outil fait l'affaire même s'il n'est sans doute pas à mettre dans les mains des diabétiques ;)
Maintenant, James réfléchit au chemin possible pour accompagner VP sur la voie du DevOps.
Il pense se lancer sur ce chemin via de l'amélioration continue, mais quand on parle d'amélioration continue, il est important de prendre en compte l'objet de l'amélioration. Plus on tente d'améliorer quelque chose qui est impacté par une fréquence élevée, plus l'amélioration, ou la dégradation, sera visible rapidement.
On ne parle pas ici du principe du Kaizen, qui permet d'envisager l'amélioration continue comme un tout, et qui lui permet également de s'assurer de son efficacité. Non, on parle de la notion de perturbation (chaos) engendré par l'amélioration.
Qui dit amélioration dit généralement modification, changement, suppression ou ajout. Toute amélioration prend du temps à se mettre en place et demande plus de temps encore avant que les effets ne soient visibles. On parle généralement de 2 à 3 cycles avant que le changement ne soit en place et de 2 à 3 cycles de plus avant de pouvoir en mesurer les effets.
Si on tente de modifier quelque chose qui a lieu tous les jours (comme le daily par exemple), il y a de grandes chances qu’après une semaine à 10 jours, on soit capable de dire si il y a eu amélioration ou dégradation.
Si en revanche, on tente de changer la manière dont on rédige les US par exemple, ça prendra beaucoup plus de temps. Il faudra compter entre 2 et 3 sprints avant que le changement ne soit réellement en place (c'est à dire que toutes les US embarquées soient au nouveau format), et 2 à 3 sprints de plus avant de valider que l'amélioration attendue est là.
C'est une donnée à prendre en compte lorsqu'on se lance avec des démarches d'amélioration continue. C'est pour cela, par exemple, qu'il est important pour une équipe, de changer régulièrement le prisme de la rétrospective. Ne pas toujours se focaliser sur les mêmes parties du process permet de générer des actions d'amélioration qui seront sans doute indépendantes de celles déjà en court.
Quand on ajoute à cela, la nécessité de mesurer (ou valider) que l'amélioration est effective, on en arrive vite à l'importance de suivre correctement les actions d'amélioration continue ainsi que d'identifier la fréquence qui les anime ainsi que l'élément mesurable qui permettra de valider qu'elle est efficace.
[[Conclusion]] Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
James a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour James, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour lui le moment de découvrir des pratiques qu'il n'avait pas encore envisagées.
Il a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'il a déjà rencontrées.
Au sortir de l'événement, James peut prendre plusieurs directions :
#James a adoré les ateliers ludiques auxquels il a participé. Il souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres... [[9 - James découvre le Serious Gaming - RDB]]
#James a pris le temps de discuter avec les coachs agiles qu'il a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions de James, comme si chacun souhaitait lui faire un petit cadeau. [[9 - James rencontre des coachs inspirants - RDB]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez lui, James se prend une grosse claque au moral. Il ne se sent pas à sa place et se prend un gros [[9 - Syndrôme de l'imposteur - RDB]]
#Aprés l'atelier auquel il a participé, [[9 - James se passionne pour le No Estimate - RDB]]
#Pour lui c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[9 - James se lance dans l'écriture d'une conférence - RDB]]
Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
James se sent flaté d'être si vite intégré dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais il se sent intégré, écouté, entouré, accepté. Alors il essaye de faire de même avec les personnes qu'il croise. Il essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca le conforte dans son idée de se lancer dans le coaching avec un miroir.
Quelle est sa prochaine étape?
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour James. [[James se passionne pour le Serious Gaming - RDB]]
#Lors d'une discussion en OFF il entend parler de l'AGFr et décide de tenter de s'y inscrire.[[Agile Games France - RDB]]
#Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour lui. [[James rejoint Nord Agile - RDB]]
<img src="https://picsum.photos/200/300?random=1"/>James choisit une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de RDB.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour RDB. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - RDB]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer Vertes Prairies dans le bon sens. [[James organise un séminaire produit - RDB]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation - RDB]]
#James se lance tout seul. [[James micro-entrepreneur]]
<<else>>
Au retour de leur formation, les parties prenantes veulent absolument se lancer : les promesses de Scrum sont géniales et en plus, les exemples donnés par le formateur donnent envie... il faut tout faire comme il a dit.
Donc ils se lancent, l'équipe se recentre sur ses basiques (by the book) :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
James essaye de déterminer la raison principale de cette problématique. Il se rend compte qu'ils sont apparemment entrés en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il lui faut revoir sa copie. Il décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>James passe beaucoup de temps à préparer la formation. On l'avait prévenu : l'ingénieurie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour James c'est sa première formation.
James passe du temps à préparer un plan, puis il le jette à la corbeille quand il commence à compiler ses slides et qu'il essaye de raconter une histoire cohérente.
Il commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Il promet de mettre à jour son cursus pour la prochaine session.
Il a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'il souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de RDB.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour James?
#Avant d'avancer plus avant dans une vraie démarche produit, James souhaite voir comment fonctionne Scrum pour RDB. Il tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - RDB]]
#James ne veut pas en rester là avec la démarche produit. Il propose à son manager d'organiser un séminaire afin de continuer à faire avancer RDB dans le bon sens. [[James organise un séminaire produit - RDB]]
#Maintenant que tout le monde est formé, James propose à son management de mettre en place [[Un comité de transformation - RDB]]
#Avec cette expérience complémentaire en poche, James passe indépendant. [[James micro-entrepreneur]]
<<else>>
* James se retrouve rapidement confronté au ShuHaRi quand il s'agit du déploiement de Scrum.
* Après quelques temps, il se rend compte que la notion même de produit mériterait d'être définie pour VP.
* Il réfléchit à proposer la mise en place d'un comité de transformation.
James restera-t-il longtemps chez RDB ou franchira-t-il le cap de l'indépendance?
[[Conclusion]]
<</if>>Pas facile de transformer une vision en action.
Mais il a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être James les animera-t-il en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. James en parle à son manager qui devra faire son choix.
[[Conclusion]] Un premier meetup c'est toujours une expérience!! James n'est pas deçu.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!!
James échange avec des personnes de tous horizons : du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James décide de s'engager un peu plus dans la communauté agile locale et [[James rejoint Nord Agile - Indep]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[James participe à son premier Agi'Lille - Indep]]
#Plusieurs personnes lui remontent qu'il devrait parler de son expérience dans une conférence. En effet, James interesse les participants à tous les événements auxquels il assiste.[[James se lance dans l'écriture d'une conférence - Indep]]
#A force de rencontrer autant de personnes sachantes et expérimentées, James se prend un bon gros [[Syndrôme de l'imposteur - James Indep]]
<<else>>
Il revient régulièrement sur les deux meetups, s'interesse à Nord Agile, puis à l'Agi'Lille.
L'horizon des événements agiles lui est maintenant ouvert et il se déplace sur quelques événements au niveau national, mais toujours en faisant attention de ne pas négliger sa facturation ;)
Aprés quelques événements, il développe l'envie de rendre à la communauté à hauteur de ce qu'il y a récupéré depuis quelques mois. Il commence à rédiger une conférence. Peut-être le croiserez vous lors de vos prochaines participations;)
[[Conclusion]]
<</if>>
Comme beaucoup de personnes, les membres de l'équipe de James appellent leur tableau de suivi de leurs tâches / user stories un kanban.
Donc, quand un contact en ligne de James lui propose d'explorer le kanaban, il ne comprend pas tout de suite ce qu'il propose. Cycle time, lead time, il ne voit pas de quoi il parle.
Aprés quelques recherches, il trouve quelques renseignements complémentaires. Il comprend que la démarche Kanban est une approche systémique de la machine de production. Qu'elle se focalise sur le process de création, de l'idée à la fin de vie potentielle.
En entrant correctement toutes les étapes de production, à partir du moment où l'idée apparait dans le système au moment ou la solution est livrée aux utilisateurs, on peut ensuite suivre les différents temps requis pour passer les étapes, travailler, de fait, aux goulots d'étranglements (boottlenecks en anglais).
Il se rend compte qu'en aucun cas, le tableau qu'ils utilisent avec son équipe n'est un tableau kanban.
Plusieurs choses l'interessent énormément dans la démarche kanban, notamment le principe de limite du travail en cours (limite de WIP) et la responsabilisation de toute l'équipe à faire avancer les étapes.
<<if setup.steps lt 12>>
Que peut-on lui proposer pour la suite sur ce sujet?
#James devrait explorer l'atelier [[Kanbanzine - DoctoChat]] pour faire découvrir, par la pratique, ces différents concepts à son équipe.
#Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à [[Une formation avec Laurent Morisseau - DoctoChat]]?
#Quelque soit la manière, elle réussi à déployer la démarche auprés de son équipe. Maintenant il lui faut expliquer au management que [[Le Kanban ca marche, mais ca prend du temps! - DoctoChat]].
<<else>>
James a plusieurs chantiers devant lui :
* Explorer l'atelier Kanbanzine pour faire découvrir, par la pratique, ces différents concepts à son client.
* Quitte à explorer ce sujet, pourquoi ne pas se renseigner directement à la source et s'inscrire à une formation avec Laurent Morisseau
* Quelque soit la manière, il réussi à déployer la démarche auprés de VP. Maintenant il lui faut expliquer au management que le Kanban ca marche, mais ca prend du temps!.
[[Conclusion]]
<</if>>Se former au test, quelle drôle d'idée? Pas vraiment pour James, ni pour le Scrum Master qu'il a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ça va faire bien sur son CV!!
James a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
<<if setup.steps lt 12>>
#Le test c'est super, mais James a l'impression que le monde agile n'est pas trop versé à ce langage. Il décide d'aller voir ce qu'en dit la communauté. [[James participe à son premier Agi'Lille entant qu'Indep]]
#Avec le Scrum Master, James se lance dans la mise en place des [[Les 3 amigos - James Indep]]
#Le test géré, James s’intéresse à [[La dette technique et Scrum - James Indep]]
<<else>>
Le Scrum Master parle à Eva des 3 Amigos...
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
James se dit que cette pratique est formidable et qu’il doit en parler autour de lui et la mettre en action.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le raisonnement de James et Jean-Paul (un vieux de la vieille chez un de ces clients) est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! James et Jean-Paul devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#James décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[Les 3 amigos - James Indep]]
#James et le Scrum Master montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble interessé et propose le lancement d'une expérimentation... mais [[Ca peut vraiment être efficace? - James Indep]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, James se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Nouveau challenge pour James : il doit accompagner DoctoChat dans la création d'une nouvelle équipe. Cette équipe devrait permettre d'augmenter la capacité du client à délivrer de la valeur sur un produit existant.
Devant lui se profilent différentes solutions.
Il peut proposer de créer une équipe de zéro. En recrutant de nouveaux développeurs, un Scrum Master déjà expérimenté et en travaillant à l'identification du périmètre de responsabilités de cette équipe.
Il faudra trouver un PO, sans doute quelqu'un déjà présent au sein du client et travailler avec lui sur la définition du backlog. L'avantage de cette situation c'est que James a déjà parcouru ce chemin avec un PO junior dans une précédente mission. Il connait les difficultés et pourra accompagner le Scrum Master et le PO dans leurs apprentissages respectifs.
Le client pourrait aussi créer une nouvelle équipe de zéro, conserver un seul PO et un périmètre commun aux deux équipes. De ce fait, l'équipe la plus ancienne pourrait travailler sur les sujets les plus urgents / délicats, pendant que la nouvelle équipe prendrait en charge les petites évolutions et anomalies peu impactantes...
James repense à un échange qu'il a eu en ligne il y a quelques temps et se dit que le "seeding" (enfin, elle pense que c'est comme ca que la personne en face l'avait appelé) pourrait être également une solution interessante: diviser l'équipe actuelle en 2 et compléter les demi équipes avec des nouveaux membres. L'avantage c'est que les anciens de chaque équipe pourront accompagner les nouveaux dans leurs apprentissages et que les fonctionnements de l'ancienne équipe seront plus faciles à dupliquer.
La nouvelle équipe est créée. Le client de James a choisi l'option "Seeding".
Il est aussi possible que le client ne lui laisse pas le choix et qu'il doive composer avec une équipe de 15 personnes. Si c'est cette solution qui est choisie, il se demande si le modèle Scrum chez son client ne va pas exploser...
[[Conclusion]] <img src="https://picsum.photos/200/300?random=1"/>Eva choisit une formation pragmatique à la démarche agile. 2 jours, avec beaucoup de mises en pratique.
Entre Le Bâton d'Helium, les balles supersoniques, la corde carrée et autres ateliers, les participants semblent avoir compris ce qui se cache derrière le manifeste et Scrum
En plus, l'organisme de formation étant certifié Qualiopi, James est assuré que les acquis des participants ont été testés.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[Eva organise un séminaire produit]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[Un comité de transformation - LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe après. [[Eva micro-entrepreneuse]]
<<else>>
Au retour de leur formation, les parties prenantes veulent absolument se lancer : les promesses de Scrum sont géniales et en plus, les exemples donnés par le formateur donnent envie... il faut tout faire comme il a dit.
Donc ils se lancent, l'équipe se recentre sur ses basiques (by the book) :
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu'ils sont apparemment entrés en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
Fort de ce constat, il lui faut revoir sa copie. Elle décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>>Eva passe beaucoup de temps à préparer la formation. On l'avait prévenu : l’ingénierie pédagogique peut prendre jusqu'à 3 fois la durée de la formation.
En plus pour Eva c'est sa première formation.
Elle passe du temps à préparer un plan, puis elle le jette à la corbeille quand elle commence à compiler ses slides et qu'elle essaye de raconter une histoire cohérente.
Elle commence la formation par s'inspirer des vidéos de Simon Sinek pour parler des hormones EDSO et raconter la démarche agile à partir de là.
Au final, la formation dure 1,5J. Les retours sont plutôt bons même si les participants lui avouent qu'ils auraient aimé avoir plus de mise en pratique. Elle promet de mettre à jour son cursus pour la prochaine session.
Elle a tout de même pu valider, via un Quizz en ligne, que les participants avaient acquis la plupart des concepts et pratiques qu'elle souhaitait leur communiquer.
Maintenant il faut valider que le fonctionnement agile de LudiGames.
<<if setup.steps lt 12>>
Quelle est la prochaine étape pour Eva?
#Avant d'avancer plus avant dans une vraie démarche produit, Eva souhaite voir comment fonctionne Scrum pour LudiGames. Elle tente de travailler avec son équipe à appliquer scrum "by the book". [[Le ShuHaRi appliqué à Scrum - LudiGames]]
#Eva ne veut pas en rester là avec la démarche produit. Elle propose à son manager d'organiser un séminaire afin de continuer à faire avancer LudiGames dans le bon sens. [[Eva organise un séminaire produit - LudiGames]]
#Maintenant que tout le monde est formé, Eva propose à son management de mettre en place [[Un comité de transformation - LudiGames]]
#Y'en a marre du Scrum Mastering, voyons ce qui se passe aprés. [[Eva micro-entrepreneuse]]
<<else>>
[[Conclusion]]
<</if>>Ce n'est pas le première fois qu'Eva entend parler du WSJF. On lui avait présenté, la première fois, comme une manière tendance de gérer les matrices de priorité.
On calcul le coût du delai en donnant des tailles de tshirt à la valeur produite par chacun des items de la liste, puis on donne une autre taille de tshirt à la notion de criticité temporelle, et pour finir on donne une notion de levée de risque à cette même liste, toujours sur une échelle en taille de tshirt.
Une fois ces données récoltées, on les cumule pour obtenir ce qu'on appelle le "Coût du délai" puis on divise ce dernier par leurs tailles projetées en effort.
L'explication s'était arrêtée là...
Les plus alertes d'entre nous auront tout de suite compris pourquoi ca n'avait pas vraiment parlé à Eva la première fois.
Avant d'aller dans une explication plus "réaliste" du WSJF, voyons ce que la première définition fournie à Eva amenait comme problématiques :
* Pas de définition de l'acronyme
* Eva n'a pas du tout compris ce qu'on appelle la levée de risque
* A aucun moment on ne parle de l'aspect relatif des estimations prises en compte dans le calcul
Donc, reprenons au début...
WSJF ou Weighted Shortest Job First, la capacité de prioriser les travaux en fonction du plus petit effort pour la plus grande valeur dégagée.
En effet, le WSFJ va diviser un "coût du délai" par un "effort de mise en oeuvre".
Ce coût du délai utilise 3 notions : la valeur business / utilisateurs, la criticité temporelle , la réduction de risque / opportunité.
Chacune de ces estimations se veulent relatives au sein du backlog (liste d'item évalués). On compare les éléments de la liste les uns par rapport aux autres. Si l'élément 1 apporte 5 fois plus de valeur que l'élément 2, on pourrait, par exemple, lui donner une valeur de 5 quand l'élément 2 aurait 1. On compare les choses entre elles plutôt que d'essayer de les mettre sur une table de valeur à l'échelle de l'entreprise.
La valeur business / utilisateurs correspond exactement à ce que vous pensez ;)
La criticité temporelle nous permet d'indiquer si des éléments de la liste ont une contrainte temporelle de délai de mise en production, d'engagement légal...
La réduction de risque / opportunité permet d'indiquer si l'élément est bloquant pour un autre item, par exemple, s'il aide à lever un risque important...
Comme on compare les éléments les uns par rapport aux autres, on essaye de garder une échelle de valeurs petite, des tailles de tshirt peuvent faire l'affaire à condition de les retranscrire en chiffres lors du calcul.
L'effort pris en compte dans la division est également relatif, et posé par l'équipe de développement.
Les avantages du WSJF sont nombreux :
* rapidité de mise en oeuvre
* facile à challenger par et avec les parties prenantes
* explicite et facile à communiquer
Aprés avoir lu plusieurs vraies retours et explications de cet outil sur Internet, Eva propose à son PO de l'appliquer.
L'adhésion du PO est immédiate, celle du management un peu plus difficile mais sans énorme difficulté.
<<if setup.steps lt 12>>
Maintenant que le WSJF est adopté chez LudiGames (au moins pour les sujets qui touchent l'équipe d'Eva) quelle pourrait-être la prochaine étape pour notre héroine?
#Eva retourne sur le sujet des ambitions de Ludigames. Elle propose d'organiser un séminaire pour discuter de la vision produit chez LudiGames [[Eva organise un séminaire produit]]
#Eva doit maintenant se concentrer à nouveau sur son équipe. Elle retourne au service de celle-ci. Cependant, elle continue aussi à développer et se rend compte que la double casquette n'est pas toujours facile. [[Production VS Servant Leadership - LudiGames]]
#Forte de son expérience d'accompagnement du PO, Eva pense qu'il est temps pour elle d'évoluer. De plus, il lui semble que LudiGames doit aussi accélérer dans son déploiement de la démarche agile [[Eva devient coach agile chez LudiGames]]
<<else>>
[[Conclusion]]
<</if>>
Quand on regarde la manière dont LudiGames gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, elle a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#Eva propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - LudiGames]]
#Eva propose la mise en place des 3 amigos [[Les 3 amigos - LudiGames]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - LudiGames]]
<<else>>
C'est alors qu’elle propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>>Pour James, le terme Devops est un peu obscure. De prime abord, il pense que le devops c'est une suite d'outils qui permettent aux entreprises de ne plus avoir à embaucher des responsables de l'exploitation, de la mise en production...
Il est très étonné lorsqu'il apprend que ce n'est pas ça.
En résumé, il comprend que le devops est un état d'esprit qui permet de rapprocher la partie OPS (opérations) de la partie développement.
Il interroge un de ses amis qui a une certaine ancienneté dans le monde de l'informatique et qui a travaillé en Angleterre dans une autre startup il y a quelques années. Il rigole : "Le devops, c'est comme l'offshore, c'est un effet de mode! Y'a 15 ans je le faisais déjà à Bristol!! Tout comme il y a 15 ans la mode était à la création de sociétés externes au Maroc ou en Inde!"
James n'est pas sur qu'il est tout à fait d'accord avec son affirmation.
Il se renseigne sur les outils qu'il a à sa disposition pour parler du DevOps et amener son équipe à s'y interesser.
<<if setup.steps lt 12>>
Il liste quelques outils interessants :
#Il pourrait demander à TechSys de venir lui présenter [[Gunther - DoctoChat]]
#Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps. [[Casino Game - DoctoChat]]
#Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le [[Lego, Scrum et Chocolat pour le DevOps - DoctoChat]]
<<else>>
Il liste quelques outils interessants :
* Il pourrait demander à TechSys de venir lui présenter Gunther.
* Il apprécie l'aspect "entre aide" et travail sur le WIP porté par le Casino Game d'Alexandre Boutin. Cet outil peut aider à faire bouger les choses au niveau des répartitions de responsabilités dans le DevOps.
* Il se dit que pour travailler correctement en Scrum il vaut mieux aborder le Lego, Scrum et Chocolat pour le DevOps.
[[Conclusion]]
<</if>>Il faut faire attention à ce que l'on propose exactement!
Au départ, le PO cherche à mettre en avant la priorité.
Pour James, une priorisation en taille de tshirt est une mauvaise idée !! Ça engendrerait beaucoup d'item avec des valeurs identiques ce qui reviendrait à ne pas prioriser. Il propose une solution alternative pour suivre la priorité : utiliser une suite numérique et interdire à 2 besoins d'avoir la même valeur (sauf s'ils sont terminés bien sur).
James propose une autre manière de prioriser : se baser réellement sur la valeur.
Si on parle de valeurs business et qu'on utilise cette donnée pour comparer les items les uns par rapport aux autres, alors ça peut fonctionner.
C'est plus rapide et plus facile à challenger. L'item 1 est-il plus apporteur de valeur que l'item 2?
Ça marche plutôt bien et si on veut suivre la valeur produite dans un burn up alors une règle de 3 suffit pour obtenir une courbe parlante.
Eva propose à son PO une échelle du style :
* XS = 1
* S = 3
* M = 7
* L = 15
* XL = 40
* XXL = 100
Le PO lui dit que pour une comparaison relative il préfèrerait des multiples plutôt qu'une pseudo fibo...
James se rend compte qu'il a eu un mauvais réflex ;)
Ils tombent d'accord sur :
* XS = 5
* S = 10
* M = 20
* L = 40
* XL = 80
* XXL = 160
Maintenant que tout le monde est calé en arithmétique, que va faire James?
<<if setup.steps lt 12>>
#Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF. [[Le WSJF - DoctoChat]]
#Le PO réussi à répondre aux besoins de l'équipe en terme de priorisation et de contenu, cependant, il continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une [[Sensibilisation agile des PP - DoctoChat]]
#James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse. Aprés quelques négociations avec son management, [[James organise un séminaire produit - DoctoChat]]
<<else>>
* Le travail fourni au PO porte ses fruits et il commence à prendre le pli. Cependant, il trouve la priorisation par la valeur limitée. James lui propose d'expérimenter le WSJF
* Le PO continue à rencontrer des blocages organisationnels qui impactent l'équipe. James se propose d'organiser une Sensibilisation agile des PP.
* James a grandement apprécié de travailler avec le PO, il se dit qu'il pourrait faire avancer toute l'entreprise sur une voix agile vertueuse.
[[Conclusion]]
<</if>>James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetée, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant James?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - RDB]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - RDB]]
#Le manager de James lui indique qu'il faut [[Créer une nouvelle équipe Scrum - RDB]] , quelles sont ses options?
<<else>>
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]]
<</if>>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF
* Un manager vient voir James avec la fameuse rengaine : L'agile ça coûte cher!
[[Conclusion]] James n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
James propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par James est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme James a les données historiques de production de l'équipe, et surtout d'estimation il est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetée, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), James fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, James sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins il a prouvé son point au PO.
A postériori il se rend compte qu'il aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
* Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et James) pour s'assurer d'une qualité technique au top? James leur propose d'explorer le craftsmanship.
* Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... James se demande si c'est normal. Il se renseigne sur le principe "Amélioration continue VS chaos"
[[Conclusion]] Quand on regarde la manière dont RDB gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, James propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, il a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position de James!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
James se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#James propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - RDB]]
#James propose la mise en place des 3 amigos [[Les 3 amigos - RDB]]
#Le Scrum Master propose la mise en place d'[[Un déversement de backlog - RDB]]
<<else>>
C'est alors qu'il propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, Eva a vraiment envie de se lancer.
Elle commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
Eva tombe sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Elle n'est pas sure de pouvoir un jour l'utiliser pour le moment mais ça l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d’après les volontés de l'équipe). Après 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
Eva essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, Eva se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
Maintenant qu'elle a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge d'Eva?
<<if setup.steps lt 12>>
#Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le [[Le WSJF - Eva Indep]]
#Eva propose à VP de travailler d'abord à la [[Valeur Business Client - Eva Indep]]
#Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle. [[Shape Up - Eva Indep]]
<<else>>
* Eva propose au PO de se faciliter la vie au niveau des priorisation et lui présente le WSJF.
* Eva propose à VP de travailler d'abord à la valeur Business.
* Eva a entendu parler d'une nouvelle tendance, Shape Up, et propose à une des équipes de l'investiguer avec elle.
[[Conclusion]]
<</if>>Pas facile de transformer une vision en action.
Mais Eva a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être Eva les animera-t-elle en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. Eva en parle à son manager qui devra faire son choix.
[[Conclusion]] Un premier meetup c'est toujours une expérience!! Eva n'est pas déçue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
<<if setup.steps lt 12>>
#Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu’[[On ne devient pas coach tout seul - Eva Indep]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[Eva rejoint Nord Agile - Indep]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
* Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu’[on ne devient pas coach tout seul.
* Eva décide de s'engager un peu plus dans la communauté agile locale et rejoint Nord Agile
* Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.
[[Conclusion]]
<</if>>Quand on regarde la manière dont le client gère ses tests, on comprend la nécessité de mettre en place un rôle agile d'assurance qualité.
L'équipe, qui est normalement auto-organisée, n'aime pas tester et ne fait que le minimum requis. Le PO, qui est de l'ancienne école, considère qu'il n'a pas à se soucier de rédiger des tests car c'est le devoir de l'équipe de livrer un code de qualité. Résultat, ce sont les utilisateurs qui testent pour eux... et c'est généralement pas joli joli... alors oui, c'est vrai, les anomalies sont résolues rapidement mais quand il s'agit d'anomalies qui influent sur le chiffre d'affaire, là il faut arrêter les bêtises.
Donc, Eva propose que le Scrum Master se responsabilise sur les tests. Après tout, à force de faire du servant leadership, elle a perdu en efficacité technique !
L'équipe apprécie la nouvelle prise de position d’Eva!! En effet, fini le Scrum Master qui contribue à l'échec des sprints d'un point de vue développement! Bienvenue au Scrum Master testeur qui sera à lui seul le goulot d'étranglement de l'équipe...
Blague à part (ou pas), le Scrum Master se sent vraiment utile dans son rôle de ScrumQA. L'équipe a grandement diminué le nombre d'anomalies mises en production à chaque release (on va pas dire à chaque Sprint, faut pas déconner!!).
Eva se rend compte que, malgré la bonne volonté du Scrum Master, il va falloir aller encore plus loin.
<<if setup.steps lt 12>>
#Eva propose au Scrum Master de suivre une formation ISTQB. [[Formation ISTQB SM - Eva Indep]]
#Eva propose la mise en place des 3 amigos [[Les 3 amigos - Eva Indep]]
#Le Scrum Master propose la mise en place d’[[Un déversement de backlog - Eva Indep]]
<<else>>
C'est alors qu’elle propose la mise en place des 3 Amigos, ainsi qu'une formation ISTQB au Scrum Master.
Au départ réticent, le Scrum Master QA fini par faire des merveilles et, même s'il se sent parfois insuffisant, la réputation de l'équipe commence à s'améliorer.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
Eva opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, elle demande un entretien avec le responsable des chefs de projets de son client. Elle lui propose de mettre à plat le workflow de création de valeur.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
Eva a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, elle a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez son client il ne le font pas).
<<if setup.steps lt 12>>
Que va faire Eva?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le [[DevOps - Eva Indep]]
#Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ça fonctionne à l'échelle d'une équipe. [[Le WSJF - Eva Indep]]
#Eva comprend que c'est un changement de culture important, elle se lance dans la démarche [[Kanban - Eva Indep]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
Eva attaque le sujet sur plusieurs flancs :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le devOps avec son équipe préférée.
* Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. Elle lance donc une expérimentation WSJF avec son PO.
* Eva comprend que c'est un changement de culture important, elle se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Entant que Scrum Master, Eva se concentre sur l'équipe. Et en ce moment, en plus d'un facilitateur de rituels et d'une aide à lever les obstacles, l'équipe a aussi besoin de bras.
Ça tombe bien, Eva aime aussi la technique!! Elle décide donc d'aider du mieux que possible l'équipe et endosse le rôle de Scrum Master / Développeur (ou ScrumDev pour les intimes).
Cette double casquette ne se porte pas sans difficultés (ou risques). En effet, il est parfois délicat d'être à la fois responsable d'aider l'équipe à lever les obstacles rencontrés tout en étant potentiellement soi même l'obstacle... Peut-elle réellement être efficace dans ces deux missions?
<<if setup.steps lt 12>>
Qu'allons nous explorer ensuite?
#Eva se rend compte de la possible dichotomie entre ces deux casquettes. [[Production VS Servant Leadership - Eva Indep]]
#Eva semble s'en sortir dans les deux domaines et décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors [[Le craftsmanship - Eva Indep]]
<<else>>
Elle continue à se poser des questions et cherche de nouveaux sujets.
* Eva se rend compte de la possible dichotomie entre ces deux casquettes (Scrum Master et développeur).
* Dans le même temps, elle décide d'approfondir un peu l'aspect "accompagnement technique" de l'équipe. Elle explore alors le craftsmanship.
[[Conclusion]]
<</if>>James a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
James opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, il demande un entretien avec le responsable des chefs de projets de chez son client. Il lui propose de mettre à plat le workflow de création de valeur.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
James a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, il a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez le client il ne le font pas).
<<if setup.steps lt 12>>
Que va faire James?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le [[DevOps - James Indep]]
#James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - James Indep]]
#James comprend que c'est un changement de culture important, il se lance dans la démarche [[Kanban - James Indep]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
James attaque le sujet sur plusieurs flancs :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, James explore le devOps avec son équipe préférée.
* James réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ça fonctionne à l'échelle d'une équipe. Il lance donc une expérimentation WSJF avec son PO.
* James comprend que c'est un changement de culture important, il se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]]
<</if>>Aurélien, Julie, Alex, Grégory, Romain, Sarah, Jo, Djamel, Marion, Aurélien, Benji, Anne... que de personnes rencontrées!!!
Le plus interessant c'est que chacun d'entre eux a une histoire différente.. L'un voulait être océanographe et s'est retrouvé embarqué dans une première exprience agile chez un géant de la téléphonie. L'autre a son diplôme en d'ingénieurie en automatisation et s'est retrouvée proposée un poste d'agiliste lors d'un remaniement conséquent de son entreprise. Un autre encore devait être graphiste mais la vie en a décidé autrement...
Que d'histoires, que d'expériences!!
Eva se sent flatée d'être si vite intégrée dans les discussions en off (hors conférences". Elles passent d'échange sur les tracas du quotidien avec les équipes aux expériences de saut à l'élastique en passant par les délires d'un certain Nico autour de Chtulu et d'un pingouin (comme quoi c'est toujours eux qui doivent mourir en premier).
Mais elle se sent intégrée, écoutée, entourée, acceptée. Alors elle essaye de faire de même avec les personnes qu'elle croise. Elle essaye d'amener un peu de ses expériences à ceux qui pourraient en profiter. Ca la conforte dans son idée de se lancer dans le coaching avec un miroir.
A partir de là, elle continue à progresser, à s'inspirer des personnes croisées, à les contacter directement lorsqu'elle a des questionnements...
<<if setup.steps lt 12>>
#Elle décide de se lancer dans cette histoire de miroir coach avec Yulie. [[Un miroir coach - Eva Indep]]
#Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesce : Le serious gaming est clairement fait pour Eva. [[Eva se passionne pour le Serious Gaming - Indep]]
#Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire. [[Agile Games France - Eva Indep]]
#Après autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
[[Eva rejoint Nord Agile - Indep]]
<<else>>
* Elle décide de se lancer dans cette histoire de miroir coach avec Yulie.
* Alex l'y pousse, Romain confirme, Marion dit "Oui", et Julie acquiesse : Le serious gaming est clairement fait pour Eva. Eva se passionne pour le Serious Gaming.
* Lors d'une discussion en OFF elle entend parler de l'AGFr et décide de tenter de s'y inscrire.
* Aprés autant de belles rencontres, il n'y a qu'une seule chose à faire pour elle :
Eva rejoint Nord Agile.
[[Conclusion]]
<</if>>
Pas facile de transformer une vision en action.
Mais Eva a tout de même plusieurs idées.
* Mettre en place une gestion des actions via le "We chose to go to the moon de Kokan" (merci Aurélien).
Avec cet atelier, qui s'anime généralement sur 2 jours, le management arrive avec sa vision et les participants travaillent aux différents travaux nécessaires pour atteindre cette vision.
Ensuite, il suffira de les animer autour des actions. Peut-être Eva les animera-t-elle en mode itératif?
* Mettre en place une démarche OKR généralisée.
En se basant sur les OKR, utiliser la vision comme un point d'entrée servant à définir les ambitions peut-être?
* Laisser VisionMaster faire.
Après tout, c'est eux les maîtres de la vision. La seule chose c'est que James se demande s'ils sont vraiment opérationnels ou juste dans la définition des visions.
* Mettre en place une démarche produit.
Après tout, les produits de l'entreprise doivent répondre à la vision, donc quoi de mieux qu'une démarche centrée sur eux pour accompagner la vision?
Bref, beaucoup de choix. Eva en parle à son manager qui devra faire son choix.
<<if setup.steps lt 12>>
Que voulez-vous voir ensuite?
#On a envie d'en s'avoir plus sur la [[Démarche OKR - LudiGames]]
#Le manager d’Eva lui demande d'animer un séminaire autour de la notion de produit. [[Eva organise un séminaire produit - LudiGames]]
#Une vision nouvelle, des actions qui animent cette vision, ça fait beaucoup de chaos tout ça non? [[Le principe de l'amélioration continue face au chaos - LudiGames]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Un premier meetup c'est toujours une expérience!! Eva n'est pas décue.
Il a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, James s'inscrit aux deux.
2 salles, 2 ambiences mais les mêmes passions animent les animateurs et participants!! James n'est pas déçue!!
Il échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
<<if setup.steps lt 12>>
Au sortir de ces premiers événements James a plusieurs possibilités devant lui:
#James a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, il est persuadé qu'[[9 - On ne devient pas coach tout seul chez RDB]]
#James décide de s'engager un peu plus dans la communauté agile locale et [[9 - James rejoint Nord Agile - RDB]]
#James veut en savoir plus, explorer encore plus de sujets, il décide donc de participer à son premier Agi'Lille.[[9 - James participe à son premier Agi'Lille - RDB]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Comment gérer le run pour une équipe Scrum?
La théorie voudrait que le run soit transparent ("gratuit") durant le sprint. C'est à dire que l'équipe sache le gérer correctement, de manière régulière, afin qu'à force, la dépense en énergie (effort) sur les sprints soit toujours la même quand on parle du run.
Du fait, scrum ne nous explique pas, dans le guide, comment gérer un run qui n'est pas constant.
James a croisé différentes options :
* Un produit qui n'est pas mis en prod assez régulièrement pour avoir une gestion des anomalies et retours utilisateurs constants.
* Un produit dont le niveau de qualité n'est pas suffisamment haut pour pouvoir garantir un niveau d'anomalies bas.
* Un produit qui part en production sans avoir été testé.
* Une utilisation du produit "saisonnière".
* Une équipe gérant à la fois de l'ajout de valeur mais aussi des demandes utilisateurs légitimes.
* ...
Du fait, il a vu différentes solutions :
* Intégrer la gestion d'anomalies dans le backlog.
* Dédier une journée de chaque sprint au run (le slack day).
* Dédier une personne (shadock, jarvis) à la surveillance et au traitement du run.
* La mise en place d'une fastlane dans le tableau d'équipe.
* ..
Toutes ces solutions fonctionnent, dépendamment du contexte.
<<if setup.steps lt 12>>
Maintenant que nous avons évoqué le run, quel sujet nous interesse?
#James explore le Kanban car il a entendu que le terme FastLane vient de là. [[Kanban - RDB]]
#Pour garantir un run constant, rien de tel que l'excellence technique ;) [[Le craftsmanship - RDB]]
#James se lance en freelance et se voit proposer une mission dans l'infra et se demande comment le run est géré chez eux. [[Agile dans l'Infra? - James]]
#James commence à avoir une expérience interessante, suffisante pour la présenter en conférence? [[James se lance dans l'écriture d'une conférence - RDB]]
<<else>>
James va ensuite poursuivre avec :
* Le Kanban car il a entendu que le terme FastLane vient de là.
* Le Craftsmanship car pour garantir un run constant, rien de tel que l'excellence technique ;)
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Entre les conférences de Vasco Duarte, la fabuleuse intervention de Frédéric Leguédois, James a vraiment envie de se lancer.
Il commence par expliquer le concept à une équipe test et surtout au PO. Ils tombent d'accord sur le fait qu'il y beaucoup de boulot à faire du côté de la découpe des US... alors ils s'y mettent.
James tombé sur un paquet de cartes de planning poker avec seulement 3 valeurs (0, 1, TFB). Il n'est pas sur de pouvoir un jour l'utiliser pour le moment mais ca l'a bien fait sourire.
L'équipe se lance, ils décident d'inscrire la notion de "No Estimate" dans leur prochaine version de DOR. Cette dernière devrait être déployée sous 3 sprints (d'aprés les volontés de l'équipe). Aprés 5 sprints ils n'y sont pas encore mais s'en approchent.
Il leur faudra encore 3 sprints avant de réellement pouvoir le déployer, non pas sans gros efforts du PO.
La découpe n'est pas facile.
James essaye d'aborder le sujet avec d'autres clients mais beaucoup sont réticents. Ils ne voient pas comment ils peuvent faire.
A bien y réfléchir, James se demande aussi si ce principe peut vraiment s'appliquer à tous les contextes (le découpage en unité, pas le no estimate).
<<if setup.steps lt 12>>
Maintenant qu'il a testé le sujet, que l'équipe test est lancée, quelle est le prochain challenge de James?
#James propose au PO de se faciliter la vie au niveau des priorisation et lui présente [[Le WSJF chez RDB]]
#James propose à un débutant en démarche agile, de travailler d'abord à la [[Valeur Business - RDB]]
avant d'avancer sur le chemin de l'agilisation.
#James a entendu parler d'une nouvelle tendance et propose à un de ses POs de l'investiguer avec lui. [[Shape Up - RDB]]
<<else>>
[[Conclusion]]
<</if>>Un premier meetup c'est toujours une expérience!! Eva n'est pas déçue.
Elle a longtemps hésité entre 2 meetups : Le Meetup Serious Gaming Lillois ou le Scrum Beer Lillois.
Ces deux meetups sont organisés par la même association.
Comme ils n'ont pas lieu en même temps, Eva s'inscrit aux deux.
2 salles, 2 ambiances mais les mêmes passions animent les animateurs et participants!! Eva n'est pas déçue!!
Eva échange avec des personnes de tous horizons: du Scrum Master au développeur en passant par le spécialiste en formation ou RH.
Des échanges riches, beaucoup d'idée, pas mal de contacts.
Au sortir de ces premiers événements Eva a plusieurs possibilités devant elle:
<<if setup.steps lt 12>>
#Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu’[[9 - On ne devient pas coach tout seul chez LudiGames]]
#Eva décide de s'engager un peu plus dans la communauté agile locale et [[9 - Eva rejoint Nord Agile - LudiGames]]
#Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.[[9 - Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
* Eva a compris que passer de Scrum Master à coach peut parfois amener son lot de complications. En effet, elle est persuadée qu’[on ne devient pas coach tout seul.
* Eva décide de s'engager un peu plus dans la communauté agile locale et rejoint Nord Agile
* Eva veut en savoir plus, explorer encore plus de sujets, elle décide donc de participer à son premier Agi'Lille.
[[Conclusion]]
<</if>>Pour gérer la dette technique en temps réel, James se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée, alors l'équipe doit déclencher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant James rencontre toujours quelques soucis :
<<if setup.steps lt 12>>
#Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue [[Le craftsmanship - RDB]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser [[Le WSJF - RDB]]
#Un manager vient voir James avec la fameuse rengaine : [[L'agile ca coûte cher! - RDB]]
<<else>>
* Il doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Il investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. James propose d'utiliser le WSJF
* Un manager vient voir James avec la fameuse rengaine : L'agile ça coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Les 3 amigos se réunissent donc le mardi, toutes les deux semaines, pour travailler aux User Stories du backlog.
Dans un premier temps, ils se mettent d'accord sur l'objectif de la réunion : " valider les critères d'acceptance de chaque US afin de garantir la définition de prêt".
Ils s'attèlent donc aux prochains besoins prévu pour le produit.
La première session, ils sont capables de revoir 3 US. C'est certes peu mais ca reste décent pour une première fois.
La seconde fois, ils travaillent à 5 US. C'est plutôt une belle amélioration... sauf que parmi ces dernières il y en a 2 qu'ils avaient déjà travaillé... Comment se fait-ce? Tout simplement qu'entre leurs deux réunions il y a eu 2 réunions d'affinage et que ces dernières ont modifié les US. "Normal, on est agile!" dit le PO.
"Normal, on est agile!", oui, peut-être se dit Eva, sauf que du coup les 3 amigos on refait leur travail...
<<if setup.steps lt 12>>
Quelle suite on donne à cette histoire?
#Eva se dit qu'elle a déjà un rituel dans lequel les membres de l'équipe se réunissent et discutent des besoins avant de s'engager et donc, pour éviter de faire plusieurs fois le même job, elle décide, unilatéralement, de mettre en place [[Un refinement revisité - Eva Indep]].
#Eva comprend que le test n'est pas le seul rempart aux défauts de qualité de l'équipe. Elle propose à cette dernière d'explorer [[Le craftsmanship - Eva Indep]]
#Afin de trouver de l'inspiration, Eva décide d'aller à la rencontre de la communauté Lilloise. [[Eva participe à son premier Agi'Lille - Indep]]
<<else>>
Dans l'équipe de James, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, James a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, James et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hazardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]
<</if>>Dans l'équipe d’Eva, on a compris que la planification est une phase, pas un rituel donné.
Bien sur, au début de chaque sprint (le jeudi matin toutes les 2 semaines), ils ont un sprint planning, mais celui-ci devenait vraiment long, principalement parce que l'équipe remettait souvent en cause le contenu des US proposées par le PO.
Afin d'éviter ces remises en question de dernière minutes, et donc les déconvenues de priorité, Eva a proposé de mettre en place le refinement (ou affinage, ou raffinage), tous les mardi matin.
Ce "rituel" réuni généralement le PO, Eva et 2 à 3 devs. Le PO expose aux participants le contenu des US qu'il souhaite amener en sprint planning, les développeurs posent un maximum de question, challengent et se challengent sur la solution technique à mettre en place.
Eva n'est pas tombée dans le piège de demander une estimation à l'US (même en point d'effort) durant ce rituel.
Au bout d'un moment, le PO a même eu l'occasion d'aborder les gros sujets (Epic, Epopée, Feature...) qu'il souhaite amener en backlog plus tard afin :
#d'avoir le premier avis des devs et de récupérer leurs questions et inquiétudes.
#d'obtenir une estimation en taille de TShirt de l'effort lié aux futures US.
Avec ces tailles de TShirt, il a mis en place une règle de 3 qui lui permet de pouvoir travailler à ses projections.
Le refinement fonctionne bien, l'équipe est efficace et le PO sécurisé. Mais reste les problématiques de test, critères d'acceptance... qui sont toujours hasardeux.
Eva décide donc d'inviter le testeur assigné à l'équipe pour travailler avec l'équipe durant ce rituel. Son objectif est, à terme, de pouvoir prendre la place de ce dernier pour ne pas le solliciter plus que nécessaire sur les rituels de l'équipe mais pour le moment il a encore à apprendre.
Cette manière de fonctionner apporte son lot de contraintes mais permet aussi à l'équipe de mettre à jour ses définitions de prêt et de terminé sur le long terme, et donc d'améliorer la qualité de leur production.
[[Conclusion]]Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, Eva se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ca rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
Après plusieurs sprints dans ce système, Eva se dit quand même qu'il faudrait regarder d'autres choses...
<<if setup.steps lt 12>>
#Comme elle a entendu parler du [[Kanban - Eva Indep]], Eva se pose la question de savoir si ca ne serait pas plus efficace pour son équipe?
#Afin d'élargir ses horizons, [[Eva participe à son premier Agi'Lille - Indep]]
#Eva commence a engranger de l'expérience, et les gens semblent apprécier l'écouter en parler [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva met du temps à comprendre ce qui arrive à sa nouvelle équipe.
Elle tente d'appliquer les mêmes principes que ceux proposés à la première:
* Des points de synchro réguliers sous forme de Daily Meeting
* La mise en place de la notion de Sprints
* L'organisation de rituels de début et fin de Sprints
* La mise en place d'un backlog pour le reste à faire du produit
Cependant, en fin de chaque sprint c'est toujours la même histoire l'équipe ne termine pas son sprint, le PO n'est jamais satisfait et l'application n'a pas été mise à jour depuis plusieurs mois.
Eva essaye de déterminer la raison principale de cette problématique. Elle se rend compte qu'elle est apparemment entrée en plein dans ce qu'on appelle le Cargo Cult.
On ne peut en effet, sur 2 contextes différents, espérer mettre en place les mêmes actions et obtenir les mêmes résultats.
<<if setup.steps lt 12>>
Fort de ce constat, elle décide de revoir sa copie. Quelle est la prochaine étape?
#Eva se rend compte qu'il faut absolument [[Accompagner le PO - LudiGames]]
#Eva entend parler de la communauté agile lloise et décide de participer à [[Eva participe à son premier Agi'Lille - LudiGames]]
<<else>>
Fort de ce constat, elle décide de revoir sa copie. Elle décide :
* D'accompagner le PO
* De participer à son premier Agi'Lille
* De retravailler avec l'équipe quite à créer leur propre manière de faire du scrum (que certains appellerons ScrumBan)
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Pour gérer la dette technique en temps réel, Eva se retrouve devant plusieurs possibilités.
La première consiste à s'appuyer sur les outils de collecte et d'affichage de la qualimétrie et à responsabiliser l'équipe sur le maintien des mesures en dessous d'un certain seuil. Dans ce cas, on ajoute à la "définition de terminé", le fait que les modifications de code apportées pour la mise en place de l'US n'ont pas dégradé la qualimétrie.
Cette pratique marche plutôt bien, à condition que le niveau de dette mesurable ne soit pas trop haut.
Une seconde manière est de mettre en place une alerte automatique lorsque le niveau de dette technique mesurée dépasse un certain seuil. Lorsque cette alerte est activée,
alors l'équipe doit déclancher soit une période de temps dédiée sur le sprint prochain pour la faire diminuer, soit un sprint de nettoyage (stabilisation).
Les deux techniques fonctionnent bien, cependant Eva rencontre toujours quelques soucis :
<<if setup.steps lt 12>>
#Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue [[Le craftsmanship - Eva Indep]]
#La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser [[Le WSJF - Eva Indep]]
#Un manager vient voir Eva avec la fameuse rengaine : [[L'agile ca coûte cher! - Eva Indep]]
<<else>>
* Elle doit améliorer l'outillage technique ainsi que la montée en compétence technique de l'équipe. Elle investigue le craftsmanship.
* La priorisation de la dette technique hors qualimétrie (dans les PBI) reste un sujet de préoccupation. Eva propose d'utiliser le WSJF chez un de ses clients
* Un manager vient voir Eva avec la fameuse rengaine : L'agile ca coûte cher!
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva n'a pas totalement réussi à convaincre, ou le PO a besoin de choses plus tangibles.
Eva propose alors un exercice à l'équipe. En effet, celle-ci n'arrête pas de remonter qu'une grosse partie de l'application est un sac de noeud (ou le grand Monstre en spaghetti volant du pastafarisme) et demande l'autorisation de le refactoriser.
Mais le PO ne priorise jamais ces travaux.
L'exercice proposé par Eva est le suivant : faire un double chiffrage de toutes (ou presque) les US d'ajout de valeur impactées par le refactoring.
Un chiffrage sans, un chiffrage avec. Et chiffrer également le refactoring. Quand on dit chiffrer, on parle bien sur d'estimation en point d'effort ou en taille de tshirt... on est pas des bêtes...
Le résultat de l'estimation est sans appel :
* Avant refactoring, 100 points d'effort (avec beaucoup d'incertitude).
* Après refactoring, 60 points d'effort (et plus de certitudes).
* Cout du refactoring: 2 sprints soit 50 points...
Comme Eva a les données historiques de production de l'équipe, et surtout d'estimation elle est capable de montrer au PO que l'estimation de 100 points est sans doute très fausse (la faute à l'incertitude - et pas la r'crudescence) et qu'en plus les sujets touchés par le monstre spaghetti sont en constante apparition.
Il n'en fallait pas beaucoup plus au PO, si ce n'est la promesse du Scrum Master de suivre le réel par rapport au projetté, uniquement sur les US impliquées.
L'équipe se lance pour 2 sprints. A la fin du second sprint, il ne reste qu'un tout petit reliquat, qui est embarqué pour le sprint d’après.
Après 5 autres sprints (suite aux priorités), Eva fait le bilan.
Sur les US travaillées lors de l'estimation, le résultat est sans appel: quand elles sont passées à travers le sprint planning de chaque sprint, le total de points d'effort est tombé à 63.
Alors oui, Eva sait que ce n'est pas fiable, que le chiffrage en effort est relatif à chaque sprint et tout et tout, mais au moins elle a prouvé son point au PO.
A postériori elle se rend compte qu'elle aurait pu utiliser un autre moyen de faire la comparaison en demandant à chaque US touchée par la refacto d'être doublement estimée à chaque sprint après refactorisation... mais ça n'aurait sans doute pas fait mouche avec le PO.
<<if setup.steps lt 12>>
Que lance maintenant Eva?
#Maintenant que la dette technique est sous contrôle, enfin, pour la partie refactoring du Monstre Spaghetti, que peut faire l'équipe (et Eva) pour s'assurer d'une qualité technique au top?[[Le craftsmanship - Eva Indep]]
#Pendant toute cette phase de refactoring, peu d'actions d'amélioration continue ont été embarquées, ce qui a permis à celle dans le backlog depuis longtemps d'atterrir... Eva se demande si c'est normal. [[Le principe de l'amélioration continue face au chaos - Eva Indep]]
#Le manager d'Eva lui demande comment faire pour [[Créer une nouvelle équipe Scrum - Eva Indep]].
<<else>>
[[Conclusion]]
<</if>>Entant que PO, je veux ..., afin de ...
Entant que Dev, je veux ..., afin de ...
Eva se focalise sur les attentes de son équipe. Elle décide de profiter de l'expérience métier du PO tout en lui facilitant aussi la vie. Elle prend alors en charge certaines taches comme l'écriture des US au bon format, ainsi que l'animation des ateliers d'affinage. Elle reste Scrum Master mais assume aussi un rôle que l'on pourrait qualifier de Scrum - PPO (ou Scrum Analyste chez certains). Elle réalise certaines tâches normalement assignées au PO. Ce dernier garde la responsabilité des décisions mais n'est plus autant sollicité pour de la rédaction.
Au moment de se lancer, Eva a proposé au PO et à l'équipe un atelier de RA-Poker qui leur a permit de redéfinir les différentes responsabilités au sein de l'équipe (ainsi que de se projeter sur la prochaine évolution de leur organisation).
<<if setup.steps lt 12>>
Au bout de quelques temps, Eva se rend compte des difficultés rencontrées par le PO. Elle se propose donc de :
#Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. [[La dette technique et Scrum - LudiGames]]
#Aborder la [[Valeur Business - LudiGames]]
#Mettre en place un mode de priorisation simple et rapide. [[Prioriser en tailles de TShirt - LudiGames]]
#Déployer le WiSJiF [[Le WSJF - LudiGames]]
<<else>>
Au bout de quelques temps, Eva se rend compte des difficultés rencontrées par le PO. Elle se propose donc de :
* Travailler à la dette technique avec l'équipe car c'est un aspect qui est difficile à prendre en compte côté PO. * Aborder la valeur Business
* Déployer le WiSJiF
[[Conclusion]]
<</if>>L'atelier Product Box est un succès. Le PO comprend parfaitement l'objectif final.
Comme il le travaille avec l'équipe et quelques parties prenantes, ils créent même un support final qui les suivra durant toute la vie du produit!!
<<if setup.steps lt 12>>
Que se passe-t-il ensuite pour Eva?
#Avec le PO ils tombent d'accord : il faut travailler à la [[Valeur Business - LudiGames]]
#Pour bien avancer sur la création de valeur, il faut implémenter [[Le WSJF chez LudiGames]]
#Maintenant que l'équipe est au fait de la vision produit, Eva s'attaque à la gestion de [[La dette technique et Scrum - LudiGames]]
<<else>>
* Le document permet à l'ensemble des parties prenantes impliquées dans le produit de se rendre compte qu'il faut apprendre à dire Non. (Comme dans la vidéo "La gestion de produit agile en 2 mots" d'Henrik Kniberg traduite par Fred Lothon).
* Malgré une superbe product box, le produit (ou le projet) continue à ne pas répondre aux promesses. Les retours des premiers testeurs sont mauvais. Eva explore les méandres du droit à l'échec.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Eva a le choix quand il s'agit de formation à la démarche produit. Entre les formations PO (et les certifications affiliées), les formations en product management (PM), celles sur le design thinking, le PMO...
Eva opte pour une formation globale, qui montre l'importance de gérer correctement un portfolio de produits / projets en mode agile.
A son retour, elle demande un entretien avec le responsable des chefs de projets de son client. Elle lui propose de mettre à plat le workflow de création de valeur.
En partant du besoin, jusqu'à la fin de vie du produit (qui, on ne va pas se le cacher est encore un concept pour cette petite structure), tout y est. La gestion de budgets, la négociation, l'allocation de ressources...
Il est temps de tout remettre à plat.
Eva a de grandes idées, comme passer les budgets en mode capacitif, et gérer le projets comme des demandes dans un grand backlog.
Lors de la formation, elle a aussi pu entrevoir la gestion par Kanban de l'activité d'une entreprise.
Le manager est un peu plus modéré... il propose de commencer petit car mettre en place ce que James propose va demander des changements de titres au sein de son équipe ainsi que des nouvelles fiches de poste (on aurait pu dire FdP mais même chez LudiGames il ne le font pas).
<<if setup.steps lt 12>>
Que va faire Eva?
#Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le [[DevOps - LudiGames]]
#Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. [[Le WSJF - LudiGames]]
#Eva comprend que c'est un changement de culture important, elle se lance dans la démarche [[Kanban - LudiGames]] en espérant prouver par l'exemple que le workflow actuel est saturé.
<<else>>
Eva attaque le sujet sur plusieurs fronts :
* Le manager est insistant : il faut commencer par la capacité des équipes à mettre en production rapidement. De fait, Eva explore le devOps avec son équipe préférée.
* Eva réussi à convaincre le manager de tester une démarche de priorisation par la valeur avec ses équipes. La seule condition mise par le manager : prouver que ca fonctionne à l'échelle d'une équipe. Elle lance donc une expérimentation WSJF avec son PO.
* Eva comprend que c'est un changement de culture important, elle se lance dans la démarche Kanban (au moins d'un point de vue représentation) en espérant prouver par l'exemple que le workflow actuel est saturé.
[[Conclusion]]
<</if>>Le mouvement Agnostic agile est né de la volonté d'assainir le rapport à la démarche agile. Sortir de l'esprit "Cadre unique agile" pour retourner à l'essence du manifeste. Au même titre que plusieurs autres mouvements (Heart of Agile par exemple) le but est de se tourner vers le besoin réel et non vers la solution uniforme.
Eva propose donc à son équipe un petit atelier de retour aux sources. Elle choisi de repartir du manifeste et de valider avec l'équipe qu'ils sont en phase avec les 4 valeurs et les 12 principes sous-jacents.
L'atelier se passe bien. Eva a réussi à impliquer à la fois les demandeurs et l'équipe de développement.
Ensemble, ils ont posé les contraintes qu'ils rencontrent ainsi que les gains attendus par rapport à la démarche agile.
<<if setup.steps lt 12>>
Quelle méthode/framework vont-ils tenter d'appliquer?
#Le fonctionnement start up de LudiGames et le besoin en réactivité constant les amènent à regarder ce que la démarche Kanban propose. [[LudiGames et Kanban]]
#Eva avait fait des recherches en amont et a parlé avec l'équipe du livre blanc de Base Camp sur Shape Up. Ils décident de se lancer avec ce modèle. [[LudiGames et Shape Up]]
#Au final, aucune des propositions qu'ils ont pu faire ressortir de leurs échanges n'a amené de solution toute faite. Ils décident donc de se lancer avec [[Une méthode maison pour LudiGames]]
<<else>>
[[Conclusion]]
<</if>>
<img src="https://picsum.photos/200/300?random=1"/>Se former au test, quelle drôle d'idée? Pas vraiment pour Eva, ni pour le Scrum Master qu’elle a convaincu.
Dans sa formation, il a la chance d'avoir un formateur qui met en pratique l'ISTQB au sein de son entreprise et en plus cette dernière est agile!!!
Entre bonnes pratiques, nouveaux rituels et autres petits trucs, il est ravi.
Bon, le seul point moins drôle c'est de passer la certif!!! Elles sont cossues les questions dit donc. Mais le Scrum Master réussi à l'obtenir! Ça va faire bien sur son CV!!
Eva a hâte de l'aider à mettre tout ça en pratique. Mais que font-ils une fois cette certification en poche?
<<if setup.steps lt 12>>
#Le test c'est super, mais Eva a l'impression que le monde agile n'est pas trop versé à ce langage. Elle décide d'aller voir ce qu'en dit la communauté. [[9 - Eva participe à son premier Agi'Lille - LudiGames]]
#Avec le Scrum Master, Eva se lance dans la mise en place des [[9 - Les 3 amigos - LudiGames]]
#Le test géré, Eva s’intéresse à [[9 - La dette technique et Scrum - LudiGames]]
<<else>>
Le Scrum Master parle à Eva des 3 Amigos...
Ah, les 3 amigos, ce fabuleux film d'animation de Disney. Dans ce dernier, Donald n'est pas plus à son avantage que d'habitude mais...
On est pas vraiment là pour faire de la critique cinématographique!!
Plus sérieusement, les 3 amigos correspondent au concept de mettre dans la même pièce demandeur, développeur et testeur afin qu'ils tombent d'accord sur une définition de la demande correcte, et notamment des éléments nécessaires au développement de la solution ainsi qu'au test de cette dernière.
Eva se dit que cette pratique est formidable et qu’elle doit en parler autour d'elle et la mettre en action.
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le raisonnement du Scrum Master est simple : l'équipe de Dev ne peut pas alimenter les testeurs tout au long d'un sprint. Du fait, au début du sprint ils ne font rien et à la fin ils sont à la bourre. Tout cela résulte à un engagement de sprint qui n'est pas tenu à chaque itération.
Cependant, ils sont chanceux chez son client, car ils ont de vrais testeurs à disposition! Mais comme ils ne sont en plus, pas dédiés à une seule équipe de développement, on se retrouve souvent de gros délais.
De leur point de vue, il n'y a qu'une seule solution : extraire la responsabilité de test du mandat de l'équipe!
Oui, mais, les testeurs aimeraient aussi fonctionner en mode agile! Eva et le Scrum Master devisent alors un plan : le déversement de backlog!
Le principe est simple : les développeurs gèrent leur backlog, à la fin de chaque itération, ils alimentent un backlog de test. Le backlog de test est alimenté par plusieurs équipes de développement et les testeurs, qui travailleraient en sprint aussi, peuvent alors prendre un engagement vis à vis de ce backlog et s'atteler aux tests...
<<if setup.steps lt 12>>
Que font-ils de cette idée?
#Eva décide de creuser un peu sur le net ce qu'il y a autour du test en agile. Il découvre [[9 - Les 3 amigos - LudiGames]]
#Eva et Jean-Paul montent un dossier (enfin, une prez powerpoint en 37 points) et vont défendre leur idée auprès du management. Ce dernier semble intéressé et propose le lancement d'une expérimentation... mais[[Ca peut vraiment être efficace? - LudiGames]]
<<else>>
Oui, le déversement de backlog peut fonctionner... C'est un peu comme une démarche Kanban mais avec, à la place des étapes, les sprints des équipes.
On va pas se mentir, Eva se rend compte rapidement (ou pas d'ailleurs), que c'est assez inefficace d'un point de vue rapidité de déploiement. Cependant, ça porte ses fruits au niveau qualitatif et ça rend le système relativement prévisible, enfin, tant que la qualité au niveau de l'équipe reste à un niveau correct!
[[Conclusion]]
<</if>>
[[1 - Choix du personnage]]
<img src="https://nicotondeur.fr/wp-content/uploads/2023/06/Qui-Est-Nico.jpeg" width="100%"/>
Super, le client l'a entendu. Ils lancent un comité de transformation... en embauchant des externes...
James est surpris d'apprendre que son idée a été recue mais qu'il n'a pas été convié à ce comité de transformation. Faut dire... il n'est qu'externe
Qu'à celà ne tienne! Il ne va pas se laisser faire ;)
Il provoque une rencontre avec ces 2 nouvelles personnes : un directeur de la transformation et un expert du change... James propose de commencer par se présenter. Chacun parle de son expérience passée, de ses envies pour son client.
James a l'impression d'entendre de beaux discours mais la seule chose qu'il voulait entendre et qu'il n'entend pas c'est une expérience agile chez les 2 nouveaux...
Bref, il comprend que le comité de transformation va principalement travailler sur l'efficacité, en amenant du "Lean management" comme ils disent, mais aussi sur l'aspect RH et sur la vision.
Donc, même si il compte bien garder un oeil sur la suite, il imagine assez difficilement faire changer les choses par le haut... pas de gestion de portfolio agile, pas de product management... pour le moment.
James se dit qu'avant de pouvoir avoir plus d'influence sur la transformation de son client, il a tout intérêt a poser des bases solides.
<<if setup.steps lt 12>>
#C'est pourquoi [[James continue avec son équipe Scrum - Indep]] afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
#Il souhaite travailler avec le PO afin de mettre en avant la [[Valeur Business Client - James Indep]]
#Il propose aux deux nouveaux de les aider et cherche une société pour les accompagner sur une définition de la vision client. [[Les experts de la vision - James Indep]]
<<else>>
* C'est pourquoi James continue avec les équipes Scrum afin de prouver par l'exemple les bénéfices d'une démarche agile maitrisée.
* Il souhaite également travailler avec le PO afin de mettre en avant la Valeur Business chez le client.
* Il proposera également, plus tard, aux deux nouveaux de les aider et cherchera une société pour les accompagner sur une définition de la vision client.
[[Conclusion]]
<</if>>Grosse question en ce moment. Y'aura-t-il encore des développeurs dans quelques années ou auront-ils tous été remplacés par l'IA?
Eva se veut rassurante. De son point de vue, il faudra toujours des DEV au sens agile du terme :
* On aura toujours besoin de personnes qui comprennent les besoins des utilisateurs pour les transformer en solution.
* On aura toujours besoin de vérifier la qualité des produits créés ainsi que le respect des instructions données.
* Il faudra toujours des personnes calées en technique pour garantir un code robuste et sécurisé!
Alors bien sur, le boulot de développeur risque de changer. On tapera moins de code nous même mais il faudra savoir interroger correctement les IA pour obtenir du code généré et le vérifier.
<<if setup.steps lt 12>>
#Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe. [[Gérer le run en Scrum - LudiGames]]
#En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la [[Valeur Business - LudiGames]]
<<else>>
Eva leur dit aussi qu'il faudra des personnes pour gérer le run, correctement, et réparer les erreurs générées par l'IA. Elle propose alors de travailler sur le sujet RUN avec l'équipe.
En plus, il faudra toujours des personnes pour prioriser les travaux à faire. Alors certe, ils seront réalisés plus rapidement mais il faudra quand même identifier la valeur Business.
[[Conclusion]]
<</if>>
Quel événement magnifique!!!
Le lieu, les bénévoles, les speakers!!! "tout le monde sont beaux"
Eva a la chance de pouvoir participer à plusieurs ateliers, dont un qui présente le No Estimate avec des légos et des pizzas (enfin je pense, j'ai pas tout compris moi même ;))
Serious Gaming, un nouveau mot dans son vocabulaire! Peut-être une nouvelle passion?
Les conférences ne sont pas moins inspirantes! Les keynoteurs de qualité, les sujets bien choisis...
Aller, on arrête là avec l'auto-congratulation ;)
Pour Eva, c'est l'occasion d'explorer des sujets méconnus, les tendances de demain. C'est également pour elle le moment de découvrir des pratiques qu'elle n'avait pas encore envisagées.
Elle a également pris le temps de discuter avec les autres participants et de découvrir d'autres environnements professionnels, d'autres problématiques que celles qu'elle a déjà rencontrées.
<<if setup.steps lt 12>>
Au sortir de l'événement, Eva peut prendre plusieurs directions :
#Eva a adoré les ateliers ludiques auxquels elle a participé. Elle souhaite se provoquer un maximum d'occasions pour exploiter ces Serious Games, en découvrir d'autres...[[Eva se passionne pour le Serious Gaming - Indep]]
#Eva a pris le temps de discuter avec les coachs agiles qu'elle a pu croiser. Chacun d'entre eux a apporté quelquechose aux réflexions d'Eva, comme si chacun souhaitait lui faire un petit cadeau. [[Eva rencontre des coachs inspirants - Indep]]
#Toutes ces personnes bienveillantes et bien pensantes. Ces puits de culture agile, d'expériences variées. En rentrant chez elle Eva se prend une grosse claque au moral. Elle ne se sent pas à sa place et se prend un gros [[Syndrôme de l'imposteur - Eva Indep]]
#Aprés l'atelier auquel elle a participé, [[Eva se passionne pour le No Estimate - Indep]]
#Pour elle c'est sur, l'année prochaine elle tentera de présenter un sujet de conférence!! [[Eva se lance dans l'écriture d'une conférence - Indep]]
<<else>>
[[Conclusion]]
<</if>>L'idée lancée par James va évoluer au fil du temps.
La première chose que James organise c'est un kick off de la communauté. Il invite toutes les personnes du client qui ont montré une appétence sur le sujet agile, ainsi que celles qui occupent des rôles systémiques agiles (Product Owner, Scrum Master...).
Ce collectif se réuni donc pendant 2 heures la première fois afin de définir ensemble les objectifs de la communauté, sa raison d'être. Basée sur les aspirations de chacun et sur ce qu'ils ont compris des volontés agiles de l'entreprise, les objectifs restent trés opérationnels pour la première version :
"S'améliorer entant que groupe dans l'utilisation des pratiques agiles et s'entraider sur les différents challenges de l'entreprise".
Ils discutent ensuite de la forme.
Au départ, ils proposent de créer un rendez-vous récurrent ouvert à tous les agilistes, et utilisent les Agile Topics Cards de Jimmy Janlën
<img src="https://i0.wp.com/agilewithjimmy.com/wp-content/uploads/2020/06/Cards.png?w=600&ssl=1">
Source : https://agilewithjimmy.com
Mais ils se rendent compte qu'au fur et à mesure des sessions, ces rencontres au format "Lean Coffee" ont de moins en moins de succès.
Ils essayent ensuite de proposer un ordre du jour défini à l'avance, cependant, les intervenants sont peu nombreux a proposer des sujets et en plus n'ont que peu de temps à
consacrer à la préparation de leurs rendez-vous.
Les internes considère que la gestion du jour le jour est plus importante que la communauté. James propose de s'investir, de faire venir des externes pour présenter des sujets... Au final, c'est lui, entant que seul coach de la structure qui insuffle toute l'énergie nécessaire à maintenir la communauté à flot. Mais le ROTI reste élevé et c'est sa principale motivation
[[Conclusion]]<img src="https://picsum.photos/200/300?random=1"/>L'idée lancée par James va évoluer au fil du temps.
La première chose que James organise c'est un kick off de la communauté. Il invite toutes les personnes du client qui ont montré une appétence sur le sujet agile, ainsi que celles qui occupent des rôles systémiques agiles (Product Owner, Scrum Master...).
Ce collectif se réuni donc pendant 2 heures la première fois afin de définir ensemble les objectifs de la communauté, sa raison d'être. Basée sur les aspirations de chacun et sur ce qu'ils ont compris des volontés agiles de l'entreprise, les objectifs restent trés opérationnels pour la première version :
"S'améliorer entant que groupe dans l'utilisation des pratiques agiles et s'entraider sur les différents challenges de l'entreprise".
Ils discutent ensuite de la forme.
Au départ, ils proposent de créer un rendez-vous récurrent ouvert à tous les agilistes, et utilisent les Agile Topics Cards de Jimmy Janlën
<img src="https://i0.wp.com/agilewithjimmy.com/wp-content/uploads/2020/06/Cards.png?w=600&ssl=1">
Source : https://agilewithjimmy.com
Mais ils se rendent compte qu'au fur et à mesure des sessions, ces rencontres au format "Lean Coffee" ont de moins en moins de succès.
Ils essayent ensuite de proposer un ordre du jour défini à l'avance, cependant, les intervenants sont peu nombreux a proposer des sujets et en plus n'ont que peu de temps à
consacrer à la préparation de leurs rendez-vous.
Les internes considère que la gestion du jour le jour est plus importante que la communauté. James propose de s'investir, de faire venir des externes pour présenter des sujets... Au final, c'est lui, entant que seul coach de la structure qui insuffle toute l'énergie nécessaire à maintenir la communauté à flot. Mais le ROTI reste élevé et c'est sa principale motivation
<<if setup.steps lt 12>>
#Un des problèmes communément remonté lors des Q&R se situe dans la gestion du RUN, James cherche des réponses. [[Gérer le run en Scrum - RDB]]
#Au bout de quelques rencontres, James et la communauté proposent la mise en place du rôle de [[9 - Scrum Master et QA - RDB]]
#Aprés autant d'aventure, James se cherche [[Une formation certifiante Coach - RDB]]
#Il sait maintenant comment présenter des sujets du fait [[James se lance dans l'écriture d'une conférence - RDB]]
<<else>>
[[Conclusion]]
<</if>><img src="https://picsum.photos/200/300?random=1"/>Le craftsmanship, ce mode de pensée qui remet l'aspect artisanal au centre de la pensée produit. Entre developpement des compétences techniques individuelles et la mise en place de méthodes et pratiques pour les favoriser, Eva voit une multitude de chemins à suivre.
Elle commence avec son équipe par les bases :
* mise en place de bonnes pratiques de co-developpement technique (Pair programming, peer review)
* déploiement d'une solution centralisée de qualimétrie et gestion de la dette technique
* travaux autour du TDD et de l'automatisation des tests unitaires, amorce de BDD avec le PO
Tous les chemins se lancent en même temps.
Certaines choses prennent et d'autre moins. La gestion de la dette technique, par rexemple, pose quelques soucis à l'équipe.
<<if setup.steps lt 12>>
Où voulons nous emmener Eva à partir de là?
#Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de rester dans le cadre Scrum. [[La dette technique et Scrum - LudiGames]]
#Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames. [[Accelerate chez LudiGames]]
#Un des freins au pure Craftsmanship chez LudiGames semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. [[DevOps - LudiGames]]
#Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva explore le sujet. [[Developpeurs et IA - LudiGames]]
<<else>>
* Eva explore les différentes possibilités de gestion de la dette technique, tout en essayant de comprendre la compatibilité, ou pas avec le cadre Scrum.
* Eva lit plusieurs articles sur l'étude Accelerate et se demande si les apprentissages de cette étude peuvent s'appliquer à LudiGames.
* Un des freins au pure Craftsmanship semble résider dans le fait que la prod n'est pas directement gérée par l'équipe de développement. Eva est persuadée qu'il faut y changer quelquechose. Eva va donc également explorer le DevOps.
* Un des développeurs de l'équipe pose une question ouverte à celle-ci lors d'une rétrospective : est-ce que ca vaut encore le coût de travailler au craftsmanship avec l'arrivée de l'intelligence artificielle? Eva s'inquiète également.
[[Conclusion]]
<</if>>