Encore une fois les Pyxissiens se sont rassemblés pour coder, coder et coder!

Les équipes ont 6 heures pour réaliser leur projet en s’amusant. Première étape créer un backlog.

Deuxième étape on se met au travail. Objectif: créer un premier incrément de logiciel fonctionnel.

Au cours des 6 prochaines heures nous aurons droit à 3 demos. À la fin du Codapalooza nous aurons eu beaucoup de plaisir et aurons en main 2 applications.

Voici donc nos projets!

L’dep

Les membres
Luc, Louis, Guillaume, Brian, Dominic, Martin

Team motto
Ça fait moins mal faire du code que faire la Split !

Le projet
Développer un système de gestion des achats au dépanneur de Pyxis. Ce systeme permettra de gèrer l’inventaire ds stocks. Heureusement l’équipe n’a pas écoulé l’inventaire de bière:-)

StatisScrum
Les membres
Mathieu, Eric, Alain, Yvon

Team motto
Nous sommes normaux statistiquement parlant

Le projet
Développer une application qui permet d’obtenir des statistiques de vélocité et de faire des simulations. La fonctionnalité préférée de l’équipe est l’outil d’analyse d’impacts de la taille des récits utilisateur (User Story’s) sur la vélocité de l’équipe.

Cette édition à été aussi enréchissante que la dernière. Soyez prêt pour la 3e édition, vous pourriez vous aussi en faire partie

La notion fondamentale est qu’un objet devrait faire aussi peu d’hypothèses que possible à propos de la structure de quoi que ce soit d’autre, y compris ses propres sous-composants.

Vous allez me dire : « C’est bien beau la théorie, mais en pratique ça s’exprime comment? »

Voici donc un exemple :

J’ai un objet « Auto » et je veux savoir si l’auto est en marche.

Code qui ne respecte pas la loi :

auto.getMotor().getState().isRunning();

Code qui respecte la loi :

auto.isRunning();

Dans l’exemple ci-dessus, le respect de la loi rend d’abord le code vraiment plus simple à lire. De plus, le code est plus facile à maintenir. En effet, si je change le design et si l’état “Running” n’est plus au niveau du moteur mais plutôt au niveau des roues, vous devez changer auto.getMotor().getState().isRunning() par auto.getTire().getState().isRunning(), alors que si vous aviez respecté cette loi, vous auriez eu juste à changer la méthode isRunning().

Un autre avantage apparaît lors du débogage. En effet, si au runtime un des objets est à null, vous aurez un null pointer exception avec le numéro de ligne. Mais qu’est-ce qui est null? L’objet ‘Auto’, ‘Motor’ ou ‘State’?

Ces exemples démontrent que de ne pas respecter la loi de Demeter n’est pas vraiment grave au premier abord. Cependant, en la respectant, non seulement votre code sera plus clair, mais vous gagnerez également beaucoup de temps sur la maintenance ou le débogage.

Et, comme vous le savez, le temps c’est de l’argent!

D’une façon générale, la très haute qualité des présentations a aidé à la bonne dynamique de la journée. Un grand bravo aux conférenciers & organisateurs!

Voici ci-dessous quelques notes de cette journée (Même si l’agilité n’était pas le sujet du jour, je me suis permis de faire des parallèles dans mes notes, lorsque ça me semblait pertinent)

BA et UX : « User Centric », confrontés au changement et complémentaires

(Sources : Kevin Brennan, The future of business analysis — Chrystel Black, Expérience utilisateur + analyse d’affaires : compatibilité ou complémentarité ?  )

Que nous soyons analyste d’affaire ou expert UX (et je rajouterai : ou expert agile), nous faisons le même constat : le manque d’efficience des projets TI et les coûts astronomiques de re-work liés à une faible analyse de besoins.

Nous avons aussi des objectifs partagés : comprendre les besoins des clients et des utilisateurs, proposer des solutions, et surtout, nous adapter aux changements et au contexte. Il est intéressant de noter que la dernière version du rôle du BA a été ajustée en ce sens :

Business Analysis (v3) : The practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders

Pour renforcer la complémentarité de nos métiers, Chrystel Black (Yu Centrik) a utilisé la métaphore des hémisphères du cerveau (créativité versus analyse), se basant sur une intéressante étude réalisée sur les métiers de BA et de UX.

Par rapport à cela, je me questionne sur comment unir les forces de nos métiers? Comment l’agile peut-il supporter ces expertises pour encourager la collaboration et l’efficience ? Comment travailler ensemble ? Comment, au lieu d’opposer les points de vue, les accueillir et les composer pour être encore meilleurs ?… Même sans réponse immédiate, je ne peux m’empêcher de trouver cela stimulant et plein de belles perspectives pour l’avenir.

Poka-yoke ou super-héros ?

(Source : Gilles Lalonde, Mettez du Lean dans vos solutions d’affaires)

Sur un autre thème, la conférence de Mr Gilles Lalonde, autant leanifiante que hilarante, m’a particulièrement interpelée. Son approche Lean/Kaizen appliquée largement dans l’entreprise (processus hospitaliers dans l’exemple) m’a permis de réaliser à quel point nous ne mettons généralement pas les efforts et l’énergie au bon endroit.

Un Poka-yoke est un détrompeur, i.e. quelque chose qui nous empêchera de reproduire une erreur.  Lorsqu’on se trouve dans une situation critique, cherche-t-on à jouer au super-héros pour sauver le monde, ou à trouver la cause du problème pour y appliquer un poka-yoke ? La complexité ici est de faire une bonne analyse du problème, en respectant les 7 étapes :

1. Identifier le problème ou le besoin
2. Comprendre la situation / le statut actuel
3. Énoncer l’objectif – établir le statut cible
4. Procéder à l’analyse des causes racines
5. Brainstormer / déterminer des contre-mesures, et établir un plan de mise en œuvre
6. Vérifier les résultats – confirmer les effets
7. Mettre à jour les standards de travail

Un outil Lean permettant de nous guider dans ces étapes est le « A3 Problem Solving ». Ne pas oublier que la créativité est de mise pour aller à la recherche de solutions innovantes…

Appliqué à l’agile, c’est ce que nous cherchons à atteindre lors des rétrospectives. J’y vois là un outil de plus pour enrichir nos façons de faire ces ateliers.

Gemba ou l’importance de bien clarifier son mandat

(Source : Gilles Lalonde, Mettez du Lean dans vos solutions d’affaires)

Encore une opportunité d’apprendre un mot intelligent pour briller dans les soirées mondaines

Gemba signifie « place réelle ». Associé au Kaizen, cela signifie là où l’action a lieu, le fait d’être présent sur le terrain. Le point du conférencier est de montrer que souvent, nos mandats ne sont pas bien définis. La haute direction a souvent une vision différente de la réalité sur le terrain, et nous mandate pour corriger un problème qu’elle pense avoir cerné. En début de mandat, M.Lalonde nous recommande de prendre le temps de clarifier nos mandats, en allant interroger les personnes concernées sur le terrain, en écoutant et en observant. Cela permet d’identifier les actions faciles, et de construire une solution basée sur les « maillons faibles », donc robuste.

L’importance de l’adhésion avant de procéder au changement dans l’organisation

(Source : Serge Cloutier, La transformation organisationnelle, d’abord un état d’esprit!)

M.Cloutier nous explique l’importance de bien « vendre » un changement :

1. En faisant un lien clair entre le changement et la vision de l’entreprise. Des exemples de changements réussis montrent qu’ils étaient basés sur la confiance dans la haute direction, et dans la cohérence du changement avec la vision de l’entreprise.
2. En identifiant les avantages individuels que chaque personne concernée pourra retirer du changement.

Il nous donne aussi quelques bonnes pratiques pour mettre en place un changement :

• Faire contribuer les personnes concernées
• Respecter les phases d’intégration d’un changement (Sensibilisation  >>  compréhension  >>   adhésion  >>  appropriation  >>  intégration)
• Ne pas implanter un changement avant d’avoir l’adhésion
• Avant d’implanter un changement, mesurer le degré d’adhésion et la capacité à changer (des questionnaires existent pour cela)
• Avoir toujours en mémoire les postulats suivants :
• Toute personne est pourvue d’intelligence et de créativité
• Chacun est responsable d’intégrer les changements qui le concerne
• Le changement se déploie à l’intérieur d’un processus
• Il existe des leaders informels dans l’organisation (qu’il convient d’identifier…)
• Toute personne désire apprendre

Cela paraît simple et évident… mais comme le mentionnait Kevin Brennan en début de journée, « People are hard and it’s not going to get easier »…

Et les autres sujets…

D’autres sujets, tout aussi intéressants, ont été abordés au cours de la journée. De la présentation d’outils visuels aux retours d’expérience, en passant par l’ « agile discipliné », cette journée était riche en information. Comme les présentations devraient être disponibles prochainement en ligne, cela donnera un panel plus complet (le lien sera ajouté lorsque disponible).

En conclusion – La ronde des spécialistes

Avec tous ces sujets et réflexions passionnants, de ma vision de Scrummaster, j’ai énormément apprécié ces échanges teintés par la spécialisation de chacun. Il n’en reste pas moins que je m’interroge sur la façon dont nous pouvons briser les silos et unir nos compétences pour le succès des projets.

Cette myriade de spécialistes m’a rappelé un article de Scott Ambler, sur les spécialistes généralistes. Tous autant qu’on est, et tel que je le perçois, il est important de s’intéresser aux autres corps de métier, pour pouvoir identifier les enjeux, comprendre et respecter les spécialisations de chacun, et collaborer efficacement. De beaux défis en perspectives, pour le mieux des projets !

La Communauté Agile de Montréal et Pyxis accueillent Jurgen Appelo pour sa toute première visite au Canada. Il sera avec nous le 30 mai pour parler de la gestion du changement (Change Management 3.0). Ce souper-conférence vous permettra de mieux gérer les défis et obstacles que peuvent amener les changements dans votre organisation.

C’est un grand plaisir pour nous de l’accueillir pour un tel événement qui permettra de rassembler les leaders Agiles, gestionnaires, Scrum Masters, propriétaires de produit (Product Owners) et développeurs.

Nous sommes heureux de travailler en partenariat avec la Communauté Agile de Montréal pour préparer une soirée unique.

Visitez notre site pour plus de détails sur l’événement et pour vous inscrire.

Pourtant, nous avons la conviction que ça vaut la peine. Nous croyons que les décisions prises en équipe sont plus éclairées, car il y a partage et prise en considération de plus de renseignements. Ensemble, le groupe trouve plus d’idées et de solutions possibles pour résoudre un problème. Prendre une décision en équipe, ça permet aussi d’avoir une compréhension commune du contexte et aussi des raisons qui motivent cette décision. Et tout cela aide surtout pour la suite. L’application de la décision sera facilitée parce que les gens auront participé activement aux choix qui ont été faits. Sans implication, il est très difficile d’aller chercher un réel engagement.

Dans un contexte Agile, c’est d’autant plus important qu’on cherche à obtenir des équipes qui s’autoorganisent réellement.

Or, comment rendre efficace cette prise de décision en groupe? Selon nous, il y a 3 choses à garder en tête :

1. Bien clarifier les attentes. Qui prend les décisions dans une sphère d’activité?
2. Utiliser le bon outil au bon moment. Le vote par oui ou non est le plus connu, mais est-il le plus efficace? Est-il celui qui amène aux meilleures décisions?
3. Faire un suivi. Comment avoir un retour optimal sur tout ce temps investi en prise de décision?

Isabelle Therrien (Agile Partnership) et moi avons rassemblé dans notre présentation beaucoup d’outils et de modèles qui vous aideront à obtenir une équipe qui est efficace dans sa prise de décision.

WebClaim est une solution informatique qui permet l’intégration complète des systèmes des assureurs. Cette solution optimise la gestion des réclamations d’assurances relatives aux bris de vitres d’automobiles. De plus, elle assure l’intégration complète des règles d’affaires des assureurs automobiles du Canada, simplifie le traitement des réclamations et accélère le traitement des dossiers des consommateurs. En fait, le système a permis d’éliminer complètement les erreurs de données dans les dossiers de réclamation.

L’équipe de Pyxis a travaillé en collaboration avec l’équipe de Belron pour développer l’application Web sur la plateforme .NET à l’aide de pratiques Agiles.
L’une des réussites marquantes du projet a été de collaborer efficacement en mode distribué entre les sites de Belron et de Pyxis. Cela a permis à l’équipe de développement de rester à l’écoute des besoins d’affaires et de s’adapter rapidement à leur évolution.

« Je suis très fier du travail de l’équipe. En plus d’avoir réalisé le projet à partir de notre centre de développement, celui-ci a été réalisé au-dessous du budget prévu. Une belle preuve que l’Agilité et une équipe solide produisent des résultats remarquables », affirme Martin Landreville, directeur des services de développement Agiles de Pyxis.

L’équipe a bien hâte au 2 juin pour connaître le gagnant dans cette catégorie. Nous souhaitons à Belron et à Webclaim la meilleure des chances.

Isabelle, membre de l’équipe, décide de fusionner les changements et de compiler les composants de son équipe régulièrement sur son poste. Elle passe plusieurs heures à faire de l’intégration et à régler les problèmes elle-même, en plus d’implémenter les fonctionnalités qu’elle et son équipe se sont engagées à réaliser. Pour pallier les retards, le Scrum Master a mis la main à la pâte et implémenté des fonctionnalités, et certains membres de l’équipe ont dû faire des heures supplémentaires.

En tant que coach Agile, voici le type d’accompagnement que je m’attends à faire auprès de l’équipe d’Isabelle :

• « Salut l’équipe, êtes-vous heureux de votre réussite? »
•  « Oui, me dit le Scrum Master. Je vois les signes de tête affirmatifs autour de moi. »
• « Maintenant que vous savez comment faire pour réussir une itération, que pensez-vous d’augmenter la vélocité? » Je remarque les yeux en détresse d’Isabelle. De plus, son visage affiche de la fatigue. L’équipe ne semble pas enthousiaste à cette nouvelle demande.
• « Ne comptez pas sur moi pour recommencer, c’est trop exigeant. À la prochaine itération, nous devrions prendre moins de fonctionnalités et baisser la vélocité. C’est le prix à payer pour un produit de qualité », répond Isabelle.
• « OK, leur dis-je? Comment avez-vous fait? Isabelle m’explique les moyens qu’elle a pris pour que cela marche. Le Scrum Master me parle des heures et du surplus qu’ils ont faits. »
• « Je crois que c’est une bonne idée de diminuer la vélocité », dit le Scrum Master. « De plus, nous pourrons effectuer cette tâche à tour de rôle. »
• « Hum! OK. Nous semblons tous d’accord que cette nouvelle façon de faire est profitable. Pensez-vous un jour développer sans cela? »
• « Non, non, jamais de la vie », me disent à tour de rôle les membres de l’équipe.
• « Bien, alors réfléchissons (et c’est le début de la magie de l’efficience). Nous ne sommes pas les seuls à avoir ce genre de problème. Alors, que font les autres équipes de développement qui ont le même contexte que nous? »
• « Bien, mon frère développe des systèmes dans le même domaine d’affaires que nous », dit Marc. « Ils ont un outil pour faire de l’intégration continue. La compilation se fait automatiquement par un script. Il compile et exécute les tests unitaires; cela fait même des revues de la qualité du code. Mon frère m’a dit que c’était facile à installer. »
• « Ouais, mais tu sais bien qu’ici, ils n’ont pas d’argent », lui répond le Scrum Master.
• « C’est un outil gratuit », rétorque Marc.
• « Ouais, mais il ne règle pas les erreurs, ni les bogues. Je l’ai essayé pendant plusieurs heures », répond Isabelle.
• « Oui, mais est-ce normal que ce soit à toi de tout régler? », lui demandais-je.
• « Non, mais qui d’autre va le faire? »
• Je regarde autour de moi et j’attends.
• « Ce sont nos erreurs, dit Marc. Nous devons avoir une nouvelle règle d’équipe. Nous devons nous assurer que le système d’intégration continue est fonctionnel à 100 %, et ce, en tout temps. »
• « Bien, leur dis-je, nous reparlerons de la vélocité à la fin de la prochaine itération. »

Désirez-vous que vos équipes travaillent plus fort ou plus intelligemment? Sélectionnez une équipe. Observez les coéquipiers et prenez des moyens pour les rendre plus efficients.

Il suffit de demander à mon ami Marc Laroche qui m’a donné en cadeau un distributeur de papier de toilette… qui est aussi une radio.

Quand j’ai vu qu’il y avait beaucoup de réactions cyniques à l’égard des lunettes à réalité augmentée de Google (Project Glass), j’étais un peu déçu.

Vous avez le droit de penser que les lunettes ne conviennent pas à vos besoins ou ne sont pas utiles, mais il s’agit tout de même d’une innovation. Chaque fois que Google ou Apple innove, les membres du clan adverse font preuve de cynisme immédiatement. Et, à chaque fois ça, me fait penser à l’histoire de Galilée qui disait que la terre était ronde. Beaucoup de critiques pour une découverte majeure.

Pour moi, l’innovation, ça change le monde à différents niveaux. Mon distributeur de papier de toilette-radio n’a pas vraiment changé le monde, mais maintenant je peux écouter la radio quand je prends un bain. L’inventeur de ce gadget n’avait certainement pas pensé à cette utilisation.

Cependant, si vous regardez l’iPhone ou la voiture intelligente de Google, vous pouvez clairement voir ce que ça apporte aux gens. Arrêtons de dénigrer l’innovation et essayons de trouver l’impact qu’elle pourrait avoir dans le futur.

Par exemple, les lunettes Google pourraient afficher les renseignements vitaux d’un patient à l’hôpital. Le médecin ne serait donc pas constamment obligé de lever la tête pour regarder l’appareil qui montre actuellement les signes vitaux.

S’il vous plaît, donnez une chance à l’innovation. Essayez de réfléchir à la portée de celle-ci; elle pourrait changer votre monde!

Face à cette situation, je me suis demandé comment amener ce gestionnaire à devenir un coéquipier qui participe aux succès de ses équipes et de son organisation. Quels sont les outils qui me permettraient de les aider à cheminer?

Le cours Management 3.0 m’a apporté plusieurs réponses, et ce, autant au niveau du savoir-faire et du savoir-être du dirigeant d’aujourd’hui et de demain qu’au niveau de ses nouveaux défis. Durant le cours, j’ai évolué sur 4 dimensions :

• le développement humain;
• la culture Agile dans l’organisation;
• la complexité du monde d’aujourd’hui;
• les équipes comme élément structurant.

Je suis donc ressorti avec de réels outils de gestion que j’ai eu la chance d’appliquer dès le lendemain. Ces outils permettent d’observer et d’améliorer le rôle du gestionnaire tout comme celui de l’équipe. Ils aident à ce qui suit :

1) Mobiliser les personnes puisqu’ils permettent de connaître les motivations des gens et d’en discuter et aussi de les stimuler au changement.

2) Habiliter les équipes puisqu’ils permettent de connaître la perception du mode de délégation et d’en discuter et aussi d’observer les problèmes ou les opportunités.

3) Aligner les contraintes puisqu’ils permettent d’établir et de transmettre les objectifs et ainsi assurer la cohérence des travaux de l’équipe.

4) Développer la compétence puisqu’ils permettent d’observer le niveau de compétence de l’organisation et d’en discuter et aussi d’établir une stratégie.

5) Élever la structure puisqu’ils permettent de visualiser la structure organisationnelle et d’en discuter et aussi de voir les opportunités et de prendre des décisions éclairées lors des changements.

6) Établir la stratégie du changement puisqu’ils permettent d’établir les agents du changement et ainsi d’énumérer les risques et les opportunités de la stratégie.

Dernièrement, avez-vous pris le temps de vous observer en tant que gestionnaire? De vous questionner sur votre rôle? Management 3.0 m’a permis (et vous permettrait) ce moment de questionnement et de réponses.

Voici quelques extraits des textes que nous avons reçus :

Karl Métivier
… En bref, le facteur humain étant ce qu’il est, il ne doit pas être géré comme une ressource, mais plutôt de manière organique. J’aime bien la métaphore que François Beauregard a utilisée pour illustrer ceci : « La gestion d’une équipe, c’est comme faire grandir un beau jardin. »
Billet complet

Michael Ouellet
… De plus, il (François Beauregard) nous fait comprendre que dans notre groupe chaque individu est différent dans sa manière d’appréhender la réalité de ce qui lui est présenté dans la conférence. Certains seront statiques et d’autres seront systémiques.

Éric Vermette
… Bien comprendre la culture et les valeurs de l’organisation (les documenter, les diffuser et les utiliser dans nos actions et décisions) permettrait d’orienter tout le monde dans la même direction.

Lisez le billet de Jean-François Desjardins sur Management 3.0 et l’esprit d’équipe : http://jfdidgeridoo.wordpress.com/2012/03/25/management-3-0-et-lesprit-dequipe/.

La participation gratuite est donnée à Michael Ouellet.

Merci à tous les participants pour leur contribution très intéressante!