mardi 16 décembre 2014

Sous-titres français des vidéos de Chet Rong

La plupart d'entre vous connaissent probablement les petites vidéos très drôles de Chet Rong, dont voici des liens sur Youtube :
- Sur la structure de l'équipe
- Sur la façon de mener les rétrospectives
- Sur l'organisation des daily stand-up
- Sur la manière d'écrire les spécifications
- Sur la planification du sprint

Pour ceux qui ne connaitraient pas, elles décrivent sous forme de sketchs humoristiques ce qu'il ne faut PAS faire en Agile.

J'ai eu l'occasion de montrer ces vidéos à certains collègues qui se sont plaint qu'il n'y avait pas de sous-titre français !

Qu'à cela ne tienne, voici ici-même les traductions dans des fichiers SRT pour ceux qui voudraient récupérer les vidéos en mp4 et les visionner avec les sous-titres :)

Enjoy !

- Sous-titres pour la structure de l'équipe
- Sous-titres pour la façon de mener les rétrospectives
- Sous-titres pour l'organisation des daily stand-up
- Sous-titres pour la manière d'écrire les spécifications
- Sous-titres pour la planification du sprint

jeudi 20 février 2014

Faire animer sa rétrospective par un scrum master d'une autre équipe

Et bien, je me rends compte que mon dernier article date de fin 2012 après l'Agile Tour...
J'avais un rythme de croisière avec les rituels Scrum, les projets, etc... C'est pas bien de se laisser aller !

Je reviens donc avec un sujet lié à une expérimentation que nous avons faite dans ma société et dont je souhaite partager le feedback ici.

La multiplication des produits et des projets a engendré autant de postes de scrum master. Je pense que nous appliquons correctement la méthode et les équipes ont du succès dans leur grande majorité.

Lorsque tout cela fonctionne bien, on peut soit se laisser porter par la routine, soit saisir l'opportunité pour expérimenter. Chose que j'ai faite en collaboration avec un collègue scrum master très motivé par l'agilité (Hugo, si tu me lis...).

Ainsi, ce dont je veux parler ici est l'échange de scrum master entre équipes pour animer les rétrospectives.

Pourquoi ?
En tant que scrum master, je fais attention à animer la rétrospective de fin de sprint de façon dynamique. J'essaie de ne pas provoquer l'ennui dans la salle et d'intéresser "l'auditoire". Pour résumer, je m'attache beaucoup à la forme pour permettre à l'équipe de s'exprimer au mieux et ainsi désigner les problèmes et trouver des solutions à appliquer au sprint suivant.

Cependant, je suis aussi une partie prenante du projet et j'ai aussi envie de m'exprimer sur les différents sujets. Ok, ça je le fais malgré tout ! MAIS ma position d'animateur fait que j'évite par réflexe d'accaparer la parole au risque de donner l'impression de trop vouloir diriger la rétrospective et frustrer potentiellement certaines personnes présentes. Même avec toute la bonne volonté du monde, ceci peut arriver, je vous le garantis !

Avec l'intervention d'un scrum master extérieur, je peux m'installer tranquillement à la table au même niveau que le reste de l'équipe. Je m'enlève aussi la tâche d'animer la rétrospective et je suis ainsi focaliser sur les thèmes à discuter.

Modalités :
Je parle bien ici de faire venir un autre scrum master pour animer la rétrospective de mon équipe (et en échange, je suis intervenu auprès de son équipe). Pas question par contre de se présenter aux daily stand-up ou mettre son grain de sel pendant le sprint car le but de cet échange est justement d'avoir quelqu'un de neutre, qui en sait le moins possible sur les événements survenus pendant le sprint au moment de commencer la rétrospective.

Avantages :
- l'avantage le plus évident est que le scrum master intervenant a du recul par rapport au projet, par rapport à l'équipe. Il est éloigné des événements du sprint et il se concentre donc uniquement sur les thèmes que l'équipe souhaite évoquer à la rétrospective. Il n'influence personne et est à l'écoute comme il n'a pas à donner son avis.
- le scrum master externe ne fait qu'animer le rituel et il est donc à 100% à l'écoute. J'évoque ce point car il m'arrive par exemple de chercher de façon automatique une solution pendant qu'une personne expose un problème. Si ensuite j'expose ma solution, ça peut être frustrant pour les autres car ils ont aussi quelque chose à proposer mais peuvent être tenter de se mettre en retrait car c'est le scrum master qui expose SA solution.
- à l'instar d'un coach agile extérieur pour aider à animer des rétrospectives, un scrum master d'une autre équipe aura, comme évoqué ci-dessus, du recul par rapport à mon projet/équipe. Par contre, il sera bien plus au fait de la politique et des habitudes en place au sein de la société. Il comprendra plus aisément certains impératifs ou certaines contraintes.

Inconvénient :
- le scrum master intervenant va devoir consacrer entre 1 à 2 heures (voir plus si vraiment il y a beaucoup de choses à discuter) à un projet qui n'est pas le sien pour animer la rétrospective. Ce temps ne sera pas dédié à son équipe et cela pourrait poser des problèmes dans certaines organisations.

ROTI :
Je donne clairement un 5/5.
En plus des avantages pour le projet et l'équipe évoqués plus haut, il y a un gain personnel. Déjà, la séance que je consacre à une autre équipe me permet de tester mon style d'animation auprès d'autres personnes. Ce n'est pas anodin comme expérience car les gens se connaissent bien (trop bien ?) au bout d'un certain temps à travailler ensemble, et éprouver son style sur un terrain nouveau est toujours une bonne expérience.
Ensuite, voir le format d'animation d'un autre scrum master sera enrichissant pour moi car je suis pris dans des habitudes, potentiellement mauvaises que même mon équipe ne voit pas ou plus.

Comme vous pouvez le voir, les avantages sont donc multiples et consacrer 1 ou 2 heures pour pouvoir s'améliorer est un prix bien maigre à payer. Je vous invite donc clairement à expérimenter ces échanges si vous en avez l'occasion :)

lundi 10 décembre 2012

Agile Tour Paris 2012 : Agilité, Management et Sponsorship

Bertrand Dour de AgileGenius LTD nous a proposé... hmmm, disons une sorte de "one man show" sur le sujet "Agilité, management et sponsorship", tout cela avec beaucoup d'humour et pas mal de sarcasmes :)

Le premier constat est le suivant : l'agilité est en hausse, de plus en plus répandue et très demandée maintenant par des clients. Naturellement, cela intéresse des SSII proposants des consultants. D'où le phénomène du commercial généraliste qui va se mettre à "vendre" (notez bien les guillemets) de l'agilité.

"Agilité vs méthodes agiles"
Alors tout le problème est là. Un commercial généraliste qui sait vendre du consultant Java ou BI ou MOA va tenter de comprendre (à sa façon) l'agilité...
Il se dit à propos de l'agilité et des méthodes agiles : "on va dire que les deux sont pareils".
Erreur bien sûr !
=> L'agilité est une philosophie tandis que les méthodes agiles sont des outils et des pratiques pour mettre en place l'agilité !
Ainsi il part déjà sur de mauvaises bases et Bertrand nous décrit les conséquences de cette façon de penser.

Acte 1 : "l'offre Agile"
Le discours du commercial va être adapté aux différentes parties pour vanter les bienfaits de son produit "Agilité".
- aux managers, il va promettre "demain vous êtes agile !"
- au marketing, il va leur faire miroiter un "meilleur time to market" et des développeurs favorables aux changements
- à la DSI, il va leur vendre une "augmentation de la productivité", une "meilleure visibilité", une "amélioration de la qualité", une "réduction des risques"
=> l'agilité c'est bien, c'est fashion !

Acte 2 : "C'est presque comme..."
Dans la continuité, le commercial généraliste va simplifier les choses pour rendre la mise en place de l'agilité facile :
- c'est le rapprochement business / IT
- il faut des open spaces

Acte 3 : Ce qu'ils ont compris...
Au final, qu'ont donc compris les clients ?
- valeur business ?
- projets vs produits ?
- équipes auto gérées ?
- scrum master ?
- implication des utilisateurs ?
- implication dans le produit ?

Acte 4 : quelques mois plus tard
En appliquant une "agilité" à cette sauce, les résultats seront rapides...
oui, rapidement désastreux :
- des équipes à bout de souffle
- une perte de qualité des développements
- l'échec bien sûr de la transformation
- probablement un blocage et un arrêt

Epilogue :
La finalité de la démonstration de Bertrand Dour est de montrer qu'on aura une mauvaise compréhension de l'agilité si on ne prend pas le temps de bien se faire expliquer.
A première vue, l'agilité parait simple avec ses règles de bon sens. Mais la mise en place peut être ardue et si elle est mal faite ou forcée, elle mènera à l'échec.

Les clés du succès ?
- de la transparence : y compris au niveau commercial.
- de l'adhésion : si les personnes n'adhèrent pas, il ne faut pas y aller.
- de l'implication : si on est ok pour appliquer alors il faut impliquer toute l'organisation, pas que les développeurs !
- du support : écouter les conseils, sortir pour voir comment ça se passe ailleurs.
- être moteur de changement si on est motivé

Au final, on notera l'attaque à peine déguisée contre les SSII qui se sont engouffrées dans la brêche de l'agilité lorsqu'elles y ont vu le potentiel commercial. J'espère en tout cas qu'il n'y avait pas trop de commerciaux dans la salle car ils devaient se sentir mal :P Malgré l'humour sarcastique et les piques lancés, il faut garder en tête le message fort que l'agilité va au-delà de la simple application des méthodes agiles. L'implication des gens et la compréhension de la philosophie de l'agilité est primordiale pour une transformation correcte. On ne peut pas vendre l'agilité comme un produit qu'on achète et qui fera les tâches qu'on lui demande. Il faudra y mettre du sien (et on parle là de l'organisation entière).

ROTI : 5/5

mercredi 5 décembre 2012

Agile Tour Paris 2012 : Pratiques Agiles comme métaphore des techniques Lean

Oana Juncu de cOemerge part d'un constat : Agile c'est bien mais Lean revient à la mode.
Au travers de sa conférence, elle effectue donc un rapprochement entre ces deux démarches.

Pour cela, elle se propose via le "clean language" de comparer certaines techniques Agile et Lean.

Tout d'abord, qu'est-ce-que le "Clean language" ?
C'est l'utilisation de métaphores sans en avoir conscience : "décrire des concepts inconnus ou complexes en analogie avec des concepts connus et simples".

En gros, c'est :
=> expliquer à quelqu'un en utilisant quelquechose qu'elle connait pour qu'elle comprenne le nouveau concept.
=> on pose donc la question : "ceci est comme quoi d'autre ?"
=> ainsi, on posera la question dans cette conférence : "des pratiques Lean sont comme quelles techniques Agile ?"

Dans notre cas, Oana a traité les concepts suivants :
1) Definition of done
2) Story Mapping
3) Retrospective

1) La collection de DoD en Agile est comme "relever le Value Stream Mapping" en Lean.
La DoD est la collection de critères d'acceptation => elle met le poids sur la valeur produite pour identifier cette valeur d'usage.
Qu'on peut illustrer par :



2) Le story mapping en Agile est comme faire un "Gemba Walk" en Lean.
C'est un voyage dans le comportement de l'outil.
Qu'on peut illustrer par :



Gemba Walk est équivalent à cela. Le "Go and see" est "l'art d'être au bon endroit" => Il s'agit d'aller sur le terrain pour comprendre comment l'organisation fonctionne et faire ce voyage pas à pas en s'immergeant dans la prolématique du terrain.
DONC un story mapping équivaut à un Gemba Walk dans la tête de l'utilisateur, piloté par la logique de fonctionnement du produit.

3) La rétrospective est comme remplir un A3 (thinking).

Et là, l'orateur fut à cours de temps... snif !

ROTI : 4/5 quand même car ce fut très intéressant mais j'en sors frustré évidemment...

dimanche 2 décembre 2012

Agile Tour Paris 2012 : Le kanban était en noir

Olivier Destrade d'IOcéan nous proposait une mise en scène d'un daily stand-up avec des intervenants se trouvant à grande distance les uns des autres :
- Le product owner est à Paris.
- Le ScrumMaster et un développeur sont à Montpellier.

Via cette petite pièce jouée avec ses deux collègues, il nous montre un exemple d'utilisation via Redmine + Kinect + projecteur sur un grand écran pour déplacer les cartes des user stories sur le taskboard partagé.

Scénario est le suivant :
- le déc a détecté des bugs qui sont bloquants pour la fonctionnalité
- il doit donc retirer d'autres US pour pouvoir consacrer des points d'effort à ce bug
- le ScrumMaster est d'accord mais le PO dit que tout est prioritaire
- Ils se mettent donc d'accord pour revoir le périmètre de certaines US afin de réduire les points et faire entrer le fix du bug dans le sprint en cours.

Les plus selon moi :
+ les intervants se voient
+ le taskboard est partagé, les personnes à Paris et à Montepellier agissent sur le même kanban
+ le PO pouvait voir QUI déplaçait quelle carte

Les moins selon moi :
- Pas d'historique sur qui déplace quoi sur le taskboard
- la détection des mouvements des doigts au moment de la saisie
- l'utilisation d'un projecteur ne permet pas un affichage continu au long de la journée

Conclusion :
Un numéro sympathique qui voulait se la jouer "Minority Report". La collaboration entre intervenants à distance est facilitée par la vidéo et la vision des mouvements de chacun (contrairement à la manipulation d'une souris par exemple). il y a de l'idée mais cela demande encore à être perfectionné.

ROTI : 3/5

vendredi 30 novembre 2012

Agile Tour Paris 2012 : Equipes de production ITIL et équipes de développement agiles, comment bien travailler ensemble ?

Alexandre Jacob de Coactiv revient sur son expérience dans la gestion de la relation entre des équipes de production et de développement où survenaient des problèmes de communication et de travail.

Voici le contexte :

D'un côté une équipe de développement agile :
- avec des livraisons hebdomadaires.
- plusieurs projets en parallèle.
- un besoin business instable.
- des technos vieilles et contraignantes (ça par contre, c'est hors agilité).

De l'autre côté, une équipe de production ITIL :
- un ensemble de bonnes pratiques.
- centrée sur le client.
- une plateforme stable.
- elle essaie d'avoir le moins de mise à jour possible.
- elle veut savoir ce qui est livré et quand.
- elle effectue des retours arrière faciles.
- elle est un détecteur de problèmes.

=> Les priorités et les valeurs sont différentes :
- mises à jour fréquentes vs. peu de mises à jour.
- développement rapide vs. détecter les problèmes + existence de procédures.
- mode réactif vs. mode proactif.
- ajout de fonctionnalités vs. faire vivre l'existant.

Cependant il y a des forces de l'équipe de production ITIL pour l'agilité :
- CSI : Continuous Service Improvement.
- très réactive face aux problèmes.
Par contre, ce qui n'est pas bon :
- la gestion du changement est complexe.
- le rythme des releases n'est pas adapté.

La question qui s'est alors posée était : "Comment rendre son équipe de production agile ?"
- le plus universel : Kanban.
- Passer aux flux tirés.
- avoir un backlog alimenté par l'équipe QA qui pousse les items testés.
- faire des rétrospectives.
- être piloté par la valeur métier.
- automatiser ce qui a peu ou pas de valeur ajouté.

Ainsi, Alexandre Jacob nous propose les clés suivantes pour organiser une équipe de production pour qu'elle soit agile :
- accepter le changement.
- collaboration avec l'équipe de développement (daily, planning).
- objectifs communs et partagés.
- automatiser les process de delivery.
- simplifier les process de gestion du changement et de release.
- créer une synergie et de la collaboration entre les équipes de dév et de prod.
- organiser le suivi et le traitement des anomalies ensemble.
- pour aller plus loin dans la collaboration : DevOps


ROTI : 4/5

lundi 26 novembre 2012

Agile Tour Paris 2012 : Tests et agilité - la vraie vie

Sylvain François de la start-up Kalistick nous propose une démystification des tests.
Il part du constat suivant :
- L'agilité est empreinte de la notion de "Definition of Done" pour les user story et les tâches.
- Cependant il subsiste une difficulté à définir le Done pour les tests.

Cela est difficile en Agile à cause :
- des livraisons rapides
- du développement incrémental
- de l'adaptation au changement
...
beaucoup de challenges donc et un besoin d'automatisation des tests.

Différents mythes tournants autour des tests ont engendré ce constat.

Mythe n°1 : la phase de test est incontournable
Dans les faits, cela n'arrive pas forcément, on a plutôt ça :
- pas de ressource spécialisée dans le test
- P.O = testeur
- pas de stratégie de test
- mal outillé pour les tests
exemples concrets :
- pas de tests fonctionnels poussés
- désactivation voir modification des tests pour les faire passer


Mythe n°2 : il existe une synergie testeurs / développeurs
En réalité, les testeurs et les développeurs ne vivent pas dans le monde et les objectifs sont parfois antagonistes (surtout quand les testeurs sont par exemple objectivés sur le nombre de bugs découverts). Les testeurs ont pour tâche d'identifier du bug Les développeurs ont pour tâche de "cacher" du bug
exemples concrets :
- des développeurs qui refusent des fiches de bugs si elles ne sont pas assez précises
- des testeurs qui refusent de tester
- des testeurs et des développeurs qui ne se parlent pas


Mythe n°3 : l'application est testée le plus en amont possible
Sylvain François nous explique que la pyramide de Mike Cohn est souvent inversée en tests manuels :
Il faut donc mettre en place des tests dès le développement !
Mais ce n'est pas évident : les TDD par exemple sont difficiles à mettre en place, l'écriture et la maintenance sont coûteuses.
Exemples concrets :
- des tests manuels sont effectués sur le sprint n puis les tests automatisés sont écrits au sprint n+1
- il faut alors dédier une équipe à l'automatisation des tests


Syndrome du fromage suisse
Le principe est que chaque couche de tests ne peut être exhaustif mais chaque couche couvrant potentiellement des parties non couvertes par d'autres, les zones se recouperont.
Il arrive que des cas ne soient pas testés du tout et là, il y a deux scénarios :
- cette partie ne fait pas partie des modifications livrées donc elle n'a pas généré de bug avant
- cette partie fait partie des modifications livrées et elle devient donc prioritaire à tester


Le graal de l'automatisation
Automatiser les tests c'est :
- des gains de productivité
- de la reproductibilité
- de la traçabilité
- moins ingrat pour les testeurs


Mais il y a des problèmes :
- le démarrage (monter en compétence, prioriser les tests à automatiser, refondre les tests existants, choisir l'outil)
- le coût de maintenant (compléxité d'implémentation, résistance des tests au changement)
- l'exploitation des résultats (origine des KO ?, pertinence des OK ?)
- performances (volume à analyser)


Conclusion :
- il est important de savoir ce qui est testé ici et là
- il est important de prioriser les tests car l'exhaustivité n'est pas atteignable
- il y a des écarts entre objectifs et réalité
- automatiser ne solutionne pas tout
- il faut identifier des critères de priorisation
- la couverture de code est une réponse mais il y en a d'autres


ROTI : 4/5