L’agilité et SCRUM pour les n… éophytes

Par défaut

Dans le cadre de mon rôle d’évangélisateur de l’agilité dans mon cadre professionnel, j’ai monté un ensemble de rendez-vous d’échanges intitulé « Parlons agilité », à la manière des « Rencontres autour de l’agilité » organisées par le Club Agile Rhône-Alpes.

Ces rencontres sont ouvertes à tous mais on y discute notamment entre praticiens agiles ce qui induit une difficulté pour les non praticiens totalement néophytes pour comprendre le sens de nos débats sans connaitre la base de la base :

  • qu’est-ce que l’agilité,
  • qu’est-ce que SCRUM ?

J’ai donc cherché à leur transmettre les bases en un minimum de temps. Nos rencontres « Parlons agilité » étant timeboxées sur 1h15, il m’a semblé préférable de fournir un peu de lecture en amont afin que chacun profite pleinement des temps de rencontre ou de jeux agiles pour vivre ou affiner la compréhension de l’agilité et éviter de passer du temps à discourir de choses que beaucoup connaissent et maîtrisent déjà.

Voici donc deux béabas :

Évidemment, c’est une porte d’entrée sur un univers en rupture, et évidemment, c’est une vision parmi d’autres, la mienne. Je ne prétends pas avoir fait un post PARFAIT, certains y trouveront peut-être des lacunes ou des imperfections.  Je suis ouvert. J’ai trouvé des choses très partielles sur le net, même sur wikipédia.

Ces deux articles ont au moins le mérite d’être des synthèses assez brèves pour comprendre quelque chose dans la suite de vos recherches et découvertes passionnantes sur cette nouvelle organisation du travail.

Bonne lecture

Jean

Mon premier Randori en java

Par défaut

Non, je n’ai pas mangé un bol de riz en Indonésie, j’ai participé à un Dojo à Montbonnot  pour développer un jeu de morpion en TDD avec des développeurs Java. Ce Dojo était mené sous forme de Randori c’est à dire dans un Dojo d’informaticiens une séance de pratique de dev et tests par pair-programming ou chacun à son tour passe en co-pilote puis en pilote face au clavier.

J’ai donc participé hier à mon premier Dojo Java… je vais pouvoir mettre sur mon CV Eclipse, Java, Junit… 6 minutes aux commandes et 6 minutes en co-pilote ;-) To be continued… Et puis va falloir que je lise java pour les nuls😉

En tant que Directeur de projets, voici les enseignements que j’en ai tiré :

  • en 1h, j’ai vu le caractère de chacun face à la fabrication d’une application dans une approche TDD
  • le réflexe TDD n’est pas acquis, il faut donc s’entrainer, les Dojo sont là pour ça
  • l’un est calme, et bien que ne disposant que de 6 minutes, fait un apport (test et programme) posé et maîtrisé
  • un autre fait très vite le code, lance les tests, ça plante, il remodifie très vite le code, ça replante, réitère ainsi de suite jusqu’à la fin des 6 minutes avec au final des TU en échec. Sa méthode ? Il donne l’impression de faire des modifs au petit bonheur la chance et de tester son test par le code… le monde à l’envers…
  • un autre réfléchit, écrit son test puis le code… lance les tests, erreur, puis réfléchit… jusqu’à ce qu’on lui dise de sauver son code et de relancer les tests… Et là, c’est OK. Il aurait pu passer 30 minutes à relire encore et encore son cas et son code … à ne pas comprendre ce qui ne marche pas… à réécrire son cas de test

C’est amusant mais le caractère des gens ressort très vite qd on est en temps compté dans un exercice de Randori…

Dans mon équipe Scrum, à part en cas de pépin où un équipier demande de l’aide et travaille temporairement en pair, le mode normal est chacun en solo face à son ordi.

Cela ne permet pas de débloquer l’autre, ni de voir ses forces (sur lesquelles je pourrai le solliciter si je bute sur un problème de tel type) ni ses faiblesse (afin de l’aider pro-activement à gagner sur ce volet).

D’où l’idée suivante que je propose de tester :

–          pour le prochain recrutement d’équipier sur un de mes projets, dès son arrivée, organiser un randori afin qu’il rencontre par pair chaque membre de l’équipe et que chacun le voit aussi à l’ouvrage. L’équipe étant collectivement engagée sur le sprint, chacun doit être conscient des possibilités des autres et notamment du nouvel arrivant pour l’aider à donner le plus vite possible le meilleur

–          pour le prochain projet que je démarre, organiser un randori au démarrage avec l’équipe pour les mêmes raisons qu’évoquées ci-dessus.

Pratiquez-vous cela chez vous ?

A+

Jean

Par défaut

Exercice de feedback intéressant – Posture de coach agile

Playground Change

La scène se passe dans le métro parisien.

– Tu prends la ligne 9 toi aussi ? Alors comment ça se passe sur ton projet en ce moment ?

– Ca avance … Tiens, faut que je te raconte, nous avons commencé de travailler avec des méthodes agiles !

– J’ai fait la même chose il y a un an et demi … Vous devez être en plein changement alors ! Où en êtes vous, toi et ton équipe, dans ces changements ?

– Nous sommes accompagnés par un consultant, il a commencé à nous parler de feedback, je n’ai pas bien compris où il voulait en venir …

– Que sais-tu du feedback ?

– Je me souviens des définitions qui m’ont été présentées il y a quelques années en formation. On y parlait de cybernétique et d’approche systémique.

– C’est un bon point de départ. Souhaites-tu que je te rappelle comment est présenté…

View original post 667 mots de plus

Post-it war à Innovallée

Par défaut

C’est désormais de notoriété publique, la Post-it War est partie d’une confrontation entre UBISOFT et BNP à Paris et a fait des émules y compris en province. A Lyon Part-Dieu, Boulevard Vivier Merle, les bureaux de part et d’autre du Boulevard se provoquent avec des créations en post-it.

J’avais envie de booster nos équipes agiles à Montbonnot et de promouvoir l’esprit agile, les bureaux voisins avaient fait des petits packman, des mini Lemings… rien de significatif.

J’ai monté un buzz en interne, lancé des piques, incité un collaborateur à faire une première création (un Mégaman)puis tout le monde est venu voir… ça gratouillait un peu partout… jusqu’à ce début octobre je donne un rdv à ceux qui voulaient… j’ai réussi à rassembler sur un nocturne une vingtaine de collabs qui, des équipiers agiles ou non aux Managers commerciaux et aux Directeurs de Projets sont venus tâter du post-it.

J’avais évidemment pris les dispositions, prévenu la sécurité, la Direction, la propriétaires des bureaux qui étaient sur les verrières les plus en vue… préparé un stock de bières et un buffet bio charcut / pain / fromage.

On a commencé à se chauffer avec un paquet de post-its… Esprit équipe auto-organisée : chacun a pris des post-its et des dessins ont vu le jour, travail spontané d’un collaborateur ou d’un binôme, d’un trinôme, sans aucune directive… Voici un aperçu de nos créations réparties dans les bureaux, couloirs, war-rooms, paliers, escaliers, salles de réunions…

OPEN POST-IT CREATIONS

Quelques traces de nos créations réparties dans les bureaux, les escaliers et paliers.

On s’est chauffés avec des petits worns, packman, megaman, panthère rose très réussie… et puis on s’est lancé dans une grande fresque DONKEY KONG sur la verrière d’entrée, haute de 3 étages et très visible depuis un rond point et une route très empruntée… de quoi mettre un peu d’ambiance chez nos voisins😉 Nous partimes 3… et finirent une dizaine sur cette grande fresque, chacun venant renforcer l’équipe initiatrice, encore une fois de façons spontanée.


On s’est bien marrés, on était content de notre création… les boss ont été super fiers de l’équipe qui du coup se sent valorisée… même le journal d’INNOVALEE parle de nous !!! Inespéré !

Notre Direction Régionale joue le jeu, pousse l’info à OPENMAG, le journal interne, ça crée un buzz dans les autres entités OPEN… notre bureau de Lyon se prépare à renchérir… le Directeur Régional a bien envie de retrousser ses manches et de coller des post-its… fever !
Comme quoi, une petite initiative locale peut faire des vagues😉

A+

Jean

Lequel est le plus « agile » ? Blog ou wiki ??

Par défaut

Petite réflexion sur les outils en vogue sur le web 2.0 et sur la contribution de la communauté agile.

Le nombre de blogs sur la toile va croissant, y compris dans le monde agile. Chacun y va de son apport avec sa logique éditoriale, certains favorisant les retours d’expérience, d’autres les notes d’humeur, une vision de l’avenir, une philosophie du SI, un rapprochement avec les logiques héritées de l’industrie nippone… On peut s’abonner aux articles de plusieurs blog, suivre les flux RSS au travers d’un agrégateur style netvibes, commenter et noter les articles, commenter les commentaires … faire un article sur son blog en citant l’article d’un autre blog… sans oublier de twitter vers tout et réciproquement😉

Effectivement le web 2.0 donne la main aux rédacteurs de tout poils et la toile se tisse avec des liens qui se croisent dans tous les sens. De sorte qu’il devient fastidieux, chronophage voire impossible de suivre tout ce qui est publié sur un thème, commentaires compris… Le coût pour se maintenir au courant des dernières publications devient prohibitif !!! Cela rappelle ce qui est advenu de l’informatique des grands comptes après des années d’empilage d’applications de toutes technologies, avec redondances fonctionnelles, interfaces multiples en entrée et en sortie… Quand la complexité devient exponentielle, le coût de maintenance devient prohibitif… il devient nécessaire d’urbaniser le SI. Alors, faut-il urbaniser l’édition on-line ?? Le wiki n’est-il pas en ce sens une préfiguration de solution ?

En ce qui concerne la communauté agile, je suis surpris de voir que les blogs pullulent et non les wikis qui me semblent beaucoup plus proches des valeurs agiles, deux d’entre elles en particulier :

  • L’interaction avec les personnes : est plus féconde dans le wiki (on écrit ensemble comme en pair programing) que dans le blog (j’écris un article, vous commentez mais l’article ne s’améliore pas…, vous pouvez aussi écrire un « contre-article » sur votre propre blog pour réagir et exposer un propos complet)
  • Davantage un produit opérationnel qu’une documentation pléthorique : de même, un wiki permet de consolider les apport et offre une vision complète, là ou une somme de blogs, commentaires et forums apporte une liste pléthorique de documentation électronique sans qu’aucune synthèse ne soit faite…

Cette vision se retrouve également au niveau des principes du manifeste agile :

  • Notre première priorité est de satisfaire le client (LECTEUR) en livrant tôt et régulièrement des logiciels (POSTS) utiles : l’avantage du wiki est qu’il est publié et évolue en permanence, alors que pour un blog, on édite un post quand il est bien ficelé, complet… on livre donc potentiellement moins souvent. Twitter ou un wiki semblent plus adaptés.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client : de même, dans un blog, une fois le post écrit, plus de changement… seulement des commentaires. Un wiki évolue en permanence…
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte : rejoint les points précédents
  • Les experts métier et les développeurs doivent collaborer quotidiennement au projet : l’aspect collaboratif me semble beaucoup plus évident sur un wiki que sur un blog, même un blog muti-éditeurs (où chacun publie ses billets).
  • La méthode la plus efficace pour transmettre l’information est une conversation en face à face : ce qui se cache derrière le « face à face » est sans barrières… or il y a moins de barrières et frontières dans un wiki que dans un blog (entre l’éditeur et les lecteurs, l’article et les commentaires)
  • Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment : c’est l’une des problématiques des blogs individuels : cela consomme un temps pour chacun pour avoir l’idée, la formaliser, la publier… un wiki par les contributions des autres apporte stimulation, idées croisées… et à la fois réduit la contribution à une idée, quelques mots, au lieu d’avoir un article complet à écrire.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité : en matière d’idées, il est plus facile de viser l’excellence à plusieurs (on se corrige, pense mieux…) et en pouvant retoucher, améliorer l’article (wiki) que sur un article mono-rédacteur figé (blog)
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle : la simplicité est très difficile à atteindre en particulier en un seul coup. Plus facile de tendre vers la simplicité en remettant l’ouvrage sur le métier… en prenant du recul, remettant en cause régulièrement ce qu’on considérait comme acquis… qui mieux que le wiki permet de revenir en arrière, de simplifier ? Quant au fait de maximiser la quantité de travail à ne pas faire, on peut faire le parallèle avec l’idée de maximiser la quantité de texte à ne pas lire : le wiki synthétise les idées contrairement aux blogs et forums où il faut lire le propos puis toutes les questions réponses, certaines étant souvent redondantes, incomplètes…
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent : il s’agit ici de l’architecture du wiki, l’organisation des idées… avec des liens internes et externes. Wikipédia me semble avoir une structure et une conception plus intéressante qu’une collection de plusieurs milliers de blogs…
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens : le travaille d’équipe me semble plus propre au wiki qu’au blog même multi-rédacteurs (mais rédacteurs individuels derrière un blog commun).

Aussi, pour aller au bout de la logique, j’ai eu l’idée de lancer un wiki pour contribuer à plusieurs à l’écriture d’un retour d’expérience consolidé et vivant permettant à des internautes qui aimeraient basculer en agile de comprendre comment y aller… Je l’ai baptise TRANSITION AGILE. Déjà 4 contributeurs m’ont proposé de confronter nos idées et écrire à plusieurs. Vos contributions sont les bienvenues. Pour l’instant, la contribution est sur login / mot de passe pour pouvoir être régulée. La lecture du wiki est ouverte au public. Cela pourra évoluer avec le temps selon l’usage et ma maîtrise de l’outil.

Bonne lecture.

Jean

Appel à contributions : projets agiles

Par défaut

Dans le cadre d’Agile Grenoble 2010, je vais animer une session avec Jean-François Jagodzinski sur la gestion de portefeuilles de projets agiles. Je suis à la recherche de contacts dans des sociétés ayant tout ou partie de leurs projets gérés en agile. Dans ce cadre, je cherche des contacts avec les portfolio ou program managers pour voir comment ils gèrent la répartition des ressources entre les projets.

Si vous êtes concernés ou si vous connaissez des sociétés et des personnes travaillant dans des environnement fortement agiles (au moins une partie significative des projets), je suis preneur des contacts. Le résultat sera publié sur un wiki et présenté à Agile grenoble 2010.

Des patates et des sucres

Par défaut

Hier soir, le Club Agile Rhône-Alpes s’est réuni comme à l’accoutumée pour l’une de ses « rencontres autour de l’agilité » fort sympathiques. Nous étions 18 professionnels à venir partager nos pratiques, nous ressourcer, nous ouvrir à une nouvelle vision de notre monde.

Emmanuel Etasse et Jean-François Jagodzinski m’ont demandé si je pouvais animer la session. Grand honneur pour moi qui ait rejoint le CARA tout récemment, que d’avoir une tribune dans un monde où je me sens encore tout petit. J’ai donc essayé d’apporter ma pierre à la communauté. Ou plutôt ma patate…

FORMATION DE FORMATEURS

J’ai eu la chance de suivre ce printemps une formation de formateurs délivrée par Jean-Denys Joubert au cours de laquelle j’ai puisé de nouvelles manières d’animer de manière décalée. En l’occurrence, d’utiliser des « jeux d’enfants » pour permettre aux adultes de prendre conscience de leur rapport à l’autre, à la collaboration, à la compétition, à la sécurisation de l’équipe et du résultat, à la gestion du temps, à la fixation et à l’atteinte d’objectifs, à l’amélioration continue, à l’innovation de rupture…  Nous avons réussi à évoquer tous ces sujets et partager nos impressions à partir de deux outils projectifs : des patates et des sucres en morceaux.

Comme nous avions 17 joueurs, nous avons travaillé en deux équipes de 8 et 9 joueurs qui se sont d’elles-mêmes mises en compétition sans que cela soit l’objectif des séquences proposées.

LA PATATE

Le jeu de balle ou jeu de la patate est un outil projectif sur la stratégie d’objectif, la prise de risque, le progrès continu, l’innovation par la rupture, la collaboration, la gestion du temps, le challenge. Avec un objet simple et une consigne simple, l’équipe dispose de peu de temps pour trouver une solution au problème. Elle teste son idée et mesure sa performance. Elle joue une seconde fois dans le même contexte et essaye de faire un peu mieux. Elle y arrive. Puis une nouvelle consigne ordonne de faire 2 à 10 fois mieux ! Une rupture. L’équipe y parvient aussi. Ce jeu qui n’est pas sans rappeler le travail agile en sprints nous questionne en particulier sur les manières dont nous animons les rétrospectives : chacun peut-il s’exprimer ? comment naissent les nouvelles idées ? apporte-t-on assez de sang neuf dans l’équipe pour ouvrir de nouveaux horizons, s’autoriser à envisager qu’il est possible de faire 2 à 10 fois mieux en changeant radicalement ?

LES SUCRES

Le jeu des sucres ou cubes est un jeu qui réalise un cycle complet de trois itérations. Chaque joueur doit estimer le nombre d’étages de la tour qu’il est capable de construire dans le temps imparti. Puis vient le chrono : la pression monte avec les étages et avec le temps qui s’égrène mais dans le stress, on ne sait plus combien il reste de temps. A quelques secondes de la fin, on essaye de faire mieux, d’ajouter un étage et patatras. Le chrono s’arrête, on compte les étages et les écroulements. Rires, satisfactions et frustrations se côtoient. « Je n’aurais pas dû… » Chacun s’exprime sur la manière dont il a fixé son objectif, comment il a géré la phase de réalisation avec ses coups de stress et ce qu’il éprouve face à son résultat. On y rencontre des prudents, des têtes brûlées etc. Comme dans la vraie vie, comme dans un planning poker…  Pour l’itération suivante, on adapte sa stratégie et son objectif, sa méthode aussi… on se compare à sa propre performance ou à celle des autres joueurs, c’est à chacun son karma. Deuxième pari, deuxième jeu, deuxième résultat… A-t-on fait mieux ? Dans l’absolu en nombre d’étages, en atteinte de l’objectif ? Mieux que les autres ? Puis vient le temps où l’on n’est plus chacun pour soi mais tous en équipe à chercher à atteindre l’objectif global. A chaque équipe sa stratégie, ses règles de solidarité implicites ou explicites… Si on fait le parallèle avec SCRUM, cela ressemble à plusieurs itérations avec chaque fois son planning poker, sa phase de réalisation et sa rétrospective. On voit l’importance des temps d’échange et ce que change dans la fixation et l’atteinte d’objectifs le passage d’une équipe ou chacun pense en fonction de lui-même à une équipe où chacun contribue à la réflexion et à la fixation et à l’atteinte d’objectifs communs. Dans l’une des deux équipes en lice, le temps de préparation a permis de réduire les risques, de calmer les têtes brûlées. Ils ont utilisé un secret : ils ont partagé la réponse à la question « je serai content si… » ; ils ont visé la satisfaction collective de savoir mesurer sa capacité de production (vélocité) et le fait de remplir le contrat dans le confort et sans risque (pour eux et pour le donneur d’ordre) plutôt que de viser d’avoir la plus haute tour et de compenser les faiblesses des uns par la force supposée des autres. Ils ont donc visé un nombre d’étages sur lequel chacun se sentait sans risque : confortable, pas le plus haut possible, car le « mieux est l’ennemi du bien » ; un sucre de plus et un édifice qui semblait solide s’écroule une seconde avant le gong. Chacun travaillant dans sa zone de confort, le contrat de solidarité a pu rester implicite. L’autre équipe était plus centrée sur le fait de faire mieux que les voisins au lieu de viser son confort. Elle s’est également plus centrée sur la prouesse technique (nombre d’étages) que sur la satisfaction du contrat rempli (avec bonus à l’appui). De fait, chacun a visé son objectif maximum atteint dans les tours précédant en s’imaginant qu’on ne pouvait pas revenir en arrière. Pour eux, le maximum d’avant devenait si ce n’est le minimum d’aujourd’hui, au moins le confort théorique acceptable. Or pour certains, c’était trop risqué  : avant la fin du chrono, l’un des joueurs rapporte qu’il lui manquait un étage… Au lieu d’avouer son risque d’écroulement et de demander à ses équipiers de compenser la fragilité de sa tour par un étage de plus sur une autre tour… il a tenté le diable et cela s’est terminé par l’écroulement de sa tour qui n’a pu être compensé par ses équipiers.

En synthèse, ce jeu des sucres est un révélateur efficace des personnalités qui composent l’équipe et de la manière dont l’équipe s’auto-organise.

De ce point de vue, ces deux heures de team-building et de partage me semblent tout à fait intéressantes dans le contexte d’équipes projet, en particulier agiles !

Un grand merci à tous les participants du CARA, à Manu et Jean-François qui m’ont donné la chance d’animer cette session et à Jean-Denys pour ses précieux outils que je ne saurais trop vous recommander

Jean