jeudi 13 novembre 2014

Fin de traduction de "Priming Kanban"

Malgré le délai et le silence, je viens de finir la traduction brute de Priming Kanban, le livre de Jesper Boeg. Ce fut un peu long, certains chapitres sont vraiment durs en termes de traduction. L'aventure est belle par contre, et le résultat devrait être vraiment superbe.

Alors un petit tour du reste à faire :
  • De la relecture avec l'équipe des traducteurs agiles
  • La traduction des graphiques
  • (Beaucoup) de mise en forme
Date de release prévisionnelle : 30/11

vendredi 17 octobre 2014

Priming Kanban en avant et cube

Et oui, la traduction de Priming Kanban avance bien. Moins que prévu du fait de quelques missions qui prennent du temps. J'ai fait une première relecture de l'étape 2, les 3 et 4 devraient être finalisées dans le week-end.
En travaillant sur de la mise en forme, j'ai redécouvert des fonctions de Word qui permettent de faire ce qui est attendu. Cela méritera peut être un tuto à l'occasion.

Et surtout, Peter Antman vient d'écrire un article très chouette sur un cube pour organiser les rendez-vous agiles. Avec l'accord de l'auteur, cela devrait rentrer dans le pipe juste après Priming Kanban =)

jeudi 9 octobre 2014

Réflexion sur l'étape 1 de Priming Kanban


Parlons sérieusement. Si l'introduction de Priming Kanban est vraiment intéressante, et méritera un poste sur les mythes de Lean / Kanban, la première étape "Visualiser le flux de travail" rentre déjà dans le dur des principes du Lean.

Respirer

Tout d'abord, l'idée même du Lean est la transformation continue et progressive des systèmes. Avant de tout casser, comprenez ! Le terme à la mode cette année était Shu Ha Ri, et c'est finalement bien le concept de fond derrière la démarche globale de Kanban :
Shu est l'apprentissage, Ha est la maîtrise, la remise en question, Ri est le dépassement. Peter Hundermark le rappelle déjà dans son ouvrage "Do Better Scrum" traduit il y a quelques temps. Nous occidentaux pressés voulons atteindre le Ri immédiatement. Non ! Stop ! Calmons nous !

La première étape pourrait finalement s'appeler "Respirer et regarder". Respirer est l'activité la plus importante de notre vie, comme le battement du coeur ou la circulation des liquides et des énergies dans le corps : c'est une primitive de la vie qui une fois acquise est ancré à un tel niveau de profondeur et d'inconscient qu'il est difficile d'en reprendre la main. Il est dit (et c'est une parenthèse un peu longue) que certain maître bouddhiste parviennent à contrôler l'absorption d'éléments toxiques dans leur corps.

Je disais "Respirer". Oui, avant de tout casser dans un processus, un mode de fonctionnement, il est nécessaire (salvateur ?) de prendre du recul, de se recentrer et de s'interroger un instant. "Où suis-je ? Que se passe-t-il ?" Dans une situation de crise, ce pas en arrière est généralement celui qui vous sauve la vie. Si vous êtes coincé dans un immeuble en feu (ce que je ne vous souhaite pas), courir tout droit peut vous mener vite à la mort.

Dès lors, cette phase initiale est la plus importante, et l'oublier ou la passer trop vite déséquilibre l'entiereté de la démarche. C'est dans une démarche systémique ce qu'il ne faut surtout pas faire. Procéder par l'action d'abord est certes tentant ("je bouge donc je suis utile") et revient souvent à allumer un incendie pour éteindre celui que vous voulez éteindre.
C'est néanmoins souvent par ce principe que l'Agile se déploie, et plus encore Scrum ces derniers temps : "Mon projet ne marche pas, j'ai des délais à respecter, vite Scrum !"

Scrum, Kanban et visualisation

Les références à Scrum sont nombreuses dans l'ouvrage de Jesper, et l'usage de Kanban comme catalyseur de Scrum a fait ses preuves, pour lesquelles Laurent Morisseau a construit quelques présentations assez drôles il y a quelques temps déjà.
Reprenons l'idée de visualisation et le rapport à Scrum. Si vous écoutez Jeff Sutherland, en particulier dans sa conférence TedX à Aix, il explique très bien l'usage de la visualisation dès le début de ces recherches. Pour avoir eu la chance de l'avoir en formation Scrum Master il y a quelques années, le découpage actuel d'un Scrum Board en trois étapes est finalement... mythique ! Alistair Cockburn le montre bien sur son "Scrum sur un Post-it" : le Scrum Board n'est pas du "Core Scrum", la visualisation par contre oui !
Ensuite, Scrum part du postulat que votre équipe est autonome et polyvalente, dans le sens où tous les acteurs d'une phase "doing", c'est à dire de la spécification à la mise en production, sont présents.
Dans ce contexte, et en gardant le principe Lean de simplicité, pourquoi découper a priori une étape "doing" en plusieurs morceaux ? Il n'y aurait de ma fenêtre qu'une bonne raison : votre définition, c'est à dire la politique en langage Lean, du "Done" ne permet pas un usage de la fonctionnalité par votre utilisateur...

En résumé, Scrum ou pas Scrum n'est pas la question. Scrumban lorsque Scrum ne marche pas est une application de Kanban décrite dans l'ouvrage pour mettre en lumière ce qui ne va pas. Et avant de trouver des patch / outils / processus compliqués pour faire tourner votre Scrum qui n'atteint pas le x4, une bête visualisation du flux actuel est souvent un bon moyen de comprendre où sont les blocages.

mercredi 8 octobre 2014

Priming Kanban en route pour la traduction

Je suis en pleine traduction de "Priming Kanban" de Jesper Boeg. Oui, l'auteur et InfoQ ont accepté l'idée =)
Le travail avance plutôt bien, l'introduction et la préface étant traduite et relue une première fois. L'équipe des traducteurs agiles fera sans doute une seconde passe et il manquera une phase d'editing pour que ce soit joli.
Là par contre, c'est plus compliqué à froid. Le document d'origine est au format InDesign. Il semble qu'Adobe dans sa grande bonté, ait songé que la meilleure façon de rendre les gens dépendants est d'acheter des softs avec des fonctionnalités inutiles en fermant les formats pour éviter toute compatibilité avec des logiciels opensource.
Je suis donc bien embêté pour le moment, et je ne vois en perspective qu'une mise en page via Word, mes premiers tests sur du format epub ne me paraissant pas convaincants pour le moment. Si vous avez une idée, n'hésitez pas à me pousser un petit mot sur twitter...

Enfin, et parce que c'est le plus important, "Priming Kanban" c'est bien mais ce n'est pas un titre français.
Alors, cher lecteur, si vous avez une idée, je suis tout ouïe. J'en ai aussi, mais je suis preneur, l'intelligence collective étant quand même plus sympa que le jus de cerveau à pas d'heure.
 Dans ma liste actuelle je vois donc :
  • Esquisse Kanban (la sonorité est proche de kisskiss bang bang de Shaine Black ;)
  • Essence de Kanban
  • Kanban ' (Kanban Prime..., désolé, fallait pas l'inviter)
  • Concentré de Kanban.
Pour être tout à fait franc, ce que je ne parviens pas encore à mettre en lumière est :
  1. La voie active utilisée avec "Priming"
  2. La polyvalence qui m'évoque à la fois un vin jeune (un primeur) ET le côté essentiel / à retenir
Sur ces bonnes paroles, je lancerais un sondage dans les jours à venir.

mercredi 1 octobre 2014

Priming kanban bientôt en Français ?

Après quelques échanges avec Jesper Boeg l'idée d'une traduction de "Priming Kanban" en français paraît envisageable.
Une version portuguaise existe depuis plusieurs années, et l'auteur m'a confirmé qu'une version chinoise est en cours ! Oublier la langue de Molière serait bien triste.

Pour rappel Priming Kanban est un mini-livre d'une soixantaine de pages concernant les étapes dans le déploiement du Kanban. C'est une bonne première approche de cette vision d'un flux d'activités, bien plus efficace comme approche que l'ouvrage (de référence) de David Anderson.

Alors, un peu de patience, ça arrive (disons une quinzaine).

lundi 29 septembre 2014

Diagramme Causes et Effets - Traduction en français

Rappel

Il y a cinq ans, Henrik Kniberg publiait un article sur les diagrammes causes et effets, dont l'original est ici

Vous pouvez maintenant lire cet article sur les diagrammes causes et effets ici.
L'avantage majeur de ce texte est sa concision et sa lisibilité, qui j'espère reste malgré la traduction. L'auteur à l'avantage de rentrer par l'exemple dans une formalisation agréable, souvent humoristique, et pleine de bon sens.
Une petite note personnelle à la suite de la traduction : les sujets que mettaient Henrik en lumière il y a cinq ans sont toujours autant d'actualité. Je vous assure, j'ai vu le cas la semaine dernière ;)

Pourquoi

Pour ceux qui auraient oubliés l'utilité d'un diagramme causes et effets, cet outil est une manière de chercher
  • d'un côté les problématiques réelles existant derrière une formulation de problème
  • de l'autre, les causes profondes, dites causes racines, du problème.
Pourquoi chercher le vrai problème ? Généralement quand quelqu'un vous soumet un problème, vous n'avez qu'une partie de l'iceberg. Les véritables motivations sont bien autres. Il n'y a pas -toujours- de volonté de vous tromper, plus simplement une omission ou juste une non mise en perspective du demandeur. Les exemples de l'auteur sont à ce titre très clair.
De l'autre,  vous avez la/les causes profondes. Là encore, il est important de ne pas s'arrêter à la surface ou au premier discours. C'est la raison pour laquelle le terme en usage est "creuser".
Ce mode de fonctionnement est typique d'une démarche Lean au sens large. Il entre dans le "Kaizen" comme le rappelle Henrik Kniberg, à savoir cette volonté de s'améliorer en continue.

Et après

La méthode s'est bien jolie, il vous reste à sauter à l'eau. Si vous suivez les propositions d'Henrik, il y a fort à parier que vous arriviez assez vite à construire des diagrammes significatifs et surtout qui permettent l'action.

Les diagrammes de causes et effets sont également à inclure dans une démarche de théorie des contraintes, dite "TOC" par les intimes. Si je n'aime pas le terme de "théorie", ces principes d'E. Goldratt, probablement repris au Lean, permettent de travailler également sur des schémas de transformation d'organisation à très grandes échelles.

Dans tous les cas, n'hésitez pas à lire / relire l'article, et surtout à pratiquer.
Bonne lecture

jeudi 25 septembre 2014

Déployer l'Agile à l'échelle de l'organisation - la méthode parfaite

 Scaling Agile a Perfect Method


Ceci est la traduction d'un post de Tobias Mayer "Scaling Agile a Perfect Method"

Depuis plusieurs mois, on voit appararaitre beaucoup de méthodes et de suggestions pour déployer l'agile à l'échelle de l'entreprise. Elles passent toutes à côté de l'essentiel, parce que les partisans de ces méthodes utilisent une mauvaise définition de mise à l'échelle. J'ai une méthode parfaite pour cela. Pour la décrire, je vais utiliser une métaphore ichtyologique (de poisson quoi, NdT). Un poissonnier écaille les poissons de la manière dont nous devrions déployer l'Agile. En fait, j'appelle cette méthode Séparer avec Filetage l'Agile, ou Safa pour faire court (prononcer "Safe'r").

Safa part de l'hypothèse (très raisonnable) que si vous êtes une entreprise essayant de "faire de l'Agile",  vous avez probablement accumulé beaucoup de cochonneries : des outils de suivi coûteux, des consultants avec des saveurs différentes, des réunions douloureuses et inutiles, de nouveaux rôles qui ressemblent aux anciens avec des noms différents, et au moins autant de tableaux, graphiques, courbes d'avancement, courbes d'atterrissage... et courbes d'épuisement.

Le poisson est votre entreprise. Il a l'air bien de l'extérieur, mais immonde à l'intérieur. Commençons la Séparation et l'écaillage. Retirez le vernis Agile véhiculé par les mots à la mode, ainsi que les bibelots d'entreprise aux couleurs vives et brillantes. Ensuite, occupez vous des risques d'étouffement, des véritables obstacles à la productivité réelle, des obstacles organisationnels limitant l'engagement, des petits désagréments qui rendent les gens malades. Enfin, retirez les tripes et les caillots de sang qui représentent tout le reste des déchets, les restes d'une vie à laquelle vous n'êtes plus liée.

Félicitations. La valeur de votre poisson-entreprise a augmenté sur le marché, et maintenant vous avez quelque chose avec lequel vous pouvez préparer un plat.

Note du Traducteur 

Les propos ci-dessous sont les idées de l'auteur de ce blog. Ils n'engagent pas la responsabilité de l'auteur de l'article traduit.

Je lis les écrits de Tobias Mayer depuis quelques années déjà, et son ouvrage "The People's Scrum" fut une sorte de révélation et une obligation à l'introspection salutaire dans mon parcours Agile.
Tobias a un ton très libre, des idées assez différentes de celles de la Scrum Alliance ou des consultants et autres chantres des méthodes venant vendre monts et merveilles.

Pour les puristes et ceux qui suivent le mouvement Agile depuis un moment, les deux dernières années ont vu fleurir des "méthodes" pour transformer l'entreprise et la rendre agile. Les anglo-saxons appellent cela "scaling", que je traduis par mise à l'échelle ou déploiement à l'échelle.
Pour ceux qui ne maitrisent pas les subtilités de la langue de Shakespeare, "to scale" veut dire à la fois mettre à l'échelle et écailler. C'est autour de ce jeu de mot que Tobias construit sa métaphore.
L'une des méthodes de "mise à l'échelle" assez à la mode et bien compliquée s'appelle SAFe. Safa est un jeu de mot venant se moquer -gentiment- de cela : la prononciation se traduit par plus sûr ou "Plus SAFe".

D'un point de vue plus concret, si vous avez commencé à travailler sur le déploiement de l'agile dans l'entreprise, vous risquez d'être dans la situation décrite par Tobias. Il existe plein d'artefacts, de pustules, de changement dans les titres des postes avec derrière assez peu de véritables transformations. Des équipes de consultants spécialistes "Agile" avec au moins un an d'expérience et une formation par leur manager, viennent vous expliquer qu'il faut mesurer, rentrer dans une démarche d'amélioration continue, de pilotage des coûts et des performances. Attendez un peu, ça me rappelle des discours des grands fournisseurs qui vendent leur dernier outil à la mode ça. Où est l'Agile ? Trop tard, votre DG vient de signer un contrat, vous avez 200 jours de prestations pour poser un processus tout beau existant ailleurs.
Vous l'aurez compris, vous êtes loin des valeurs du Manifeste Agile, et finalement loin de ce qui a pu faire la réussite de l'Agile dans les équipes.
Pour sortir de cette boucle de la frustration, démotivation et du burn-out (autre jeu de mot difficilement traduisible avec burn-up et burn-down) Tobias propose une approche plus Lean qu'Agile : couper les conneries, virer les trucs qui ne servent à rien sauf à rougir le bas de page de l'entreprise, retourner aux fondamentaux de l'agile.
Une fois que le poisson est propre, pardon, que l'entreprise est purgée des trucs qui le rendent impropre à la consommation, vous pouvez y aller.

Alors, Agiliste, dans l'entreprise, encore quelques efforts ;)

mercredi 24 septembre 2014

Du meilleur Scrum

Du meilleur Scrum
Voici la première traduction maison : "Do Better Scrum" version 3 devient "Du Meilleur Scrum" en bon français.

Ce livre de Peter Hundermark est un panorama complet de Scrum avec un plan simple et efficace :
  • Un bon rappel des basiques sur les deux premiers chapitres avec le pourquoi de la méthode et les artefacts et activités principales,
  • Une manière de démarrer votre première équipe / projet / produit,
  • La gestion de l'équipe dans l'espace, ce que les professionnels appellent la "colocalisation"
  • Les métriques et autres mesures d'avancement avec Scrum,
  • Le sujet à la mode avec le passage d'un modèle Scrum à une équipe à un déploiement de l'Agilité au sein de l'organisation,
  • Quelques réponses sur les questions cruciales que sont : comment s'améliorer et où trouver de l'aide pour le faire,
  • Un peu de perspective entre le reste des pratiques agile, le lean et Scrum
Simple, accessible et gratuit, cet ouvrage est un premier approfondissement permettant d'aller plus loin qu'un simple article wikipedia, ou la simplification optimale d'Alistair Cockburn présentant Scrum sous la forme d'un Post-it

mardi 23 septembre 2014

Introduction

Un proverbe chinois pose :
D'un chemin de dix pas, fais en un et tu en auras fait la moitié.
Les Arts Pratiques sont l'ensemble des savoirs intangibles qui se transmettent par la pratiques régulières. Plus que l'artisanant qui est aujourd'hui un terme utilisé de manière péjorative, ils sont ces capacités à s'adapter continuellement pour construire quelque chose de bien et de beau.
J'ai pris le chemin de l'Agile depuis cinq ans au moins, avec des tours et des détours, des formalisations et des certifications. Voici un nouveau pas, celui du partage avec la communauté. Les experts et sages sont nombreux et c'est avec beaucoup d'humilité que j'écrirai pour le plaisir et le besoin d'exprimer des aventures dans les eaux de l'organisation, de la famille et des mondes associatifs.
Car si aujourd'hui agile rime avec entreprise, business et "approche tirée par la valeur" (value-driven approach), ce qui me semble important est la vision humaniste véhiculée par les premiers agilistes.

Sur ces mots, que la route soit bonne.