Transformation Agile : place à l'expérimentation !

J'ai l'habitude de proposer une démarche pour la transformation Agile basée sur l'expérimentation, on pourrait dire inverse à l'approche by the book souvent préconisée pour les équipes qui se lancent.

Mon constat est que plus on est novice en Agilité, plus on a besoin d'expérimenter et de comprendre avant de mettre en pratique (c'est l'inverse du Shu Ha Ri !).

Pour faire le contrepoint du désordre "expérimental" propice à l'épanouissement des individus, la transformation Agile doit aussi assurer l'atteinte d'objectifs mesurables et définis dans le temps. C'est la meilleure façon d'éviter des transformations qui durent des mois et parfois même des années et qui s'arrêtent un jour uniquement par ce qu'il n'y a plus de budget sans jamais savoir si finalement l'investissement en valait la peine !

Voici en quelques points la démarche que j'ai l'habitude de proposer.

Transformation Agile : attention au changement !

De nombreuses transformations Agile échouent, car elles se fondent uniquement sur des activités, des processus et des outils (les Framework Agile) en oubliant que l'Agilité est avant tout un changement de culture.

De quoi parle-t-on ?

Imaginez un peu qu'un architecte vous propose de construire votre maison en mode Agile. Vous seriez vous dans un premier temps séduit de maîtriser le budget et de pouvoir changer la position de la salle de bain après l'avoir construite, mais lorsque vous aller parler de votre projet à vos amis et quand il faudra convaincre un banquier de vous prêter de l'argent, vous allez vous heurter à des questions comme :

• Tu as vraiment confiance dans cet architecte ?
• Comment ça ! Tu n'as pas de plan précis de la maison ?
• Avant de vous prêter de l'argent, j'ai besoin de garanties sur ce qui va être construit !

La choc culturel que représente ce changement dans votre contexte social risque fort de vous faire rentrer dans le rang des constructions sur plan.

Le changement, quel qu'il soit, est un sujet à traiter à part entière car ses impacts sur les individus et les liens qu'ils entretiennent avec l'entreprise vont souvent bien au-delà de ce que l'on imagine.

Réflexions sur l'estimation des User Story

Les Story Points (SP) sont définis comme une mesure de la complexité des User Story.

Quand on parle de complexité à une équipe, elle pense difficulté et elle pense temps pour résoudre la difficulté individuellement. Le débat devient vite :

• Quelle note donner à une tâche très longue mais simple ?
• C'est compliqué mais très rapide... je fais quoi ?
• C'est difficile à estimer, il faut découper
• Pour moi c'est rapide, je l'ai déjà fait... pour moi c'est long, je ne connais pas...

La pratique de l'estimation est souvent remise en cause car elle est fastidieuse et son usage est parfois détourné pour engager les équipes sur des dates de livraison peu fiables.

Dans cet article je vais essayer de vous présenter quelques réflexions sur ce sujet, mais tout d'abord commençons par le commencement : les User Story.

Une journée de Coach Agile

J'ai pris l'habitude de commencer la journée par une rapide revue de mes actions en cours. Pour cela nous avions mis en place avec le sponsor de la transformation Agile un mur des actions de Coaching.

Aujourd'hui il me reste pas mal de sujets à traiter mais j'évite d'utiliser ce mur comme un catalogue d'actions à mettre en oeuvre, ma priorité est de m'adapter aux besoins de ce plateau de 60 personnes.

Ce mur est avant tout un effort de transparence sur un référentiel d'actions de coaching.

Il suscite des questions et donc des interactions autour de mon action et c'est exactement ce que je cherche !

Scrum Master, rôle ou métier ?

J'écris cet article suite à une discussion avec une RH à propos du recrutement des Scrum Master (SM) et des compétences demandées.

J'ai eu l'occasion de Coacher une équipe dont le SM avait été désigné par le management. 

Officieusement, le manager me laissait entendre qu'il attendait du SM qu'il mette la pression sur l'équipe pour atteindre ses objectifs et qu'il fasse du reporting de tous leurs faits et gestes.

Je ne suis pas très fan de cette vision du SM alors...

Retrouver l'espoir dans les activités de maintenance avec le framework Cynefin

Ceci est un article sur la conférence que j'ai tenu au Kanbanday le 28 mai 2015.

Il s'agit d'un retour d'expérience sur la mise en place d'un tableau Kanban dans des équipes de maintenance applicative.

La maintenance applicative

Les équipes chargées de la maintenance ont comme rôle de maintenir un système opérationnel. Leur engagement est en général sans limite pour la simple et bonne raison que personne ne s'est donné la peine de leur en donner.

Dans certains cas le système prend l'eau et l'effort pour le maintenir à flot devient considérable.

La management visuel nous aide dans un premier temps parce qu'il permet d'identifier des blocages mais très vite c'est la priorisation qui devient un casse tête.

Cynefin

Cynefin est un Framework d'aide à la prise de décision qui catégorise les situations :

1. Simple : La situation dans laquelle la relation entre cause et effet est évidente
2. Compliqué : La situation dans laquelle la relation entre cause et effet demande de l'analyse et requiert l'intervention d'experts
3. Chaotique : La situation dans laquelle il n'y a aucun lien identifié entre cause et effet
4. Complexe : la situation dans laquelle le lien entre cause et effet ne pourra être découvert que par l’expérimentation

Il y a un cinquième domaine, le désordre, que je n'ai pas utilisé ici (c'est probablement le domaine dans lequel les équipes étaient !)

Un REX sur la transparence salariale

Le salaire est souvent un sujet de gêne entre les salariés du privé.

Et oui je parle du privé parce que dans le public les fonctionnaires connaissent leurs statuts réciproques et donc les salaires de tout un chacun !

Même quand on se connait bien entre collègues, on a du mal à aborder ce sujet.

Pourquoi ?

• Parce que j'ai le sentiment d'avoir mal négocié mon salaire, j'ai honte qu'il soit si bas
• Parce que je sais que je suis très bien payé et mieux que tous les autres
• Parce que ça ne m'intéresse pas de savoir ce que gagne les autres
• Parce que...

Alors que toutes les raisons sont bonnes pour ne pas dire son salaire, je n'ai jamais connu d'équipe où à un moment ou un autre il ne se pas dit : "Paul avec ce qu'il gagne, il pourrait se bouger le c... mais il gagne combien Paul en fait... beaucoup trop !"

Alors qu'on en parlait un jour avec des collègues, je ne sais pas trop pourquoi, j'ai pris un Post-IT, j'ai écrit mon prénom et mon salaire dessus, je l'ai collé au mur et ça a donné le mur des salaires :

Les prénoms sont masqués et ce n'est pas pour ne pas être transparent,
non c'est juste que ce n'est pas le sujet de mon article !