Post #500

Il me semble qu’il n’y a pourtant pas si longtemps que j’ai marqué d’une pierre blanche la première année de mon blog. Oui, c’était il y a à peine plus d’un an. Mon rythme est donc disons… honorable ! Revoyons tout cela en chiffres !

Mon blog en chiffres !

Il y a un an, je me réjouissais de mes 221 posts. Un an et deux semaines plus tard, ce sont donc 279 nouvelles entrées qui s’y sont ajoutées.
Au niveau rythme, après un petit creux de début d’année, je tourne à une moyenne d’un peu plus de 20 posts par mois. Considérez quand même qu’un post sur trois est une citation et cela rend la chose moins démente.

Histogramme posts tumblr

Plus intéressant à mon goût : l’évolution des Notes de lectures si je les compare aux autres billets (en excluant les citations). Sur les 12 derniers mois, la tendance s’est inversée par rapport à l’année précédente. Les billets dépassent en nombre les notes de lecture, parfois de beaucoup.

Stats billets vs Note de lecture

La fréquentation

Elle semble en augmentation !

Statistique de fréquentation 2012-2013

En fait, il faut la rapprocher de celle de l’année précédente. Toutefois comme je n’ai mis en place les analytics qu’en Mars 2012, il me faut “normaliser” les données sur les deux années. J’ai donc multiplié les données de la première année par 1,5 ; ce n’est pas tout à fait juste, mais disons que c’est une approximation acceptable.

Stats 1ère année vs 2nd année

Les chiffres font apparaitre une augmentation substantielle des visites, ou plutôt des visiteurs uniques (le chiffre que je préfère suivre). 

Les rebonds paraissent important (en baisse insignifiante), mais c’est plus probablement lié au fait que la plupart des visites viennent des liens Twitter. Malgré tout, deux chiffres me surprennent : la diminution très sensible des pages vues par visite : de 2,72 à 1,7 ! Cela se traduit de manière naturelle par une diminution du temps passé à chaque visite : de 2,72 mn à 1,77 mn. Normalisé à une page, cela fait 57 sec par page sur la première année et 1,13 min par page sur cette dernière année.
Qu’en est-il des browsers ? C’est assez stable, avec un poil de perte de terrain de Firefox et un poil de regain côté Safari, mais pas de gros changements à part ça…

Stats browsers 2nd année

See you next time

Déjà 500 posts. Peut-être devrais-je réduire le rythme ? Hélas, j’ai encore quelques sujets sur la pile. La prochaine synthèse est prévue pour mon millième post. Espérons que ce soit dans un bout de temps !

Moving on…

Il n’est pas dans mes habitudes de parler de moi dans ce blog. Je vais le faire aujourd’hui, ce qui fait de ce post un texte un peu particulier.

Parler de soi n’est pas s’apitoyer. Pas nécessairement, en tout cas pas ici. Si je compte bien, c’est la première fois que je me livre à l’exercice. Un post vraiment spécial pour moi, donc.

Je suis venu te dire que je m’en vais

J’ai passé 5 ans au bureau du Scrum User Group, un peu plus, même. J’y étais depuis sa création par Luc Legardeur, jusqu’à aujourd’hui sans interruption. Cela faisait de moi l’ancien du groupe.

Et cela se termine aujourd’hui.

Etre l’ancien ne me confère aucun statut particulier, et c’est tant mieux. Par contre il n’a jamais été concevable pour moi de figurer au bureau de l’association et de rester inactif. Je vois cela comme une forme d’escroquerie : “voyez, je suis au bureau du SUG, d’ailleurs je l’ai mis dans mon profil LinkedIn (ce que je n’ai jamais fait, d’ailleurs)”. Si c’est pour ne pas contribuer aux actions de l’association…

No empty Space

Quitter un engagement de si long terme me donne une petite impression de vide, d’inconfort. Même si je suis convaincu d’avoir pris la bonne décision, lâcher cette situation réconfortante ne s’est pas fait aisément. Je sais, vous allez me dire que ce n’est pas comme si j’avais quitté mon boulot. C’est vrai, mais quand même…

Là où cela me laisse perplexe, c’est que ce changement qui semble normal avec un regard d’agiliste, a exigé de me faire violence. La stabilité, j’aime bien. Mon petit confort, j’aime bien aussi. Aller vers l’inconnu, confronter une situation nouvelle : pas trop. Oh, une fois que c’est passé, que j’ai réussi de nouvelles chose, accompli une action dont je suis fier ou pris un râteau sans trop de dommages, ça va. Je suis même fier en fonction des cas (ou raisonnablement pas trop honteux).

Bref, suis-je vraiment un agiliste au fond de moi ? Est-ce le “moi conscient” qui a pris la barre, sachant que la démarche agile est la bonne, mais heurte le “moi inconscient” qui lui est bien frileux ? Je vais arrêter ici ma psychologie à 2 balles, je vous ai probablement perdu. En fait je me suis perdu moi-même.

Pourquoi ?

C’est le moment que vous attendez : celui où je vais cracher mon venin ! Cela ne va pas arriver. Non seulement cela ne serait pas correct, mais il n’y a pas lieu de le faire. Nous avons fait de nombreuses choses en 5 ans, et je suis fier d’y avoir participé. Il suffit de regarder le Meetup pour s’en rendre compte ! Que vais-je mettre spécialement au crédit de cette période ?

  • Les personnes que j’ai pu côtoyer au bureau. Plus spécialement, certaines dont j’étais plus proche. Mais je ne vais pas citer de noms.
  • Les rencontres. A l’occasion des soirées, des Scrum Day ou des Scrum Beers. Notre communauté est riche de personnes avides de connaissances et de réflexions.

Je garde un excellent souvenir non seulement des rencontres lors des évènements, mais aussi des échanges avec les orateurs lors des préparations. On m’a régulièrement remercié pour avoir géré les appels à orateurs. La vérité, c’est que ce fut chaque fois un plaisir !

Alors, pourquoi quitter ?

Pour des raisons purement égoïstes ! Oui, faire partie d’un groupe et s’entraider sont des valeurs importantes. Mais cela ne doit pas se faire au détriment de nos motivations personnelles. Surtout quand il s’agit de bénévolat. Pour moi, il s’agit de prendre du plaisir à faire ce que je fais, d’avoir envie d’abattre le travail qui est devant moi. C’est aussi comme cela que j’arrive à donner le meilleur de moi-même.

Pour diverses raisons, ce n’est plus le cas. Les choses ne vont pas mal, ni pour moi ni pour l’association. Mais cela ne corresponds pas à mes aspirations actuelles.

La page est donc tournée.

Moving on…

Mon départ du SUG ne va rien changer à l’association. Ce n’est pas un regret, mais une source de satisfaction. Bien faire son boulot, c’est apporter une contribution utile sans se rendre incontournable. Montrez-moi une personne dont l’absence met un groupe en péril, je vous présenterais une personne qui ne fait pas son boulot jusqu’au bout. Dans certains cas, c’est même de la malhonnêteté.

Pour peu qu’il y ait quelqu’un pour reprendre le harnais, tout continuera comme avant. Je l’escompte bien, car j’ai bien l’intention de me rendre aux évènements que l’association organisera !

Très bien, mais quelles sont mes prochaines étapes ?

Pour l’instant, je reste sur mes projets actuels :

  • Deux conférences à préparer, à Bruxelles très bientôt et fin Novembre à Grenoble. Deux sujets différents que j’inaugurerai. Ca fait du boulot.
  • L’adaptation Française de The People Scrum.

Tout cela sans compter ce Blog va bien m’occuper au moins jusqu’en Décembre. Et après ? Je ne sais pas. Je sais simplement qu’il est temps d’aller de l’avant.

Snoopy moving on

En finir avec la démo ?

Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?

La démo, puisqu’il le faut…

La démo ? C’est bien !

Crowd waving

La démo, c’est vraiment bien !

La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.

Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !

Mais ce n’est pas le cas.

En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.

Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :

  • Ceux qui sont heureux d’aller à la démo.
  • Ceux qui appréhendent la démo.

En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.

La démo c’est cool, on va pouvoir montrer ce que l’on a fait !

Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.

Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !

J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :

L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?

Ce qui est considéré comme terminé doit correspondre à la “définition of done”.

Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !

Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.

Bonjour, je voudrais voir mon burndown chart

Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.

Illustrons cela par un bon vieux burndown chart.

Burndown Chart de la démo

Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.

Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.

En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !

Grâce à la démo, retrouves le charme oublié du “cycle en V” !

En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.

En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.

La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !

Cette pente glissante se traduit par deux symptômes étroitement liés:

  • Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
  • Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.

Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.

Continuous integration

Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.

Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !

Direction le tribunal

Parfois, la revue de Sprint, cela ressemble à ça :

Cours de justice

Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.

Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.

On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :

  • Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
  • Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
  • Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?

De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.

Revue de sprint ou réunion de spécification

“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.

Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.

Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.

Micro-démo

Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.

N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.

Voici la recette dans les grandes lignes:

  • La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
  • Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
  • On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
  • S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
  • Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.

Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.

Mais alors, a-t-on encore besoin de la démo ?

La substantifique moelle de la revue de sprint

La revue de sprint, ce n’est pas seulement la démo. C’est aussi :

  • Exposer la vélocité de l’équipe [Aubry12], p. 125
  • Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
  • Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.

Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?

En fait, oui !

Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.

Une question de boucle de feedback

En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.

Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.

Alors, la démo, c’est mal ?

La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :

  • De montrer l’avancement du produit à un public large.
  • De collecter du feedback global sur l’itération et l’état du produit.
  • De mettre les pièces du puzzle ensemble

Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !

Références

[Aubry12] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3

[Lacey12] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4

En finir avec le Scrum Master ?

Le quatrième volet de notre série va nous conduire du côté du Scrum Master. Dans l’épisode précédent (l’été dernier, donc) nous avons remis en cause le Product Owner, il semble justice d’en faire de même avec le Scrum Master, n’est-ce pas ?

Avant d’aller plus loin, rappelons l’avertissement désormais habituel : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

Scrum Master, ta mission si tu l’acceptes …

Mission impossible

Comme nous l’avons fait avec le Product Owner, il est bon de camper le paysage en synthétisant les missions du S.M. ; Nous avons de la chance, le terrain est mieux balisé aujourd’hui.

Le Scrum Master est souvent décrit comme le “chien de berger”, qui doit :

  • Veiller au bon suivi des cérémonies Scrum et âtre un agent du changement(1) (3)
  • Encourager l’équipe, l’aider à progresser et devenir autonome (1) , un rôle qui se prolonge envers les autres parties prenantes du projet (2)
  • Eliminer les obstacles (4)

Je note aussi que les écrits initiaux de Scrum donne un trait nettement plus fort au Scrum Master, le décrivant notamment comme un rôle de management, que ne le font les textes plus récents où il est plutôt décrit comme un facilitateur et un “servant leader”.

Pourquoi en faut-il un ?

image

Scrum édicte en règle la présence du Scrum Master : l’équipe doit pouvoir se concentrer à 100% sur le projet sans perdre de temps sur des considérations annexes, car le SM y veille. A la base, cette présence du Scrum Master repose donc sur  deux postulats:

  • L’équipe n’a pas la maturité pour prendre en charge sa discipline agile sans qu’un garant soit là pour y veiller.
  • L’environnement nécessite que quelqu’un joue le rôle de pare-feu, car les parties prenantes en contact avec celle-ci créent trop de perturbations.

Maintenant, imaginons un environnement favorable (donc ne nécessitant pas de “firewalling”) et une maturité affirmée de l’équipe, que reste-t-il de cette nécessité ?

C’est probablement le point qui a motivé la question posée en ce sens cet été sur Quora.

La question sur Quora

Is it possible to run Scrum without Scrum Master ?  

Les réponses que j’appelerais “bibliques” sont quand même majoritaires. Toutefois je constate qu’elles reposent sur deux fondements :

  • Le fait que les conditions d’un projets entrainent nécessairement la présence des deux postulats que j’ai cité plus haut.
  • Une croyance forte dans le bienfait de la présence des rôles.

Une autre partie des réponses affirme que cela est possible, généralement sur la base du niveau de maturité de l’équipe. Ma réponse préférée est celle de Xu Yi : “when you need to ask the question, no, you can’t. when you don’t need to ask the question, yes, you can.”.

Retour à la case départ : il est nécessaire du fait du manque de maturité de l’équipe et pour protéger des perturbations. Non seulement la réponse n’est pas satisfaisante, mais il y a plus : le SM peut s’avérer dommageable à l’équipe !

Protection ou isolation ?

Dans un excellent post qui a d’ailleurs devancé ma chronique, Tobias Meyer parle d’éliminer le Scrum Master ! Il avance plusieurs arguments à cela :

  • Le rôle tel qu’il est décrit ne peut être décemment endossé par quelqu’un se dénommant “master”.
  • L’idée même qu’une personne dédiée à être guide de l’équipe, à résoudre les problème pour elle est un non-sens, lorsque l’on considère le niveau de qualification des membres de cette équipe.
  • “protéger” l’équipe va à l’encontre de l’idée de responsabiliser celle-ci.
Bad Scrum Master

Ce troisième point plus particulièrement m’interpèle : l’un des principes de base de Scrum est de permettre à l’équipe de se concentrer à 100% sur son travail. Les rôles de PO et de SM sont là pour aider à atteindre cet objectif. Mais “protéger” peut rapidement devenir “isoler”. Le Scrum Master devient ainsi l’interlocuteur privilégié et parfois unique avec l’équipe. Certains développeurs y trouvent leur compte, qui préfèrent dialoguer avec leur machine qu’avec des utilisateurs. Au-delà de cette formulation ironique, n’oublions pas que nous avons tous tendance à nous replier sur notre zone de confort : programmer c’est être en terrain connu, donc dans la zone de confort, parler avec l’utilisateur à propos de son métier, c’est être dans l’inconnu, hors de la zone de confort.

Les valeurs agiles nous parlent de communication. L’équipe doit aller hors de sa zone de confort, elle doit aller au front pour comprendre et s’approprier la matière sur laquelle elle travaille. Scrum ne dit pas le contraire, mais la notion de “rôle” et de “protection” est tellement facilement assimilable au chef de projet à l’ancienne …

Une question de maturité d’équipe

Livrons-nous à un petit “remember the futur”. Tous les membres de l’équipe ont un niveau de maturité élevé en agilité, l’organisation a bien compris la nécessité de n’être pas intrusive. A quoi ressemble le fonctionnement de cette équipe ?

  • Le product owner vient aux stand-up. Il sait qui travaille sur quelle store. Il échange directement avec le développeur ou même le plus souvent, il lui envoie l’utilisateur le plus directement concerné.
  • Les améliorations du processus viennent de n’importe quel membre de l’équipe. Chacun évoque son idée au moment opportun (durant l’itération) et on n’attends pas l’itération suivante pour la mettre en oeuvre.
  • L’organisation n’interfère pas avec l’équille pour des questions politiques. Elle sait que la manière la plus productive d’obtenir un résultat est de laisser les personnes faire leur travail. Le comité de direction donne cependant du feedback lors des démos afin de réorienter le projet si nécessaire.

Dit comme ça, ça fait un peu bizounours. En fait, ça l’est bien un peu, hélas ! Nous n’avons pas terminé notre exercice, toutefois. Voyons comment on pourrait arriver ici en venant d’une situation standard.

Des rôles qui peuvent se répartir

Un coach m’a un jour affirmé qu’il voyait l’inutilité de sa présence comme l’accomplissement réussi de sa mission. C’est fort bien dit et aussi très juste.

La hiérarchie interfère avec l’équipe ? Certes, on peut faire rempart. Mais n’est-ce pas mieux de travailler avec la hiérarchie pour trouver un mode de fonctionnement équilibré et non intrusif ? Si le management intervient, c’est souvent qu’il a des craintes ou des insatisfactions.

Le mode de fonctionnement de l’équipe peut être amélioré, la productivité augmentée ? Oui bien sûr on peut montrer du doigt les voies d’amélioration … mais n’est-ce pas plus efficace d’enseigner à l’équipe à voir son propre gâchis, comme on dit en Lean ? Si un homme a faim, apprends lui à pêcher plutôt que de lui donner un poisson…

D’ailleurs, l’équipe étant auto-organisée, ne peut-elle dédier une personne sur chacun de ces fronts ? Pourquoi nécessairement tout ramener à une seule personne ? Que se passe-t-il quand elle n’est pas là ? Il est temps d’évoquer la sociocratie.

L’approche sociocratique

N’étant pas spécialiste du sujet, je ne vais pas m’y étendre. Ce mode de gouvernance est régit par 4 principes (5) :

  • Prise de décision par consentement: Les actions sont entérinées à moins d’objections.
  • Le cercle : c’est une entité autonome dans son travail et les décisions qui régissent son exécution.
  • Le double lien : en plus du lien hiérarchique traditionnel, chaque cercle choisit son représentant au niveau supérieur. Il participera aux décisions par consentement de ce niveau.
  • L’élection sans candidat: personne ne se porte volontaire pour un poste, les électeurs proposent des candidats qui sont libres d’accepter ou non le résultat du scrutin.

Pour une équipe ayant acquis une certaine maturité et une certaine conscience agile, l’évolution vers ce type de gouvernance semble une suite logique. Elle permet aussi au final de faire tourner le rôle de Scrum Master ou même s’y mettre fin.

Effets collatéraux

J’ai évoqué la “non nécessité du Scrum Master”. Mais allons plus loin : sa présence peut elle être nuisible, même si ce dernier est bien intentionné ?

Hélas la réponse est : oui ! Et sa présence paut avoir des effets de bord néfastes, jugez-en !

Effet colatéral

Enfin non, ce n’est quand même pas à ce point. Dans une équipe auto-organisée, l’agilité doit être l’affaire de tous. C’est déjà un peu antinomique de décider qu’une personne donnée sera porteuse de cette mission ! Passons.

Mais que peut-il se passer si une personne est en charge de la mise en oeuvre de Scrum ?

  • D’abord, les autres membres de l’équipe ne s’en préoccupent plus, jugeant que c’est l’affaire de “l’autre”.
  • Puis on arrive dans une situation de passivité où les choses ne se passent que si le SM s’en charge. Par exemple : avez-vous vu des équipes qui ne font pas le daily meeting un jour, car le Scrum Master est absent ? Oui, ça arrive !

Bien sûr, ce n’est pas toujours comme ça. Heureusement. Mais ça peut aussi être pire, si le Scrum Master n’est pas bien disposé.

Le chef de projet est de retour

Au secours ! Car oui, si Scrum décrit explicitement le rôle du SM comme n’étant pas un rôle de management, il n’est pas trop difficile de s’assoir dessus, surtout si tout le monde est bien disposé en ce sens. Retour au bon vieux commande-controle !

Chaplin, le dictateur

Alors quelle est la recette du désastre ? Elle n’est pas compliquée.

Prenez une bonne vieille équipe fonctionnant à l’ancienne. Ca ronronne bien. Les membres de l’équipe sont tranquillement en mode “ouvrier spécialisé”. Le chef de projet stresse un peu plus car tout repose sur ses épaules. Il distribue les tâches, car au moins c’est un mode de fonctionnement qu’il comprend.

Prenez une équipe managériale que l’on a fait mijoter dans un saladier-séminaire d’agilité. On l’a saupoudré d’épices exotiques lui faisant miroiter monts et merveilles : ils pourront changer d’avis tous les jours, la productivité sera multipliée par 100000 (je dois oublier un ou deux zéros), les utilisateurs auront des trucs mieux que ce qu’ils espèrent grâce à l’usage avisé de le télépathie. Les trucs standard, quoi.

Extrayez de l’équipe le chef de projet et faites-le revenir dans une poelle-formation Scrum Master. Les autres membres de l’équipes restent à la boite à bosser, car faut quand même pas exagérer.

Mixez l’ensemble, servez et voyez ce qui se passe.

Les membres de l’équipe ne comprennent pas trop ce qu’on attends d’eux et sont un poil déstabilisés (on vient de leur dire qu’ils sont enfin libre, mais bon ça reste un peu abstrait). Par défaut on va attendre les ordres, là on ne risque pas grand chose. Le chef de projet enthousiaste attends le démarrage de l’auto-responsabilité, l’allumette à la main. Pas grand chose n’arrive. Histoire d’amorcer la pompe, le chef de projet va distribuer les tâches (ou les user stories, ou ce que vous voulez) aux développeurs. Retour à la case départ. Enfin pas tout à fait, on a changé le vocabulaire.

Et si on ne trouve pas, on ne va pas ?

Le tableau que je dresse parait noir. Hélas il arrive. Et généralement on essaie alors de se voiler la face en se disant que non ce n’est pas comme avant. Pas tout à fait.

Mais que fait-on si on n’a pas de Scrum Master sous la main ? Ou que personne ne souhaites l’être.

  • On prends une victime au hasard ?
  • On roule sans ?

Clairement, sélectionner une victime n’est jamais la bonne approche. Surtout dans un rôle où la confiance est primordiale. Si l’équipe n’est pas non plus aguerrie à la pratique de l’agilité en générale ou de Scrum en particulier, il est aussi illusoire de penser que les choses se mettront en place tout seul. Il est préférable alors d’aller chercher un Scrum Master expérimenté en prestation. Mais oui.

Encore faut-il que ce Scrum Master ait bien compris son rôle et guide l’équipe dans le bon sens afin de ne pas faire tourner Scrum à la grosse farce !

Bon, alors le Scrum Master, c’est mal ?

“Scrum Masters, soyez les coaches de vos équipes agiles”. J’évite généralement dans cette colonne de faire la promotion de qui que ce soit. Mais ce slogan nous est asséné par Véronique Messager depuis maintenant un certain nombre d’années (6). Et elle a raison, c’est bien de cela dont on doit parler. Scrum n’évoque pas la chose, mais la véritable voie du Scrum Master est celle du coaching : être celui qui rends possible non pas Scrum, mais que l’équipe s’approprie Scrum !

Bref, le Scrum Master doit être un catalyseur, et pas le gars sur lequel on se décharge de l’agilité. Et dans ce cadre, son apport peut s’avérer décisif !

Références

(1) Scrum 2nd edition ;  Claude Aubry ; Dunod 2011 ; p. 44

(2) Scrum field guide : Mitch Lacey ; Addison Wesley 2012 ; p. 104

(3) Agile Software Development with Scrum ; Ken Schwaber & Mike Beedle ; Prentice Hall 2002 ; p. 31

(4) Essential Scrum ; Kenneth S. Rubin ; Addison Wesley 2012 ; p. 185

(5) Sociocratie : http://fr.wikipedia.org/wiki/Sociocratie ;

(6) Coacher une équipe agile ; Véroniue Messager ; Eyrolles 2012

Et pourtant c’est l’été…

Nous entrons en zone estivale, parait-il !

L’heure pour moi de faire le point et de passer en régime d’été. Attention “régime d’été” ne signifie pas “silence radio” !

Pour ma part…

Pour ma part, ces derniers mois ont été un peu chargés. Entre autre parce que j’ai changé de boulot. Je n’aurait pu quitter le précédent comme un voleur, et le suivant commençait à me mobiliser avant même d’avoir définitivement posé mes valises. Je vais maintenant consacrer mon temps à l’accompagnement agile, avec des choses connues et maitrisées à mettre en oeuvre et aussi d’autres moins connues… Bref, de quoi être enthousiaste, mais c’est aussi moins de confort.

Ah oui, j’allais oublier : une formation coaching que je vais suivre avec Véronique Messager très bientôt.

J’ai quand même bien mérité un petit break, et je vais le prendre !

Et aussi un peu de préparation

Je serais à l’Agile Tour Bruxelles sur la fin d’année, peut-être aussi sur une ou deux autres conférences. Ce sera au moins une nouvelle session à caractère participatif à préparer. Donc l’été sera aussi studieux.

Du côté du Scrum User Group, le programme de l’an prochain n’est pas encore établi, il faut dire que le Scrum Gathering occupe une partie d’entre nous (mais pas moi). Mais en toute logique, nous devrions commencer à nous en occuper dès maintenant.

Sur le blog

Je suis fermement décidé à ne pas laisser une semaine sans post, congés ou pas. Les divers évènements vont se tarir après la semaine prochaine, donc il y aura encore quelques retours ici même dans la dizaine de jours qui vient, puis il faudra attendre Septembre. J’en profiterais pour rattraper certains retards de ce côté remontant à plusieurs mois !

Au minimum, je livrerais ici une note de lecture par semaine, peut-être plus. Mais elles auront un petit goût archéologique, car je vais remonter des choses un peu anciennes. On reprendra les choses plus type en Septembre. Ne débranchez pas, ça peut quand même vous intéresser et le passé éclaire parfois le présent.

Pour ce qui est des citations, je vais bien sûr continuer à les dispenser.

Toujours sur le blog: en finir avec…

Je vous avez asséné l’an dernier ma série de l’été: en finir avec… avec ses 3 premiers opus (ici le premier, le second et le troisième). J’avais d’ailleurs conclus cette série par un lightning talk donné à Nantes.

Je suis fermement décidé à la reprendre. je ne vais pas m’engager sur un nombre de posts, mais j’aimerais en faire 3 entre maintenant et mi-septembre. Chacun d’entre-eux représente pas mal de boulot, cela dit, et c’est l’été, je le rappelle …

A très bientôt, donc.

Done or done-done ?

  • T’as finis ton US ?
  • Ouais, ça y est, c’est bon !
  • Donc, t’es done ?
  • Oui, elle est “done” !
  • On peut la mettre en prod ce soir ?
  • Ah ben non, y’a encore des trucs à faire …
  • Donc, elle est pas “done” ?
  • Ben si, le dev est terminé. Mais il reste des trucs à faire, mais c’est pas moi. Elle est pas “done-done"…

Le concept de "definition of done” de Scrum est souvent interprêté comme une licence à ne pas aller jusqu’au bout de l’action (la mise en production, même seulement “potentielle”) mais comme un niveau d’accomplissement:

  • Developpement terminé.
  • Acceptance tests terminés.
  • End user tests / beta testing terminé.
  • Qualification opérationelle terminée.

Ce n’est pas le cas. Ce n’est pas de cela dont Scrum Parle quand on parle de “definition of done”. Le “done” de Scrum signifie toujours que mon développement peut être déployé en production sans autre forme de procès, que je le fasse effectivement ou pas !

image

Cela signifie simplement qu’en fonction de l’organisation, le paquet-cadeau pourra contenir différentes choses :

  • Une documentation utilisateur.
  • Un audit de conformité au plan d’urbanisation.
  • Une formation utilisateur.
  • Un outillage de monitoring pour les équipes de production
  • etc…

Votre imagination peut être sans limite, mais il en ira alors de même du coût de votre “definition of done” !

image

Mais on voit les équipes abdiquer par rapport à ce critère et inventer des niveaux de “done” intermédiaires ! Pourquoi ?

le plus souvent parce que les organisations font peser sur elles des contraintes de fonctionnements qui ne leur permettent pas d’avoir le contrôle sur toute la chaine jusqu’à la mise en production.

  • Ce peuvent être des cellules de test séparées, avec des plannings indépendants du projet et générant ainsi du délais.
  • Très souvent, sont concernées les équipes de productions, avec leurs propres plannings de mise en production transverses à de nombreuses équipes.
  • De manière générale tout ce qui créé des silos dans l’entreprise est un frein à avoir un véritable “done” !

Impuissants face à ces choix d’organisation, les équipes Scrum préfèrent s’adapter et aligner leur définition de terminé à ce qu’ils peuvent réellement contrôler, donc le périmètre de leur équipe. Mais cela ne corresponds pas à un réel accomplissement. Ce “terminé” va juste prendre la poussière sur une étagère avant d’être testé / qualifié, etc… et ensuite seulement être réellement utilisé !

image

Cette définition de terminé est un leurre. Il nous donne (peut-être) bonne conscience. Mais surtout il dissimule les lacunes du système !

Ne faites pas cela ! Conservez, augmentez même la visibilité des lacunes du système ! N’abdiquez pas sur la définition de terminé : ce doit toujours être un produit qui peut être passé en production, là tout de suite, maintenant !

N’oubliez pas que d’autres vont plus loin encore dans l’appréhension du done : en Lean Startup, même si cela n’est pas explicitement exprimé ainsi, on est “done” quand on a eu le feedback des utilisateurs et qu’on en a tiré les leçons !

Le constat mis en évidence est souvent douloureux, peut paraitre insurmontable, mais c’est le véritable chemin qui vous reste à parcourir pour arriver à un réel processus agile.

2.0, I me mine (opus 2012)

J’avais fait le point début 2012 sur les outils 2.0 que j’avais utilisé en 2011. Une année s’est écoulée. Faisons le point sur ce qu’il en est aujourd’hui.

J’utilise beaucoup moins, voir plus du tout

Yammer : Certes c’est toujours l’outil du SUG, mais je n’y vais plus que quand j’y suis obligé. J’avais évoqué l’an dernier son manque de polyvalence, c’est sans doute ce qui a fini par me lasser.

Podio  : On en avait parlé, puis on a laissé tomber, du moins pour l’instant. Plus de Podio à l’horizon pour moi.

Google Doc : Je sais bien que ça ne fait pas très Geek de dire ça, mais je n’utilise pas Google Doc (ou plutôt Google Drive maintenant) pour mon usage personnel. Je n’aime pas travailler dans des documents dans une interface Web et vous viendrez me réveiller quand la suite Google sera au niveau de Microsoft office ! Cela dit, je l’utilise (à mon corps défendant) dans le cadre professionnel. Mais je trouve l’usage hors ligne peu convainquant et le système de rangement incompréhensible.

Google Plus : Je n’ai rien contre Google Plus, mais on ne peut pas être partout. Je n’y vais guère parce que je n’en ai pas pris l’habitude, probablement pour l’essentiel. Je m’en sers pour buzzer sur certains de mes posts.

Quora  : De temps en temps, j’ai un accès de courage et je balaie des sujets pour voir si j’ai une réponse à y apporter. Disons 3 ou 4 fois dans l’année. Mais jamais hélas je n’y ai trouvé les réponses à mes interrogations ! J’attribue le temps que j’y passe parfois à répondre à ma volonté de maintenir ma visibilité sur la toile… Bon, je dois quand même avouer que je suis très fier d’avoir Jeff Sutherland dans mes followers !

IFTTT  : Le service est génial, tellement génial qu’il parvient à se rendre invisible ! Hélas, le changement des conditions d’utilisation de Twitter en ont rendu l’usage que j’en ai pratiquement inopérant ! Shame on you, Twitter !

Je continue à utiliser

Trello  : Je trouve toujours le service aussi simple, efficace et agréable. Trello est plus adapté aux projets qu’au fil de l’eau. Je m’en sert pour mes projets perso, petits ou gros, mais très irrégulièrement. On est parti pour utiliser cela sur nos projets du SUG, ce que je trouve bien.

Meetup  : Il reste l’outil principal du SUG. J’y ai découvert deux nouvelles communautés cette année : Lean Startup France (http://www.meetup.com/lean-startup-france/) et Agile Playground (http://www.meetup.com/Agile-Play-Ground/). Je devrais aussi y adjoindre la petite communauté Evernote (http://www.meetup.com/Evernote/Paris-FR/) que j’ai commencé à fréquenter (merci à Pierre Journel de l’avoir créé).

GMail  : Toujours aussi important pour moi, rien à ajouter !

Diigo  : Cet outil de bookmarking reste d’une utilisation sporadique pour moi. Visiblement, cela va le rester. Pourtant la fonction d’annotation est plutôt sympa…

github  : Pas encore un gros utilisateur à titre privé. Par contre, je commence à utiliser gist, que j’ai commencé à intégrer à Tumblr !

Stackoverflow  : Toujours aussi pertinent quand il s’agit de trouver une réponse à un problème de développement. Quora n’est pas prêt de prendre le dessus !

Slideshare : Je ne l’avis signalé l’an dernier, c’est maintenant corrigé. Toutes mes présentations publiques y sont consignées. Il faut aussi dire que j’intègre cela de bonne manière dans Tumblr. 

Twitter : Je ne suis pas un enragé de Twitter, mais de toute évidence un utilisateur régulier sans aucun doute. Je ne poste pratiquement jamais durant ma journée de travail (il faut bosser aussi, n’est-ce pas ?) et en fait je ne suis pas non plus les tweets en journée ! C’est donc le soir dans les transports que je passe en revue une bonne partie des tweets de la journée et je met en favoris les liens qui ne peuvent se lire facilement sur l’iPhone. Comme tout le monde, je n’en lis pas la moitié en différé. Et ne plus avoir mon canal IFTTT n’arrange rien à l’affaire…

LinkedIn  : Je n’en fais ni plus ni moins que ce que j’en faisais avant. La fin de l’intégration Twitter ne change pas grand chose pour moi. Mais je regrette l’abandon de la fonction agenda. Je reste sur ma politique de n’accepter en relation que les personnes que j’ai rencontré au moins une fois.

J’utilise plus aujourd’hui qu’hier

Dropbox  : Concurrence oblige mon quota est passé de 50 Go à 100 Go (106 en fait). J’utilisais déjà ce stockage de fichier dans le clous de manière assez libérale, disons que je ne me suis pas arrangé ! Les partages de répertoires à titre professionnel ou privé sont toujours simples et pratiques. Longue vie à Dropbox !

Evernote  : J’ai aussi élargi mon usage d’Evernote ! De la simple prise de note sur le vif je suis passé à la préparation de posts en mode brouillon (y compris celui-ci), le stockage de cartes de visites, de documents, le partage de notes avec mes équipes, etc… J’ai écris un post sur ce sujet il y a 6 mois. Bref est arrivé ce qui devait arriver : suis passé au plan premium il y a un petit mois de cela …

Producteev  : Toujours mon outil de prédilection pour gérer ma todo liste. Il a peu évolué de mon point de vue, à part la liste de tâches que j’apprécie bien. Par contre l’interface a des comportements assez curieux et je n’arrive toujours pas à configurer la fin de la journée à minuit ! Une application iPhone existe que j’ai évidemment installé … mais que je n’utilise pas au final !

Tumblr  : J’avais commencé assez doucement Tumblr en fin d’année dernière. Avec environ 280 posts à ce jour je crois que l’on peut dire que “je l’utilise plus” ! J’ai non seulement pris un rythme de croisière, mais diversifié mes publications : notes de lecture, comptes-rendus de conférence avec photo (j’ai même fini par acquérir un APN de bonne qualité pour cela), articles PDF, présentations, citations, etc… La “vanité URL” en est la cerise sur le gâteau.

Les nouveaux venus

Dashlane : Une belle galère de gérer ses mots de passes et de les sécuriser correctement. Il existe quelques solutions sérieuses pour cela, mais pas beaucoup. J’ai choisi Dashlane, franchement sérieux, très sérieux et pratique ! Et j’en finis avec le trousseau d’accès du Mac. C’est certainement parmi mes “nouveaux” celui qui me donne le plus grand surcroit de confort : je diversifie et renforce mes mots de passe, je ne stocke plus rien dans le navigateur et je laisse Dashlane me connecter sur les sites ! Sans compter les quelques fonctionnalités annexes que je vais vous laisser découvrir !

Flickr : Flickr n’est pas vraiment le dernier truc à la mode qui monte. De là à penser qu’il faut être un foutu has been pour classer ce service dans les “nouveaux venus"… En fait je trouve Flickr assez pratique pour publier mes photos sur Twitter. Ne serait-ce que parce qu’il propose un redimensionnement de très bonne qualité. Sans être mortelles, les fonctionnalités sont potables : des albums que l’on peut regrouper, etc… L’ergonomie est d’un autre siècle et c’est sans doute pour ça que je ne l’exploita pas encore pleinement. Mais le service est là, donc…

Disqus : J’ai intégré Disqus dans Tumblr pour les commentaires, c’est surtout pour cela que Disqus figure ici. Donc un usage très modéré je dois dire, cr j’ai très peu de commentaires sur mes posts !

Issuu : C’est la solution que j’ai trouvé pour stocker, partager et intégrer des documents PDF dans Tumblr. La liseuse est peut-être en Flash, mais franchement elle a de la gueule ! Les fonctionnalités du services ne sont pas mal non plus, une fois que l’on s’est accoutumé à la logique …

Capitaine Train : J’achète maintenant mes billets de train exclusivement ici ! C’est simple, rapide et zen ! Bravo à cette startup française d’avoir su combiner la qualité de service et la relation client. Un projet monté en ce qui ressemble fort à du Lean Startup !

Ideascale : Ideascale figure ici car nous l’utilisons pour les propositions de sessions pour certains évènements du SUG. Maintenant, pour tout dire, je ne suis pas franchement conquis.

A l’année prochaine !

Le nombre de services que j’utilise est en légère augmentation depuis l’année dernière. C’est surtout parce qu’il y avait certaines choses que je ne confiais pas encore au cloud. Si beaucoup d’entre-eux ont une "dimension sociale” je ne les utilisent pas ou peu en ce sens. Je ne cherche pas à avoir des “amis” ou à suivre qui que ce soit sur Flickr ou Slideshare, c’est moins vrai sur Tumblr. Le seul pur réseau social à figurer ici est Twitter.

Même si certains services semblent proches ou identiques, je segmente leurs usages :

  • Je n’utilise Trello que pour les projets, alors que Producteev est une pure todo liste au jour le jour
  • Si Slideshare et Issuu peuvent tous les deux stocker et présenter des documents, Slideshare me sert pour mettre en ligne mes présentations uniquement, alors que ce sont des articles en PDF que je confie à Issuu.

Voilà pour cette année. Rendez-vous dans 12 mois pour faire le point.

En finir avec … (le lightning talk)

Voici le support de mon lightning talk “en finir avec …” tel que je l’ai présenté l’Agile Tour Nantes 2012. C’est une présentation courte, de moins de 15 minutes.

Teaser de la présentation

L’agilité est en pleine expansion. Nombreux sont les projets, nombreuses sont les sociétés qui l’adopte ! Nous devons nous féliciter de cet engouement, et pourtant …

Pourtant cette adoption croissante n’est qu’apparence dans certains cas. Dans plus en plus de cas, même. Si Scrum est aujourd’hui l’approche qui fédère le plus, les quelques idées centrales de la méthode sont de plus en plus souvent dévoyées. Il en va de même d’autres pratiques agiles.

Ah ! Vous faites du Scrum, je vois que vous avez un P.O. et un Scrum Master. Vous n’avez plus de cahier des charges mais des User Stories, donc tout va bien.

Cocher la liste des pratiques agiles en repeignant plus ou moins les vieilles pratiques ne convient pas, il faut en finir avec cela !

Dans cette courte session, je vous propose de faire la peau à 3 pratiques : la Roadmap, le Product Owner et les User Stories. Mais vais-je vraiment les assasiner ? Pour le savoir il vous faudra assister à ce lightning talk !

Quelques rappels sur “en finir avec”

Cette série comprend aujourd’hui une présentation générale du principe de cette série ainsi que 3 posts:
Elle compte désormais la présente présentation, et une partie de la présentation de Caroline Damour et Emilie Franchomme à laquelle j’ai participé (du moins pour “la dernière”).
Viendront cette présentation sous forme d’articles, d’autres posts (certains sont en préparation, soyez patients) et peut-être une saison 2 ?

The virtues of emergence

J’ai eu de nouveau le plaisir de donner mon lightning talk “les vertus de l’émergence” lors de l’agile tour Bruxelles. Cette fois, c’était en Anglais, l’exercice était donc un peu plus difficile. Voici le support de cette présentation, un peu modifié par rapport à la langue et au modèle graphique de l’évènement.

Le slide-show ne rend pas bien compte de la présentation. J’avais posté ici-même cette présentation sous forme d’article. Mais c’est uniquement en français pour l’instant.

La même présentation est aussi accessible en français, avec le modèle graphique du Scrum Day 2012.

I was lucky enough to give my lightning talk “the virtues of emergence” during the Bruxelles agile tour. This time, it was in English, so a little bit more difficult for me. Here is the slide show, slightly modified from my first presentation.

As you will see, this doesn’t reflect the presentation. That’s why I wrote an article from this, accessible from here. But it’s only in French for now. I won’t guarantee I’ll perform a translation, but I’ll take that in consideration.

Un an de blog Tumblr

J’ai débuté ce blog il y a tout juste un an, il est temps de jeter un coup d’oeil vers le passé et d’en faire le bilan annuel. Je dis “un an”, mais en fait, je n’ai commis que 2 posts en Octobre 2011 et il a fallu attendre Décembre pour que je commence à publier avec régularité. Tant pis pour moi, mes chiffres devront s’accommoder de ce démarrage en douceur !

Les posts en chiffre

En un an j’ai posté 221 articles. Un nombre très important d’entre eux, toutefois moins de la moitié sont des notes de lecture, il y en a 97 jusqu’à présent pour être exact !

Ce n’est pas réellement une surprise, car la publication de notes de lecture était bien la motivation initiale de la création de ce blog. Certains me demandent comment je fais pour publier avec un tel rythme. Sérieusement, ce n’est pas mon rythme de lecture, loin s’en faut. En fait, je procède comme l’industrie pétrolière : je vis sur mes réserves fossiles. C’est certain, un jour elles seront épuisées. Mais j’ai encore un peu de marge en attendant.

Voici la répartition des posts mois par mois.

stats-posts-1erAnniv

Le mois de Mai fut le plus productif avec 37 posts, la moyenne se maintenant depuis entre 20 et 30 posts par mois. Les congés ou les périodes d’intense activité professionnelle ont une évidente incidence sur mon activité Blogistique.

La fréquentation

Je n’ai activé les Google Analytics que depuis le 5 février. C’est bien dommage car j’ai raté les statistiques sur mon article du 30 décembre 2011 : “réponse à Tests Driven Dévelopment : un pacte diabolique”. Voici les données brutes.

stats-freq-tumblr-1erAnniv

Je ne comptabilise en suivi que les visiteurs uniques, donc moins que les visites et encore moins que les pages vues. Ma journée la plus intense fut le 29 Août avec 79 visiteurs uniques. Clairement, je reste un petit blog du fin fond de la campagne. Cela se traduit en visites par un score de 90, toujours sur la même journée et par 112 pages vues, toujours le 29 août. Il faudrait compter avec 459 pages vues le 7 Juillet, mais je crois hélas que des opérations de maintenances opérées par moi-même faussent un peu le score.

Pour résumer, voici quelques statistiques générales

stats-visiteurs-1anniv

Le taux de rebond semble important, mais cela s’explique en grande partie par le fait qu’un grand nombre de visites font suite à l’envoi de liens via Twitter.

Enfin, une dernière statistique : les browser employés.

stats-browser-1anniv

Chrome se taille largement la part du lion. Firefox passe derrière, qui ne laisse que des miettes à Safari et moins encore à Internet Explorer. Je dirais que c’est assez symptomatique de la communauté qui me lit.

Et maintenant ?

J’ai commencé ce Blog pour publier des notes de lecture, j’y ai ajouté des posts relatifs à l’agilité et des citations. De temps en temps je suis sorti du cadre informatique pour poster sur d’autres de mes centres d’intérêt. Je ne vais probablement pas tellement modifier ma ligne de conduite, mais il y aura de petites nouveautés tout en restant dans ce cadre. Je n’en dis pas plus.

Au niveau Look, j’ai un tout petit peu enrichi le thème Tumblr de base, mais cela est resté simple. Je ne suis de toute manière pas une grosse bête de la personnalisation Tumblr. Les ajouts les plus visibles sont certainement le nuage de tags et les badges. L’utilisation des Google Web Font pour le titre est plus discrète.

La seule nouveauté à venir à court terme devrait être une nouvelle URL pour ce blog, un tout petit plus prétentieuse que la présente. Cela devrait être fait d’ici la fin du mois.

Sur ce, rendez-vous l’année prochaine !