Lors du deuxième podcast de Vox Agile : ‘Élargir les horizons’, nous avions enlevé toutes les bébelles pour empêcher les sons nuisibles, mais ce n’était pas suffisant.

Comme les micros étaient sur une table en bois, le son se propageait plus facilement. Le simple fait de frotter la table avec la main créait un bruit de fond. Nous avons donc utilisé une serviette pour couper le son.

Donc, le truc podcast, c’est:

Une serviette ou un tissu épais sur la table empêche la propagation du son.

Lors du premier podcast de VoxAgile, j’ai réalisé quelque chose : le tripotage de bébelles, ça fait du bruit.

En effet, nous avions laissé un verre et des crayons sur la table où nous faisions l’enregistrement.

Le premier réflexe des personnes autour de la table a été de prendre les crayons ou le verre.
Ils ont joué avec ces bébelles, ce qui faisait des bruits de tapotage et de frottement.

Donc, le premier ‘truc podcast’ c’est :

Enlever les bébelles pour empêcher le tripotage et, par le fait même, les bruits parasites.

Voila déjà une semaine que j’ai assisté à l’Agile Tour de Montréal. J’ai décidé de partager mes commentaires en espérant avoir des réactions pour continuer les discussions qui ont été abordées durant l’événement.

Conférence de Mary Poppendieck

La journée a commencé avec la conférence de Mary Poppendieck. Cette conférence avait comme sujet : “Correctness can be proven at any time”

De cette conférence, je retiens 2 choses qui n’ont pas nécessairement un lien direct avec le sujet principal.

1. Le premier concept est le suivant : Ethnography.

En gros, ça consiste à étudier comment le produit que l’on développe est réellement utilisé. Mary a mentionné qu’une entreprise avait divisé les différents développeurs d’un produit en 6 équipes.

Ces équipes devaient suivre un client à l’achat du produit, le suivre jusqu’à la maison et évaluer comment l’utilisateur utilisait le produit. Par la suite, les gens se sont réunis et ont découvert que certaines fonctions n’étaient même pas utilisées.

2. La deuxième chose que je retiens, ce n’est pas vraiment nouveau mais la phrase qu’elle a utilisée ma beaucoup marqué. La voici :

The biggest defect is tolering defect.

En gros, il ne faut pas dire : C’est un bogue hyper-simple; ce n’est pas grave si on ne le corrige pas tout de suite. Chaque bogue devrait être de priorité 1.

Conférence de Scott Ambler

La deuxième conférence à laquelle j’ai assisté était celle de Scott Ambler. Cette conférence m’a laissé un peu perplexe. J’ai bien aimé le concept entre Myth Buster et Family Feud, mais le message véhiculé était plutôt négatif. Après chaque Myth confirmé ou détruit, il n’amenait pas de piste de solutions ou d’idées pour l’améliorer. Vers la fin, j’ai un peu décroché car il ne nous ‘garochait’ que des statistiques.

Conférence de François Beauregard

La troisième conférence était celle de François Beauregard. Comme toujours, François a su captiver l’auditoire avec son humour. J’ai bien aimé le message qu’il voulait véhiculer, soit que l’Agilité n’est pas une solution miracle. Ça prend une volonté de changer, et surtout un changement de philosophie. En gros, il faut miser sur l’humain.

Conférence de Gino Marckx

La quatrième conférence était celle de Gino Marckx. J’ai bien aimé car il s’agissait d’une séance interactive. De plus, merci à Éric Laramée, j’ai pu trouver une solution à un de mes problèmes. En gros, cette conférence avait pour but d’aider les gens à trouver les raisons derrières un problème et trouver des solutions.

Une phrase qui m’a marquée est la suivante :

Everybody is right from their own perspective.

Voici un exemple un peu extrême de ce que j’ai compris de la phrase :

Un développeur qui dit : Je ne comprend pas que le PO ne veuille pas que l’on fasse du refactoring , ça va prendre juste un sprint et après ça va aller tellement mieux.

Le développeur ne sait peut-être pas que le PO a eu une directive du stakeholder comme quoi s’il n’a pas développé la fonction demandée, le projet va être interrompu.

C’est un peu extrême mais j’essaie de démontrer que selon l’information en main, nous n’avons pas la même perspective.

Conférence de Jérôme Barrand

Je n’ai pas assisté à la cinquième conférence car la journée commençait à me rentrer dans le corps.

Cependant, je suis resté jusqu’à la conférence de Jérome Barrand, que j’ai bien aimée car l’humour de Jérôme m’a donné un regain d’énergie. Pour être franc, je ne me souviens plus trop du message si ce n’est que l’Agilité peut aider les entreprises.

La seule chose dont je me souvienne se sont ses histoires de Renaud 5 et de ce qui est plus complexe qu’un homme.

Pour finir, j’aimerais juste dire que j’ai bien aimé ma journée et que nous pouvons être fiers de ceux qui ont participé à l’évènement.

J’espère aussi que nous avons pu amasser beaucoup d’argent pour FIAN avec la vente de chandails et de l’application _agilely Timersur App Store.

Mon 5 cennes

Comme l’un des objectifs du Campus de Pyxis est d’améliorer les bonnes pratiques de développement logiciel tout en s’amusant. J’ai voulu faire une retrospective qui fait abstration du coté technique afin de valider, si le monde s’amuse sur le campus.

J’ai donc fais quelques recherches dedans le Internet et je suis tombé sur le blog The Agile Leap qui m’a inspiré l’activité que j’appel Retrospective en image.

Voici en gros l’activité

Préparation:

1. Découper dans les revues différentes photos (essayer d’avoir autant d’image negative que positive)

À la Rétrospective:

1. Étendre les différentes photos sur la table.
2. Donner la directive suivante a l’équipe:

Vous avez 5 minutes pour choisir une photo qui represente selon vous le dernier sprint. Lorsque la photo a ete choisi, vous devez la coller sur le flip chart.

1. Lorsque tout le monde a choisi une photo, ne passer aucun commentaire et demander a chaque personne d’expliquer leur choix.
2. Lorsque tout le monde a répondu, faire un résumé de ce qui a été dis.
3. Par la suite, dépendants des réponses, il suffit de voir les pistes de solutions pour règler les points negatifs

Retour d’expérience sur l’activité

Comme je veux respecter la confidentialité des retros, je vais simplement donner des constatations générique de l’activité.

En gros, ce fut très concluant puisque chaque membre de l’équipe a pu parler du dernier sprint sans aller dans le technique. Deplus, nous avons pu eclaircir ce qui a bien fonctionné et ce que nous devrions améliorer.

J’ai aussi remarqué qu’une image peut avoir différente représentation selon différente personne. En effet, j’avais choisi une photo qui selon moi était négative, mais un des membres a pris cette même photo et lorsqu’il la expliquer celle-ci avait une representation positive.

Ce que j’ai aimé apres la rétro c’est que le flip chart contenant toutes les images donnait une bonne vue d’ensemble du sprint.

Conclusion

Pour conclure, je vous invite a essayer cette rétrospective et me donner des commentaires. Aussi comme Trémeur Balbous me l’a dit, je vais réessayer cette activité de facons plus systematique (a chaque 4 sprint), Afin de mieux évaluer l’impact de cette activité.

Contexte :
Des anciens collègues à moi ont eu une discussion sur comment faire pour expliquer aux gens d’être plus goal-oriented VS task-oriented.

Voici un résumé de la discussion
Math asks: Why is so difficult for people to be goal-oriented rather than task-oriented ?
Kath replies: Simply tell them: “guys, your only task is to fulfill the goal”

Mais sérieusement, je voulais savoir s’il y a du monde qui ont d’autres moyens un peu plus politiquement correct d’expliquer à l’équipe pourquoi c’est mieux d’être goal-oriented.

Pyxis a parlé de donner des cours sur son site, voici un exemple qui pourrait être interessant :

http://aboutscrum.com/videos/learn-scrum-in-10-minutes/

Suite à la formation Salto donnée par Aspectus, Pyxis Technologies a décidé de changer le rôle du Caddy. En effet, le Caddy n’a plus comme mission principale d’agir à titre de ressource humaine, mais d’agir aussi comme coach personnel.

Voici donc un resumé du nouveau processus caddy.

Pourquoi?

Parce que l’individu est la richesse la plus importante de l’organisation, que son développement est intimement lié à celui de Pyxis et que les Caddys sont le meilleur moyen d’aider un individu à se développer.

Quoi?

Le Caddying est une relation d’accompagnement et de coaching sans autorité qui est basée sur la confiance et le respect. Dans un premier temps les Caddys permettent à l’individu de se retrouver dans l’organisation et dans un deuxième temps d’y développer leur plein potentiel au grand bénéfice de l’individu, des Caddys et par le fait même de Pyxis.

Qui?

Le Caddy est une personne humble et capable d’une grande écoute. Il a le courage de confronter l’individu si cela s’avère nécessaire et la sagesse de le faire dans le respect de la personne. Avant tout, il partage avec l’individu un objectif commun : le développement de ce dernier.

L’équipe Caddy est consciente de l’impact positif énorme qu’elle peut avoir sur l’organisation. Guidés par la même passion du développement de l’individu, les Caddys savent faire preuve entre eux de la même humilité, de la même écoute, du même respect et du même courage

Moyen

Le Caddying est un des rôles les plus importants au sein de Pyxis et ce dernier est reconnu comme tel, encouragé et valorisé par l’organisation. Chaque collaborateur à Pyxis Technologies doit avoir un Caddy. Une fois par semaine le golfeur et le Caddy se rencontre. Cette rencontre permet au Golfeur de parler de ses soucis et de demander des conseils à son Caddy, s’il y a lieu.

Résultat

Le Caddying a un impact positif significatif sur le développement du golfeur ainsi que sur le développement des aptitudes du Caddy. Grâce au Caddy l’individu apprend à mieux connaître ses motivations personnelles, comprend mieux l’organisation, sa mission et comment il peut y contribuer.

Un ancien collègue qui est en train de développer un site web personnel, m’a demandé quel outil j’utilisais pour le développement d’un site web. Je lui ai donc parlé du plugin Firebug qui est selon moi l’outil le plus connu.

Par la suite, j’ai fait une recherche pour savoir s’il n’existait pas d’autres outils.

Je suis tombé sur ce blog: http://www.eviltester.com/index.php/2009/04/29/how-on-earth-did-we-test-the-web-without-these-tools/

Je voulais donc avoir votre opinion sur les autres outils…