Hellocratie, Holocratie, Holacratie, Honolulucratie
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.
Nul n'est censé ignorer la définition de fini
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.
Du scrummaster au coach agile
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.
We're gonna groove
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.
Portfolio Projets kanban, partie 2
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).
La Scierie à pratiques évolue
Puisque nous sommes dans les jeux (jeu des pièces) ou les ateliers éducatifs voici une mise à jour de la scierie à pratiques, certaines propositions ne sont pas neuves du tout, mais que je ne les avais jamais publié. Je pense donc que la page Scierie à pratiques est un peu obsolète. Laissez les pratiques émerger C’est Stéphane qui avait rapidement proposé cette évolution, et avec le temps elle a montré sa pertinence. L’important est de ne pas donner de liste de pratiques en amont mais de demander aux participants de lister leurs pratiques (disons 12/16 pratiques). Tout simplement. Mais c’est drôlement efficace, tout en ouvrant l’approche à tous les domaines.
Jeu des pièces
Mon actualité m’a fait rajeunir un peu ma documentation sur ce petit jeu agile, le jeu des pièces, ou le “coin toss”. Simple mais très efficace, prenez un gros quart d’heure. Et comme le veut cet ancien proverbe chinois : Dis-moi et j’oublierai. Montre-moi et je me souviendrai. Implique-moi et je comprendrai. – Proverbe chinois L’objectif du jeu va être de démontrer quelques bénéfices fondamentaux de l’agile : un focus sur la valeur en maximisant celle-ci (maximiser la valeur, minimiser l’effort), et délivrant celle-ci au plus tôt (“time to market”) tout en intégrant une capacité au changement.