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

vendredi 23 novembre 2012

Agile Tour Paris 2012 : REX - 10 pièges à éviter

Tuan Vo Vinh de la Société Générale nous propose son retour d'expérience de la transformation agile et plus particulièrement de la mise en place de Scrum au sein des équipes qu'il gère. Il nous explique que sa motivation était sa frustration de n'avoir assisté jusqu'ici qu'à des conférences présentant des retours d'expérience de transition agile positive et sans problème. Son objectif est donc de nous présenter les erreurs et ratés qui sont survenus sur ses projets mais également les solutions qu'ils ont trouvées pour régler ces difficultés. Sa présentation consistait donc en une liste de 10 erreurs commises par une partie ou l'autre et ce que lui, en tant que non-agiliste, et ses coaches ont appliqué comme solution.

1) La fraude sur la marchandise :
Certaines choses paraissent évidentes pour les utilisateurs comme par exemple le fait que les anciennes fonctionnalités seront inclus dans le projet de refonte de leur produit. Malheureusement, ils n'expriment pas ce besoin auprès du PO qui acte donc le fait qu'ils ne souhaitent plus certaines fonctionnalités...
Solution proposée : avoir une liste d'exigences et un minimum viable product bien définis.

2) La prime d'assurance :
Le coût de l'agilité n'a pas été anticipée. Surtout l'erreur a été commise de considérer que les sprints seraient un succès à 100%, ce qui a entrainé un surcoût au final.
Solution proposée : prendre en compte le coût de l'agilité (rituels et estimation)

3) Oublier la vision :
Il survient au fil des sprints un problème de vision à long terme. Le PO reste focalisé sur le sprint N+1 voir N+2 mais en oublie qu'il y a par exemple une v2 dont les exigences peuvent demander certains aménagements pour éviter le faire/défaire/refaire.
Solution proposée : Remember the future en permanence !

4) "In God we trust" :
Penser à tort que le PO sait tout et ne se trompe jamais.
Solution proposée : challenger le PO, par l'équipe ou le project manager.

5) Engagement mou :
Il arrive que l'équipe ait une baisse d'engagement. Les solutions apportées par le management furent dans un premier temps agressives (heures supplémentaires) puis douces (récompenses en temps libre si engagement du sprint respecté). Cela n'eut aucun effet sur l'engagement.
Solution proposée : avoir des profils seniors moteurs

6) "Please do not disturb" :
Pas de gestion des imprévus alors qu'il y a des impératifs. Le sprint est trop isolé.
Solution proposée : l'adaptation ne veut pas dire échec. Acquérir la capacité de déscoper et restaffer.

7) Plaire au client, oublier le reste :
Typiquement les user story au black pour plaire aux demandes des sponsors/clients.
Solution proposée : ne pas sortir du backlog les fonctionnalités non fonctionnelles.

8) "What you see is NOT what you get" :
Conséquence de l'effet démo :le client pense à tort que parceque ça marche en démo, alors la fonctionnalité ne connaitra aucun bug en production.
Solution proposée : toujours avoir des tests UTILISATEURS avant le mise en production accepter les régressions tester les cas limites faire des sprints de bug fix

9) L'armée de clones :
Penser que tout le monde est identique car les performances individuelles sont masquées par l'équipe qui forme une entité. Le manager ne peut pas récompenser l'excellence individuelle.
Solution proposée : "one to one coaching et feedback" sans influence externe.

10) Pas pour les enfants :
l'Agile semble facile. C'est faux : la mise en place et le bon fonctionnement est difficile !
Solution proposée : choisir les bonnes personnes capable de le faire. Si les personnes n'acceptent pas l'agilité, c'est peut-être que ce n'est pas la bonne organisation pour l'appliquer.


Au final, ce qu'on peut voir c'est que l'agilité est difficile d'application. D'un point de vue personnel je ne suis pas d'accord avec certaines des solutions apportées qui font plutôt penser à une mauvaise compréhension de scrum. Cependant, chacun trouvera des solutions aux problèmes selon son contexte et les solutions proposées par Tuan Vo Vinh ont le mérite d'avoir fonctionné pour les projets SGIB, dans leur environnement particulier, ce qui n'est pas forcément une mauvaise chose après tout...

ROTI : 3/5

lundi 5 novembre 2012

Memento Scrum à destination de l'équipe

Mise à jour du 16/01/2013 : La version 1.1 du mémento est disponible en suivant le même lien.
Il est également disponible sur developpez.com !



Ca y est ! J'ai enfin réussi à finir ce mémento ! pfiou... \o/
Comme on me l'avait dit, le cadre de la méthode Scrum se veut simple : il y a les rôles, les artefacts, les rituels.
Mais la mise en oeuvre est complexe et parfois ardue même. Pour qu'elle soit correcte, il faut qu'elle soit suivie en engageant un coach par exemple qui accompagnera votre organisation dans sa transformation agile.

Alors pour répondre au premier besoin, c'est-à-dire constituer un résumé du cadre de la méthode Scrum, un mémento (un anti-sèche si vous voulez) me semble un support assez pratique :)

Quand je dis "à destination de l'équipe", cela veut dire que les informations contenues dans ce document sont utiles aux membres de l'équipe de développement pour leur permettre de travailler sur un projet Scrum. L'idée est d'avoir en un coup d'oeil des renseignements de base, en cas de trou de mémoire (comme on fait lors d'un examen, oups...).

J'aurais pu faire un billet avec exactement le même contenu mais un dépliant est plus facile à consulter une fois imprimé et plié comme montré ci-dessous :

Vous pourrez le poser dans un coin de votre bureau et l'ouvrir dès que vous voulez vous remémorer un élément. Puis vous pourrez le mettre à la poubelle une fois que l'équipe n'aura plus besoin de pense-bête :)

Pour finir, voici le lien vers le fichier PDF à imprimer chez vous !
Si votre imprimante gère le recto verso, il faut cocher l'option "Imprimer en recto verso", puis le radio bouton "Retourner sur les bords courts".


Je tiens à remercier Thierry pour ses nombreuses relectures.

lundi 14 mai 2012

Les acronymes SCRUM

Histoire de ne pas buter sur un acronyme (et c'est assez frustrant parfois), j'écris ce billet sous forme de petit pense-bête, de façon à conserver une liste des acronymes Agile et Scrum pour avoir à ma disposition la correspondance entre les lettres et les mots, plus une description rapide.
A compléter au fil du temps... :)


US : User Story
Description d'une fonctionnalité du point de vue utilisateur.

3C : Card Conversation Confirmation
Une US est souvent écrite sur une carte (Card) ou un post-it, généralement sous la forme "En tant que... Je veux... de façon à...". Cependant, elle doit aller plus loin que la seule phrase décrivant la demande fonctionnelle. Elle implique la partie Conversation, c'est-à-dire l'échange avec le client (par exemple lors de l'estimation) et la partie Confirmation, donc les tests d'acceptation de l'US. (Source : http://www.agileforall.com/2010/05/03/new-to-agile-remember-a-user-story-is-more-than-a-card/)

INVEST : Independent Negotiable Valuable Estimable Small Testable
Ce sont les caractéristiques que doit avoir une US.
- Independent : l'US est indépendante des autres US.
- Negotiable : une US d'un backlog de produit est modifiable jusqu'à ce qu'elle intègre un backlog de sprint.
- Valuable : l'US doit avoir de la valeur pour le client.
- Estimable : l'US doit être assez claire pour être estimée.
- Small : plus une US sera grande, plus il y aura d'incertitude pour l'estimer.
- Testable : on doit pouvoir écrire des tests d'acceptation pour une US.
(Source : article Wikipedia)

PO : Product Owner
Rôle de la personne représentant le métier, le client, l'utilisateur.

DEEP : Detailed appropriately Estimated Emergent Prioritized
Cet acronyme liste les caractéristiques que doit avoir un backlog de produit. Les items doivent être DEEP, ce qui signifie...
- Detailed Appropriately : détaillée de façon appropriée, donc d'être comprise par les développeurs.
- Estimated : les US estimées permettent de faire un macro-planning du projet.
- Emergent : un backlog est changeant avec le temps.
- Prioritized : les US doivent être ordonnées par ordre de priorité, ainsi les développeurs s'occuperont des US ayant le plus d'importance en premier.
(Source : http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep)

MVP ou MMF : Minimal Viable/Marketable Product
C'est l'ensemble des fonctionnalités que le produit doit posséder au minimum pour pouvoir être proposé sur le marché. C'est une sorte de liste des must-have, on n'y inclut donc pas les nice-to-have comme l'éternel "faire le café" (sauf si vous travaillez chez Nespresso évidemment...).

DOD : Definition Of Done
Dans le cas d'une US, la définition de fini est la liste de critères qu'elle doit remplir pour être considérée comme ayant l'état "fini", donc livrable à l'utilisateur final.

EVSP : Explorer Shopper Vacationer Prisoner
Lors de l'étape "Set the stage" d'une rétrospective, cette activité est utilisée pour prendre la température des participants et voir dans quel état d'esprit ils se rendent à ce rituel. Lorsque j'anime une rétrospective, je pratique cette activité sous la forme MCTP pour Moteur/Client/Touriste/Prisonnier. C'est une petite variation de l'activité décrite dans le livre "Agile Retrospective Making Good Teams Great" d'Esther Derbyand et Diana Larsen.
En plus d'être un sigle avec des mots français, il y a une différence au niveau du rôle de Moteur au lieu d'Explorer. Comme décrit dans le livre, l'Explorer va être intéressé par toutes les découvertes qu'il fera. Le Shopper, lui fera son marché des actions qui l'intéressent. Pour moi, une personne venant dans un état d'esprit Moteur compte apporter quelque chose et faire des propositions. Le Client, lui, se dit qu'il est là pour écouter et accepter les propositions qui lui paressent pertinentes. La différence se situe donc au niveau de l'apport à la rétrospective que la personne se positionnant en Moteur compte avoir.
Attention cependant au risque de micro-management, le Moteur souhaite proposer des choses comme par exemple des actions pour le sprint à venir. Mais c'est l'équipe qui aura la paternité de l'action décidée, potentiellement très différente de l'idée de départ.
(livre : Agile Retrospective Making Good Teams Great)

SMART : Specific Measurable Attainable Relevant Timeboxed
Les actions décidées lors de la rétrospective doivent être SMART.
- Specific : ne doit pas être vague.
- Measurable : doit avoir des critères d'acceptation.
- Attainable : ne doit pas être irréaliste.
- Relevant : doit être utile et avoir un impact.
- Timeboxed : doit être définie dans le temps.
(livre : Agile Retrospective - Making Good Teams Great)

ROTI : Return On Time Invested
C'est la note donnée à la fin de la rétrospective pour indiquer si le temps consacré à ce rituel a été utile.

ROI : Return On Investment
Retour sur investissement en français, donc les bénéfices engendrés par l'argent dépensé pour créer ou refondre un système.

ADAPT to Scrum : Awareness Desire Ability Promotion Transfer
Cet acronyme décrit les activités dans le cadre de l'adoption de Scrum par une organisation.
- Awareness : se rendre compte que les process en place ne délivrent plus des résultats acceptables.
- Desire : le désir d'adapter Scrum est une volonté d'affronter les problèmes.
- Ability : penser que vous avez la capacité de réussir avec Scrum.
- Promotion : faire la promotion de Scrum en partageant votre expérience et vous souvenir de vos succès.
- Transfer : diffuser votre implication dans l'utilisation de Scrum au sein de la compagnie.
(Source : http://itechcloud.blogspot.fr/2011/07/adapting-to-scrum.html)

lundi 16 avril 2012

Différence entre ScrumMaster et Coach Agile

J'écris ce billet pour répondre à une question posée dans un commentaire ailleurs dans ce blog :
Quelle est la différence entre un Coach Agile et un ScrumMaster ?

La méthodologie Scrum n'évoque pas de Coach Agile à proprement parlé, d'où la confusion qu'il peut y avoir entre le rôle de ScrumMaster et celui de Coach Agile.

Je fais ci-dessous un tableau pour essayer de mettre en parallèle les deux postes selon quelques critères :
ScrumMaster Coach Agile
Son Rôle - Le ScrumMaster est un facilitateur, un garant du processus, un gardien de l'équipe. - Le coach Agile est un guide auprès de l'équipe et auprès de l'organisation.
Ses Tâches - Il s'assure que la méthodologie est appliqué correctement.
- Il protège l'équipe des perturbations pendant le sprint.
- Il accompagne l'équipe et l'organisation dans sa transition vers l'agilité.
Son périmètre - Le ScrumMaster intervient en tant que point de contact avec le Product Owner.
- Il est un membre de l'équipe, il est partie-prenante au sein du projet.
- Le coach Agile est en contact avec toute l'organisation
- Il ne prend pas de décision affectant le projet, il oriente l'équipe pour les aider à prendre les décisions d'eux-mêmes.
Sa durée - Le rôle de ScrumMaster reste nécessaire même une fois que l'équipe est à l'aise avec Scrum. - Le coach Agile n'est plus nécessaire une fois la transition faite, il doit avoir transmis son savoir et l'équipe de développement n'a plus besoin de lui (en théorie)

La différence est perceptible mais on peut comprendre la confusion. De mon point de vue, une équipe agile peut avoir besoin d'un coach agile en plus d'un ScrumMaster. Il faut noter que l'un est temporaire et l'autre travaillera plus sur la durée du projet.

N'hésitez pas à mettre un commentaire si vous pensez que des points sont manquants ou faux !

Sur le web :
http://agilecoach.typepad.com/agile-coaching/2009/11/agile-coach-versus-scrummaster.html
http://www.agilejournal.com/articles/columns/column-articles/1917-the-role-of-the-agile-coach
http://scrumology.com/guest-post-what-is-an-agile-coach/

samedi 31 mars 2012

Scrum Day 2012 : "Le jour où Josiane sauva notre projet" par Nicolas Jozwiak et Nathaniel Richand

Le titre est intriguant au premier abord : on pourrait penser que Josiane est une super développeuse ou scrummaster ou coach agile qui serait intervenu et aurait sauvé le projet en 4 mois. Ce n'est pas exactement ça. Mais cette personne, ou plus justement ce persona, a eu une importance toute particulière au sein du projet dont Nicolas Jozwiak et Nathaniel Richand nous font le retour d'expérience.

Tout d'abord, il faut situer le contexte :
- un projet en crise commencé 8 mois plus tôt mais qui part en effet tunnel.
- des acteurs (métier, managers, développeurs) qui ne s'entendent pas sur la vision du produit.
- une deadline archi non négociable.

Nicolas et Nathaniel sont alors appelés pour intervenir sur ce projet et redresser la situation. Avec leur expertise de l'Agile et Scrum, ils mettent alors en oeuvre les outils à leur disposition pour identifier les problèmes et les résoudre, afin de permettre à leur projet de vivre. Parmi les outils présentés tout au long de leur conférence, on trouve l'emploi de product box, de story mapping, de timeline, et surtout Josiane.

Mais alors, qui est Josiane ? Car elle figure bien au titre de leur conférence.
Josiane est un persona, un personnage de fiction qui représente l'utilisateur qui accèdera à l'application. On lui attribue certaines compétences qui doivent être représentatives de l'utilisateur final lambda. C'est d'autant plus important lorsque, comme c'est leur cas, vos utilisateurs sont extérieurs à la société. Ils ne sont pas aussi disponibles que des utilisateurs internes vers lesquels on pourrait se tourner à tout moment pour poser des questions ou obtenir des précisions. Ils ne transigeront pas avec les fonctionnalités proposées et le risque est de les voir partir vers la concurrence s'ils ne sont pas satisfaits.

Le but est donc de bien comprendre les attentes de ces utilisateurs.
Et c'est là que se situait le problème : chaque acteur du projet avait une vision différente de la définition du produit qui serait proposé. Chacun voyait des fonctionnalités indispensables de son point de vue mais différentes du point de vue des autres parties.

Josiane a permis à tout le monde de parler la même langue si on peut dire. Josiane peut être vue comme un canal de communication entre des acteurs avec des compétences différentes et des connaissances différentes. Elle servait de référence pour que chacun utilise le même point de vue utilisateur et s'entende sur ce qui était prioritaire et/ou indispensable pour le produit.

Bon, le duo n'a pas utilisé que Josiane pour remettre en selle leur projet. Le concept de MVP (Minimum Viable Product) a permis de prioriser les fonctionnalités réellement indispensables pour leur deadline et les ateliers product box ont été utiles au début pour permettre à chacun d'exprimer sa propre vision du produit fini et la partager avec les autres. Mais l'artefact qu'est Josiane (et d'autres personas) semble être le pilier qui a permis à tout le monde de se comprendre et ensuite de travailler pour aller dans le même sens.

Aujourd'hui, le projet n'est pas bouclé à 100% mais il a été livré à la date souhaitée avec les fonctionnalités indispensables permettant acceptation du produit.
Ce projet prend l'allure d'une aventure avec des hauts et des bas. Elle inspirera peut-être des personnes qui se retrouveraient dans une situation similaire et pourrait utiliser leur Josiane...

En tout cas, la conférence fut un très bon moment, comme un bon film avec une happy end :)

ROTI : 5/5

Ce feedback est également disponible dans une version retravaillée avec Thierry Leriche sur son blog sur developpez.com

jeudi 29 mars 2012

ScrumDay2012 : "Scrum Master Academy" par Gilles Mantel et Jean-Laurent De Morlhon

Etant un aspirant Scrum Master, j’ai tout de suite été intéressé par cette conférence.

Xebia est une SSII qui propose des formations certifiantes de ScrumMaster. Cette certification fait d'ailleurs l'objet d'un débat au sein de la communauté Agile sur le bienfondé d'une certification à un poste dont les compétences relèvent plus de la pratique et de l'expérience, plutôt que d'une somme de connaissances.

Et le constat sur le terrain des deux orateurs ne fera pas mentir cette polémique. Il faut d'ailleurs beaucoup de courage pour admettre qu'un produit vendu par sa propre société (les formations certifiantes) ne fournit aucune garantie de produire de bons ScrumMasters. Attention, je ne dis pas que les personnes issues de ces formations ne sont pas compétentes, beaucoup le sont même certainement et je compte moi-même dans un avenir proche participer à une telle formation. Mais le succès du rôle de ScrumMaster demande d'avoir été un certain temps au contact des problèmes et parfois d'avoir échouer pour pouvoir rebondir et apprendre de ses échecs. Beaucoup de monde oublie qu'ils dévient de l'agilité en se focalisant trop sur l'application stricte ("by the book" comme on dit) de Scrum.

C'est via leurs observations sur le terrain que Gilles Mantel et Jean-Laurent De Morlhon ont tiré ce constat : certaines erreurs sont commises par des ScrumMasters, dues à l'inexpérience ou simplement car ceux-ci n'avaient jamais rencontré telle ou telle situation problématique. Les réponses apportées pouvant causer du tort au projet et/ou à l'équipe.

Les deux orateurs, qui sont des coachs agile aguerris, nous proposent donc une conférence organisée en une liste de règles à appliquer au jour le jour dans votre role de ScrumMaster. Celles présentées lors de la session étaient toutes pertinentes et pas mal d'entre elles tenaient presque du bon sens ("Connaissez vos valeurs agiles", "Transparence et pas indécence"). Le temps imparti était trop court pour passer en revue la totalité des règles qu'ils ont créées (une cinquantaine en tout). Ils se sont donc restreint à une quinzaine considérées comme importantes et les ont classées en deux catégories : les règles à appliquer en rythme de croisière et les règles de crise, qui court-circuitent parfois celles citées plus tôt dans les slides mais justifiées par le contexte.
La présentation de chaque règle est agrémentée d'exemples de situations vécues et ensuite du scénario de déblocage de celle-ci via l'application de la règle en question. Un point important sur lequel ont insisté les deux coachs était que ces règles ne devaient pas faire office de parole divine.
Lorsqu'en tant que ScrumMaster, on prend de la bouteille, on saura de mieux en mieux désamorcer les situations et sortir des impasses. C'est votre expérience et votre style qui fera de vous un bon ScrumMaster. Par contre, ces règles constituent une très bonne base de départ pour quelqu'un fraichement sortie d'une formation CSM.

La FrenchSUG devrait mettre en ligne la vidéo de cette conférence, je vous encourage fortement à la visionner (je mettrai le lien ici quand elle sera disponible). La présentation est très drôle dans la forme et la Scrum Master Academy a tenu ses promesses : de loin, on dirait un show d'un duo comique; de près, on apprend beaucoup de choses !

Ce feedback est également disponible dans une version retravaillée avec Thierry Leriche sur son blog sur developpez.com

mercredi 28 mars 2012

Lendemain de Scrum Day 2012

Et voilà, lendemain de Scrum Day et retour au bureau sur mon petit projet en Scrum.

Quel bilan tirer de cette journée ? Du bon, et même de l'excellent, mais parfois du pas très bon... En tout cas, ce fut une journée enrichissante et surtout dense (1 keynote + 2 conférences le matin et 3 conférences puis la keynote de cloture l'après-midi).

Comme d'habitude, c'est toujours un horrible choix cornélien que d'avoir des conférences auxquelles vous aimeriez assister mais programmées à la même heure dans des salles différentes !
Heureusement la FrenchSUG proposera les conférences en vidéo d'ici peu (j'espère très vite :)

Le centre de congrès était classe (forcément, vu le quartier...) et j'ai reconnu des têtes que j'avais croisées à l'Agile Tour.

Globalement :
- une keynote du matin en anglais et un Maarten Volders qui parlait assez vite. Shame on me, je n'ai saisi qu'à peu près 80% du discours;
- un scrum day tourné vers le jeu (game storming, innovation games) pas seulement pendant le keynote mais aussi lors d'autres conférences, chose à laquelle je ne m'attendais pas mais ce fut un sujet plaisant;
- les locaux étaient petit pour 500 personnes, surtout à l'heure du déjeuner où il fallait jouer des coudes;
- dommage que certains ateliers se déroulaient sur plus de 2 heures, ce qui équivalait à manquer 3 conférences !

Je ferai des feedbacks des conférences qui m'ont marqué plus en détail bientôt dans ce blog :)

ROTI : 4

lundi 19 mars 2012

En route pour le Scrum Day 2012

Le mardi 27 mars 2012 aura lieu le Scrum Day 2012 aux Espaces CAP 15 à Paris.

Comme pour le dernier Agile Tour, je tâcherai de faire un retour sur les conférences auxquelles j'aurai pu assister et qui m'auront marqué.

Au menu, des retours d'expérience, du management, du Scrum avancé et des ateliers.

Comme la dernière fois, mon twitter pour me suivre au fil de la journée @HingCChan

samedi 3 mars 2012

Lecture : "Agile Retrospective Making Good Teams Great" d'Esther Derby et Diana Larsen

Dans la méthodologie Scrum (et en Agile), la rétrospective est un des rituels les plus importants, voire le plus important. Les problèmes liés au projet et/ou à l'organisation y sont détectés par l'équipe, discutés et des actions y sont proposées pour améliorer le processus de développement. Consacrer un livre entier à ce rituel semble donc cohérent.

Le livre "Agile Retrospective Making Good Teams Great" se présente comme un mode d'emploi de la rétrospective.
Supposons que vous êtes un ScrumMaster qui cherchez à redynamiser une équipe que la routine a un peu endormi. L'équipe ne participe pas autant qu'avant lors des rétrospectives et vous avez besoin de nouveauté pour revigorer leur intérêt. Ce livre vous permettra d'y faire votre marché dans les différentes formes d'activités pour conduire les phases successives de la rétrospective et apporter du changement, suivi, on l'espère, d'un souffle nouveau.

La première partie du livre passe en revue rapidement l'ensemble du processus du rituel au travers des différentes étapes (set the stage, gather data, generate insights, decide what to do, close the retrospective).
Avec des exemples à l'appui, cela nous donne une idée de la rétrospective "de base". Bien sûr, elle ne doit pas se dérouler de la même façon dans toutes les équipes et les situations, sinon on n'aurait besoin que d'un robot =)

Les deux parties qui suivent donnent justement des conseils pour adapter sa façon de diriger une rétrospective en prenant en compte les spécifités de l'environnement où vous intervenez.

Pour adapter, et donc customiser le déroulement de votre rétrospective, les auteurs donnent ensuite une énorme liste d'activités, ceci pour l'animation de chacune des étapes du rituel. Personnellement, j'ai reconnu des activités déjà appliquées sur d'anciennes missions : - ESVP pour "set the stage", timeline pour "gather data", brainstorming pour "generate insights", SMART Goals pour "decide what to do", ROTI pour "close the retrospective". La richesse du livre est donc de proposer tout un tas d'autres activités pour redynamiser votre équipe et casser la routine instaurée par n rétrospectives d'itérations qui, en se ressemblant toutes, risquent de lasser votre équipe. Chaque activité est à appliquer selon la réaction que vous souhaitez provoquer dans l'équipe.

Puis les auteurs finissent sur une partie, très succincte, qui va plus loin, mais sans entrer dans le détail, en parlant des rétrospectives de releases ou de projets.

Le livre dans son ensemble est axé tant sur des techniques de conduite du rituel que sur la gestion humaine et il conclut en une partie plutôt ciblée coaching et psychologie pour tout ce qui touche à la conduite du changement ou au support.

Comme je le disais, ce livre peut être utilisé comme un livre de recette pour y piocher des activités selon vos besoins ou vos envies. C'est une lecture très intéressante, mais pas forcément à parcourir en un trait donc. Il y a une bonne quantité d'activités à proposer à son équipe pour casser une éventuelle routine.

dimanche 12 février 2012

Lecture : "Kanban et Scrum - tirer le meilleur des deux" par Henrik Kniberg et Mattias Skarin

En parcourant les articles sur l'Agilité ces derniers temps, on voit émerger comme une guerre intestine au sein des différentes pratiques Agile. Particulièrement, on voit une opposition entre Kanban et Scrum.
J'ai lu "Kanban et Scrum - tirer le meilleur des deux" il y a quelques temps déjà et le débat qui a lieu actuellement m'a donné envie d'en faire un feedback.
La cohabitation est-elle possible ? Pour être honnête, le livre ne concerne pas ce sujet directement : il fait en fait un comparatif entre les deux méthodologies. Mais ce qu'on retient de la lecture est que chaque méthodologie est plus adaptée selon les situations et c'est à nous de faire un choix quand à l'outil qu'on appliquera.

Première constatation après la lecture de ce livre : le titre est un peu trompeur car il traite plus de Kanban que de Scrum. L'un dans l'autre, ce n'est pas si grave car l'un des deux auteurs (Henrik Kniberg) a écrit le très bon "Scrum et XP depuis les tranchées" dont je parlais dans le premier billet de mon blog. Alors vous pourrez toujours vous y reporter si vous cherchez à vous renseigner sur Scrum en particulier :)
Deuxième chose à noter : le livre contient deux parties bien distinctes chacune écrite par un auteur.

La première partie est d'Henrik Kniberg. Il expose tout au long d'une longue comparaison les différences (mais aussi les similitudes) entre les deux méthodologies. Ceci au travers des différents processus, artefacts, en termes de normes et contraintes d'application qui les composent.
Les comparaisons sont faites en mettant Scrum face à Kanban et un peu aussi par rapport à d'autres méthodologies telles que XP ou RUP. Au fil de ces comparaisons, nous en apprenons plus sur le fonctionnement des deux méthodologies. Ce qu'on comprend c'est que Kanban et Scrum sont relativement peu normatifs, et comme cela nous permet pas mal de liberté, l'auteur nous encourage à intégrer d'autres outils pas forcément préconisés ouvertement par l'une ou l'autre des deux méthodes. La recommandation qu'on retient dans cette partie est d'utiliser les méthodologies selon les besoins et les particularités de son organisation. Kanban imposant moins de règles que Scrum, il est possible d'inclure à sa pratique de Kanban des éléments de Scrum si on le juge utile.

La seconde partie est de Mattias Skarin qui nous parle de l'application de Kanban dans un cas d'étude précis. Lorsqu'on applique une méthodologie à son organisation, c'est qu'on cherche à changer quelquechose. Et c'est presque toujours parceque ce quelquechose marche mal ou pas du tout. Il y a donc une situation de crise à l'origine de cette volonté de révolution. Mattias Skarin parle donc de cette expérience d'introduction d'une équipe d'exploitation à Kanban. Il nous explique la situation de départ, décrit les principes de Kanban (le TAF, le tableau, le temps de cycle...), et les résultats obtenus. Le bilan fait est franchement positif et si vous vous reconnaissez dans la situation de départ, la démarche décrite tout au long de cette partie pourra vous servir.

La structure du livre dans son ensemble se veut être une découverte progressive de Kanban. La comparaison avec Scrum en fait ressortir les spécificités et l'étude de cas nous plonge dans un exemple d'application et met en lumière ses bienfaits.

Finalement, contrairement à ce qu'on peut penser en lisant le titre du livre, les deux méthodes ne sont pas forcément opposées. Comme indiqué en introduction, il s'agit d'utiliser le bon outil pour sa situation et son problème propre. L'étude de cas exposé par Mattias Skarin l'a montré : pour une équipe d'exploitation et de support, Kanban est plus adapté que Scrum.

En conclusion, le livre est une bonne introduction à Kanban, à recommander pour une première approche. Le style des auteurs est fluide et les deux parties sont complémentaires sans trop de redites. On apprend à connaitre Kanban et on s'imprègne aussi de la philosophie des auteurs, c'est-à-dire expérimenter et adapter l'utilisation de la méthodologie choisie à son organisation.

jeudi 26 janvier 2012

La première vélocité

La vélocité est un concept un peu surprenant au premier abord. Cependant, il suffit de participer quelques temps à un projet Scrum pour bien comprendre son fonctionnement. Mais qu'en est-il de la première vélocité affectée à l'équipe de développement pour le début de la phase de développement ? Est-ce une valeur arbitraire fixée par la méthodologie ? Est-ce le coach Agile qui évalue l'équipe sur des critères objectifs et donne son évaluation de la vélocité de départ ? C'est ce que j'ai voulu savoir sur cette valeur de départ qui, bien que destinée à varier au fil du temps, donne le premier étalon de la capacité de développement d'une équipe.
Le constat que j'ai pu faire était qu'il y avait de multiples écoles en la matière. Chacune possède des attraits et je vais tenter de les décrire au mieux. Déterminer laquelle est la meilleure ne relève cependant pas de ce billet, et je pense surtout que le débat n'a pas lieu : chacun devrait choisir selon les spécificités de la société et de l'organisation où on intervient.

Pour ceux qui veulent fonctionner encore un peu avec le concept de jour/homme
Une méthode pour une équipe qui aborde pour la première fois le côté abstrait des points d'histoire est de faire un choix arbitraire pour l'équipe : par exemple, 1 point = 1 heure de travail. Cela permet aux gens habitués au concept de jour/homme de faire des estimations de leurs premières tâches en se basant sur une capacité de travail connue d'eux. Ainsi la vélocité est égale à la somme des points d'histoire pour le temps total d'un sprint (10 jours ou 80 heures) et donc on obtiendra une première vélocité pour l'équipe. Par contre, l'étape importante au cours des sprints suivants est de se soustraire de cette égalité ! Sinon, comment justifier que la vélocité puisse varier d'un sprint au suivant vu que le nombre de jours et d'heures restent le même ?

La vélocité atteinte lors du sprint 1 devient la vélocité étalon des sprints suivants
C'est un sprint qui est un peu difficile à faire avaler aux managers : on part en roue libre pendant un sprint, donc 10 jours... La capacité de travail n'est pas connue, donc le planning n'est pas faisable avant la prochaine rétrospective (argh!). Au bout de cette période, on obtient une valeur de vélocité qui donnera une base pour le planning poker suivant.

Affecter 2 points arbitrairement à une user story très simple et s'en servir comme étalon
Il s'agit de choisir dans le backlog de produit une user story très compréhensible de tous les membres de l'équipe. Comme chacun sait combien de temps il mettra pour la faire, on lui affecte 2 points. Les autres user story seront estimées par l'équipe relativement à cette user story étalon.

Estimer une multitude de user story divisées en tâches élémentaires
C'est une technique se rapprochant des deux méthodes précédentes, un petit mixte quoi. Il s'agit de prendre une bonne quantité de user story de façon à être sûr qu'il y en a bien plus que ce qu'on pourra terminer dans le sprint. Ce processus est quelque peu long car il faut diviser toutes les US en tâches la plus élémentaire possible de façon à avoir une estimation ne dépassant pas 5 points, quelle que soit la valeur que représente 1 point pour l'équipe. Ce découpage unitaire très poussé doit permettre d'estimer des US en se basant sur des tâches unitaires. A la fin du sprint, on obtient une vélocité assez juste.

Estimer une quantité limitée de tâches non cruciales à faire pendant le sprint 0
C'est un peu un mixte des méthodes dont je viens de parler, mais appliquer au sprint 0. Une possibilité est d'utiliser ce sprint zéro pour travailler sur des tâches de petite taille et qui serviront d'étalons pour l'estimation lors du planning poker en début de sprint 1. Un sujet qui génère des débats est bien ce sprint zéro. A quoi sert-il ? Entre autres à mettre en place les postes de travail, l'environnement d'intégration, etc... Dans notre cas, on peut consacrer un peu de temps de ce sprint zéro à faire du développement. Pas forcément quelquechose de crucial, d'ailleurs, c'est probablement déconseillé. Mais implémenter quelques fonctionnalités pour avoir l'opportunité de valoriser en points du vécu (c'est le point important) et s'en servir comme échelle après.

Enfin, une technique originale par Claude Aubry
Il nomme cette méthode "l'estimation par similitude d'effort". En gros, il s'agit de regrouper des user story par taille (basée donc sur l'effort estimé pour chaque story), d'ordonner ces groupes et d'affecter ensuite les valeurs de points provenant de la suite de Fibonacci (1, 2, 3, 5, 8, 13...) aux différents groupes dans l'ordre dans lequel ils sont : les US du premier groupe seront affectées de 1 point, le deuxième groupe 2 point, etc... La méthode est appliquée plutôt en formation pour gagner du temps, mais je voulais la citer car je trouvais que c'est une façon intéressante d'estimer quand on ne sait pas par quel bout commencer.

Finalement, une des critiques qu'on essuie lorsqu'on présente le concept de vélocité est l'incertitude sur les délais et le planning que les gens ressentent vis à vis de cette façon d'estimer. Oui, c'est du macro-planning et nous sommes incapable de donner une date précise de mise en production au client (dans un premier temps). Mais ne soyons pas hypocrites, ce n'est pas comme si on était plus juste en cycle en V, on est plus précis, ah, ça oui : "cette application sera livrée le 6 mars". Sauf que tout le monde sait pertinemment que la date de MEP ne sera pas respectée, ou alors avec beaucoup de concession sur ce qui sera livré... La question est : pourquoi vouloir être précis si on sait qu'on ne sera pas juste ? Avec le calcul de la vélocité, vos estimations se font de plus en plus précises au fil des sprints et la date annoncée pour la MEP sera bien plus juste (je fais la distinction entre juste et précis) vu l'expérience accumulée au fil du temps. La date de MEP est annoncée plus tard mais aura un écart moindre (voir aucun écart) avec la réalité. Et surtout, l'honnêteté aura été de reconnaitre notre incertitude du début et notre confiance plus tard, au lieu de s'engager sur un délai qu'on ne sait pas s'il sera tenable et ensuite de trouver des excuses pour justifier des retards comme cela arrive fréquemment sur du cycle en V. C'est comme quand vous faites construire votre maison par un promoteur, il vous annonce une date de livraison très précise qui ne tient pas compte des aléas (pluie, gel, etc...). Pourtant, ce sont des choses qui ont des grandes probabilités d'arriver alors pourquoi les ignorer ? Et à l'approche de la date de livraison de la maison, vous recevez une lettre listant les jours non travaillés pour telle ou telle cause. Résultat : le client n'est pas content et le constructeur rush les finitions pour minimiser le retard... \o/

A lire, les articles que j'ai consultés pour concocter ce billet :
http://www.aubryconseil.com/post/L-estimation-par-similitude-d-effort
http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/21/Estimation-Agile-et-Cone-d-incertitude
http://www.scrumdesk.com/effort-vs-time/
http://scrummethodology.com/scrum-sprint-zero/
http://stackoverflow.com/questions/5076452/how-to-set-up-story-points-and-first-sprint-capacity-for-scrum

samedi 14 janvier 2012

Mes deux cents : "Quelques mauvaises pratiques"

Ceux qui ont lu les quelques billets de mon blog auront bien senti que je suis très enthousiaste à propos de Scrum et d'Agile. C'est parceque j'ai connu des situations de mauvaises pratiques, et qui n'arrivaient plus dès lors que j'ai commencé à travailler sur des projets Scrum. Oui, j'ai connu du grand n'importe quoi avant de découvrir Scrum. Et voici quelques anecdotes :)

- J'avais 22 ans et j'étais plein de motivation et d'espoir pour le futur. Lors d'un projet de refonte, le chef de projet présente une solution pour la nouvelle interface et de façon naïve j'osais m'exprimer ainsi : "ah non, je suis pas d'accord sur cette solution". Réponse du chef de projet : un grand rire bruyant suivi de "non mais on te demande pas ton avis, on te demande de faire". J'étais renvoyé dans les cordes et je me suis vu me faire remettre en place : celle d'un ouvrier à qui on ne demande pas de penser. Vous vous rendez bien compte que se faire couper ainsi dans son élan coupe également toute motivation. J'étais passé dans ma tête d'une obligation de résultat à une obligation de moyen. Une équipe est une équipe car les gens sont différents et ont des idées différentes. Certains vont voir des solutions à des problèmes lorsque d'autres seront bloqués et vice-versa. C'est cette collaboration et cet apport d'idées de toutes parts qui fait la richesse de l'équipe. Il est inutile de croire qu'une personne peut avoir toutes les réponses. Et dans le cas de mon anecdote, c'est ce que le chef de projet pensait : sa solution était la bonne, quoiqu'en pensent les membres de l'équipe. La conséquence avec ce genre de management est que si moi ou un membre de l'équipe s'aperçoit d'une mauvaise pratique, un trou de sécurité ou tout autre problème, nous sommes encouragés à ne rien dire et ça tombe bien, c'est ce qu'on nous demande : implémenter une solution, même si elle est mauvaise. J'ai écrit de la m**** ? Ce n'est pas grave car c'est ce qu'on m'a demandé de faire et j'ai donc "réussi" ma mission :/ Ok, j'avais 22 ans à l'époque et ça ne se serait pas passé comme ça si ça arrivait aujourd'hui, je le reconnais ;)

- C'est une anecdote arrivée à des membres de mon équipe et à moi-même aussi. Les équipes ont souvent un outil d'intégration continue tel que Jenkins. Si celui-ci détecte que des tests unitaires ne passent pas à cause de régressions par exemple, il lance une alerte. Il s'avère que sur certains projets, c'est un outil qui sert de joujou à pointer la "nullité" des uns et des autres. "Machin, tu as cassé le build !" (traduction : "t'es vraiment une tâche !") comme si c'était le projet en entier que cette personne venait de planter... Comme le disait judicieusement un ancien collègue : "Ce n'est pas grave de casser le build ! L'important est de le réparer !" Et c'est bien cela qui importe : pourquoi avoir un outil de surveillance si l'on considère qu'il ne doit jamais passer à un autre état que "OK" ? Ce qui importe lorsque l'état du build est KO est de s'en rendre compte vite et d'intervenir au plus vite, et non de perdre son temps à dire à la personne en cause comme ce qu'il a fait est mal, etc...
- Ahlala, c'était toujours un moment particulier quand mon chef de projet me tendait une feuille avec un boulot à faire pour dans 3 jours. Une question qu'avait soulevée un collègue de cette mission me paraissait pourtant pertinente : "Mais qui a estimé cela à trois jours ?". Le chef de projet nous donna une réponse avec une telle confiance dans la voix qu'elle en semblait presque logique et légitime : "et bien il y a des concepteurs très expérimentés là qui ont pour rôle d'écrire les specs et de les estimer". Whoa! Heureusement qu'il y avait ces types pour nous dire combien de temps on allait mettre pour développer tel ou tel module. C'est pas grave s'ils ne connaissaient rien à Java et ne nous connaissaient pas non plus vu qu'ils ne nous ont jamais parlé en un an et demi. Vraiment, on se demande pourquoi on demanderait leur avis aux développeurs...

Bon je m'arrête là sinon on va croire que je n'ai rencontré que des galères dans ma vie... :P