Regard Lean sur la productivité des équipes de développement logiciel

Le sujet de la mesure de la productivité des équipes de développement logiciel réapparaît fréquemment dans les conversations sur l'agilité, ces derniers temps en particulier autour d'un article de McKinsey. Aussi ai-je décidé de vous proposer ce regard sur le sujet.

Cette réflexion est en partie tirée d'un article beaucoup plus large traitant de l'agilité à l'échelle. Un peu noyée dans le reste de l'article, il m'a semblé approprié de l'extraire pour rappeler la perspective Lean sur le sujet. Par « Lean » nous entendons la version originelle de Toyota (le Toyota Production System) et l’amélioration continue par le Kaizen (i.e. la résolution de problèmes par chacun, chaque jour).

La question est donc : comment mesurer la productivité d'une équipe ou d'un programme agile ? Comment articuler cette productivité avec la valeur business (ou valeur d'usage) de la solution mise à la disposition des utilisateurs ? Et, question la plus importante, souvent ignorée dans ces échanges : comment utiliser cet indicateur de productivité pour piloter l'amélioration et le développement de compétences des collaborateurs ?

[Mille mercis à Laurent Barbier et Thomas Luquet pour leurs nombreux commentaires et questions qui ont rendu cet article plus clair et plus équilibré].

1. Productivité : définition dans le contexte du logiciel

Comme bien souvent dans ces échanges interminables, je me rends compte que l'on ne commence pas par définir précisément le terme clef : ici productivité. Il en est de même lorsque l'on parle de « culture» , « d'innovation » , de « bienveillance » ou encore de « résolution de problème ». Ce que j'invite donc à faire est de s'accorder sur cette définition.

L'INSEE définit ainsi la productivité : « le rapport, en volume, entre une production et les ressources mises en œuvre pour l'obtenir. » On retrouve donc plusieurs notions : production ; ressources utilisées, et donc unité de temps : dans le monde du logiciel les collaborateurs étant les contributeurs principaux, leur temps passé représente une ressource essentielle des projets [Note : c’est le temps passé qui représente une ressource, pas le collaborateur].

Dans le Lean la définition de la productivité est la suivante :

Le nombre de pièces bonnes que l’équipe a livrées au client / par personne / par unité de temps

Par exemple, dans une équipe de Support IT [nous passerons au logiciel juste après] de 6 personnes qui résout en moyenne 12 incidents par jour, alors la productivité est de 2 tickets par personne par jour (12 / 6).

Plusieurs points essentiels dans cette définition :

1. On suit la productivité de l'équipe, on ne suit pas la productivité de l'individu, car on veut créer les conditions de la collaboration et on ne souhaite pas passer du côté obscur du productivisme. Suivre les lignes de codes rédigées par un développeur donné s'inscrit directement dans cette pente glissante que nous souhaitons épargner aux équipes ;

2. On relie directement l'indicateur de performance (ici productivité) au client (l’utilisateur). S'il n'y a pas ce lien, alors il y a un risque avéré de désalignement entre, d'une part, les activités menées par l'équipe de développement et, d'autre part, ce qu'attend le client. Suivre la vélocité de l'équipe (le nombre de Story Points livrés par sprint - évoquée par l'article) est inapproprié : cette unité ne représente pas de valeur directe pour le client. En suivant ce type d'indicateurs, on crée une rupture opérationnelle entre l'équipe et le client et on induit des comportements contre-productifs d'optimisation locale pour une diminution de l'optimum global (voir un exemple ici).

3. De plus, notez ici que quand on parle de productivité et bien, errmm … comment dire, on parle juste de la productivité. Nous ne mélangeons pas tout (comme dans cet article suscité), et ne parlons pas de qualité, de délai, de satisfaction client ou de satisfaction collaborateurs, qui sont des indicateurs de performance opérationnelle. La productivité en fait partie mais le sujet ici est circonscrit à ce seul indicateur.

4. Mesure : Dernière chose et non des moindres : la productivité se mesure. On ne peut pas utiliser des procédures déclaratives telles que le Developer Veolicity Index (DVI) proposé dans l'article de McKinsey pour évaluer la productivité d'une équipe de développement logiciel. Inférer que parce que le développeur utilise telle méthode ou tel outil alors sa productivité sera bonne, c'est un peu comme imaginer que quelqu'un qui suit le même protocole d'entrainement qu'Usain Bolt court le 100m en moins de 10 secondes. Ce n’est pas là une approche rigoureuse - et cela me semble étrange d'avoir à le rappeler - mais la seule chose qui peut nous confirmer l'atteinte de cette performance reste la mesure : en l'occurence, le chronomètre.

Quelle est la « pièce » ?

Le point clef, et probablement l'étape méthodologique la plus fine, est de définir « la pièce », i.e. l'unité d'oeuvre qui représente de la valeur et qui est livrée par l'équipe au bon niveau de qualité au client.

Dans certains contextes cela peut s'avérer problématique : l’exigence fonctionnelle, la fonctionnalité, la demande d’évolution. Le problème étant que ces unités d’oeuvre ont une granularité très variable et peuvent être assez grosses en termes de charge. Pour un processus Lean plus fluide, nous avons besoin d’une unité d’oeuvre plus granulaire qui intègre de la valeur pour le client.

Dans le cas d'une équipe agile, le corpus de l'agilité nous fournit un outil particulièrement adapté pour suivre cette productivité ...

Love (User) Story

La User Story présente cette caractéristique qui la rend si précieuse : elle est organisée autour de la perspective et de la valeur client.

Comme l’explique Mike Cohn dans User Stories Applied, les fonctionnalités que nous avions dans nos spécifications de systèmes d’information du XXème siècle décrivaient le système depuis sa propre perspective, en tant que capabilité : le système sera capable de faire ceci (proposer des billets de train à une date donnée) et de faire cela (le paiement en ligne). Il s’agit d’une vision depuis le système vers l’utilisateur.

La User Story définit la fonctionnalité depuis la perspective de l’utilisateur en rendant tangible la valeur qu’il en retire à travers un cas d'utilisation simple, court et spécifique :

“En tant que voyageur, je peux réserver mon billet de train en deux minutes sur mon mobile afin d’ éviter de perdre deux heures en allant à la gare.”

Cette perspective permet de limiter un des plus gros gaspillages de l’industrie des services numériques (la surproduction – les fonctionnalités non utilisées par les utilisateurs) et de concentrer ses efforts sur l’impact apporté à l’utilisateur par le cas d’usage.

US en Production

Aussi, pour suivre la productivité de l'équipe agile, nous (coachs Lean) préconisons donc de suivre le nombre de User Stories livrées en production par l'équipe par sprint. Notez que l'on regarde ce qui est livré au client, donc en production. [Dans le cas d'une équipe qui livre en production tous les deux ou trois mois, on pourra utiliser la pré-production afin d'isoler l'équipe des contraintes de l'entreprise].

On pourra me rétorquer que les US ne sont pas de la même taille (complexité) et qu'on ne compare pas la même chose. Objection rejetée par le Lean puisque l'on regarde cette unité d’oeuvre depuis le point de vue du client : un cas d'utilisation est un cas d'utilisation. Par ailleurs, alors que l'équipe gagne en maturité agile, elle converge normalement vers des US plus petites, de tailles équivalentes. [Pour l'objection liée à la valeur pour le client, voir plus bas] .

Scaler la User Story

En prolongeant cette réflexion, on peut extrapoler que, de la même manière que la User Story est l’unité d’oeuvre à la main d’une équipe pour créer de la valeur, l_'Epic_ (ensemble de User Stories apportant une fonctionnalité complète au client) est l’unité d’oeuvre qui permet de mesurer la valeur produite par un ensemble cohérent d'équipes agiles (exemple : un Release Train dans SAFe). Et les Initiatives (ensemble d'Epic composant un processus entier) représentent la valeur livrée par un programme Agile composé de plusieurs ensemble cohérents d'équipes agile (e.g. un programme SAFe composé de plusieurs Release Trains).

Se basant sur ces unités de valeur (US, Epic, Initiatives) nous pouvons commencer à construire une vision de la productivité, et de son pilotage, dans les équipes, dans les ensembles d'équipes, et dans les programmes agiles : nombre d’US livrées en production par une équipe par sprint ; nombre d’Epics livrées en production par un train par trimestre ; nombre d’initiatives livrées en production par un programme par an.

La proposition Lean est que le pilotage de la productivité va se concentrer autour des ces unités d'oeuvre qui sont le produit du processus de Delivery et des éléments de valeurs opérationnelles (i.e produites par les équipes opérationnelles) indépendamment de leur valeur business.

2. Discovery et Delivery

L'objection fréquemment présentée à cette notion de pilotage par la valeur opérationnelle est que toutes les US, Features et EPIC ne représentent pas la même valeur business, et que ce n’est pas si simple que de compter ces unités d’œuvre pour évaluer la valeur livrée.

Il s’agit d’une objection en partie valide. Le point d’achoppement est que nous mélangeons alors le pilotage de deux processus distincts : le Discovery et le Delivery.

Deux processus imbriqués

Le Discovery est le processus amont qui consiste à identifier un problème client, à le cadrer fonctionnellement et à faire des hypothèses sur une solution qui permettrait de le traiter et, ainsi, de créer de la valeur. Il s’agit d’un processus qui aide à comprendre le marché et la demande client, un processus d'innovation : l’introduction d’une nouveauté dans un groupe social, selon la définition de Schumpeter.

Le Delivery est le processus de transformation de cette idée en solution logicielle mise à la disposition de l’utilisateur. Même si la dimension de conception et d'architecture technique peut s'avérer importante, il s’agit davantage d’un processus de production, avec des étapes clairement identifiées structurées autour des différentes unités d’oeuvre (US / Epic, etc …). La complexité vient du fait que le Delivery est imbriqué à l’intérieur du processus de Discovery qui débute avant (le processus de réflexion amont) et qui se termine après (l’étude de l'impact marché et la mesure des résultats de la solution livrée).

Séparer les deux pilotages pour mieux les traiter

L'idée principale proposée ici est que mélanger les deux sujets, à savoir le pilotage du  processus de Delivery (valeur opérationnelle) et le pilotage du processus de Discovery (valeur business), est le meilleur moyen de n’en traiter aucun correctement.

Une divergence de point de vue avec Martin Fowler dans son article Cannot Measure Productivity de 2003

I might argue that a successful project is one that delivers more business value than the cost of the project. So if Joe and I run five projects each, and I succeed on four and Joe on one - do I finally do a better job than Joe? Not necessarily. If my four successes yield $1 million profit each, but Joe's one success yields $10 million more than the cost of all his projects combined - then he's the one who should get the promotion.

Cet argument 1/ n'est valide que si Joe et Martin peuvent choisir le projet sur lequel ils travaillent et 2/ les rend complètement dépendant du travail d'analyse fait en amont par l'équipe marketing et en aval par les opérations (quid si des problèmes de production empêchent la solution développée par Martin d'atteindre l'ensemble de son marché ?) : ils n'ont plus la main sur leur performance et on leur a retiré une partie de leur capacité d'agir sur leurs indicateurs, ce que nous souhaitons absolument éviter avec le Lean. Enfin on retrouve ici le spectre du management par objectifs personnels, et on sait depuis Deming combien cette héritage de Drucker est pernicieux et impacte négativement la dynamique de collaboration.

À la main du Delivery

De la même manière qu’il n’est pas de la responsabilité du PO de s’assurer que les tests unitaires passent sur leq système d’intégration et de déploiement continu (CI/CD) ou que l’on a les bons jeux de tests sur cette chaîne, on ne peut pas responsabiliser l’équipe de Delivery sur les Outcomes de ce qui est livré.

Cela ne veut pas dire qu’elle n’est pas concernée par le sujet : faire accompagner un UX Designer lors des visites utilisateurs par des développeurs, dans le but que ces derniers développent aussi une connaissance plus profonde du métier, est ainsi une excellente initiative. En outre, l’équipe a aussi son mot à dire pour aider à la prise de décision sur la priorisation des différents sujets en fonction d’éventuels points d’architecture ou de tactique de livraison.

Mais les unités de valeur sur lesquelles l’équipe de Delivery a la main (et dont elle se doit d’améliorer le réalisation en permanence) ce sont ces unités de valeur opérationnelle (US, EPIC, Initiatives), pas le business plan, et il ne faut pas mélanger les deux sujets car cela ne peut que la ralentir.

À la main du Discovery

Le pilotage de la valeur business quant à lui relève des rôles qui sont orientés produit (Product Owner, Product Manager, Head of Product, Global Process Owners), qui doivent piloter les Outcomes (éléments de valeur business) en considérant chaque Epic comme un mini business plan, en faisant des hypothèses de résultats attendus et en mesurant les résultats obtenus pour valider - ou invalider - leurs hypothèses business initiales. C'est dans l'exploration de ces écarts que gît l'apprentissage - ici la découverte du marché.

Cela nécessite que le logiciel soit en production pour ensuite faire les mesures et études adéquates. Par exemple : amélioration de la satisfaction utilisateur de tant de points ; réduction du taux d’attrition ou du taux de rebonds d'un tel pourcentage ; augmentation de la part de marché de tant de points ; augmentation du nombre de nouveaux inscrits au service de tel nombre, réduction du nombre de demandes support ; augmentation du CA etc. You name it ...

Des indicateurs de différentes natures

Ce ne sont pas seulement des processus distincts : ce sont aussi des processus de natures différentes qui sont pilotés par des indicateurs de nature différentes.

Dans le processus de Delivery (production des US et EPIC), les indicateurs relèvent de la valeur opérationnelle et sont des _Leading Indicator_s (indicateurs pare-brise, du futur proche) : on peut s'organiser pour piloter de façon volontariste cette valeur opérationnelle.

Par exemple, si dans un sprint de 10 jours l’équipe a prévu de livrer 10 US, alors il faut chaque jour sortir une US. La question du Scrum Master le matin sera alors d'une simplicité biblique : quelle est la User Story que l'on sort aujourd'hui ? Comment nous organisons nous pour y parvenir ? Qu'est-ce qui pourrait nous en empêcher ?

Et dans un groupe de 10 équipes agiles qui doivent sortir 26 Epics sur un trimestre (13 semaines) on se posera collectivement la question : quels sont les deux Epics que nous allons livrer cette semaine ? Cela va tirer de nombreuses questions liées aux dépendances, à l’intégration, à la réduction du WiP Epic et à une meilleure synchronisation qui vont permettre de tirer l’ensemble de ce dispositif vers le haut. Cela va surtout permettre de simplifier le champs d'attention des équipes et de les aligner sur des objectifs clairs et à leurs mains.

En revanche, dans le processus de Discovery (analyse business et fonctionnelle), les indicateurs relèvent de la valeur business et sont des Lagging Indicators (indicateurs rétroviseurs) que l'on mesure a posteriori. Notons que c'est bien là que réside la valeur business : dans la mesure et l‘étude, une fois le logiciel mis en production. L'intégration d'un panel client dans les phases amont peut permettre de dé-risquer plus facilement des sujets mais n'affranchit pas les équipes business de mener ces mesures en production.

3. Accélérer le Delivery pour améliorer le Discovery

Le juge de paix reste bien évidemment la valeur business produite : il ne sert à rien de livrer davantage de valeur opérationnelle (Epic et US) si on constate que la valeur business attendue n’est pas au rendez-vous. Mais il s’agit d’une réflexion sur le processus de Discovery, qui est d’une autre nature (innovation) et qui n’empêche évidemment pas d’avancer sur l’amélioration du Delivery (production).

Dans le State of DevOps report de 2014, Jez Humble et al. rappellent ainsi que “les entreprises avec des organisations IT performantes ont statistiquement deux fois plus de chance de dépasser leurs objectifs de profitabilité et de part de marché”.

Améliorer la performance opérationnelle (qualité, délais, coûts, satisfaction client), de notre programme agile (SAFe ou pas) en termes de Delivery représente un atout incontestable pour améliorer la valeur business : plus on livre des Epics (qui sont des hypothèses business) rapidement en production plus on peut en tester la validité, en mesurer le résultat et construire une compréhension vision plus fine de notre marché. Comme l’explique Marc-Antoine Lacroix, le CTO de la FinTech Qonto : Shipping Fast is our Product Strategy. Là encore, l'amélioration de la performance opérationnelle (en ce cas, la réduction drastique du Lead Time de delivery des features) est un élément nécessaire pour aider la recherche de performance business.

Cela ne veut pas non plus dire que le modèle préconisé est celui de « l’usine à fonctionnalités ». Toujours chez Qonto, leur stratégie est de réduire l’en-cours des fonctionnalités livrées (pour en accélérer la livraison) ce qui veut dire que leur processus de Discovery est particulièrement exigeant et que ce qui entre en Delivery a été suffisamment challengé et cadré pour limiter le risque de livrer des fonctionnalités sans réelle valeur pour le client.

S'affranchir du spectre du productivisme

Il reste toutefois une question clef : comment nous prémunir du productivisme (focus exclusif sur la productivité) dès lors que l'on suit la productivité d'équipes de développement logiciel ? Un sujet brûlant dans le cadre du Lean que ce système de management a parfaitement intégré. Je rencontre souvent des coachs agiles qui ont besoin d'être rassurés sur ce sujet des indicateurs, en particulier ceux liés à la productivité.

Il y a plusieurs réponses à cela. La première, déjà évoquée, est que nous ne suivons pas la productivité personnelle. Une seconde que nous aimons mettre en œuvre dans les projets Lean est de suivre en parallèle la satisfaction des collaborateurs. Aussi, nous identifions les indicateurs de performance opérationnelle à l'aune desquels nous allons suivre l'efficacité des équipes (productivité, qualité, délai, satisfaction client) mais aussi des indicateurs de satisfaction collaborateurs. Le suivi en simultané de cet ensemble d'indicateurs permet de conserver une tension systémique et d'éviter de déséquilibrer le système dans un sens ou dans un autre.

Les impeccables Théodore Broche et Nicolas Ploquin préparent ainsi une série d'articles pour montrer la corrélation positive entre l'amélioration de la productivité grâce au Lean et celle de la satisfaction des collaborateurs (hint : élimination des gaspillages et développement de leur capacité d'agir).

Amélioration continue et manager Coach

Le second levier est celui du management et de l'animation. Le fait de ne pas atteindre un objectif est un « problème » dans la définition stricte du Lean : un écart de performance entre ce qu'attend le client et ce qu'on a livré. Lorsqu'on n'atteint pas l'objectif on peut alors creuser les causes et le manager peut alors jouer pleinement son rôle de coach dans la démarche d'amélioration continue.

Exemple : l'équipe devait livrer 10 US elle n'en a livré que 8 : que s'est-il passé sur les 2 US qui ne sont pas sorties ? A quelle étape du processus a-t-on rencontré des obstacles ? Conception fonctionnelle (définition de l'US) ? Conception technique (hypothèse d'ingénierie) ? Développement ? Tests ? Mise en production ? Pilotage (trop d'US en parallèle) ? Que cela nous apprend-t-il sur notre processus ? Qui doit apprendre quoi pour réussir ? Nous travaillons alors sur ces 2 US spécifiques car nous cherchons des éléments actionnables, des points de connaissance sur notre processus et nos fausses croyances.

De la même manière qu’on ne souhaite pas donner à l’équipe des indicateurs sur lesquels elle ne peut agir (des indicateurs d’Outcomes), en la faisant travailler sur des sujets spécifiques (et donc actionnables), on crée les conditions pour développer sa capacité d’agir. Si j'osais je dirais qu'on contribue ainsi à son ”empowerment”.

Cette réflexion peut de la même façon être appliquée au niveau supérieur dans le pilotage des Epics : on devait sortir 4 Epic ce mois-ci sur le Train et nous n'en avons sorti que deux : en raison de quel obstacle ? A quelle étape du processus ? D'une manière identique, en creusant ces sujets on va découvrir de nouveaux points de connaissance sur notre processus de conception fonctionnelle (amont) ou d'animation du Delivery.

Il s’agit probablement là de la vertu principale du pilotage de la valeur opérationnelle. Kent Beck l’évoque dans sa réponse à l’article de McKInsey lorsqu’il liste les raisons pour lesquelles suivre la productivité du développement est pertinent :

#4: a software engineer who wants to grow at their craft. The question could be: “How can I measure my own productivity, and which metrics can I improve to become a better engineer?” This is a question more engineers should ask of themselves!

Deux limites identifiées toutefois dans cette vision. Tout d’abord il s’agit encore de productivité personnelle. Ensuite il suggère un peu plus loin dans l'article de ne pas partager cet indicateur à son manager qui voudra alors suivre la performance opérationnelle, avançant qu’il est préférable de ne suivre que la performance business. Ce qui peut s’entendre pour des petites structures ou des équipes particulièrement matures (qui “please their customer at least once a week” - ce qui n’est malheureusement pas le sujet de la vaste majorité des équipes agiles que j’ai croisées), mais qui me semble contre-productif pour les grandes organisations ou des équipes moins matures.

Piloter la valeur business

Enfin, last not least, nous pouvons alors faire le Check sur la valeur business apportée par les Epics livrées : quel est le niveau de satisfaction des utilisatrices et utilisateurs ? Qu'aurait-il fallu pour qu'ils soient complètement satisfaites et satisfaits ? Avons nous validé les hypothèses business exprimées dans l'Epic (réduction de l’attrition des utilisateurs ; augmentation du nombre de nouveaux utilisateurs ; amélioration de la satisfaction client et de la note sur l’AppStore ...).

Si les réflexions dans la section précédente (analyse des US ou des Epics non sorties) avaient pour objectif une meilleure compréhension des processus internes, nous sommes ici dans la compréhension du marché. Mener ces réflexions avec les équipes produit et les équipes Delivery est un formidable gage de cohésion et d'alignement des équipes mais aussi d’intégration des processus de Discovery, de conception fonctionnelle et Delivery.

Suivre la productivité des programmes agiles

D'expérience, suivre la productivité des programmes agiles en pilotant les US et Epics terminées permet d'obtenir un bien meilleur alignement des équipes de Delivery ainsi que des résultats très significatifs (voir un exemple dans Culture Kaizen).

Cela permet aussi d'avoir un pilotage beaucoup plus simple. Laissons les Story Points (une estimation de la complexité sur une échelle de Fibonnacci - pas franchement un indicateur facilement appréhendable) aux jeunes équipes pour construire leur prédictabilité - elles s'en sépareront naturellement alors qu'elles gagnent en maturité -, mais ne l'utilisons pas comme indicateur, car cela ne fait pas de sens pour le client. Ensuite, ne mélangeons pas le pilotage de la valeur opérationnelle (processus de Delivery) avec celui de la valeur business (processus de Discovery) pour laisser aux équipes de développement une plus grande capacité d'agir.

Enfin, cette approche permet de repositionner le manager en rôle de coach en amélioration continue et développement des compétences, pour encourager les équipes à comprendre les écarts entre ce qu'elle avait prévu et ce qui s'est passé, à travers l'analyse approfondie de cas spécifiques et la mise en oeuvre d'expérimentations rapides.

Il ne s'agit pas d'une solution idéale (je ne suis pas certain qu'il en existe une) mais encourageant la collaboration à chaque niveau (équipe agile, ensemble d'équipes, programme) et optimisant la capacité d'agir des équipes, avec des indicateurs qui sont entièrement à leurs mains, elle crée les conditions de l'amélioration et du Kaizen.