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.