Comme je l’ai signalé hier, je m’attelle à la tâche de non pas traduire, mais adapter la prose de Tobias Mayer : The People’s Scrum !
A peine ai-je commencé que je dois déjà faire face à une première difficulté : traduire le titre de l’ouvrage ! L’idée n’est pas nécessairement de faire une traduction littérale, mais de préserver l’esprit du texte !
There is now a fourth translation of The People’s Scrum in the works. Christophe Addinquy will be doing his “spirited translation" into French. Thanks, Christophe!
The People’s Scrum, c’est un livre sur Scrum pas comme les autres ! C’est grandement dans l’esprit de ce que j’essaie de faire avec certains des articles de ce blog. C’est pourquoi nous avons décidé de travailler ensemble sur ce qui sera bien plus qu’une traduction, une adaptation !
Je cherche en ce moment à traduire le titre du livre pour bien en refléter l’essence. Votre aide est la bienvenue !
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 !
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 :
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”.
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:
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.
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 :
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 !
Dans un excellent post qui a d’ailleurs devancé ma chronique, Tobias Meyer parle d’éliminer le Scrum Master ! Il avance plusieurs arguments à cela :
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 …
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 ?
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.
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.
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) :
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.
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 !
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 ?
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é.
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 !
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.
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.
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 !
“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 !
(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
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, 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 !
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.
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.
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.
- 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:
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 !
Cela signifie simplement qu’en fonction de l’organisation, le paquet-cadeau pourra contenir différentes choses :
Votre imagination peut être sans limite, mais il en ira alors de même du coût de votre “definition of done” !
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.
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é !
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.
Alors je dois l’avouer, je n’ai même pas encore lu la saison 1 ! J’ai bien été relecteur de quelques histoires, mais je n’ai pas encore sorti le livre de son étagère où il prend tranquilement la poussière. Tellement à lire, si peu de temps…
Le volume de la saison 1 va bientôt avoir un compagnon de misère : j’ai commandé mon exemplaire de la saison 2, oui même en sachant qu’il risque de s’écouler un petit moment avant que je m’y plonge sérieusement.
Etes-vous comme moi ? Au final peu importe : nous allons y trouver les textes émanant d’intervenants réguliers de la communauté agile française. Nous n’avons pas toujours le temps ou l’opportunité de les voir en conférence. Et même alors nous regrettons de n’avoir au mieux que le support de présentation à notre disposition et pas la substantifique moelle ! Cessons de nous lamenter, rupture douce vient à la rescousse.
Vous pouvez :
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.
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 !
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.
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.
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.
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 :
Voilà pour cette année. Rendez-vous dans 12 mois pour faire le point.
J’avais évoqué l’arrivée de “Rupture Douce” en août sur Leanpub. C’est finalement sur Lulu que l’ouvrage est rendu disponible : deux éditions papier et une édition eBook (PDF). Des versions ePub et mobi (cette dernière pour le Kindle) sont à venir.
J’ai eu le plaisir de faire la relecture finale de quelques une des histoires comprises dans ce volume. Les éléments se sont un peu ligués contre moi pour que je puisse offrir une aide plus importante.
Une partie des royalties du livre sera versée à “La Courte Echelle Collège”, un projet qui vise à sensibiliser les filles de 3ème aux carrières techniques (dont l’informatique) avant qu’elles aient fait leurs choix d’orientation en les mettant au contact de marraines qui seront des “role model”, femmes ayant réussi dans des métiers traditionnellement plutôt masculins.
Pour ma part, ce sera une version papier, car je compte bien me faire dédicacer l’ouvrage par le “chief editor” et peut-être même par certains contributeurs…
La Scrum Night III se déroulera chez Google, les inscriptions ont rencontré un grand succès !
Mais qu’est-ce qu’une Scrum Night sans ses ateliers ? Il y a déjà des propositions, il est encore temps d’en faire !
Rejoingnez-nous sur Ideascale pour proposer vos ateliers, jeux, etc…
Bref, suivez le lien !
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 !
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.
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.
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.
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
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.
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.
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 !
Software Freethinker 