Catégorie : Agile/Lean

Outils de productivité partie 3: Agile Results

imagePour faire suite à la série de billets sur les outils de productivité, nous allons parler aujourd’hui d’une technique intéressante qui nous permet d’être « Agile » avec nous-mêmes, et ce sur différents niveaux.

Cela fait quelques années que je lis régulièrement les articles de J.D. Meier. Ce dernier travaille chez Microsoft, mais on ne parlera pas ici de son côté technique, mais plutôt de ses trucs pour obtenir des résultats.

De son blogue, Source of Insight, il a publié plusieurs articles très intéressants sur la productivité, comment atteindre nos buts et améliorer la balance entre travail et vie à la maison. Il a récemment formalisé toute sa méthode dans un livre intitulé « Agile Results ». Ce dernier est gratuit en ligne et on peut se procurer aussi une version papier.

 

Les grandes lignes de sa méthode sont les suivantes:

  • La règle de trois: Toujours y aller avec trois objectifs à la fois dans vos planifications.
  • Adopter le concept de « Monday Vision, Daily Outcomes, Friday Reflection« , qui est en gros:
    • Vision du lundi: On identifie nos 3 résultats souhaités pour la semaine
    • Résultats Journalier: On révise nos 3 objectifs de la semaine et on regarde comment les faire avancer aujourd’hui en priorisant nos tâches.
    • La Rétrospective du vendredi: On regarde notre semaine en se posant les deux questions suivantes:
      • Quelles sont les trois choses qui vont bien ?
      • Quelles sont les trois choses à améliorer ?
  • Trouver ses « hotspots » afin de savoir comment on distribue notre temps et se fixer des limites. Le tout afin de bien balancer notre vie. C’est un peu philosophique, mais assez important pour se questionner sur quoi investir en priorité et les conséquences à ne pas investir à d’autres endroits.

Le livre mentionne aussi un paquet de stratégies et de points clefs obtenir des résultats. Très intéressants à lire. La version du web du livre est très pratique et on s’y retrouve bien. Il y a un résumé de la méthodologie et  des « Cheat Sheets », posters et autre.

iStock_000001342452LargeDe mon côté, je pratique régulièrement la règle de trois et le « Monday Vision, Daily Outcomes, Friday Reflection ». C’est vraiment la base de mon rythme pour réaliser un paquet de trucs, comme écrire ce billet. Pour ce qui est des hotspots, je m’y suis attardé une fois je crois pour bien les connaître et c’est tout. Bref, cette méthode marche bien pour moi. D’ailleurs la section « Mes points clefs » que l’on retrouve régulièrement à la fin de mes billets, est tirée de cette technique.

Si les « Agile Results » vous branchent, n’hésitez pas à lire aussi le blogue « Source of Insight » qui publie régulièrement de bons articles et résumés. J’en ai d’ailleurs aussi inscrit, dans les références au bas de ce billet, des liens sur des articles intéressants de J.D. Meier et de E-Books gratuits qu’il a déjà écrits.

 

Mes points clefs :

  • Planifier nos tâches et ce que l’on veut accomplir, et ce de manière journalière, hebdomadaire, mensuelle et annuelle
  • Apprendre à mieux se connaître et important pour se fixer des objectifs
  • Nos résultats guident nos actions

 

 

Références :

Publicité

Les « skills » de l’Agilité

L’agilité, ce n’est pas seulement Scrum et le XP Programming. Plusieurs autres méthodes, concepts, notions et habilités gravitent aussi autour de l’agilité. Les travaux de l’Agile Skills Project répondent justement à cela. Ils ont répertorié toutes ces habilités et les ont classés selon les 7 piliers suivants:

  • Business Value
  • Collaboration
  • Confidence
  • Product
  • Self Improvement
  • Supportive Culture
  • Technical Excellence

Je vous recommande fortement d’y aller jeter un coup d’œil au site. On y retrouve le détail de leurs travaux et le classement des habilités « Agiles ». Ce qui est intéressant avec tout cela, c’est qu’on peut voir dans quel secteur (ou pilier) nous avons des acquis et à quel endroit il serait intéressant d’évoluer. Ceci vaut aussi bien de manière individuelle, d’équipe ou au niveau d’une entreprise.

J’ai aussi fait une petite présentation sur Slideshare pour illustrer les 7 piliers de l’agilité:

Vous m’en direz des nouvelles !

Références:

Atelier Gestion Visuelle

clip_image002

Aujourd’hui, lors de l’Agile Tour Québec 2010, j’ai eu l’occasion d’animer un atelier sur la gestion visuelle. Le tout s’est bien déroulé malgré le temps plus restreint (1 heure) pour mener l’activité.

La participation de tous fut excellente et une bonne créativité en est ressorti dans le tableau des tâches de tous et chacun. Bravo !

J’avais aussi mentionné que je publierais sur mon blogue les ressources en questions mentionnées lors de la séance ainsi que les photos prises des tableaux.

Les voici :

Aussi, si vous voulez discuter ou poser des questions au sujet de la gestion visuelle, juste à mentionner le hashtag #GestionVisuelleQc sur Twitter. J’y participerai avec joie aux discussions qui pourront y avoir lieu.

Merci encore à tous les participants de l’atelier et à ceux de l’Agile Tour Québec 2010 en général !

Critique du livre Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great SoftwareUn autre livre sur l’agilité ?

Bon, il parle de quoi ce livre, une autre méthodologie ?

Une autre manière différente d’appliquer l’agilité ?

Non, rien de tout cela.

Ce magnifique petit livre (250 pages environ) ne fait que nous réexpliquer les différentes facettes de l’agilité mais d’une manière un peu spéciale.

Tout est présentement de manière simple, abondamment illustré et drôle par moment.

Voici la description des différentes sections du livre :

  • Dans la première partie du livre, on commence avec la base, soit l’Introduction à l’agilité et la description d’une équipe agile et les rôles que l’on y retrouvre normalement.
  • Dans la deuxième partie, Agile Project Inception, j’ai particulièrement apprécié la section sur le début d’un nouveau projet et les choses à faire afin que l’équipe s’approprie davantage le projet. On y explique diverses activités telles que le Inception Deck, un Elevator Pitch et la conception d’un Product Box. Je vais sûrement tenter d’essayer ces techniques un jour au l’autre.
  • La troisième partie, Planification d’un projet Agile, on discute de User Stories, Estimation et comment être flexible avec le Scope d’un projet.
  • La quatrième partie, Exécution d’un projet Agile, le concept d’itération prend tout son sens et on aborde plusieurs notions pour aider à livrer régulièrement notre produit logiciel. On voit comment les notions des 3 premiers chapitres fonctionnent ensemble. Exemples:
    • Comme quoi faire à l’itération 0
    • Quand faire l’analyse fonctionnelle
    • Communiquer l’information à l’équipe
    • Faire un espace de travail visuel
  • Pour finir, la dernière partie, Création d’un logiciel Agile, on fait la revue des pratiques d’ingénierie Agile connues et éprouvées tels que les tests unitaires, le refactoring, le TDD et l’Intégration continue. Même si je connaissais très bien ces notions, c’était intéressant de les trouver résumé dans le livre en y mentionnant de bons arguments pour les pratiquer.

Donc, on revoit la plupart des notions de l’agilité, ses principes et ses pratiques. Mais remis au goût du jour avec plusieurs illustrations et de nouvelles manières d’expliquer l’agilité. Le livre est raconté de la manière étudiant-professeur (ou plutôt Maître Sensei et Aspirant Guerrier pour rester avec la thématique Samurai) afin de nous glisser de prodigieux conseils tout au long du livre. On sent que l’auteur, Jonathan Rasmusson, a fait plusieurs projets agiles et veux nous communiquer son savoir et ses trucs. Bref, on trouve ici un guide visuel sur l’agilité, rien de moins. Même si vous être expérimenté avec l’agilité, vous avez de quoi à apprendre que ce soit les conseils du maître Sensei ou certaines techniques moins couvertes ailleurs.

Certaines notions ne sont abordés qu’en surface, tels que les Users Stories et le Refactoring,  et pour bien les maîtriser, il faudra peut-être faire d’autre lectures.

Petit point à améliorer selon moi dans le chapitre 2 sur l’équipe Agile. Le rôle « Programmeur Agile » couvre un peu trop large. On aurait dû le diviser avec un autre rôle plus senior genre « Tech Lead » ou « Agile Architect ». C’est certain qu’à la base on veut effacer un peu les rôles traditionnels et rendre l’équipe multifonctionnelle. Sauf que cela prend quelqu’un qui se charge en autre du respect des normes, de coacher l’équipe, de faire le lien avec les autres systèmes de l’entreprise et d’avoir une vue globale de l’architecture.

Merci en passant Pragmatic Press de m’avoir donné une copie ebook du livre en version beta et finale afin que j’en fasse la revue.

Darts

Mes points clefs:

  • Avant de commencer un projet Agile, il a des activités à ne pas oublier
  • Toujours avoir en tête les principes du manifeste agile et comment les appliquer concrètement
  • Scrum et XP Programming y sont mélangés pour ne faire qu’un dans le livre.

Les références:

Scrum vs Scrum

Dans le coin droit, la ScrumAlliance et dans le coin gauche, la Scrum.org.

L’enjeu premier: La certification

Je trouve un peu déplorable ce qui se passe avec ces deux organisations dévouées à promouvoir l’approche Scrum. L’an passé, Ken Schwaber, fondateur de Scrum, quitte l’organisation qu’il a créée, la Scrum Alliance, pour des différents avec les autres organisateurs.

La raison de cette séparation ? Ken Schwaber mentionnait il n’y a pas très longtemps dans un webcast que la Scrum Alliance ne s’est pas bien comporté, tel un mauvais garnement, et s’est un peu égaré en devenant une entreprise voulant faire des profits.

Il fonde alors la Scrum.org et y propose aussi des cours certifiés pour de bonnes sommes d’argent. Bon, jusque là, on peu trouver cela un peu bonnet blanc et blanc bonnet malgré ce qu’en pense Ken Schwaber.

Pour les professionnels œuvrant dans le domaine de l’agilité, c’est un peu embêtant. Ceux qui détiennent déjà une certification avec la Scrum Alliance, comme moi, se demande s’il faut aussi aller chercher les nouvelles certifications de Scrum.org.

La compagnie Pyxis, dont les formations agiles sont une de leurs activités principales, n’ont pas trop le choix et offre les deux types de certifications.

D’une manière générale, on peut aussi se poser la question à savoir si les certifications en valent vraiment la peine ? Bob Martin a écrit un bon article là-dessus ici en questionnant la valeur d’une certification et son influence lors de l’embauche. À lire ici:

Pour moi, je trouve que la certification est un atout, sans plus. Cela prouve que l’on a soit :

  • Assisté à un cours (pour la certification ScrumMaster entre autre)
  • Passé un examen ou un questionnaire d’admissibilité

Il peut y avoir des tas de bonnes personnes avec des certifications et d’autres qui, bien que certifiés, sont moins compétentes.

Mais ce qui est le plus intéressant, n’est pas vraiment tout cette histoire de certification. Regardons de plus près un autre aspect qui est commun chez ces deux organisations:

  • Scrum Alliance: elle prépare une série de cours pour certifier des développeurs Scrum en y incluant les aspects d’ingénierie agile aux notions de Scrum.
  • Scrum.Org: Les premiers cours de Scrum Professionnal Developer sont déjà offert. Avec une alliance avec Microsoft, un cours de 5 jours a été développé pour faire la simulation d’un développement Agile de A à Z avec la nouvelle version de Visual Studio Team System 2010. Seront aussi inclus les notions du XP Programming dans le cours. On mentionne aussi qu’il y aura une version Java pour plus tard.

Ces deux formations semble des plus intéressantes de part leur contenu et la manière de les enseigner. 

Est-ce que vous remarquez quelque chose ? Moi je vois ici que les deux font la même chose et sont en train d’annexer le XP Programming à Scrum. On fait souvent mention effectivement que Scrum ne mentionne aucune technique d’ingénierie agile et qu’il est de bonne pratiques d’inclure des aspects du XP Programming au Scrum. Bob Martin y est même allé de la citation suivante:

XP + SCRUM = XP. SCRUM is a perfect subset of XP that wants to become XP.

Tandis que Ken Schwaber mentionne, dans le même webcast mentionné plus tôt, que XP est en train de disparaître malheureusement et que Scrum est un des seul processus les mieux définis.

Bref, au lieu de promouvoir l’agilité sous une seule bannière, on est divisé par cette petite guerre. Pourtant, le fait d’inclure les pratiques du XP Programming est en soi une évolution normale et souhaité selon moi. Mais de là à vouloir faire disparaître le XP Programming…

Qu’en pensez-vous ?

 

Références pour ce billet:

Critique de livre : The Five Dysfunctions of a Team

FiveDysfunctionsCover Ce livre n’est ni technique et ne parle pas d’agilité. Pourquoi donc j’en ai fait la lecture ? Et bien tout a commencé cet été lors de mon passage à la conférence Agile 2009 qui a eu lieu à Chicago, lorsque j’ai assisté à la présentation suivante :

Scaling Up by Scaling Down: A (re)Focus on Individual Skills

Dans cette présentation sur le comment faire progresser une équipe pour la rendre hyper-performante, on mentionnait le livre en référence. Intrigué, je me suis procuré le livre en question sur les 5 dysfonctions d’une équipe. En passant, la présentation a été filmée et vous pouvez donc l’entendre au complet sur le site d’infoQ:

http://www.infoq.com/presentations/scaling-up-by-scaling-down

Je vous la recommande fortement si vous voulez en savoir davantage sur le leadership d’équipe et le lien avec l’agilité. Le conférencier, Ashley Johnson,  parle avec un anglais qui est en général très facile à comprendre.

Pour revenir au livre, c’est un bon livre et j’ai l’est vraiment aimé. Il est d’ailleurs utile pour tout ceux qui sont intéressé par le travail d’équipe, peu importe leur rôle. C’est une lecture assez facile, cela m’a pris environ 1-2 semaine pour le terminer. De plus, son contenu est présenté ainsi, de manière peu conventionnelle:

  • Les 184 premières pages du livre racontent une "fable" sur le leadership.
  • C’est dans les 40 dernières pages que le modèle des 5 dysfonctions nous est décrit.

J’ai trouvé très instructif ce format. On nous fait découvrir graduellement la théorie des 5 dysfonctions d’une équipe à travers une histoire fictive, mais très réaliste. On devient rapidement accroché à l’histoire et on a hâte de voir la suite et comment l’équipe va réussir à corriger ces 5 dysfonctions. Ce format nous permet de comprendre la théorie à travers une histoire au lieu d’y aller directement avec la théorie sans trop de concret. Ah si les écoles fonctionneraient de cette manière…

Pour les 5 dysfonctions d’une équipe je les résume ainsi avec une traduction libre :

  • Manque de confiance envers les autres (Absence of trust)
  • Peur des conflits (Fear of conflicts)
  • Manque d’engagement (Lack of commitment)
  • Éviter la responsabilisation (Avoidance of accountability)
  • Inattention aux résultats (Inattention to results)

On doit commencer idéalement par résoudre la première dysfonction, ici le manque de confiance, et résoudre les autres en ordre par la suite pour finir avec le dernier, soit l’inattention aux résultats.

Vous trouverez le détail de ces dysfonctions dans les documents suivants disponibles:

Autre bon résumé si vous avez moins de 5 min, écouter l’auteur du livre, Patrick Lencioni, nous décrire brièvement les 5 dysfonctions:

 

Pour poursuivre mon habitude des points clefs, voici ce que je retiens de cette lecture :Darts 

  • Si on se retient de dire des choses de peur de confronter les autres, cela nuit grandement à rendre une équipe fonctionnel
  • Viser le consensus de toute l’équipe n’est pas toujours la bonne chose à faire. L’important c’est que tous les membres de l’équipe aient eu l’occasion de s’exprimer. Après, la décision passe beaucoup mieux au sein de l’équipe.
  • Je vois bien intégrer ce genre de modèle aux pratiques de rétrospective et d’amélioration continue d’une équipe Agile. À essayer donc lors d’un prochain projet.

Agile Tour 2009: Ressources post-événement

at2009_quebecPour faire suite à la conférence Agile Tour Quebec 2009, j’ai réuni dans ce blogue, des liens diverses qui parle de cet événement. S’il m’en manque, juste à m’en aviser et je vais mettre à jour cette page en les ajoutant.

Articles:

Présentations:

Blogues des présentateurs:

Agile 2009: Dernier jour et conclusion

Bon, après quelques jours de retard, mais voici mes dernières impressions de la conférence:

  • Keynote et Banquet du jeudi soir:  Le banquet était un peu ordinaire et on semblait nous presser entre les services. Je n’avais pas encore terminé le plat principal qu’on posait le dessert sur ma table. Mais bon, le keynote de Jared Spool c’est avéré très bon et nous a fait rigoler par moment.
  • Open Jam – vendredi matin: C’était très mollo le matin et rien, à part des petites discussions ici et là, ne semblait être au programme. Sauf, Yves Hanoulle qui proposait un atelier avec des blocs sur le Leadership. J’y ai donc assisté et ce fut très plaisant. On a fait l’expérience de trois types de leaderships suivant:

– strong directive leadership

– without leader

– process leader

Je vous laisse deviner le type qui a mieux fonctionné et aussi avec lequel une meilleure chimie s’est produite dans l’équipe…

Voici une photo de l’une de nos réalisations (c’est le Big ben à Londres):

img_1719

Le retour a été un peu plus pénible du côté des transports. Une randonnée quasiment interminable en taxi pour se rendre du centre-ville à l’aéroport. Par la suite, notre avion part avec une heure en retard. Mais ce ne sont que de simples inconvénients comparé à la super conférence que j’ai assistée. Très formateur et motivante à tous les points de vue. Il va falloir sûrement que j’y retourne un jour…

Agile 2009: Jour 4

Bon, aujourd’hui la journée a commence de manière un peu déroutante quand je me suis rendu compte à 10 minutes du début de ma session qu’elle avait été annulée…

J’ai donc regardé l’horaire des sessions pour en trouver une intéressante et qui allait avec l’horaire de ma deuxième session et le temps allait rapidement tout d’un coup. J’ai donc choisie celle-ci :

  • Scaling Up by Scaling Down: A (re)Focus on Individual Skills: Quand on dit que parfois c’est bon de sortir de sa zone de confort, et bien c’est ce que j’ai vécu un peu avec cet atelier sur le leadership et l’individu. On a ici parlé de comment utiliser nos habilités pour augmenter son niveau de leadership au sein d’une équipe, d’une organisation. Tout ça avec le contexte  de l’Agilité et dans le but d’avoir des équipes efficaces et productives. Cette session m’a fait beaucoup réfléchir.
  • Visual Management for Agile Teams: Atelier sur la gestion visuelle. Chaque équipe avait à construire son propre Taskboard avec des « story » et des « tasks ». Après chaque étape, chaque équipe allait juger le tableau d’une autre équipe. Pleins de conseils et de trucs appris dans cet atelier.
  • Growing an Agile Culture from value seeds: Les présentateurs nous montrent comment, en partant des valeurs du XP Programming, ils les ont personnalisées et intégrées à leur compagnie. Il y a eu aussi des vidéos et des photos de leurs lieux de travail. Inspirant !
  • The impact of Agile Architect Teams in Scaling Enterprise Efforts:  Durant cette session, le rôle de l’architecte dans un contexte agile a été abordé. Mais, le plus intéressant, c’est de voir comment tout cela s’applique dans un contexte d’un gros projet avec plusieurs équipes de Scrum, appelé aussi des « Scrum of Scrum ». Dans ce contexte, on aussi regardé qu’est-ce qu’un architecte agile a pour tâches et comment une équipe d’architectes s’organise dans tout cela.
  • Set-based design: The anti-Agile or Agile : Encore là, une présentation de qualité. On nous a présenté c’est quoi le « set-based design » et ses liens avec l’agilité, le Lean et le système de production Toyota. Cette technique est un peu paradoxale et avant-gardiste mais très intéressante à connaître.

Ceci marque la fin des sessions normales. Il y aura ce soir un keynote avec le banquet et demain AM cela sera des sessions « Open Jam ». En passant, voici de quoi à l’air le “Open Jam”:

IMG_1709

Agile 2009: Jour 3

J’ai vraiment bien choisi mes séances de mercredi car elles étaient tous excellentes. Voici le résumé des conférences

  • The Bottleneck Game : Excellent atelier animé par Pascal et Portia, les responsables du site AgileCoach. Durant l’atelier, j’avais le rôle de “Customer Acceptance” et c’était amusant et instructif.
  • Emergent Design & Evolutionary Architecture : J’ai vraiment aimé cette séance. Neal Ford nous a présenté une bonne définition du “Emergent Design” et son l’implication sur l’architecture. Bref, une bonne série de conseils pratiques.
  • Learning: the best approaches for your brain : On expliquait ici en introduction comment la neuroscience et la compréhension de comment notre cerveau fonctionne pouvait nous aider à apprendre. Par la suite, le groupe devait choisir 3 des 5 sujets par “dot-voting” qui seront abordés durant la séance. Encore là, très bonne présentation fait par Mark Levinson, un gars d’Ottawa, et Linda Rising.
  • From Concept to Product Backlog – What Happens Before Iteration 0? : Le présentateur faisait le tour, dans sa présentation, de tout ce qu’il faut regarder avant l’itération 0, afin de ne pas avoir trop de problèmes par la suite. Très bonne conférence. Fait intéressant, la présentation a été enregistrer par InfoQ et sera sûrement disponible bientôt sur leur site.

Hier soir (mercredi), nous avons faire un petit regroupement de francophones présent à la conférence et  sommes allé bouffer et prendre un verre ensemble. C’était amusant et sympatique. J’ai en profiter pour prendre une photo de nuit de Chicago:

IMG_1693