Un peu partout fleurissent les invocations : soyez heureux, soyez motivés, soyez impliqués, soyez responsables, être heureux, happiness chef blabla. Mais cela ne se décrète pas. Concernant l’engagement, concernant l’implication, ce n’est pas une injonction à laquelle on peut répondre. Vous ne pourrez pas décider de rendre telle ou telle personne motivée. Mais vous pouvez créer un cadre, un contexte, qui permettent à ces personnes d’être motivées, impliquées. On voit régulièrement revenir ce message : une très petite part des employés dans le monde se sentent impliqués.

J’ai l’impression de revenir sur un sujet largement débattu par ailleurs, mais ne trouvant pas chaussure à mon pied sur les différents articles en ligne, je décide de rapidement revenir sur cette question de la cotation, de l’estimation, rapide et visuelle. Au détour d’une de mes interventions, lors de ce qu’appelle désormais le milieu agile un “PI Planning”, j’observe une nouvelle fois un écueil souvent répété : on prend plus de temps à pinailler sur des estimations que de se poser les vraies questions sur ce que l’on doit fabriquer, que de faire du storytelling pour mieux faire comprendre et comprendre son besoin.

Ce texte est la première partie d’une refonte de celui-ci : modernité, agilité, engagé datant de deux années. Je parle de cela à de nombreux auditoires. Mon discours évolue nécessairement. J’ai voulu qu’il reflète plus ce que je dis aujourd’hui. La deuxième partie à venir sera sur l’engagement.[J’ajoute que, oui c’est normal, un paragraphe est en double, et il y a des répétitions, car c’est un texte que je raconte ainsi j’apprécie répéter plusieurs fois la même phrase.

Ci-joint les slides de ma session sur Agile Fluency à Agile France. Dans l’idée c’est 20/25 mn de présentation sur Agile Fluency (je ne pense pas que plus soit nécessaire), et un petit atelier d’appropriation qui se base une idée de Crisp et les pratiques de Spotify.

Merci encore à Claude qui il y a trois ans m’a mis le nez dans ce petit texte (mais qui devient grand) sur une façon de percevoir un cheminement agile.

J’observe un nouvel élan autour de Cynefin, mais toujours pas mal d’incompréhensions ou de difficultés à se l’approprier. Pas si simple, oui, c’est d’abord une façon de comprendre les contextes qui nous entourent pour ensuite en déduire des façons d’agir. Afin d’essayer de rendre cela plus intelligible je le passerai sous le filtre d’une histoire : être parent et utiliser cynefin pour définir des façons d’agir.

D’abord à quoi ça sert ?

Mais d’abord à quoi cela sert ? Cynefin est une matrice, une grille de lecture, qui vous encourage à bien comprendre le contexte dans lequel vous vous trouvez, et en fonction de celui-ci, vous indique comment prendre des décisions et comment agir. Quel style de décisions, quel type d’actions, et pourquoi, et à quel type de résultats s’attendre. C’est donc souvent un outil pour ceux qui prennent des décisions. Comprendre les contextes et les façons d’agir relatives à ces cadres. Cynefin vient du gallois pour dire le lieu, l’endroit ; sous-entendu : comment agir dans ce lieu. On peut imaginer mille déclinaisons de cette “grille de lecture” mais il n’y a pas de “comment” servi clef en main.

L’année dernière avec Dragos nous nous étions lancés dans l’instauration d’un groupe de travail, d’un site (http://agilecfo.fr), d’un séminaire autour de #noestimates, #beyondbudgeting. Définitivement convaincus que la partie budgétaire, intimement liée à la partie “estimation”, était un élément incontournable d’un vrai changement de cap pour une gestion moderne des organisations.

Encore hier j’ai pu noter la décisive différence entre un engagement de moyens plutôt que de résultats dans le bien-être d’une cellule, d’un département agile sous-traité.

À la suite de mes deux articles sur les graphes Kanban expliqués aux enfants, on me demande si je voudrais préciser un peu des choses sur l’utilisation des limites dans Kanban. Impossible de faire un article sur les limites expliquées aux enfants, ceux qui en ont savent. Je vais donc simplement essayer d’expliquer ce que je sais et ce que je comprends des limites dans Kanban. Le spécialiste étant bien évidemment