Confondre vitesse et précipitation

« L’équipe est à combien de vélocité ? »
« Pourquoi vous faites pas monter votre vélocité ? »
« Pour qu’on soit dans les temps, je vous demande de multiplier par 2 votre vélocité »

Ces quelques exemples reéls montrent qu’il arrive souvent que la vélocité soit prise par les personnes extérieures aux équipes Scrum, mais parfois aussi par le Product Owner ou le Scrum Master, comme une mesure de productivité d’une équipe.

Déjà. De quoi parle-t-on.

Définissons la vélocité d’une équipe. Il faut savoir qu’il n’est nullement question de vélocité dans le Scrum Guide. C’est un outil qui s’est constitué pour les équipes afin de prévoir (et non pas prédire) la quantité de d’elements qu’une équipe est capable de délivrer pour la prochaine itération. Elle se calcule en faisant la somme des points de complexité des éléments TERMINES durant la précédente itération. On peut lisser cette vélocité en prenant les valeurs des 3 derniers sprints pour obtenir une valeur plus stable. Cette valeur aide l’équipe à définir le contenu d’un sprint « à peu près ». Et c’est suffisant en terme de planification.

Définissons aussi ce que l’on appelle la productivité.
Si je m’en réfère à wikipedia : la productivité du travail est définie comme la production (quantité de biens ou de services produits) obtenue pour chaque unité du facteur de production (comprendre ressource) « travail » utilisé.
Dans le cas d’une équipe Scrum, la quantité de biens produits pourrait être le nombre de User Stories produites, ou la somme des points de complexité des user stories produites, ou le nombre de ligne de codes pour réaliser les user stories produites et l’unité du facteur de production utilisé pourrait être une équipe Scrum durant une itération.

La productivité d’une équipe serait donc le nombre de User Stories produites durant une itération, ce serait la vélocité de l’équipe ?

Non.

Et n’est pas non plus une mesure de la vitesse à laquelle une équipe ponds des stories.

La vélocité, une mesure quand même ?

On va se le redire tout de suite : oui c’est une mesure, nous l’avons vu plus haut. Non ça ne mesure pas la productivité d’une équipe.

Soyons honnête : on parle de métiers intellectuels, de recherche de solution à des problèmes pas d’une usine d’assemblage de pièces, toutes identiques les unes les autres. Ce n’est pas possible de calculer une productivité qui veuille dire quelquechose.
Un logiciel informatique est un ensemble de composants tous différents, du code spécifique à chaque problème à résoudre. Il n’est donc pas possible de dire « aujourd’hui j’ai fait 10 lignes de code, demain je dois faire pareil » ou « ma productivité est de 1 story par semaine ». NON.

La vélocité est un outil de planification, pas une mesure de productivité et de contrôle.

Elle sert à une équipe à jauger de sa capacité à pouvoir terminer des choses dans un temps donné. Point.
Cette mesure est dépendante de chaque équipe, de chaque produit et du niveau de collaboration entre tout les membre de l’équipe. A la poubelle les modèles, abaques, comparaison de vélocité entre équipe.

J’aime bien utiliser la comparaison avec tetris : L’objectif d’une itération pourrait correspondre à compléter 4 lignes de tetris. Pour faire ces 4 lignes, l’équipe définit la taille des blocs que lui présente le Product Owner puis les pose 1 à 1. Lorsque l’équipe pense avoir rempli les 4 lignes, l’équipe s’arrête de remplir : objectif atteint !

Lors des premières itérations, l’équipe se rendra compte qu’elle ne sait pas remplir 4 lignes mais 3.5 ou au contraire est capable de remplir 5 lignes. C’est cette mesure de la somme des tailles de blocs que l’équipe est capable de réaliser au cours d’une itération qui corresponds à sa vélocité.

Et elle n’est pas fixe. Parfois on se rate est on fait moins de blocs, parfois l’équipe atteint un niveau de collaboration idéal et en état de Flow, elle remplit 6 ou 7 lignes : c’est une estimation qui permet de se fixer un objectif atteignable et potentiellement reproductible.

Ce qui marche avec des blocs de tetris marche aussi avec le développement logiciel : on cherche à estimer ce que l’on est capable de faire et non à chiffrer dans le détail. Pas la peine de passer 2 jours à chiffrer le moindre traitement : le niveau de précision de ce que l’on sera capable de faire ne sera pas meilleure que de passer 2 heures à définir cette capacité en story points, en taille de t-shirt ou en patates.

La mesure d’avancement doit être un logiciel qui fonctionne, pas le nombre d’heure qu’un dev passe à coder un algo python.

Okay et on fait quoi alors si je veux utiliser la vélocité autrement ?

Déjà se creuser la tête pour identifier ce que l’on souhaite réellement : planifier ? organiser le travail ? Communiquer ? Selon l’objectif visé, la stratégie pour l’atteindre sera différent.

Si on s’en tient à l’usage correct de la vélocité : utilisez cette mesure pour identifier un problème dans l’équipe, pour jauger de la capacité de l’équipe, pour estimer l’atterrissage dans le temps d’une version de logiciel.
Et cela ne marche qu’avec une équipe stable et des éléments à réaliser de taille comparable, livrés régulièrement. Il faut donc être TRES prudent lorsque l’on utilise cette mesure.

Et si vous voulez faire autre chose avec la vélocité, de toute évidence ce n’est pas bon signe. Interrogez-vous. Quel est votre intention en manipulant ainsi la vélocité ? N’êtes-vous pas en train, doucement, de glisser vers un bon vieux système command & control ? Et si vous exprimiez votre inquiétude à cette équipe pour travailler ensemble à trouver la meilleure solution ?

Et si vous abandonniez carrément l’usage de la vélocité et testiez l’usage du #noEstimates ?



 

Rétrospective 2018

Il s’agit ci-dessous de mes réflexions sur l’année professionnelle 2018 compte tenue de ma tendance à oublier des éléments qui parfois peuvent être importants 😀

2018 aura été une année multiple. Éprouvante, enrichissante, inattendue.

J’ai passé cette année à faire quasi exclusivement des choses que je n’avais jamais faites. Et je vous assure que passer une année entière en dehors de sa zone de confort c’est éprouvant.

Dans les grandes lignes et sans ordre d’importance, je suis passé de Shu à Ri (j’y suis pas totalement) sur Scrum, appréhender le rôle de manager dans un environnement complexe, donner l’exemple d’un autre modèle de management auquel je crois, j’ai coconstruit et animé une communauté nationale de pratique Agilité, recruté des agilistes convaincus et qui me poussent à ne pas me contenter du simple nécessaire, j’ai vécu des départs déchirants, des projets agiles catastrophiques, j’ai vu des équipes merveilleuses, soudées et motivées, j’ai eu des jours où je me suis dit que la vie est géniale et d’autres où j’ai eu envie de tout lâcher (parfois dans la même journée), j’ai partagé des émotions intenses.

Objectifs 2018 ?

Dans la lignée de mes objectifs annuels précédents, aucun des objectifs que je m’étais fixé début 2018 n’a été atteint.
A vrai dire, c’est en rédigeant cette rétrospective que je me suis rappelé en avoir définis plusieurs. J’ai du cherché où je les avait noté. On peut dire que je ne risquais pas de les atteindre

J’en avais d’autres cependant. Eux n’étaient pas écrits mais étaient dans ma tête. Ceux-ci sont ambitieux :

  • Faire naitre une vraie agilité chez Open
  • Aider à changer la culture de l’entreprise par le partage et la transmission de nos connaissances et nos passions
  • Rassembler autour de la première des valeurs qui comptent : l’humain.

Nous n’avons qu’une seule vie, faisons en sorte de faire les bonnes choses de toutes ces journées.

Mes réussites cette année

  • Avoir repris le rôle de leader de la communauté de practice Agilité et faire en sorte qu’elle avance. Pas à pas.
  • Avoir aidé à changer des pratiques du recrutement
  • Appliquer des pratiques du management 3.0
  • Accompagner des équipes Scrum vers le succès

Mes échecs / mes apprentissages

  • Équilibre vie pro/vie perso. Ce fut une catastrophe cette année. Par passion certes mais la passion ne fait pas tout. J’avais de grosses ambitions cette année et j’avais envie que tout avance de front. Globalement ce fut un succès du point de vue pro mais j’ai été un fantôme pour ma famille. Lorsque l’on parle d’agilité, on parle souvent de focus sur la valeur que l’on apporte au temps que l’on donne, j’ai oublié une part importante cette année et on me l’a rappelé fortement en fin d’année. Le travail peut attendre, pas la famille ni les amis.
  • On ne peut pas forcer les gens à changer. 2018 a été une année où j’ai beaucoup animé de formations à l’agilité. Expliquer le manifeste, les valeurs, les principes, Scrum, Kanban, l’état d’esprit avant tout autre chose.
    J’avais dans l’idée (naïve) que l’on comprendrait qu’il s’agit d’un changement attitude, d’un moyen pour mieux travailler, mieux collaborer, mieux communiquer.
    J’ai constaté que pour beaucoup, l’agilité est surtout un élément pour sortir du lot, pour être mieux payé, trouver un autre job ou faire du business.
    J’ai constaté aussi que les personnes qui sont rééllement interressées n’ont pas besoin qu’on les force. Ces personnes viennent d’elles-même poser des questions sur des problèmes qu’elles rencontrent pour trouver comment faire autrement.
    Si on veut faire progresser l’agilité dans une organisation, il faut inviter les personnes qui en ont envie : on ne peut pas forcer les gens à changer.
  • La gestion de mes émotions et de mes besoins. S’il y a bien un espace où j’ai pris une claque c’est bien celui-là. Jusqu’à cette année j’ai vécu en control freak de mes émotions par peur de ne pas savoir les maitriser. Finalement cela m’handicapait plus que cela ne me sauvait car j’étais en grande difficulté à identifier ce que je voulais et à l’exprimer. Plusieurs personnes avec qui j’ai travaillé cette année m’ont aidé à lâcher, à écouter et comprendre mes émotions et donc mes besoins. De façon empirique ou de manière méthodique par la CNV par exemple. Je suis loin de me connaitre réellement mais au moins maintenant j’en ai conscience. Merci à eux <3

Et 2019 ?

Je reboucle sur le début de cet article : j’oublie mes objectifs que je me fixe en début d’année. L’un des principes qu’il faut s’appliquer à soi c’est d’accepter de ne pas être parfait, d’avoir raté quelque chose et de reprendre là où on s’est arrêter.
Pour qu’un objectif tienne il faut qu’il soit grand, ambitieux, qui donne envie de le suivre mais il doit aussi s’adapter avec le temps car on ne sait pas prévoir ce qui va se passer dans les prochaines semaines/mois.
Et c’est une de mes managés qui a trouvé ce qu’il me fallait, une pratique qu’elle utilise depuis des années : les OKR (Objectif Key Result) accompagnés d’une démarche agile : inspection et adaptation :

Plutôt que de définir des résolutions qu’on ne respectera pas, définissons 1 grand objectif pour le prochain trimestre et 3 résultats clés mesurés que l’on attends par cet objectif. Et ENSUITE définissons semaine après semaine les actions qui nous permettent d’atteindre cet objectif.

Rendez-vous fin 2019 pour le debrief 🙂

 

On mange quoi ce soir ?

Je me souviens il y a quelques années, lorsque je rentrais chez moi après une journée bien remplie se posait la question du dîner. Globalement soit ma femme, qui adore cuisiner, prenait ce qui se trouvait dans le frigo et confectionnait un plat toujours délicieux. Pour moi qui ne sais absolument pas cuisiner c’est comme un tour de magie.

on mange quoi ?

Puis nous avons eu des enfants. 2. Et lorsque l’on a des enfants, on n’a clairement moins de temps pour tout ce qu’on faisait avant.

Pas le temps de se poser, pas le temps de réfléchir à ce qu’on mange et pas trop de temps pour cuisiner non plus.

Bref, la question systématique de fin de journée c’est : « On mange quoi ce soir ? » (multiplier par le nombre d’individu présents sur place). Et apparemment nous ne sommes pas seuls ^^

Quand on y pense, cette question banale peut trouver une réponse simple en recherchant ce qu’on a mangé

  • hier,
  • avant-hier,
  • la semaine dernière,
  • le moi dernier, etc…

et récupérer ces idées pour les réutiliser ce soir.

Le problème c’est que nous avons une mémoire légèrement meilleure qu’un poisson rouge et donc se rappeler ce qu’on a mangé le mois dernier n’est pas si simple. Et si on notait tout ça ? Juste les noms des recettes. On pioche au hasard parmi la liste, ensuite on se débrouille pour retrouver la recette sur le net, ça c’est facile.

D’où la création, pour moi et ma femme au moins, de ce service que j’ai mis au point qui s’appelle « On Mange quoi ? »

On mange quoi ce soir

Rien de très compliqué ici :

  • On peut ajouter des idées de repas (entrée, plat, dessert) selon la saison,
  • Au hasard, mais de saison, le service propose une des idées qu’il a en stock,
  • Un clic à l’écran = une nouvelle proposition d’idée.

Avec ça, en 5 minutes on sait ce qu’on mange ce soir. Reste plus qu’à cuisiner 🙂

(Et puis j’en ai fait une appli android mais ça on en parlera plus tard 🙂 )


 

Crédit photo : Floris van Halm

 

Warm up

S’exprimer ? Ne pas s’exprimer ?

… S’exprimer.

Ici est donc mon espace d’expression qui complète mon (mes?) compte Twitter.

Je le vois comme un endroit pour poser mes questions, réflexions, résultats sur les sujets qui me tiennent à cœur.

  • Le web, tout ce qui touche aux systèmes d’informations et le secteur public.
  • L’entreprise et le milieu professionnel (cet univers impitoya-a-ble)
  • Mes projets personnels

Tout ça s’ajoutera petit à petit ^^