Je ne sais pas trop, j’ai une sorte de frénésie d’écriture. Un nouveau thème hier, un article hier, un autre aujourd’hui, probablement d’autres à suivre dans la semaine. Une maladie mentale sans aucun doute. Enfin, voici deux formats de rétrospective que nous allons essayer durant cette semaine (que nous avons essayé, j’amende l’article).

Le bestiaire des contes et légendes

Comme beaucoup j’ai fait des jeux de rôles (JRTM, Donjons & Dragons, Légendes celtiques, etc.), même grandeur nature, j’ai lu J.R.R Tolkien, George Martin ou Andrzej Sapkowski, mais aussi Astérix, ou Thorgal ou Jon le Chninkel. Voici donc un cadre pour faire une rétrospective avec le bestiaire de nos contes et légendes.

C’est dimanche, et je sors d’un repas de (belle)-famille. J’ai donc besoin d’exterioriser une pression intérieure. Merci de m’assister dans cette tâche. j’entends trop souvent dire que les estimations sont liées à la complexité. C’est trop limitatif.

Dans notre monde mouvant il faut agir au plus juste. Enfin surtout dans nos entreprises où un constant rapport entre l’effort et la valeur est de mise (et si on peut juger de cette valeur au plus vite, on saura mesurer au mieux notre effort).

Et voici l’holacratie qui se murmure un peu partout. Rien de nouveau et pourtant des choses intéressantes. De la frustration, de l’irritation, des moments de plaisir. Avant d’aborder dans le détails certains points (de prochains articles ?), voici une impression d’ensemble.

Paradoxe

L’holacratie ne semble être fait de rien de nouveau. Ce n’est qu’un assemblage de choses connues. Et pourtant un petit air d’innovation flotte, une sorte d’équilibre. Comme si on avait matérialisé une avancée. Bien sûr d’un côté les vieux baroudeurs hurlent au détournement marketing (et je dois avouer que je hurle avec les loups), de l’autre les défenseurs de l’holacratie disent qu’il ne faut pas chercher d’où cela vient et déposent la marque pour en faire – j’imagine – le maximum de pognon. Allez on va s’en sortir.

La définition de fini c’est l’ensemble des critères que l’on se donne pour considérer en agile que les éléments sur lesquels on travaille sont finis, ou pas. Le fini est essentiel, car il permet d’avoir quelque chose de concret. on sort de l’hypothèse, on a quelque chose que l’on peut vendre, donner, proposer, essayer, etc, on va apprendre. Le feedback est toujours intéressant, même avant le “fini”, mais naturellement avec le fini il prend beaucoup plus de valeur. Et le fini nous permet d’aller chercher du feedback ailleurs (utilisateurs finaux, dehors dans le monde extérieur, etc.). Le fini est aussi binaire, c’est fini ou ce n’est pas fini. Cette polarité est franche et permet une vraie lecture simplifiée des réalisations en cours (ça, on l’a, ça on ne l’a pas), et ouvre vers des arbitrages plus judicieux. Avec cette notion stricte de fini (ou pas), on évite les “on a 80% de cette fonctionnalité et 70% de celle-ci” ce qui, vous le savez tous, ne veut rien dire dans la vraie vie. Quand les gens nous disent “on a 80% de cette fonctionnalité” bien souvent, ils expriment l’idée que 80% du temps alloué sur la réalisation de cette fonctionnalité a été consommé. Mais rien n’indique que les 20% restant ne prendront pas plus que les 80% précédent. Et donc on souhaite du feedback régulièrement et on souhaite des choses finies régulièrement pour apprendre, vendre, donner, essayer, etc, le plus tôt possible. Et donc on retombe dans un besoin d’exprimer des choses finies qui font sens (sur le plan fonctionnel, usuel, métiers, commercial) avec des éléments assez réduits (taille, effort de réalisation). Mais ce n’est pas le sujet de cet article mais plutôt de celui-ci.

Suite d’un tweet que j’ai émis ce week-end : “finalement un coach agile c’est un scrummaster qui ne prend plus de décision”. Voici un essai brouillon de complément de réponse.

Scrummaster ? Coach agile ? Normalement, idéalement, à mes yeux ces deux expressions désignent la même chose, le même rôle, la même intention, la même attitude (vous savez que j’aime ces deux mots). C’est le même boulot. Je suis d’accord pour convenir que le scrummaster désigne quelqu’un de moins expérimenté que le coach agile. Mais si l’expérience est souvent un critère de qualité, elle ne l’est pas toujours. Ainsi d’accord pour commencer à dire que le scrummaster a généralement un périmètre plus réduit que le coach agile. Par exemple le scrummaster est dédié à une équipe, et le coach agile à une organisation, ou du moins quelque chose qui dépasse une ou deux équipes, un département, un domaine, etc. D’où le serpent qui change de peau, pour simplement représenter la mue. Mue qui n’ouvre pas forcément sur quelque chose de différent contrairement à la chrysalide.

Pablo : Claudio on a un souci.

Claudio : Oui Pablo, après celui des certifications, un deuxième fléau guette le mouvement agile : le fléau des évaluations. On veut connaître son niveau d’agilité, savoir si on a une plus grosse agilité que son voisin ou son concurrent.

Pablo : Ah mais il m’arrive d’ “auditer” l’agilité d’entreprises.

Claudio : Moi aussi ces dernières années, j’ai pratiqué de nombreuses évaluations ou audits “agiles”, j’ai réfléchi à la façon de les mener, notamment avec Alexandre Boutin, j’ai discuté avec des gens que cherchaient à définir un modèle d’évaluation agile. J’ai lu de nombreuses propositions de modèles, le dernier en date étant celui du Cigref, inutilisable de mon point de vue. J’en suis arrivé à la conclusion suivante : ce qui compte, ce n’est pas tant de savoir où on est, mais la route à suivre. L’agilité est un voyage. Attention, il me paraît légitime de s’évaluer dans le but de progresser. Mais rester dans les schémas classiques de l’évaluation et les appliquer à l’agilité, c’est là que se situe le danger.

Petite suite au sujet du portfolio projets kanban partie 1 de janvier 2016. Petite, car l’essentiel de cette introduction à kanban était présent précédemment.

Qu’est ce que l’on mesure ?

Finalement qu’est ce que l’on mesure ? Bien tout simplement, par exemple, le nombre d’éléments dans votre kanban. Donc le nombre d’éléments sur lesquels un effort de création de valeur est accompli. Il faut bien comprendre que le kanban montre un flux qui vit, un travail en cours. Mise à part la première et la dernière colonnes qui sont des déversoirs (importants), toutes les autres colonnes devraient montrer une activité, une action, une dynamique. Si vous avez plusieurs milliers d’anomalies et un kanban lié à la gestion de ces anomalies, vous n’allez pas les placer sur le mur, c’est impossible et inutile. Vous allez faire entrer dans le flux du kanban celles sur lesquelles vous voulez travailler (c’est déjà une décision forte).