#kniberg

A bunch of cries for help philosophical reflections with no answers rhetorical questions on METRICS

I have soooo many questions:

*Why do managers are so obsessed with tracking someone's busyness?

Why do they pray for Velocity like.. it's a #1 metric (and the only one) for any agile project? Like.. seriously? Who told u that?

They are initially unreliable, measuring the basic team's activities, might be useful only for internal forecasting (MIGHT, but definitely not SHOULD)... they are so easily adjustable - like, "we've doubled our velocity by increasing our estimation grade".. and still Managers don't get it and even keep on comparing teams, based on their velocity (cause it's so convenient), extracting personal velocity (my favorite!), building forecasts and unrealistic expectations (cause it's so silly to expect no changes on initially unpredictable environment and tell everyone, that u're "agile") Gosh

*Why do managers pay so much attention to the outputs, but never try measuring actual outcomes, the real value?

I have a story about that. I was on a project, where main measure of success for my teams was.. Predictability rate (Planned vs. Delivered) Every quarter I was providing my PM with results of my 3 teams. Team A reached 3 out of 4, Team B had 4 out of 5 and Team C completed just 1 out of 5... and my Manager called me out and requested a detailed list of reasonings on why is my Team C so low-performing? I was accused of the Team C spoiling the overall score in the domain for up to 20%... and the thing is - they weren't The thing is - all 3 month Team C was involved into the post-release troubleshooting and had spent 76% of their capacity on fixing critical issues. And thanks to my own system of measuring - I had numbers to prove the Teams' actual value. Yes, they didn't manage to deliver all expected features, but on the other hand - they kept production line stable. What's more important after giant release?

Have I tried to initiate any changes on that? Surely. Did it succeed? Partially. On Domain level - yes, on Company level - no

So, let's get back to the question. Why do managers prefer staying stubborn and seek outputs instead of bringing effort to check qualitative insights, process flow and customer value?.. Like being busy is good, but being productive is much better, isn't it?

Yes,

It takes time

It requires deeper involvement and collaboration in the company

It requires motivation and proper leadership

It requires consistency and shared understanding

But there are sooooo many cool things u can do when u're facing the right direction:

Lean Flow metrics (high five, Kanban!) with a wide range of its variabilities, based on Throughput, WIP, Cycle & Lead time

Quality metrics, like Test Automation coverage, Defects Cycle time, Mean time to recover, Deployment Frequency

Value-oriented metrics, like Customer Satisfaction Gap, Usage Index, Potential Market Share

Ability to Innovate metrics, like Technical Debt, Time spent merging code between branches, Innovation Rate

Team health & Culture metrics, like Kniberg's health checks or eNPS

There's whole list of awesome frameworks and multi-level approaches created already, like DORA, SPACE or Evidence-Based Management (my favorite).. then, why not to use them?

Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.

Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.

Optimiser l’utilisation des ressources

Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances...

Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !

Et Scrum, dans tout ça ?

J’ai déjà longuement parlé de Scrum dans ce blog. Il se séfinit par quelques règles simples. Et aussi du Shu Ha Ri qu’évoque également Kniberg. Hélas, de nombreuses organisations sont « bloquées dans le Shu » !

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

Quand le code est commité ?

Quand le produit est testé ?

Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Parlons tests

A un moment donné il faut bien parler tests. Mais de quel tests ? Petite leçon de vocabulaire de la part d’Henrik, et aussi de la nécessité des tests exploratoires… et d’inclure la dette technique dans la notion de qualité.

Kniberg nous propose aussi de maintenir un « tests automation backlog », et aussi un « tech backlog » qui s’injecte dans les sprints en fonction d’une bande passante réservée.

Pendant ce temps, chez Spotify...

Kniberg est aussi connu pour avoir popularisé le mode de fonctionnement chez Spotify. Je ne vais pas revenir dessus, cela a été largement exposé. La culture Spotify amène par ailleurs à privilégier le « failure recovery » au « failure avoidance », selon une approche que l’auteur appelle le « limited blast radius ».

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Chap 4 : « non, merci »

Nous avons du mal à dire « non ». En tout cas, moi j’ai cette difficulté. Quand, comment et pourquoi dire « non », afin de se focaliser sur ce qui a vraiment de la valeur, c’est le sujet de cette partie. C’est ce que Henrik Kniberg appelle le « value filter ».

Changement de décors pour cette nouvelle présentation de Henrik Kniber : comment mettre en oeuvre les pratiques agile et Lean à la maison avec 4 enfants !

Kanban

D’abord le Kanban. Il y en a un peu partut chez les Kniberg ! Un Kanban commun pour les tâches partagées, sur le réfrigérateur pour les enfants ou encore pour préparer un barbequeue entre amis. La famille Kniberg est partie durant 8 mois pour un « familly trip » autour du monde. Il y a eu un Kanban pour préparer cela aussi. Cela comprenait d’ailleurs une expérimentation du concept, avec un séjour de 4 jours à Londres.

WIP limite

Un problème récurrent avec les enfants : le bordel dans la chambre ! Un problème qui ne s’est pas posé durant leur voyage, car la quantité d’affaires à transporter était limitée. Alors on utilise le même système : on limite le nombre de vêtements à ce que peuvent contenir les tiroirs ! Un système qui s’étend ensuite à la cuisine, pour le lavage de la vaisselle, avec une pincée de « definition of done ».

Burnup chart

Junior a du mal a être dans les clous avec ses devoirs ? Son coach de père lui met au point un burnup chart a suivre lui-même au fur et à mesure qu’il fait ses devoirs.

Autres management visuel

Cartes, « dream gallery », Kaizen boards, Henrik Kniberg n’hésites pas non plus à utiliser tout l’arsenal de management visuel à sa disposition.

Et d’abord, c’est quoi Scrum ?

Oui, je sais, on peut faire référence au Scrum Guide et à toute ces sortes de choses, mais pour Henrik Kniberg, ce sont :

De petits morceaux de fonctionnalités

Des équipes subdivisées en petites équipes

De petites tranches de temps.

Une valeur métier optimisée

Avec un processus optimisé !

Et c’est tout !

Pourtant, visiblement, tout ça peut mal se passer. Voyons comment et comment y remédier. Avec 5 cas de figure.

Mal utiliser le processus

S’en prendre à Scrum alors qu’il faudrait plutôt penser à notre façon de l’utiliser est le premier symptôme. Le grand classique est le temps consacré aux cérémonies : s’il est exagérément long, il s’agit simplement d’un avertissement, nous essayons de pratiquer Scrum comme une méthode classique !

Bootstraper un déploiement continu sur le cloud avec CloudBees

En 25 minutes, Henrik Kniberg nous fait la démonstration depuis zero de la création d’une petite webapp type « hello world » sous Eclipse, avec son test local avec Jetty et ses tests unitaires, vers la mise sous Git dans CloudBees, l’intégration dans Jenkins et le déploiement dans un sandbox, toujours sur CloudBees. Partant de là, on complexifie l’application en y intégrant une persistance avec MongoDB sur la base des services accessible depuis la plateforme SaaS !