Lors de notre dernière discussion, nous avons parlé de communication entre les cadres et les employés, de notions d’efficience ainsi que d’autres idées-clés d’amélioration continue.

Pour cette discussion, explorons ensemble l’idée de faire du bon boulot rapidement.

A : Vous avez dit à plusieurs reprises que quelque chose devait changer afin que le boulot soit réalisé plus rapidement. Une histoire de compétences et de d’autres trucs pour rendre le travail plus facile. C’est bien ça ?
B : Si et seulement si le goulot d’étranglement se trouve bien en phase de développement, alors cela devrait permettre de faciliter les choses

Il y a des choses intéressantes dans ce que dit A. En fait, les compétences, et les outils et le savoir-faire peuvent permettre de travailler plus vite. Un développeur avec une bonne connaissance de ses outils et de tas d’autres choses peut accomplir son travail en beaucoup moins de temps qu’un développeur ayant moins de connaissances.

Ceci est souvent confondu avec être un « développeur puissance 10 » mais il s’agit en fait d’un simple développeur entouré d’autres individus qui ne connaissent ni l’environnement technique, ni la base de code ni les outils. Si vous aimez les développeurs puissance 10, investissez en eux pour les aider à apprendre à aller plus vite. C’est ce qui est évoqué dans Modern Agile « Rendre les gens fantastiques », et dans le Manifeste Agile « Fournissez-leur l’environnement et le soutien dont ils ont besoin ».

Mais avançons …

A : D’accord. Supposons donc que le goulot d’étranglement se situe dans le développement ; Qu’est-ce que nous changeons ?
B : Toute chose qui rend difficile ou risquée de livrer du code opérationnel aujourd’hui.
A : Comment savons-nous ce qu’il en est, ou ce que nous devons faire à la place ?
B : En expérimentant. Certains changements apportent quelque chose, d’autres non.

Depuis que j’ai commencé cette série de blogs, j’ai fait une série d’ateliers au cours de laquelle j’ai demandé à l’équipe « qu’est-ce qui vous ralentit ? ». Il ne s’agit pas d’une question difficile à poser. Dans un environnement sain, les équipes sont heureuses de faire part des problèmes qu’elles rencontrent.

La plupart du temps, les équipes ne savent pas comment régler le problème, ou elles ne savent pas comment obtenir le temps et le soutien dont elles ont besoin (cf. les principes de Modern Agile (vo) et du Manifeste Agile à nouveau) pour régler le problème afin de pouvoir aller plus vite. Dans ce cas précis, un manager (vo) peut clairement faire la différence.

Soutenir les expérimentations ou tout autre type d’effort pour supprimer les goulots d’étranglements n’est non seulement pas une bonne pratique agile, ou une bonne manière de faire de l’empirisme ou du bon Modern Agile (« expérimenter et apprendre rapidement »), c’est du bon management et la bonne manière de travailler. Laisser les personnes s’engluer dans des problèmes qui les ralentissent tout en les exhortant à aller plus vite n’est pas ce qu’il faut faire. C’est mieux d’être efficace, non ?

A : Nous ne pouvons pas nous permettre de faire ça. Je vous déjà dit que notre calendrier était serré. Est-ce que nous pouvons faire simplement des choses qui marchent et ne pas perdre de temps ?
B : Si vous ne pouvez pas vous permettre d’expérimenter et d’apprendre, vous ne pourrez pas vous améliorer. Faites du mieux que vous pouvez avec votre vélocité actuelle. Triez le travail à faire par valeur. Réduisez le périmètre.

Si nous ne donnons pas les moyens d’apprendre et d’expérimenter, alors nous ne nous donnons pas les moyens d’aller plus vite. Point final.

Est-ce possible d’être vu en train d’apprendre et d’essayer des choses au travail ? Que se passe t’il si vous essayer quelque chose et que cela ne fonctionne pas ? Comment cela apparaît-il sur l’entretien annuel ?

Nous espérons qu’une approche expérimentale, informative, attentive du développement logiciel soit perçue comme quelque chose de positif de la part de l’organisation. Il est arrivé cependant que la vélocité soit récompensée et que le savoir-faire soit récompensé mais aucune concession ne doit être faite pour rendre possible l’acquisition de la vélocité et du savoir-faire. Sinon cela rend très difficile la perspective de pouvoir retenir des gens motivés.

A : Il nous est impossible de réduire le périmètre. Il nous est impossible de décaler la date cible. Il nous est impossible d’expérimenter. Qu’avez-vous d’autres à nous proposer ?
B : Échouer du mieux que vous pouvez. Faites du mieux que vous le pouvez, en partant du principe que vous allez échouer.

Le « meilleur échec possible » fait ici office d’objectif à atteindre pour un travail donné dans un temps déterminé. Nous découpons d’abord ce travail en tranches que nous affinons ensuite en fines tranches. Si nous essayons de traiter une poignée de ces fines tranches dans ce délai imparti, ordonnées par importance/priorité, alors lorsque le temps sera écoulé, nous nous apercevrons alors que nous n’avons pas tout terminé mais que nous aurons terminé et intégré les choses les plus importantes.

Le pire échec possible est d’avoir 100% du travail terminé à 90%. Rien n’est livrable ni utile. C’est un gâchis.

Avoir 90% du travail fait à 100% est un succès partiel. Ce n’est pas une réussite à 100%, mais c’est tout de même 90% des fonctionnalités utilisables, fonctionnelles, démontrables et vendables. Cela ne satisfait peut-être pas tout le monde, mais cela peut aider certaines personnes. Seule une partie de la valeur est livrée, et c’est tout de même vachement mieux que d’avoir zéro valeur.

Si vous ne pouvez pas aller plus vite, alors faites de votre mieux avec votre vitesse actuelle. Échouer aussi bien que possible.

A : C’est tout ?
B : Non. Rappelez-vous que le développement n’est peut-être pas le goulot d’étranglement.

Les organisations sont stupéfaites et vexées de découvrir que leur temps de traversée de 45 jours de mise à disposition jusqu’au marché ne puisse pas être amélioré (de beaucoup) en accélérant la phase de développement tout simplement parce que le développement n’est pas le premier consommateur de temps dans leur cas.

Dans certains cas, diviser le temps de développement par deux, lorsque cela est possible, donnera comme résultat 44 jours au lieu de 45. La majorité du temps consacré au développement logiciel se passe, en fait, à attendre dans différentes files d’attente.

  • Files d’attente d’approbation
  • Files d’attente de priorisation
  • Files d’attente de revue
  • Attendre que d’autres finissent d’abord
  • Attendre pour que le test soit fait
  • Attendre pour le code soit corrigé
  • Attendre jusqu’à ce que la crise actuelle sur l’exploitation soit terminée
  • Attendre qu’un expert réponde à une question ou qu’il soit disponible pour aller le voir

Et c’est encore plus pire qu’il n’y paraît car ces files d’attente se retrouvent intégrées dans des boucles.

  1. Le code attend que le développeur soit disponible, parce qu’il est occupé par quelque chose d’autre
  2. Les développeurs travaillent sur le code
  3. Le code attend une revue de code, parce que les re-lecteurs sont occupés
  4. Si la revue de code renvoie le code au développeur pour modifications, alors aller en 1
  5. Le code attend pour une compilation sur un serveur de test officiel, parce que les serveurs sont occupés
  6. Le code attend un testeur disponible, parce que les testeurs sont occupés
  7. Le testeur attend que le code soit compilé et installé sur un serveur de test officiel parce que le serveur vient tout juste d’être mis à disposition du testeur nouvellement disponible et doit être préparé
  8. Les testeurs testent le code
  9. Si des anomalies ou des améliorations à apporter sont trouvées, alors aller en 1
  10. Le code attend avec d’autres morceaux codes dans un lot prêt à être déployé
  11. Si un problème arrive pendant le déploiement, aller en 1 pour trouver ce qui ne va pas et procéder à une remédiation

Et s’il y a un changement intervient en 4, puis en 9, en 4 à nouveau, puis encore en 9, et encore en 9 à nouveau ? Quelle va être la durée de ces files d’attente ? Si, comme c’est souvent le cas, 95% ou plus de ce temps est passé à attendre alors développer deux fois plus vite vous conduira à une amélioration de 2,5% du délai de mise sur le marché 1. Pfiou. Pas très impressionnant, n’est-ce pas ?

Mais si vous êtes dans cette situation, alors ce sont de très bonnes nouvelles.

Vous n’avez pas besoin d’être un génie technique pour corriger les temps d’attente ou les files d’attente. Cela demande seulement quelqu’un avec des barrettes de responsables et un peu d’approche systémique.

Vous pouvez le faire. Vous pouvez faire la GROSSE différence en termes de délai de mise sur le marché.

Vous pouvez donner à vos employés l’environnement et le soutien dont ils ont besoin. Est-ce de la formation ? de l’information ? sur la théorie du management ? des ordinateurs plus rapides ? Leur apprendre à prévenir les anomalies ? (vo). Leur apprendre à utiliser leur compétence de développeurs plus efficacement ? Éliminer les silos (travailler ensemble plutôt que de s’attendre au travers des fils d’attente) ?

Vous pouvez changer le système. Vous êtes un responsable. Vous en avez les compétences et la lattitude (vo).

Et ça, ce n’est pas des bonnes nouvelles ?

Auteur : Tim Ottinger
Source : Q and A on velocity, Part X
Date de parution originale : 02 Septembre 2019

Traducteur : Nicolas Mereaux
Date de traduction : 07/03/2021

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

  1. ou time-to-market si vous préférez le terme anglophone ↩